Download Fast-changing technology and increased competition are placing

SOFTWARE
REQUIREMENTS
These slides are prepared by Enas Naffar to be used in Software requirements course - Philadelphia university
based on the material of "Requirements Engineering" textbook
1
Chapter 1
Requirements
Analysis
Design
Implementation
Testing
Operation &
maintenance
2
I need a
system
that …
What is a Software
Requirement?
Software capability needed by the user to solve a problem
to achieve an objective [Dorfman]
System Requirements define what the system is required to
do and the constraints under which it is required to operate
[Sommerville]
Software capability that must be met or possessed by a
system…to satisfy a contract, standard, specification, or
other formally imposed documentation [Dorfman]
(1) A characteristic that a system or software item is
required to possess in order to be acceptable to the
acquirer. (2) A binding statement… Requirements are
expressed using the word “shall”. [IEEE/EIA J-STD-016]
INTRODUCTION TO REQUIREMENTS
• Fast-changing technology and increased competition
are placing ever increasing
development process.
pressure
on
the
• Requirements are the basis for every project,
4
defining what the stakeholders –users, customers,
suppliers, developers, businesses – in a potential
new system need from it and also what the system
must do in order to satisfy that need.
INTRODUCTION TO REQUIREMENTS
• Once
•
5
•
communicated and agreed, requirements
drive the project activity.
Agreed requirements provide the basis for
planning the development of a system and
accepting it on completion.
They are essential when sensible and informed
tradeoffs have to be made and they are also vital
when changes are requested during the
development process.
INTRODUCTION TO REQUIREMENTS
Requirements form the basis for:
6
• Project planning
• Risk management
• Acceptance testing
• Change control
INTRODUCTION TO REQUIREMENTS
What reasons could cause a project to fail?
 Incomplete requirements 13.1%
 Lack of user involvement 12.4%
Lack of resources 10.6%
 Unrealistic expectations 9.9%
Lack of executive support 9.3%
 Changing requirements/specification 8.7%
Lack of planning 8.1%
7
 Didn’t need it any longer 7.5%
INTRODUCTION TO REQUIREMENTS
Project success factors
 User involvement 15.9%
 Management support 13.9%
 Clear statement of requirements 13.0%
 Proper planning 9.6%
 Realistic expectations 8.2%
 Smaller milestones 7.7%
 Competent staff 7.2%
8
 Ownership 5.3%
INTRODUCTION TO SYSTEMS
ENGINEERING
What then do we mean by a “system”?
A system is a:
• collection of components – machine, software and human –
• which cooperate in an organized way –
• to achieve some desired result – the requirements.
9
To understand the requirements of a system properly,
we should understand its enclosing system.
INTRODUCTION TO SYSTEMS
ENGINEERING
10
Consider a railway system. What are
the components of this system?
11
INTRODUCTION TO SYSTEMS
ENGINEERING
INTRODUCTION TO SYSTEMS
ENGINEERING
• The engineering of requirements must take the
nature of systems into account.
12
• Essential considerations are emergent properties,
the constraints and provisions of the external
environment and the interfaces with surrounding
systems.
REQUIREMENTS AND QUALITY
13
Quality is “fitness for purpose” or conformance to
requirements – it is providing something that
satisfies the customer and in doing so ensures
that the needs of all the stakeholders are taken into
account.
REQUIREMENTS AND QUALITY
• Goal
of software development is to develop
quality software–on time and on budget–that
meets customer’s real needs
• Project
success
depends
requirements management
on
effective
• Requirements error are the most common type of
systems development errors and the most costly
to fix
•A
14
few key skills can significantly reduce
requirements errors and thus improve software
quality
REQUIREMENTS AND QUALITY
• There
are lots of evidences around us of
systems that failed because requirements were
not properly organized.
• Even
if the system works, it is useless if it
doesn’t meet users’ requirements.
• Improving
15
requirements means improving the
quality of the product.
REQUIREMENTS AND THE
LIFECYCLE
There is a common misconception that requirements
engineering is just a single phase that is carried out
and completed at the outset of product development.
Requirements engineering has a vital role to play at
every stage of development.
16
As an initial approach, consider one of the very last
activities in the development process: acceptance
testing. What is a system accepted against? – the
stakeholder requirements.
REQUIREMENTS AND THE
LIFECYCLE
17
The classic V-model, which is used to depict the various
stages of development, has its basis in this relationship
between testing and requirements
REQUIREMENTS AND THE
LIFECYCLE
• Without effective requirements engineering,
development projects are like ships drifting
rudderless in a storm!
• Above all else, with good requirements
management, hearing the voice of the users and
customers becomes a matter of clear lines of
communication throughout the development
process.
REQUIREMENTS AND THE
LIFECYCLE
Another role that requirements can play in an
organization is to act as a means of communicating
between projects.
This is a good idea, because many organizations wish to:
• maximize reuse of artifacts across projects;
• manage families of similar products;
• optimize process by learning from the experiences of other
projects;
REQUIREMENTS AND THE
LIFECYCLE
• A good set of stakeholder requirements can
provide a concise, non-technical description of
what is being developed at a level that is
accessible to senior management.
• Similarly, the system requirements can form an
excellent technical summary of a development
project.
REQUIREMENTS AND THE
LIFECYCLE
• If requirements are to play such a central role in
systems development, they need to be
maintained.
• To change the design of a product without
having also updated the requirements to reflect
that change is to store up huge problems for
later stages of development.
• Hence requirements engineering connects
strongly with change management.
REQUIREMENTS AND THE
LIFECYCLE
The impact of that change on quality, cost and
schedule needs to be assessed.
This assessment forms the basis on which to:
• accept or reject the change (where that is a
choice);
• negotiate the cost of the change with the
customer/suppliers;
• organize the redevelopment work.
REQUIREMENTS TRACEABILITY
In the requirements engineering context, traceability is
about understanding how high-level requirements –
objectives, goals, aims, aspirations, expectations,
needs – are transformed into low-level requirements.
REQUIREMENTS TRACEABILITY
In a business context, one may be interested in how
• business vision is interpreted as business objectives
are implemented as business organization and
processes.
24
In an engineering context, the interest may focus on
how
• stakeholder requirements are met by system
requirements are partitioned into subsystems are
implemented as components.
REQUIREMENTS TRACEABILITY
Using traceability can contribute to the following
benefits:
25
• Greater confidence in meeting objectives.
• Ability to assess the impact of change.
• Ability to track progress.
• Ability to balance cost against benefit.
REQUIREMENTS TRACEABILITY
26
Traceability relationships
are usually many-to-many –
that is, one lower level
requirement may be linked
to several higher level
requirements and vice
versa.
REQUIREMENTS TRACEABILITY
• Requirements management tools typically allow
such
linking
by
drag-and-drop
between
paragraphs of documents.
27
• The links are rather like hyperlinks in web pages,
but should ideally be traversable in either
direction.
28
REQUIREMENTS AND
MODELLING
The systems engineering sandwich.
REQUIREMENTS AND MODELLING
• They are mutually supportive activities that should
not be equated.
• The requirements themselves are a complete
snapshot of what is required at each level in
increasing levels of detail.
• A particular model never says everything about a
system – if it did, it would not be a model.
REQUIREMENTS AND MODELLING
Models assist the requirements engineer in analyzing
the requirements at a particular level so as to:
• Communicate with the customer and improve
mutual understanding of the system to be developed;
• Analyze the system to ascertain the presence of
desired emergent properties (and the absence of
undesirable ones);
• Determine how to satisfy the requirements by
deriving new requirements at the layer below.
REQUIREMENTS AND TESTING
• Testing is any activity that allows defects in the
system to be detected or prevented, where a defect is a
departure from requirements.
• Testing is closely related to requirements at every
level.
Requirements and Testing
• Testing activities include reviews, inspections,
analysis through modeling in addition to the classical
tests of components, subsystem and systems that are
carried out.
• Qualification should begin as early as possible, since
waiting until the system is almost complete before
carrying out any kind of testing can lead to very
expensive design changes and rebuilds.
33
REQUIREMENTS IN THE PROBLEM
AND SOLUTION DOMAINS
REQUIREMENTS IN THE PROBLEM
AND SOLUTION DOMAINS
Needs
– in user
terms
Problem Domain
Features – a
service provided
by the system
that fulfills a need
Software requirements
– more specific
Solution Domain
34
REQUIREMENTS IN THE PROBLEM
AND SOLUTION DOMAINS
Consider an online bookstore to compete with Amazon.
Example of a feature:
Click Ordering
Examples of requirements related to this feature:
User shall be able to activate 1-click ordering within his account
User shall be able to deactivate 1-click ordering within his account
User shall be able to order books with just 1 click
…
User shall be able to “Undo” his 1-click order for a period of 30 minutes
from the time he placed such an order
35
REQUIREMENTS IN THE PROBLEM
AND SOLUTION DOMAINS
Without a clear distinction between problem and
solution, the following may result:
• lack of understanding of the real problem;
• inability to scope the system and understand which
functions to include;
• domination of debate about the system by the
developers and suppliers, because the only
descriptions of the system are expressed in terms of
solutions;
36
• inability to find optimal solutions due to lack of
design freedom.