Download - - Introduction to RE

7/27/2019 - Introduction to RE

1/56

Requirements Engineering

CT056-3-2

Introduction to Requirements

EngineeringLecture 2


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


3/56


Learning Outcomes

By the end of this lecture, YOU should be

able to:

To define RE and its subcomponents

To classify requirements


4/56


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:




Functional and Non-functional Requirements

Requirements Constraints



5/56

CT056-3-2 Requirements Engineering Introduction

Subcomponents of requirements

engineering


Requirements

Development

Requirements

Management

Elicitation Analysis Specification Validation


6/56



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/56CT056-3-2 Requirements Engineering Introduction


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


8/56CT056-3-2 Requirements Engineering Introduction Slide 5 (of 19)


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



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]




Software requirements engineering is the science

and discipline concerned withestablishing and

documentingsoftware requirements.

[Thayer and Dorfman:

Software Requirements Engineering]




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]



"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



D l d U Vi



Developers and Users Views

Developers View Of Users Users View Of Developers



Learning from each other

Users, customers,

managers, domain

experts, anddevelopers 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 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/


19/56


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


20/56


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.


21/56


Why Software Projects Fail


22/56


Contribution of Requirements

Defects


23/56


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


24/56


Understand the Domain

What is important?

Which things are stable and which change?

How does the project add to an organizations' success


25/56


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?


26/56


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


27/56


Slide by Gerrit Muller, ESI, 2007


28/56


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


29/56


Example Requirement Template


30/56


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%


31/56


Users of requirements document


32/56


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


33/56


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


34/56


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


35/56


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


36/56


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.


37/56


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.


38/56


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.


39/56


Types of extra-functional requirements


40/56


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.


41/56


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


42/56


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.


43/56


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


44/56


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


45/56


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


46/56



The set of requirements together should be:

Complete

Expressed using a clear and consistent notationat the same level of detail

Without duplication


47/56



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


48/56


Lets consider


49/56


Requirements

Prioritization


50/56


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


51/56


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, ..


52/56


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


53/56


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


54/56



Example


55/56


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


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

Download - - Introduction to RE

Top Related