SOFTWARE REQUIREMENTS

ENGINEERING

LECTURE 02: Requirements and Requirement Engineer

Qurat Ul Ain

1
 TODAY’S LECTURE: AGENDA

Requirement Engineer’s Role

Requirements Classification
Characteristics of Excellent Requirements

2
 REQUIREMENT ENGINEER’S ROLE

Gather, analyze, document, and validate the needs

of the project stakeholders.
Principal conduit through which requirements flow
between the customer community and the software
development team
A project role, not necessarily a job title.
May be a dedicated specialists or project manager, subject
matter expert (SME), developer, and even user.
Must have skills, knowledge, training. 3
ROLE OF REQUIREMENTS ENGINEER

Requirements
Engineer
 REQUIREMENT ENGINEER'S TASKS

 Define business requirements. 

 Help the business or funding sponsor, product manager, or
marketing manager define the project's business requirements.
 "Why are we undertaking this project?"
 Business requirements include a statement of the organization's
business objectives and the ultimate vision of what the system
will be and do.
 Suggest a template for a vision and scope document and work
with those who hold the vision to help them express it.

5
 REQUIREMENT ENGINEER'S TASKS

 Identify project stakeholders and user classes.  

 Select appropriate representatives for each user class, enlist
their participation, and negotiate their responsibilities.
 User representatives might hesitate until they know exactly
what you expect from them.
 Write down the contributions required from customer
collaborators and agree on an appropriate level of
participation from each one.

6
 REQUIREMENT ENGINEER'S TASKS

 Elicit requirements. 
 Interviews, Facilitate requirements workshops, Document analysis,
Surveys, Customer site visits, Business process analysis, Work flow
and task analysis, Event lists, Competitive product analysis,
 Users naturally emphasize the system's functional requirements, so
steer the discussions to include quality attributes, performance
goals, business rules, external interfaces, and constraints.

7
 REQUIREMENT ENGINEER'S TASKS

 Analyze requirements.  
 Look for
 derived requirements
 unstated requirements.

 Spot the vague, weak words that cause ambiguity.

 Point out
 conflicting requirements
 areas that need more detail.

8
 REQUIREMENT ENGINEER'S TASKS

Facilitate requirements prioritization.  

Collaboration and negotiation between the various user classes and
the developers to ensure that they make sensible priority decisions.
Requirements prioritization spreadsheet tool might be helpful.

9
10
 REQUIREMENT ENGINEER'S TASKS

Write requirements specifications.

 Shared understanding of a system that will address the customer's
problem.
 Specify the functional requirements at a level of detail suitable for use by
the developers who will implement them. This level of detail will vary
from project to project.
 A Web site being built incrementally by a small, well-synchronized team can
get away with limited requirements documentation. In contrast, a complex
embedded system that will be outsourced to an offshore supplier needs a
precise, detailed SRS.
• Using standard templates for use cases and the SRS accelerates
requirements development.
11
 REQUIREMENT ENGINEER'S TASKS

Model the requirements. 

 Determine when it is helpful to represent requirements using
methods other than text.
 Graphical analysis models, tables, mathematical equations, and
prototypes.
 Depict information at a higher level of abstraction than does
detailed text.
 To maximize communication and clarity, draw analysis models
according to the conventions of a standard modeling language.

12
REQUIREMENTS MODELS

13
 REQUIREMENT ENGINEER'S TASKS

Lead requirements validation.  

 Ensure that requirement statements possess all the desired
characteristics (that we discuss later in this lecture) and that a
system based on the requirements will satisfy user needs.
 Req. Engrs. are the central participants in peer reviews of
requirements documents.
 They should also review designs, code, and test cases that
were derived from the requirements specifications to ensure
that the requirements were interpreted correctly.
14
 REQUIREMENT ENGINEER'S TASKS

Manage requirements.  
A Requirements Engr. is involved throughout the entire
software development life cycle, so (s)he should help
create, review, and execute the project's requirements
management plan.
Storing the requirements in a requirements management
tool facilitates this ongoing management.

15
 REQUIREMENT ENGINEER'S TASKS

Requirements management includes tracking the status of

individual requirements as they progress from inception to
verification in the integrated product.
With input from various colleagues, the R. Engr. collects
traceability information that connects individual requirements
to other system elements.
Managing changes to the baseline requirements by using a
change-control process and tool.

16
 REQUIREMENTS CLASSIFICATION

During a systems development project,

 Requirements will be created that describe what the
business needs (business requirements)
 What the users need to do (user requirements)
 What the software should do ( functional requirements)
 Characteristics the system should have (nonfunctional
requirements)
 How the system should be built (system requirements)
17
During the analysis phase, requirements are written from the
perspective of the business, and they focus on what the system
needs to do in order to satisfy business user needs
A good starting place is to concentrate on what the user actually
needs to accomplish with the system in order to fulfill a needed
job or task. These user requirements describe tasks that the users
perform as an integral part of the business’ operations, such as:
“Schedule a client appointment”; “Place a new customer order”;
“Re-order inventory”; “Determine available credit”; and “Look
up account balances.”
By understanding what the user needs to do in terms of tasks to
perform, the analyst can then determine ways in which the new
system can support the users’ needs.

18
Determining ways in which the new system can support
user needs leads to statements of the system’s functional
requirements.
The International Institute of Business Analysis (IIBA)
defines functional requirements as “the product
capabilities, or things that a product must do for its users.”3
Functional requirements begin to define how the system
will support the user in completing a task

19
User requirements and functional requirements defined in
the analysis phase will flow into the design phase, where
they evolve to become more technical, describing how the
system will be implemented. Requirements in the design
phase reflect the developer’s perspective, and they usually
are called system requirements
These requirements focus on describing how to create the
software product that will be produced from the project.

20
The final category of requirements is nonfunctional
requirements
The IIBA defines this group of requirements as “the quality
attributes, design, and implementation constraints, and
external interfaces which a product must have

21
 FUNCTIONAL REQUIREMENTS

 Specify the software functionality that the developers must

build into the product to enable users to accomplish their
tasks, thereby satisfying the business requirements.
 Almost any action, e.g. calculate, inspect, publish, or most
other active verbs can be a functional requirement.
 Example:
 The user shall be able to search either the entire database of patients
or select a subset from it (admitted patients, or patients with asthma,
etc.)

22
 NFRS/QUALITY ATTRIBUTES

Non-Functional Requirements (NFR) include performance

goals and descriptions of quality attributes.
Quality attributes augment the description of the product's
functionality by describing the product's characteristics in
various dimensions that are important either to users or to
developers.
Characteristics that relate to the system as a whole
 usability, portability, efficiency, and robustness etc.

23
 EXAMPLES: NFRS
The system shall support up to 2000
simultaneous users against the central
database at any given time, and up to
500 simultaneous users against the
local server at any one time.
The system shall provide access to
a legacy course catalogue database
with no more than a 10 seconds
latency
24
 OTHER NON-FUNCTIONAL
REQUIREMENTS

Constraints that impose restrictions on the choices

available to the developer for design and
construction of the product.
Constraints do not affect the external behavior of the
system, but must be fulfilled to meet technical, business,
or contractual obligations.
Example: The system development process and
deliverable documents shall conform to the MIL-STD-
2167A
25
 “FURPS+” CLASSIFICATION OF
REQUIREMENTS

• Functional
• Non-Functional (NFRs)
• Usability
• The ease with which the system can be learned and operated by the intended users.
• Help, documentation, required training time, task times for typical tasks,
conformance to usability standards, etc.

• Reliability
• Allowed MTBF (Mean Time Between Failures)
• Recoverability, etc.

26
 FURPS+ CLASSIFICATION OF
REQUIREMENTS

 Performance
 Response time, throughput, …
 Average, maximum response time for a transaction
 Number of customers/transactions the system can
accommodate
 Example:
 Buyers want to complete sales processing very quickly.
One bottleneck is external payment authorization. Our goal:
authorization in less than 1 minute, 90% of the time.
 Supportability:
 Supportability is the ability of the software to be easily
modified to accommodate enhancements and repairs 27
 FURPS+ CLASSIFICATION C O N T.

+ indicates additional constraints such as:

 Design Constraints
 E.g. requiring a relational database
 Interface constraints
 i.e. protocols for interaction with external systems
 Implementation Constraints
 Required platform, implementation language
 Physical constraints
 Hardware devices
28
 FURPS+ CLASSIFICATION EXAMPLES

• "The persistence will be handled by a relational database" FURPS+

Type?
• “+” design constraint.

• "The database will be Oracle 8i" FURPS+ Type?

• “+” implementation constraint.

• "The system will run seven days a week, twenty-four hours per day"
FURPS+ Type?
• “R” reliability requirement.
29
 NFR CLASSIFICATION

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 30
 NON-FUNCTIONAL REQUIREMENTS

Availability  
 Availability is a measure of the planned up time during
which the system is actually available for use and fully
operational.
 More formally, availability equals the mean time to failure
(MTTF) for the system divided by the sum of the MTTF
and the mean time to repair the system after a failure is
encountered.
 Scheduled maintenance periods also affect availability.
 Some authors view availability as encompassing reliability,
maintainability, and integrity.

31
 NON-FUNCTIONAL REQUIREMENTS

Efficiency  
Efficiency is a measure of how well the system utilizes
processor capacity, disk space, memory, or communication
bandwidth.
Efficiency is related to performance, another class of
nonfunctional requirement.
If a system consumes too much of the available resources,
users will encounter degraded performance, a visible
indication of inefficiency.
32
 NON-FUNCTIONAL REQUIREMENTS

Flexibility  
Flexibility measures how easy it is to add new capabilities to the
product.
If developers anticipate making many enhancements, they can
choose design approaches that maximize the software's flexibility.
This attribute is essential for products that are developed in an
incremental or iterative fashion through a series of successive
releases or by evolutionary prototyping.

33
 NON-FUNCTIONAL REQUIREMENTS

Interoperability  
Interoperability indicates how easily the system can
exchange data or services with other systems.

34
 NON-FUNCTIONAL REQUIREMENTS

Reliability  
The probability of the software executing without failure
for a specific period of time is known as reliability.
Ways to measure software reliability include the
percentage of operations that are completed correctly and
the average length of time the system runs before failing.

35
 NON-FUNCTIONAL REQUIREMENTS

Robustness  
Robustness, sometimes called fault tolerance, is the degree to which a
system continues to function properly when confronted with invalid
inputs, defects in connected software or hardware components, or
unexpected operating conditions.
Robust software recovers gracefully from problem situations and is
forgiving of user mistakes.
When eliciting robustness requirements, ask users about error
conditions the system might encounter and how the system should react.

36
 NON-FUNCTIONAL REQUIREMENTS

Usability  
Also referred to as ease of use and human engineering,
usability addresses the myriad factors that constitute what
users often describe as user-friendliness.
Software designed for effective and unobtrusive usage.
Usability measures the effort required to prepare input for,
operate, and interpret the output of the product.

37
 NON-FUNCTIONAL REQUIREMENTS

Integrity

No Change in data

38
 NON-FUNCTIONAL REQUIREMENTS

Maintainability  
Maintainability indicates how easy it is to correct a defect
or modify the software.
Maintainability depends on how easily the software can be
understood, changed, and tested.

39
ATTRIBUTE TRADE-OFFS

40
 ORIGIN OF THE REQUIREMENTS
MISINTERPRETATIONS

Meyer’s Seven Sins of Specifier

The presence in the text of an element that does not carry information relevant to
Noise any feature of the problem.

The existence of a feature of the problem that is not covered by any element of the
Silence text.

The presence in the text of an element that corresponds for to a feature of the
Over-specification problem but to features of a possible solution.

The presence in the text of two or more elements that define a feature of the system
Contradiction in an incompatible way.

The presence in the text of an element that makes it possible to interpret a feature of
Ambiguity the problem in at least two different ways.

The presence in the text of an element that uses features of the problem not defined
Forward Reference until later in the text.

The presence in the text of an element that defines a feature of the problem in such
a way that a candidate solution cannot realistically be validated with respect
Wishful Thinking to this feature.
 CHARACTERISTICS OF INDIVIDUAL
REQUIREMENT STATEMENTS

Complete
Correct
Feasible
Necessary
Prioritized
Unambiguous
Verifiable
Realistic
42
 COMPLETE

Each requirement must fully describe the functionality to

be delivered.
It must contain all the information necessary for the
developer to design and implement that bit of functionality.
If you know you're lacking certain information, use TBD
(to be determined) as a standard flag to highlight these
gaps.
Resolve all TBDs in each portion of the requirements
before you proceed with construction of that portion.
43
 CORRECT

Each requirement must accurately describe the

functionality to be delivered.
The reference for correctness is the source of the
requirement, e.g.
an actual client
a higher level system requirements specification.

44
 FEASIBLE

It must be possible to implement each requirement within

the known capabilities and limitations of the system and its
environment.
To avoid infeasible requirements, have a developer or
marketing personnel work with the requirements analysts
throughout the elicitation process.
Incremental development approaches and proof-of-concept
prototypes are ways to evaluate requirement feasibility.

45
 NECESSARY

Each requirement originates from a source you recognize

as having the authority to specify requirements.
Trace each requirement back to its origin,

46
 PRIORITIZED

Assign an implementation priority to each functional

requirement, feature, or use case to indicate how essential it
is to a particular product release.
If all the requirements are considered equally important,
it's hard for the project manager to respond to
budget cuts
schedule overruns
personnel losses
new requirements added during development.
47
 UNAMBIGUOUS

The reader of a requirement statement should be

able to draw only one interpretation of it.
 Natural language is highly prone to ambiguity
 Effective ways to reveal ambiguity include:

 formal inspections of the requirements

specifications,
writing test cases from requirements
 creating user scenarios that illustrate the
expected behavior of a specific portion of the
product.
 VERIFIABLE

See whether you can devise tests or use other verification

approaches, such as inspection or formal specification, to
determine whether each requirement is properly
implemented in the product.
Requirements that are in-feasible, or ambiguous are also
not verifiable.

49
 EXAMPLE: VERIFIABLE NFR

An operator shall not have to wait for the transaction to

complete… change to measureable
An operator shall not have to wait more than 1s for a
transaction to complete for at least 95% of the
transactions.
Interesting phenomenon: What gets measured gets done.

50
 REALISTIC

Should be realistically possible to implement

51
 CHARACTERISTICS OF REQUIREMENT
SPECIFICATION (SRS)

Complete
Consistent
Modifiable
Traceable
Noiseless
Free of Over-specification
Ranked for importance and/or stability
 COMPLETE SRS

No requirements or necessary information should be

absent.
Missing requirements are hard to spot because they aren't
there!
 CONSISTENT SRS

• Consistent requirements do not conflict with other software

requirements or with higher level (system or business)
requirements.
“Doors must always be kept closed between platforms”
and “Doors must be opened in case of emergency stop”
• Inconsistencies can slip in undetected if you review only the
specific change and not any related requirements.
• Recording the originator of each requirement lets you know who to
talk to if you discover conflicts.
 MODIFIABLE SRS

 You must be able to revise the SRS when necessary and to

maintain a history of changes made to each requirement.
 Each requirement be uniquely labeled and expressed
separately from other requirements so you can refer to it
unambiguously.
 Related requirements are grouped together.
 Each requirement should appear only once in the SRS.
 Create a table of contents, index, traceability matrices
 TRACEABLE SRS

A traceable requirement can be linked backward to its origin and

forward to the design elements and source code that implement it
and to the test cases that verify the implementation as correct.
Traceable requirements are uniquely labeled and are written in a
structured, fine-grained way, as opposed to large, narrative
paragraphs.
 NOISELESS SRS

Noise is an SRS item yielding no information on

any problem world feature
Example: “Non-smoking signs posted on train windows”
 OVERSPECIFICATION-FREE SRS

Overspecification is an SRS item stating a feature

not in the problem world, but in the machine
solution.
Example:
 “The setAlarm method shall be invoked on
receipt of an Alarm message”
 RANKED FOR IMPORTANCE AND/OR
STABILITY

Requirements should be ranked according to importance

and change