- introduction to re
TRANSCRIPT
-
7/27/2019 - Introduction to RE
1/56
Requirements Engineering
CT056-3-2
Introduction to Requirements
EngineeringLecture 2
-
7/27/2019 - Introduction to RE
2/56
CT056-3-2 Requirements Engineering Introduction Slide 2 (of 19)
Topic & Structure of the lesson
Subcomponents of Requirements Engineering
Requirements Development
Requirements Management
Significance of RE
Why Requirements Engineering?
What is a Requirement?
Types of Requirements
Requirements Prioritization
-
7/27/2019 - Introduction to RE
3/56
CT056-3-2 Requirements Engineering Introduction Slide 3 (of 19)
Learning Outcomes
By the end of this lecture, YOU should be
able to:
To define RE and its subcomponents
To classify requirements
-
7/27/2019 - Introduction to RE
4/56
CT056-3-2 Requirements Engineering Introduction Slide 4 (of 19)
Key Terms you must be able to use
If you have mastered this topic, you should be able
to use the following terms correctly in your
assignments and exams:
Requirements Engineering
Requirements Development
Requirements Management
Functional and Non-functional Requirements
Requirements Constraints
Requirements Prioritization
-
7/27/2019 - Introduction to RE
5/56
CT056-3-2 Requirements Engineering Introduction
Subcomponents of requirements
engineering
Requirements Engineering
Requirements
Development
Requirements
Management
Elicitation Analysis Specification Validation
-
7/27/2019 - Introduction to RE
6/56
CT056-3-2 Requirements Engineering Introduction
Requirements Development
Involves:-
Identifying the products expected user classes
Eliciting needs from user class
Understanding user tasks, goals and business objectives
Analyzing user information, distinguishing task goals,
functional and non-functional requirements
Transforming user needs to requirements specification
-
7/27/2019 - Introduction to RE
7/56CT056-3-2 Requirements Engineering Introduction
Requirements Management
Is the establishing and maintaining an agreement withthe customer on the requirements for the software
project
The agreement is embodies in the written requirement
specification Req. Mgt. Activities :-
Define requirements baseline
Review proposed changes
Incorporate approved requirements
Keeping project plans
Tracing individual requirements, from design to source code
Tracking requirements status
-
7/27/2019 - Introduction to RE
8/56CT056-3-2 Requirements Engineering Introduction Slide 5 (of 19)
Requirements Engineering
The process of establishing the services that the
customer requires from a system and the
constraints under which it operates and is
developed. The requirements themselves are the
descriptions of the system services and
constraints that are generated during the
requirements engineering process.Ian Sommerville
-
7/27/2019 - Introduction to RE
9/56CT056-3-2 Requirements Engineering Introduction
Requirements Engineering (def)
Requirements Engineering (RE) is a set ofactivities concerned with identifying and
communicating the purpose of a software
intensive system, and thecontexts in which it will
be used. Hence, RE acts as the bridge between
the real-world needs of users, customers, and
other constituencies affected by a software
system, and the capabilities and opportunitiesafforded.
[Easterbrook, Chapter 1]
-
7/27/2019 - Introduction to RE
10/56CT056-3-2 Requirements Engineering Introduction
Requirements Engineering (def)
Software requirements engineering is the science
and discipline concerned withestablishing and
documentingsoftware requirements.
[Thayer and Dorfman:
Software Requirements Engineering]
-
7/27/2019 - Introduction to RE
11/56CT056-3-2 Requirements Engineering Introduction
Requirements Engineering (def)
can be defined as thesystematic process of
developingrequirements through aniterative
co-operativeprocess of analyzing the problem,documenting the resulting observations in a variety
of representation formats, and checking the
accuracy of the understanding gained.
[Macaulay: Requirements Engineering]
-
7/27/2019 - Introduction to RE
12/56CT056-3-2 Requirements Engineering Introduction Slide 6 (of 19)
"The hardest single part of building a software system is deciding
precisely what to build. No other part of the conceptual work is as
difficult as establishing the detailed technical requirements, including all
the interfaces to people, to machines, and to the software systems. No
other part of the work so cripples the resulting system if done wrong.No other part is more difficult to rectify later".
Fred Brooks, "No Silver Bullet",
IEEE Computer,1987Author of The Mythical Man-mon
-
7/27/2019 - Introduction to RE
13/56CT056-3-2 Requirements Engineering Introduction Slide 7 (of 19)
-
7/27/2019 - Introduction to RE
14/56CT056-3-2 Requirements Engineering Introduction Slide 8 (of 19)
D l d U Vi
-
7/27/2019 - Introduction to RE
15/56CT056-3-2 Requirements Engineering Introduction
Developers and Users Views
Developers View Of Users Users View Of Developers
-
7/27/2019 - Introduction to RE
16/56CT056-3-2 Requirements Engineering Introduction
Learning from each other
Users, customers,
managers, domain
experts, anddevelopers share
different skills,
backgrounds, and
expectations.
-
7/27/2019 - Introduction to RE
17/56CT056-3-2 Requirements Engineering Introduction
Developing a shared vision
Requirements emerge
from a process of
co-operative learning in
which they are explored,
prioritized, negotiated,
evaluated, and
documented.
-
7/27/2019 - Introduction to RE
18/56CT056-3-2 Requirements Engineering Introduction
The 10 top reasons for not doing
requirements
10. We dont need requirements, were using objects/java/web/.
9. The users dont know what they want
8. We already know what the users want
7. Who cares what the users want?
6. We dont have time to do requirements
5. Its too hard to do requirements
4. My boss frowns when I write requirements
3. The problem is too complex to write requirements
2. Its easier the change the system later than to do the requirements up front
1. We have already started writing code, and we dont want to spoil it
Volere Requirements Resources http://www.volere.co.uk
http://www.volere.co.uk/http://www.volere.co.uk/ -
7/27/2019 - Introduction to RE
19/56
CT056-3-2 Requirements Engineering Introduction
I held my entire program up for 4+ weeks due to unclear,
unwritten requirements. Took some heat for that in the beginning,
but the deep dive requirements effort is highlighting a Silicon spin
we didn't know about, standards that we don't support, other postlaunch requirements nobody consideredall of this causing us
and mgmt to question the viability of the product. BTW, this is all
stuff we wouldn't have realized until it smacked us in the face 6
months from now. Spending a month now prevented us from
spending millions before a conscious decision.
From : Reflections on a Successful Corporate Requirements Engineering Training
Curriculum, Erik Simmons, Intel Corporation, 2005
-
7/27/2019 - Introduction to RE
20/56
CT056-3-2 Requirements Engineering Introduction
Stakeholders issues
Steve McConnell, in his book Rapid Development, details a
number of ways users can inhibit requirements gathering:
Users don't understand what they want or users don't have a clear idea
of their requirements
Users won't commit to a set of written requirements
Users insist on new requirements after the cost and schedule
have been fixed.
Communication with users is slow
Users often do not participate in reviews or are incapable of doing so. Users are technically unsophisticated
Users don't understand the development process.
Users don't know about present technology.
-
7/27/2019 - Introduction to RE
21/56
CT056-3-2 Requirements Engineering Introduction
Why Software Projects Fail
-
7/27/2019 - Introduction to RE
22/56
CT056-3-2 Requirements Engineering Introduction
Contribution of Requirements
Defects
-
7/27/2019 - Introduction to RE
23/56
CT056-3-2 Requirements Engineering Introduction
Why Requirements Engineering?
Scope the problem
Understand the problem
for the client as well as the architect
Basis for design
Contract between client/user and builders
agreement on what has to be built
-
7/27/2019 - Introduction to RE
24/56
CT056-3-2 Requirements Engineering Introduction
Understand the Domain
What is important?
Which things are stable and which change?
How does the project add to an organizations' success
-
7/27/2019 - Introduction to RE
25/56
CT056-3-2 Requirements Engineering Introduction
Initial Steps in RE process
What are the drivers?
Stakeholders & concerns
What are the constraints?
Economical/technical/organisational
What is the scope of the system?
-
7/27/2019 - Introduction to RE
26/56
CT056-3-2 Requirements Engineering Introduction
Twin Peaks Process
Separate but concurrent development of requirements & architecture
WHAT:
problem
structuring
HOW:
solutionstructuring
Progressing understanding of architecture & design provides a
basis for discovering further system requirements and vice versa
There is interaction between available solutions and requirements
-
7/27/2019 - Introduction to RE
27/56
CT056-3-2 Requirements Engineering Introduction
Slide by Gerrit Muller, ESI, 2007
-
7/27/2019 - Introduction to RE
28/56
CT056-3-2 Requirements Engineering Introduction
What is a Requirement ?
A statement about the proposed system that all
stakeholders agree must be made true in order
for the customers problem to be adequately
solved.
Short and concise piece of information
Says something about the system
All the stakeholders have agreed that it is validIt helps solve the customers problem
Contract between customer and builder
-
7/27/2019 - Introduction to RE
29/56
CT056-3-2 Requirements Engineering Introduction
Example Requirement Template
-
7/27/2019 - Introduction to RE
30/56
CT056-3-2 Requirements Engineering Introduction
Errors
Up to 30-50% of the errors found further downstream thedevelopment process are due to errors in the
requirements.
Requirements errors are typically non-clerical.incorrect facts 49%
omissions 31%
inconsistencies 13%
ambiguities 5%
Requirements errors can be detected.Review by authors 23%
Review by others 10%
-
7/27/2019 - Introduction to RE
31/56
CT056-3-2 Requirements Engineering Introduction
Users of requirements document
-
7/27/2019 - Introduction to RE
32/56
CT056-3-2 Requirements Engineering Introduction
Types of Requirements
User requirements:
The description of the functions that the system has to fulfil
for its environment in terms of the users interacting with the
system, e.g. in the form of use cases.
Software requirements:
The software requirements are a translation and a more
precise description of the user requirements, in terms for
software engineers.
T f R i t
-
7/27/2019 - Introduction to RE
33/56
CT056-3-2 Requirements Engineering Introduction
Types of Requirements -Functional and extra-functional requirements
Functional requirementsStatements of services the system should provide, how the systemshould react to particular inputs and how the system should behave inparticular situations.
Extra-functional or non-functional requirements
constraints on the services or functions offered by the system such astiming constraints, constraints on the development process, standards,
Availability, Security, Reliability, Timeliness, etc.
Domain requirementsRequirements that come from the application domain of the system
and that reflect characteristics of that domain. Requirements otherthan specific needs of the userstandard user interfaces to all databasesBecause of copyright requirements all documents to be deleted upon arrival
-
7/27/2019 - Introduction to RE
34/56
CT056-3-2 Requirements Engineering Introduction
Describe functionality or system services.
Depend on the type of software, expected
users and the type of system where thesoftware 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.
Functional requirements
-
7/27/2019 - Introduction to RE
35/56
CT056-3-2 Requirements Engineering Introduction
Eg. Of functional Requirements
What inputs the system should accept
What outputs the system should produce
What data the system should store that other
systems might use
What computations the system should
perform
-
7/27/2019 - Introduction to RE
36/56
CT056-3-2 Requirements Engineering Introduction
The LIBSYS system
A library system that provides a single
interface to a number of databases of
articles in different libraries.
Users can search for, download and print
these articles for personal study.
-
7/27/2019 - Introduction to RE
37/56
CT056-3-2 Requirements Engineering Introduction
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 forthe 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 accountspermanent storage area.
-
7/27/2019 - Introduction to RE
38/56
CT056-3-2 Requirements Engineering Introduction
Non-functional requirements
These define system properties and constraintse.g. reliability, response time and storagerequirements. Constraints are I/O devicecapability, system representations, etc.
Process requirements may also be specifiedmandating a particular CASE system,programming language or development method.
Non-functional requirements may be more criticalthan functional requirements. If these are not met,the system is useless.
-
7/27/2019 - Introduction to RE
39/56
CT056-3-2 Requirements Engineering Introduction
Types of extra-functional requirements
-
7/27/2019 - Introduction to RE
40/56
CT056-3-2 Requirements Engineering Introduction
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 thesystem and its development process e.g. interoperability
requirements, legislative requirements, etc.
-
7/27/2019 - Introduction to RE
41/56
CT056-3-2 Requirements Engineering Introduction
Examples of Extra Functional Req:
Reliability
Typically expressed in terms of
for repairable systems
Mean Time Between Failures (MTBF)
Number of hours that pass before a component fails
E.g. 2 failures per million hours: MTBF = 10^6 / 2 = 0,5 * 10^6 hr
for non-repairable systems
Mean Time To Failure (MTTF)
Mean time expected until the first failure of a system Is a statistical value over a long period of time
Mean Time To Repair (MTTR) Availability
-
7/27/2019 - Introduction to RE
42/56
CT056-3-2 Requirements Engineering Introduction
Examples XFR: Maintainability
Maintainability
The average person time required to fix a category 3 defect
(including testing and documentation upgrade) shall not
exceed two person days.
-
7/27/2019 - Introduction to RE
43/56
CT056-3-2 Requirements Engineering Introduction
Constraints
Constraints are not negotiable
Constraints concerning the environment and technology of the system.
Platform
Technology to be used
Constraints concerning theproject plan and development methods
Development process (methodology) to be used
Cost and delivery date
Often put in contract or project plan instead
-
7/27/2019 - Introduction to RE
44/56
CT056-3-2 Requirements Engineering Introduction
Constraints
Constraint restrict how the requirements are to beimplemented.
Interface Requirements.
How external interfaces with other systems must be done.
Communication Interfaces.
The networks and protocols to be used.
Hardware Interfaces.
The computer hardware the software is to execute on.
Software Interfaces.
How the software should be compatible with other software:
applications,compilers, operating systems, programming languages,
database management systems.
User Interfaces.
Style, format, messages
-
7/27/2019 - Introduction to RE
45/56
CT056-3-2 Requirements Engineering Introduction
Requirements on Requirements (1)
Each individual requirement should be :
Important/necessary for the solution of the current
problem
Unique Unambiguous
Logically consistent
Not over-constrain the design of the system
Atomic: not consist of multiple separate requirements
-
7/27/2019 - Introduction to RE
46/56
CT056-3-2 Requirements Engineering Introduction
Requirements on Requirements (2)
The set of requirements together should be:
Complete
Expressed using a clear and consistent notationat the same level of detail
Without duplication
-
7/27/2019 - Introduction to RE
47/56
CT056-3-2 Requirements Engineering Introduction
Requirements on Requirements (3)
S Specific
To-the-point, precise
M Measurable
Quantifiable and verifiable
A Acceptable (to the stakeholders)
Accessible, understandable (for the user)
Achievable(technically/planning/economically)
R RealisticDeducible to the real business drivers
T Testable
-
7/27/2019 - Introduction to RE
48/56
CT056-3-2 Requirements Engineering Introduction
Lets consider
-
7/27/2019 - Introduction to RE
49/56
CT056-3-2 Requirements Engineering Introduction
Requirements
Prioritization
-
7/27/2019 - Introduction to RE
50/56
CT056-3-2 Requirements Engineering Introduction
Big Requirements Up Front
Source: Jim Johnson of the Standish Group, Keynote Speech XP 2002
Pie chart shows percentage of functionality used by stakeholders
Successful Projects Still Have Significant Waste
Pareto-rule applies: 20% of functionality delivers 80% of value
-
7/27/2019 - Introduction to RE
51/56
CT056-3-2 Requirements Engineering Introduction
Prioritizing Requirements
MIL STD: Must have, will have, may have
RUP: MoSCoW
Must have
Should have
Could have
Wont have
Criteria: indicate importance
Alternative criteria: volitility, cost to realize, risk, ..
-
7/27/2019 - Introduction to RE
52/56
CT056-3-2 Requirements Engineering Introduction
Cost-Value Prioritization of Requirements
Motivation for Prioritization:
Focus development effort
Allocate resources based on importance
Make trade-offs between conflicting
goals, such as quality, cost and time-to-
market
-
7/27/2019 - Introduction to RE
53/56
CT056-3-2 Requirements Engineering Introduction
Cost-Value Prioritization of Requirements
Process:
1. Review requirements for clarity and completeness (by Requirements
Engineers)
2. Assess relative value of requirements in pair wisemanner (Customers and users)
3. Assess relative cost of realizing requirements in pair wise manner (by
experienced SW Engineers)
4. Calculate (value, cost)-pairs (using AHP*)
5. Plot requirements as (value, cost)-pairs
6. Prioritize
-
7/27/2019 - Introduction to RE
54/56
CT056-3-2 Requirements Engineering Introduction
Requirements Prioritization
Example
-
7/27/2019 - Introduction to RE
55/56
CT056-3-2 Requirements Engineering Introduction
Key points
Requirements set out what the system
should do and define constraints on its
operation and implementation
Functional requirements set out services
the system should provide
Non-functional requirements constrain the
system being developed or the
development process
User requirements are high-level
statements of what the s stem should do
-
7/27/2019 - Introduction to RE
56/56
Key points
User requirements should be written in
natural language, tables and diagrams
System requirements are intended to
communicate the functions that the system
should provide
System requirements may be written in
structured natural language, a PDL or in a
formal language
A software requirements document is an