5 Requirements Engineering

2005 IAS, Universitt Stuttgart 1
SER
5 Requirements Engineering
Software Engineering for Real-Time Systems
5.1 What are requirements?
5.2 Requirements Engineering
5.3 Specifying Requirements
5.4 Requirements Tracing
5.5 Summary
SER 5.1 What are requirements?
Poor Requirements Management Puts Projects at Risk
for Failure
Source: Standish Group 2000
success
26%
late or over
budget
46%
cancelled
28%
SER
Out of control
unclear requirements
changing requirements
unstable baselines
ad hoc requirements
management
big gaps between customer
expectations and actual
product contents
Poor estimates
planning out of reach
insufficient resources
Why Improving on Requirements Management?
Inadequate management
no commitments
volatile or missing
decisions
plans not followed through
subcontracting just
happens
40..60% of all faults
start out from
requirements
SER
What are Requirements ?
ambiguous
not accomplishable
over-determined
incomplete
inconsistent
List of wishes:
- a bicycle like Joe
- a round ball
- a fast car
- watching the Simpsons
- a veteran car
List of wishes:
- a bicycle like Joe
- a round ball
- a fast car
- watching the Simpsons
- a veteran car
Requirements
typically are:
Terminology
A requirement is
A condition or capability needed by a user to solve a problem or achieve
an objective.
A condition or capability that must be met or possessed by a product or
product component to satisfy a contract, standard, specification, or other
formally imposed documents.
Requirements management is a systematic approach to
Eliciting, organizing, and documenting all the requirements (functional,
non-functional, non-technical) of the system, and
Establishing and maintaining agreement between the customer/user and
the project team on the changing requirements of the system
Source: IEEE 610.12-1990
Viewpoints on Requirements
Description of an attribute
Description of a functionality
Description of a constraint
The sum of all requirements defines the
scope of the product
Described in a way to allow validating whether
the requirement is actually realized.
functional requirement
Test cases
The requirements description determines, what a product
should be able to do and what it looks like,
NOT : how it is realized.
nonfunctional requirement
Characteristics of requirements (1)
Unambiguous -- Every statement has one interpretation. Terms are clear
and well defined.
Complete -- All significant requirements are included. No items have been
left for future definition.
Verifiable -- All features specified as part of the project have a
corresponding test to determine whether they have been successfully
delivered.
Consistent -- Conflicting terminology, contradictory required actions, and
impossible combinations are notably absent.
Modifiable -- Redundancy is absent; index and contents are correct.
Traceable -- Each referenced requirement is uniquely identified.
Correct -- Every stated requirement represents something required of the
system to be built.
Potential conflict: comprehensible
requirements in natural language might
not fit into this list of characteristics.
SER
Characteristics of requirements (2)
Reference book for developers, testers, customers, users, marketing, etc
determining of project relevant contents and terminology
classification
keywords
When describing technical requirements you can distinguish between:
functional requirements
(What is the software system that is being developed supposed to do?)
classification
non functional requirements
(Which attributes apply to the functional requirements?)
SER
Functional requirements
definition: input
definition: output
data models
definition: functions, processes, events
definition: interfaces
SER
Nonfunctional requirements
performance requirements
amount of users
extent of data
response times
process frequency
quality requirements
dependability
Safety
security
implementation requirements
methods
guidelines
acceptance
documentation
Resources (skills, certification)
SER
Example: RTOS
Embedded systems often ask for soft or hard real-time requirements.
During requirements engineering, its the task of the systems engineer to
determine how this translates into system specs (cost, effort, skills!)
On top of ensuring these requirements is a real-time OS (RTOS). RTOS
form the foundation of an embedded system.
To be considered real-time, the RTOS must provide dependability,
predictability, simultaneity, and timeliness.
Precision timing in a RTOS is achieved by (selection criteria)
Utilizing asynchronous threads (I.e., Multiple threads of execution
(multi-threaded); Priority scheduling to meet critical thread deadlines;
Low/deterministic context switching time; Low/deterministic inter-
thread communication time)
High resolution deterministic timers (I.e., Needed to support periodic
threads; Needed for system timeout)
Configurability (I.e., Many real-time systems are also embedded,
which places limitations on the amount of memory, type of processor
etc.)
SER
Classification of Requirements
Requirements
Non-
Technical
Technical
Functional
Non-
Functional
external
- User interface
- Interworking
internal
- Load
balancing
- Power supply
external
- Performance
- Reliability
- Usability
internal
- Testability
- Maintain-
ability
Cons-
traints
- Standards
- Environmental
- Organization
Proper-
ties
- Cost
- Marketing
Source: Ebert, 1998
Functional requirements are accompanied with
nonfunctional and nontechnical requirements
Z 1
Z 2
Z 3
Z 4
D
I
N
functional
requirements
non
functional
requirements,
regulations,
standards
what ?
what has to be considered ?
user requirement specification/
system requirement
specification
Constraints,
attributes
V
E D
TV
SER
Difference between functional and non functionalrequirements
illustrated by the example of a heating regulator
Functional requirements:
In dependence of the measured external temperature T
A
and the
adjusted desired temperature T
S
a regulation of the boiler temperature
T
K
should be realized. The regulation is realized by turning the
burner fan on or off :
State of the burner = function (T
A,
T
S,
T
K
)
The deviation may not exceed 2 C
SER
a) The realization of the regulator has to be achieved with a micro computer
using the programming language Ada.
b) The heating regulator has to run with a failure probability of maximal 0,01;
given a maintenance interval of one year.
c) During the adjustment of the heating regulator the relevant rules taken
from the Regulation for Heating Systems (HeizAnIV - 22.09.1978) have to
be taken into account.
d) Due to the related costs only analog-digital converter with low resolutions
(10 bits) can be used.
Further Attributes:
non functional requirements
SER
5.5 Summary
SER
Goals of requirements engineering
support determining the requirements
support the software / systems engineers in editing the requirements
specify
classify
put in a hierarchical order
trace
support validating the system (quality assurance)
interface
Test starts
already in
early stages
SER
Agreement on What the System Should Do
The Goal
Validation Requirements
Verification
Customer
User Community
Requirements
System
To Be Built
SER
Conceptual formulation versus conception = WHAT versus HOW
professor student
requirements specification
Thats what I want..."
Concept (design specification)
Thats how I want to do this"
customer
supplier
SER
Viewpoint-oriented elicitation
Stakeholders represent different ways of looking at a
problem or problem viewpoints
This multi-perspective analysis is important as there is
no single correct way to analyse system requirements
SER
Example: ATM viewpoints
Bank customers
Representatives of other banks
Hardware and software maintenance engineers
Marketing department
Bank managers and counter staff
Database administrators and security staff
Communications engineers
Personnel department
SER
Typical problems for system analysts
vague formulations
vague terms
incomplete descriptions
First of all the system analyst has to understand the conceptual formulation as
described by the customer
SER
Activities during the initial phases of a project:
Analysis of the present state of the technical process, of already available
devices or software as well as of organizational circumstances
R
e
q
u
i
r
e
m
e
n
t
s
E
n
g
i
n
e
e
r
i
n
g
Determination and description of the conceptual formulation
and of the user requirements for the automation system
Analysis of the conceptual formulation, composition (design)
of a technical solution, validation of this solution with CASE
systems
project planning (incl. estimation of efforts)
SER
Requirements Engineering
p
r
o
j
e
c
t

p
l
a
n
n
i
n
g
technical
process
SW/ HW system design
definition of
requirements
(what?)
technical
Solution
(how?)
may be analysis of
present state
SER
Requirements Engineering Activities
Requirements
Engineering
collection
analysis
allocation
tracing / change management
specification / verification
SER
Top Risks of Requirements
Overlooking a crucial requirement
Inadequate customer representation
Modeling only functional requirements
Not inspecting requirements
Attempting to perfect requirements before beginning construction
Representing requirements in the form of designs
Source: Lawrence, Wiegers, Ebert, 2001
SER
Manage Risks
Categorize
Group requirements, permitting a higher-level understanding of
relationships and dependencies.
Consistently apply a specification template (e.g. use cases, IEEE 830,
IEEE 1233).
Organize
Use automated tools to assist in understanding and tracing of
requirements from inception to allocation to delivery.
Apply strict change management.
Prioritize
Determine the order of consideration based on criticality of need and
level of associated risk.
Implement in increments following the priorities. Descope lowest
priority features.
SER
Requirements Engineering Process
Analyze: formulate, classify,
put requirements in hierarchical order
Trace requirements
and validate the system versus requirements
Collect and specify requirements
Allocate requirements
SER
Scenarios
Scenarios are descriptions of how a system is used in practice
They are helpful in requirements elicitation as people can relate to these
more readily than abstract statement of what they require from a system
Scenarios are particularly useful for adding detail to an outline
requirements description
SER
Scenario descriptions
System state at the beginning of the scenario
Normal flow of events in the scenario
What can go wrong and how this is handled
Other concurrent activities
System state on completion of the scenario
SER
Use cases
Use-cases is a scenario based technique in the UML which identify
the actors in an interaction and which describe the interaction itself
A set of use cases should describe all possible interactions with
the system
Sequence diagrams may be used to add detail to use-cases by
showing the sequence of event processing in the system
SER
Library use-cases
Library
User
Lending services
User
administration
Catalogue
services
Supplier
Library
Staff
SER
Successful Negotiation Means Win-Win
To protect the supplier:
Express disagreement and unrealistic conditions openly.
Offer compromise approaches, once needs are understood.
Have a signed contract with requirements. Agree on clear and
reasonable acceptance criteria.
Include a software key that will operate after the date of contracted
software acceptance.
State in the contract that the supplier owns the code until final
payment.
Clearly agree on liabilities and support after handover.
To protect the client:
Clearly state that payment will be provided only for systems that meet
the agreed upon functionality.
Require milestone presentations of progress for continued funding.
Provide a realistic and precise expectation of functional and
nonfunctional requirements (e.g. reliability).
SER
5.5 Summary
SER
Specifying Requirements
The definition of a requirement specification following international standards
(see ch. 5.5):
In a user requirements specification the user orientated requirements incl.
the attributes, constraints, etc are described. This data must be quantifiable
and testable.
The requirements specification defines WHAT KIND OF task is solved.
The requirements specification is created by the client or on his behalf.
It serves as bidding, offer and/ or basis.
SER
Create the requirements specification
1. Determine the requirements specification
user / stakeholder requirements
system requirements
External / environmental inputs
2. Writing the requirements
communication and decision between clients and contractors
3. Classification (and prioritization) of the requirements
functional requirements
data requirements
quality requirements
performance requirements
implementation requirements
organization requirements
regulations, norms
safety requirements
nice-to-have-requirements
SER
4. Putting requirements in a hierarchical order
5. Check requirements
unambiguousness
completeness
verifiability
consistency
modifiability
comprehensibility
reliability / practicability
SER
Structuring requirements
Advantages:
better manageability
better understandability
identifiable requirement
comprehensibility
basis of a contract
descriptive text
abcdefg 84279834
43 5923850 9345
34 464 756
lkjklj jk jk lklk l
kklklgkd
fgj gjfk glfl jgk jj
fgk ghg jkj df g#
3423 345 67 79
345 674289
34534 6867 2468
23423 57 686
2342 575 789
345 67 89
hjdcbc
dsfsd sdf fghg
hjh gg ggj hgjg
fgh gfhf fghf
gfghgf
fhfghf gfhf fz
423 /T/( &/
$% /&( /%(/
%&/9
234 &/( /()
2342 23423 4564
34535
46749876 46 46
wkrlw
35348 34593 4746
34534 35 4656 55675
57575 575 57567
576577
575 57 5757 56868
57
56756 5765 567567
575675
user requirements
user constraints
capabilities
attributes
boundary
conditions
constraints
SER
Structuring requirements
Introduction
General description
Specific requirements
Appendices
Index
This is a generic structure that must be instantiated for specific systems.
See Standards (ch. 5.5) for further extensions.
SER
Requirements Specification structure
Introduction
Glossary
User requirements definition
System architecture
System requirements specification
System models
System evolution
Appendices
Index
SER
5.5 Summary
SER
Requirements Trace To Many Project Elements
SER
Requirement tracing
Traceability is concerned with the relationships between requirements,
their sources and the system design
Source traceability
Links from requirements to stakeholders who proposed these
requirements
Requirements traceability
Links between dependent requirements
Design traceability
Links from the requirements to the design
SER
Requirement - Feature Matrix according to Boehm
Feature
Requirement
F
1
F
2
F
3
...
R
1
X
11
X
12
X
13
R
2
X
21
X
22
X
23
R
3
X
31
X
32
X
33
.
.
.
Requirements Features
Matrix
Requirements Features
Matrix
SER 5.4 Requirements Tracing
X
ij
= A ... examined and consequences accepted
B ... not examined yet
O ... without consequences (irrelevant)
D
i
... reference to designing decision
R
i
... reference to another requirement
designing decision verbal description
D
1
D
2
comment 1
comment 2
.
.
.
.
.
.
SER
Traceability between Work Products
requirement ...
requirement ...
requirement ...
Requirements specification
1."sections" referring to
requirement ...
requirement ...
fulfils ...
substitute ...
Analysis Model
actions
data
interfaces
processes
...
design
activities
project participants
resources
products
...
project management
SER 5.4 Requirements Tracing
project management
ACTIVITY SWCE-3-development.
PROBLEM: During this development stage the SWCE 3 is being developed...
TECHNICAL-FRAMEWORK:
PLANNED-SECTIONS: P1.1.1.1.1. SW configuration entity 1,
P1.1.1.1.1.1. SW component 1,
P1.1.1.1.1.2. SW component 2.
PLANNED OBJECTS: SWCE 1, SW component 1, SW component 2.
PREDECESSORS: segment specification-Segment 1.
ACTIVITYEND
ACTIVITY SWCE-3-development.
PROBLEM: During this development stage the SWCE 3 is being developed...
TECHNICAL-FRAMEWORK:
PLANNED-SECTIONS: P1.1.1.1.1. SW configuration entity 1,
P1.1.1.1.1.1. SW component 1,
P1.1.1.1.1.2. SW component 2.
PLANNED OBJECTS: SWCE 1, SW component 1, SW component 2.
PREDECESSORS: segment specification-Segment 1.
ACTIVITYEND
...
1.1.1.1.1. SW configuration entity 1
This system components task is to...
1.1.1.1.1.1. SW component 1
This software components task is to...
REQUIREMENT 10001 (1) ...
REQUIREMENT 10001 (3)
...
...
1.1.1.1.1. SW configuration entity 1
This system components task is to...
...
analysis model design
ACTION SWCE 1.
DESCRIPTION:
PURPOSE: ...
DESCRIPTIONEND
DECOMPOSITION:
(/ SW comp. 1, SW comp. 2 /)
ACTIONEND
ACTION SW comp. 1
DESCRIPTION:
...
FULFILS: REQ. 10001 (3)
REQ. 10002 (1)
ACTION SW comp. 1
DESCRIPTION:
...
FULFILS: REQ. 10001 (1)
REQ. 10002 (2)
...
SER
Requirements change
The priority of requirements from different viewpoints changes during the
development process
System customers may specify requirements from a business perspective
that conflicts with end-user needs
The business and technical environment of the system changes during its
development (this is most frequent reason for change)
Typically ca. 2..3% per month!
SER
Requirements Change Management
Requirements change management is the process of managing changing
requirements during the requirements engineering process and system
development
Requirements are inevitably incomplete and inconsistent
New requirements emerge during the process as business needs change
and a better understanding of the system is developed
Different viewpoints have different requirements and these are often
contradictory
SER
Tool support
Requirements database
Requirements should be managed in a secure, managed data store
Change management
The process of change management is a workflow process whose stages
can be defined and information flow between these stages partially
automated
Traceability management
Automated retrieval of the links between requirements
SER
5.5 Summary
SER 5.5 Summary
Summary
Requirements engineering includes collection, analysis, allocation,
specification, verification, tracing and managing change of requirements.
Requirements analysis is iterative involving domain understanding,
requirements collection, classification, structuring, prioritization and
validation
Systems have multiple stakeholders with different requirements and
different views on the same system to be developed.
Most frequent error: to give the customer what she needs and not what she
wants.
SER
Standards
IEEE 1220: Systems Engineering Process
ISO 15288: System Life Cycle Processes
ISO 12207: Standard for Software Life Cycle Processes
CMM, CMMI, ISO 15504: Software Process Improvement and
Capability Determination
SW-CMM: Software Engineering Capability Maturity Model
SE-CMM: Systems Engineering CMM
CMMI: Capability Maturity Model Integration
IEEE 1233: Guide for Developing of System Req. Specifications
IEEE 830: Recommended Practice for SW Req. Specification
5.5 Summary
SER
Internet Resources
Requirements Engineering / Management web links
http://www.shu.ac.uk/tfre/web.links.html
Requirements Engineering hotlist
http://www.cc.gatech.edu/computing/SW_Eng/hotlist.html#requirements
IEEE Task Force on Requirements Engineering
http://www.shu.ac.uk/tfre/welcome.html
RENOIR (Requirements Engineering Network Of Int. cooperating Research groups)
http://www.cs.ucl.ac.uk/research/renoir/
Requirements Engineering Journal
http://rej.co.umist.ac.uk/
Intern. Council on Systems Engineering - Requirements Working Group
http://www.incose.org/rwg/
Guidance to select a requirements management tool
http://www.incose.org/toc.html , http://www.incose.org/tools/tooltax.html
Practical examples for requirements documents, inspection checklists, req. prioritization
http://www.processimpact.com
Estimation tools (and more)
http://www.methods-tools.com
5.5 Summary
SER
Further Information
Software Requirements (Best
Practices)
by Karl E. Wiegers /$34.99/
Paperback - 368 pages /(September
1999)
Microsoft Press; ISBN: 0735606315
Well-written introduction to
requirements engineering. Focus
especially on practitioner. Excellent
chapter on tools for requirements
engineering.
5.5 Summary

5 Requirements Engineering

Uploaded by

Copyright:

Available Formats

You might also like

5 Requirements Engineering

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

5 Requirements Engineering

Uploaded by

Copyright:

Available Formats

2005 IAS, Universitt Stuttgart 1

You might also like