Requirements Engineering CT056-3-2

Introduction to Requirements Engineering

Lecture 2

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

CT056-3-2 Requirements Engineering

Introduction

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

CT056-3-2 Requirements Engineering

Introduction

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

CT056-3-2 Requirements Engineering

Introduction

Slide 4 (of 19)

Subcomponents of requirements engineering

Requirements Engineering

Requirements Development

Requirements Management

Elicitation

Analysis

Specification

Validation

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

CT056-3-2 Requirements Engineering

Introduction

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

CT056-3-2 Requirements Engineering

Introduction

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

CT056-3-2 Requirements Engineering

Introduction

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

Requirements Engineering (def)

Software requirements engineering is the science and discipline concerned with establishing and documenting software requirements.

[Thayer and Dorfman: Software Requirements Engineering]

CT056-3-2 Requirements Engineering

Introduction

Requirements Engineering (def)

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]

CT056-3-2 Requirements Engineering Introduction

"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

CT056-3-2 Requirements Engineering

Introduction

Slide 6 (of 19)

CT056-3-2 Requirements Engineering

Introduction

Slide 7 (of 19)

CT056-3-2 Requirements Engineering

Introduction

Slide 8 (of 19)

Developers and Users Views

Developers View Of Users Users View Of Developers

CT056-3-2 Requirements Engineering

Introduction

Learning from each other

Users, customers, managers, domain experts, and developers share different skills, backgrounds, and expectations.

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

CT056-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

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 post launch 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

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.

CT056-3-2 Requirements Engineering

Introduction

Why Software Projects Fail

CT056-3-2 Requirements Engineering

Introduction

Contribution of Requirements Defects

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

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

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?

CT056-3-2 Requirements Engineering

Introduction

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

Slide by Gerrit Muller, ESI, 2007

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 valid It helps solve the customers problem Contract between customer and builder
CT056-3-2 Requirements Engineering Introduction

Example Requirement Template

CT056-3-2 Requirements Engineering

Introduction

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 omissions inconsistencies ambiguities 49% 31% 13% 5%

Requirements errors can be detected.

Review by authors Review by others 23% 10%

CT056-3-2 Requirements Engineering

Introduction

Users of requirements document

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.

CT056-3-2 Requirements Engineering

Introduction

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

Extra-functional or non-functional requirements

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

CT056-3-2 Requirements Engineering

Introduction

Functional requirements
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 highlevel statements of what the system should do but functional system requirements should describe the system services in detail.
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
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.

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 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 accounts permanent storage area.

CT056-3-2 Requirements Engineering

Introduction

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.

CT056-3-2 Requirements Engineering

Introduction

Types of extra-functional requirements

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 the system and its development process e.g. interoperability requirements, legislative requirements, etc.

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

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.

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 the project plan and development methods Development process (methodology) to be used Cost and delivery date Often put in contract or project plan instead

CT056-3-2 Requirements Engineering

Introduction

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

CT056-3-2 Requirements Engineering

Introduction

Requirements on Requirements (2)

The set of requirements together should be: Complete

Expressed using a clear and consistent notation at the same level of detail
Without duplication

CT056-3-2 Requirements Engineering

Introduction

Requirements on Requirements (3)

S Specific To-the-point, precise
Measurable Quantifiable and verifiable Acceptable (to the stakeholders) Accessible, understandable (for the user) Achievable(technically/planning/economically) Realistic Deducible to the real business drivers Testable

CT056-3-2 Requirements Engineering

Introduction

Lets consider

CT056-3-2 Requirements Engineering

Introduction

Requirements Prioritization

CT056-3-2 Requirements Engineering

Introduction

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

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

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-tomarket

CT056-3-2 Requirements Engineering

Introduction

Cost-Value Prioritization of Requirements

Process:
1. 2. 3. 4. 5. 6. Review requirements for clarity and completeness (by Requirements Engineers) Assess relative value of requirements in pair wise manner (Customers and users) Assess relative cost of realizing requirements in pair wise manner (by experienced SW Engineers) Calculate (value, cost)-pairs (using AHP*) Plot requirements as (value, cost)-pairs Prioritize

CT056-3-2 Requirements Engineering

Introduction

Requirements Prioritization Example

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 system should do
Introduction

CT056-3-2 Requirements Engineering

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 agreed statement of the system
Introduction

CT056-3-2 Requirements Engineering