Software Requirements and the

Requirements Engineering Process

PD & SQL BI – Intake 44

10/28/2023
 It is the descriptions of
It is about WHAT not Nothing can be said the services provided by
What is a HOW obvious a system and its
operational constraints

requirement? It may range from a high

It may serve as the basis
level abstract statement It may be as complex as
for a bid for a contract or
to a detailed a 500 pages of
the basis for the contract
mathematical description
itself
specification
What is requirements engineering?

It is the process of discovering, analyzing, Each software development process goes

documenting and validating the through the phase of requirements
requirements of the system engineering
 Why requirements?

What are the advantages of a complete Changes in requirements are expensive.

set of documented requirements? Changing the requirements costs:
Ensures the user (not the developer) drives system 3 x as much during the design phase
functionalities 5-10 x as much during implementation
Helps avoiding confusion and arguments 10-100 x as much after release [Code Complete, p30]
Helps minimizing the changes
Why requirements?

◼ 2/3 of finished system errors are

requirements and design errors A
careful requirements process doesn’t
mean there will be no changes later
◼ Average project experiences
about 25% changes in the
requirements
◼ This accounts for 70-80% if the
rework of the project Important
to plan for requirements changes
Different levels of abstraction

System requirements (abstract

User requirements (abstract +)
-)
• Usually the first attempt for • Services and constraints of
the description of the the system in detail
requirements • Useful for the design and
• Services and constraints of development
the system • Precise and cover all cases
• In natural language or • Structured presentation
diagrams
• Readable by everybody
• Serve business objectives
Example

User requirement: A user found a new job announcement,I wants to add a new
position to the website so s/he can start working on doing the initial research and
apply to it

System requirement: A registered user on the academic jobs website should be able to
add a new position listing with the name of the school and academic unit, date of
posting, date of expiry, application deadline, and contact and application details. The
interaction fails if: the position is already listed, the application deadline is in the past,
position announcement is expired, or the contact information is missing. If fails, point
mistakes to user and ask the user to fix and resubmit.
 Types of requirements

Non-functional requirements Domain requirements Note: You can have user/system

Functional requirements functional/non-functional
requirements.
Constraints on the services or functions From the application domain of the
Services the system should provide offered by the system system
What the system should do or not in Examples: Timing constraints, constraints May be functional or non-functional
reaction to particular situations on the development process (CASE, Examples: Medicine, library, physics,
language, development method…), chemistry
standards etc
 First attempt to describe functional and non-
functional requirements
• Understandable by the user

User Problems:

requirements • Lack of clarity - ambiguous language

• Requirements confusion - functional, non-functional
requirements, design information are not distinguished
• Requirements amalgamation – several requirements are
defined as a single one
• Incompleteness – requirements may be missing
• Inconsistency – requirements may contradict themselves
 ◼ Guideline to minimize the issues:
◼ Separate requirements – separate the
requirements, separate functional and non-
functional requirements, requirements must be
clearly identified (e.g. by a number)
◼ Include a rationale for each requirement – helps
clarify reasoning behind the requirements and
may be useful for evaluating potential changes in
the requirements
◼ Invent or use a standard form/template

User ◼ Distinguish requirements priorities

◼ Example: MoSCoW (Must, Shall, Could,

requirements Want/Will (no TBD))

◼ Avoid technical jargon

◼ Testable (write test cases)

◼ Deliverables
 ◼ Elaborate the user requirements to get a precise, detailed and complete
version of them
◼ Used by designers and developers
◼ An important aspect is how to present/write system requirements
◼ Natural language is often used!
◼ The difference between user and system requirements must not be
thought as a detail

System
requirements
 ◼ Example: If sales for current month are below target sales, then
report is to be printed unless difference between target sales and
actual sales is less than half of difference between target sales and
actual sales in previous month, or if difference between target sales
and actual sales for the current month is less than 5%.
◼ Problems:
◼ Difficult to read
◼ Ambiguity: sales and actual sales, 5% of what?

System
◼ Incomplete: what if sales are above target sales?

requirements
 Natural language (informal requirements)
• Reviled by academics
• But widely practiced: everybody can read them, finding a
better notation is hard

Writing Structured natural language

system • Forms/templates are used to bring some rigor to natural
language presentations
requirements Graphical notations
• Using boxes, arrows… but they mean different things to
different people

Formal specification
• Based on logic, state machines…
• Hard to understand for many people
 Product behavior

Product requirements

Ex: Timing, performance,

memory, reliability,
portability, usability

Non- Policies and procedures in the

customer’s and developer’s

functional They can be further

categorized into:
Organizational requirements
organizations

requirements Example: Process

requirements,
implementation
requirements, delivery
Non-functional requirements requirements
may be more critical than
functional requirements. (The
system may be useless…)
Factors externals to the
system and the development
process

External requirements

Example: Interoperability,
legislation, ethics
 Non-functional requirements
Non-functional
requir ements

Product Or ganizational External

requir ements requir ements requirements

Ef ficiency Reliability Portability Interoperability Ethical

requir ements requir ements requirements requirements requirements

Usability Delivery Implementation Standards Legislative

requirements requirements requir ements requirements requirements

Performance Space Privacy Safety

requirements requir ements requirements requirements
 The academic
job website
requirements • Very readable
document • Some ambiguities
(Available on
the website)
Requirements
documents
• Microsoft template. Karl E.
Wiegers. Software
Examples of Requirements. Windows Press.
templates: • Volere template
• http://www.volere.co.uk
 ◼ 5 important activities:
◼ Feasibility study
Requirement ◼ Requirements elicitation and analysis
engineering ◼

◼
Requirements documentation
Requirements validation
◼ Requirements management
 Requirement engineering
Feasibility Requirements
study elicitation and
analysis
Requirements
specification
Feasibility Requirements
report validation
System
models
User and system
requirements

Requirements
document
 ◼ It is done at first to decide whether or not
the project is worthwhile
Feasibility ◼ Look at different perspectives:
◼ Market analysis, financial, schedule, technical,
study resource, legal…
◼ Should make you aware of the risks
 ◼ Doing the study
◼ Consult information sources: managers,
software engineers, end users…
Feasibility ◼ Based on information collection (interviews,
study surveys, questionnaires…)
◼ Should be short (2-3 weeks)
 ◼ What if the system wasn’t implemented?
◼ What are current process problems?
◼ Do technical resources exist?
◼ What is the risk associated with the
technology?
◼ Is new technology needed? What skills?
Feasibility study ◼ How will the proposed project help?
◼ How does the proposed project
contribute to the overall objectives of the
organization?
◼ Have the benefits identified with the
system being identified clearly?
 ◼ What will be the integration
problems?
◼ What facilities must be supported by
the system?
◼ What is the risk associated with cost
and schedule?
Feasibility study ◼ What are the potential
disadvantages/advantages?
◼ Are there legal issues?
◼ Are there issues linked with the fact
that this is an offshore project?
◼ …