REQUIREMENTS ANALYSIS

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 1

Functional and non-functional requirements


Functional requirements
• Statements of services the system should provide, how the system
should react to particular inputs and how the system should behave
in particular situations.


Non-functional requirements
• constraints on the services or functions offered by the system such
as timing constraints, constraints on the development process,
standards, etc.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 2

Functional requirements

Describe functionality or system services

Depend on the type of software, expected users and
the type of system where the software is used

Functional user requirements may be high-level
statements of what the system should do but
functional system requirements should describe the
system services in detail

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 3

Examples of functional requirements

The user shall be able to search either all of the
initial set of databases or select a subset from it.

The system shall provide appropriate viewers for the
user to read documents in the document store.

Every order shall be allocated a unique identifier
(ORDER_ID) which the user shall be able to copy to
the account’s permanent storage area.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 4

Requirements imprecision

Problems arise when requirements are not precisely
stated

Ambiguous requirements may be interpreted in
different ways by developers and users

Consider the term ‘appropriate viewers’
• User intention - special purpose viewer for each different document
type
• Developer interpretation - Provide a text viewer that shows the
contents of the document

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 5

Requirements completeness and
consistency

In principle requirements should be both complete
and consistent

Complete
• They should include descriptions of all facilities required

Consistent
• There should be no conflicts or contradictions in the descriptions of
the system facilities

In practice, it is impossible to produce a complete
and consistent requirements document

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 6

Non-functional requirements

Define system properties and constraints e.g.
reliability, response time and storage requirements.
Constraints are I/O device capability, system
representations, etc.

Process requirements may also be specified
mandating a particular CASE system, programming
language or development method

Non-functional requirements may be more critical
than functional requirements. If these are not met,
the system is useless

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 7

Non-functional classifications

Product requirements
• Requirements which specify that the delivered product must behave
in a particular way e.g. execution speed, reliability, etc.

Organisational requirements
• Requirements which are a consequence of organisational policies
and procedures e.g. process standards used, implementation
requirements, etc.

External requirements
• Requirements which arise from factors which are external to the
system and its development process e.g. interoperability
requirements, legislative requirements, etc.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 8

Non-functional requirement types
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

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 9

Goals and requirements

Non-functional requirements may be very difficult to
state precisely and imprecise requirements may be
difficult to verify.

Goal
• A general intention of the user such as ease of use

Verifiable non-functional requirement
• A statement using some measure that can be objectively tested

Goals are helpful to developers as they convey the
intentions of the system users

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 10

Examples

A system goal
• The system should be easy to use by experienced controllers and
should be organised in such a way that user errors are minimised.

A verifiable non-functional requirement
• Experienced controllers shall be able to use all the system functions
after a total of two hours training. After this training, the average
number of errors made by experienced users shall not exceed two
per day.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 11

Requirements Baselines

Software developers often want to freeze the
requirements following some initial requirements
work and then proceed with development. This is the
classic waterfall paradigm. It doesn’t work well in
most situations. It’s far more realistic to define a
requirements baseline and then manage changes to
that baseline.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 12

Baseline Defined

The term baseline comes from the domain of
configuration management. The IEEE Standard
Glossary of Software Engineering Terminology
defines a baseline as:

A specification or product that has been formally
reviewed and agreed on, that thereafter serves as
the basis for further development, and that can
be changed only through formal change control
procedures.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 13


A baseline is given a unique name so that the project participants can refer
to it unambiguously. Good configuration management practices allow the
team to reconstruct accurately any previous baseline and all its components.

A requirements baseline is a snapshot in time that represents the agreed-
upon, reviewed, and approved set of requirements committed to a specific
product release. That “release” could be a complete delivered product or any
interim development increment of the product. When stakeholders “sign off”
on requirements, what they’re really doing is agreeing and committing to a
specific requirements baseline (whether they think of it in those terms or
not).

Once the project team establishes a requirements baseline, the team should
follow a pragmatic change control process to make good business and
technical decisions about adding newly requested functionality and altering
or deleting existing requirements. Change control is not about stifling
change. It’s about providing decision makers with the information that will let
them make timely and appropriate decisions to modify the planned
functionality. That planned functionality is the baseline .
When to Baseline

Formal change control begins

Project managers determine the staffing levels
and budgets needed.

Project managers determine the staffing levels
and budgets needed.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 15

Factors to Consider Before
Defining a Requirements Baseline

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 16

Interfaces See if functionality has been defined to handle all identified
external interfaces to users, other software systems, hardware
components, and communications services.

Model Validation Examine any analysis models with the user representatives,
perhaps by walking through test cases, to see if a system based on
those models would let the users perform their necessary activities.

Prototypes If you created any prototypes, did appropriate customers evaluate

them? Did the BA use the knowledge gained to revise the SRS?

Alignment Check to see if the defined set of requirements would likely achieve
the project’s business objectives. Look for alignment between the
business requirements, user requirements, and functional
requirements.

Reviews Have several downstream consumers of the requirements review

them. These consumers include designers, programmers, testers,
documentation and help writers, human factors specialists, and
anyone else who will base their own work on the requirements.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 17
Scope Confirm that all requirements being considered for the
baseline lie within the project scope as it is currently
defined. The scope might have changed since it was
originally defined early in the project.

TBDs Scan the documents for TBDs (details yet to be determined).

The TBDs represent requirements development work remaining
to be done.

Templates Make sure that each section of the SRS template has been
populated. Alternatively, look for an indication that certain
sections do not apply to this project. Common oversights are
quality requirements, constraints, and assumptions.

User Classes See whether you’ve received input from appropriate

representatives of all the user classes you’ve identified for the
product.

Verifiability Determine how you would judge whether each requirement was
properly implemented. User acceptance criteria are helpful for
this.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 18
 Identification of
Performance and
Safety Requirements
 Requirement Analysis:
“What” and “How”
• What is it?
 The process by which customer needs are
understood and documented.
 Expresses “what” is to be built and NOT
“how” it is to be built.

 Example 1:
 The system shall allow users to withdraw cash.
 [What2:?]
Example
 A sale item’s name and other attributes will be
stored in a hash table and updated each time
any attribute changes. [How?]

22
C- and D-Requirements

 C-: Customer wants and needs;

expressed in language understood
by the customer.
 D-: For the developers; may be more
formal.

23
• Performance. Provision is made for specific
performance requirements to be specified in
conjunction with associated functional requirements,
but not all performance requirements can necessarily
be specified conveniently in that way. (Note that there
may also be specific functional requirements for
performance monitoring and tuning facilities:
Performance Requirements:
• The extent to which mission/function must be executed.
• Generally measured in terms of Quantity, Quality,
Coverage, Timeliness or Readiness i.e, Speed, accuracy,
frequency, throughput.
• How well it has to be done.
• Will be done interactively developed across all identified
functions based on system life cycle factors.
• Characterized by degree of certainty in their estimate,
degree of criticality to system success and their relation
to other requirements.
How to do it?
 Requirements analysis
 Stakeholder identification
Stakeholders are persons or organizations
(legal entities such as companies, standards
bodies) which have a valid interest in the
system.
Other stakeholders will include:
• anyone who operates the system (normal
and maintenance operators)
• organizations which regulate aspects of the
system
• anyone who benefits from the system.
• people or organizations opposed to the system
Stakeholder interviews:
Stakeholder interviews are a common technique used in
requirement analysis. These interviews may reveal
requirements not previously envisaged as being
within the scope of the project, and requirements
may be contradictory.
Contract-style requirement lists:
One traditional way of documenting requirements has
been contract style requirement lists. In a complex
system such requirements lists can run to hundreds of
pages.
Measurable goals:
Stakeholders and developers can then devise tests to
measure what level of each goal has been achieved thus
far. Once a small set of critical, measured goals has been
established, rapid prototyping and short iterative
development phases may proceed to deliver actual
stakeholder value long before the project is half over.
Prototypes:
Prototypes help users get an idea of what the system will
look like, and make it easier for users to make design
decisions without waiting for the system to be built.
Major improvements in communication between users
and developers were often seen with the introduction of
prototypes.