Week 1 lecture 2 - introduction to re

Requirements Engineering
CT056-3-2
Introduction to Requirements
Engineering
Lecture 2

CT056-3-2-Requirements Engineering Introduction to RE
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
Slide 2 (of 19)

Learning Outcomes
By the end of this lecture, YOU should be
able to:
•To define RE and its subcomponents
•To classify requirements
Slide 3 (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
Slide 4 (of 19)

Subcomponents of requirements
engineering
Requirements
Development
Requirements
Management
Elicitation Analysis Specification Validation

Requirements Development
Involves:-
• Identifying the product’s 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

Requirements Management
• Is the establishing and maintaining an agreement with
the 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

• 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
Slide 5 (of 19)

Requirements Engineering (def)
Requirements Engineering (RE) is a set of
activities concerned with identifying and
communicating the purpose of a software
intensive system, and the contexts 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 opportunities
afforded.
[Easterbrook, Chapter 1]

Software requirements engineering is the science
and discipline concerned with establishing and
documenting software requirements.
[Thayer and Dorfman:
Software Requirements Engineering]

… can be defined as the systematic process of
developing requirements through an iterative
co-operative process 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]

"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,1987
Author of The Mythical Man-mon
Slide 6 (of 19)

CT056-3-2-Requirements Engineering Introduction to RE Slide 7 (of 19)

CT056-3-2-Requirements Engineering Introduction to RE Slide 8 (of 19)

Developers’ and Users’ Views
Developers’ View Of Users Users View Of Developers

Learning from each other
Users, customers,
managers, domain
experts, and
developers share
different skills,
backgrounds, and
expectations.

Developing a shared vision
Requirements emerge
from a process of
co-operative learning in
which they are explored,
prioritized, negotiated,
evaluated, and
documented.

The 10 top reasons for not doing
requirements
10. We don’t need requirements, we’re using objects/java/web/….
9. The users don’t know what they want
8. We already know what the users want
7. Who cares what the users want?
6. We don’t have time to do requirements
5. It’s too hard to do requirements
4. My boss frowns when I write requirements
3. The problem is too complex to write requirements
2. It’s easier the change the system later than to do the requirements up front
1. We have already started writing code, and we don’t want to spoil it
Volere Requirements Resources http://www.volere.co.uk

“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 post
launch requirements nobody considered…all 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

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.

Why Software Projects Fail

Contribution of Requirements
Defects

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

Understand the Domain
What is important?
Which things are stable and which change?
How does the project add to an organizations' success

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?

Twin Peaks Process
Separate but concurrent development of requirements & architecture
WHAT:
problem
structuring
HOW:
solution
structuring
Progressing understanding of architecture & design provides a
basis for discovering further system requirements and vice versa
There is interaction between available solutions and requirements

Slide by Gerrit Muller, ESI, 2007

What is a Requirement ?
• A statement about the proposed system that all
stakeholders agree must be made true in order
for the customer’s problem to be adequately
solved.
– Short and concise piece of information
– Says something about the system
– All the stakeholders have agreed that it is valid
– It helps solve the customer’s problem
– Contract between customer and builder

Example Requirement Template

Errors
Up to 30-50% of the errors found further downstream the
development 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%

Users of requirements document

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.

Types of Requirements -
Functional and extra-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.
• Extra-functional or non-functional requirements
•constraints on the services or functions offered by the system such as
timing constraints, constraints on the development process,
standards, Availability, Security, Reliability, Timeliness, etc.
•Domain requirements
Requirements that come from the application domain of the system
and that reflect characteristics of that domain. Requirements other
than specific needs of the user
• standard user interfaces to all databases
• Because of copyright requirements all documents to be deleted upon arrival

• 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.
Functional requirements

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

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.

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.

Non-functional requirements
• These 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.

Types of extra-functional requirements

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.

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

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.

Constraints
Constraints are not negotiable
Constraints concerning the environment and technology of the system.
• Platform
• Technology to be used
Constraints concerning the project plan and development methods
• Development process (methodology) to be used
• Cost and delivery date
– Often put in contract or project plan instead

Constraints
Constraint restrict how the requirements are to be
implemented.
• 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

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

The set of requirements together should be:
• Complete
• Expressed using a clear and consistent notation
– at the same level of detail
• Without duplication

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 Realistic
Deducible to the real business drivers
T Testable

Let’s consider

Requirements
Prioritization

The Cost of Traditional BRUF
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

Prioritizing Requirements
• MIL STD:
• Must have, will have, may have
• RUP: MoSCoW
Must have
Should have
Could have
Won’t have
Criteria: indicate importance
Alternative criteria: volitility, cost to realize, risk, ..

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

Cost-Value Prioritization of Requirements
Process:
1.Review requirements for clarity and completeness (by Requirements
Engineers)
2.Assess relative value of requirements in pair wise
manner (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

Requirements Prioritization
Example

Summary
• 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 system should do

Summary
• 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 agreed
statement of the system requirements

Next session
Software Development Life Cycle

Week 1 lecture 2 - introduction to re

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Week 1 lecture 2 - introduction to re (20)

Week 1 lecture 2 - introduction to re