Requirements Engineering

Education & Research

1
Course Agenda
• De 201 / De Bridge Certification Scheme
• Course Scope
• ‘Software Requirements’ definition
• Need for Systematic Approach to Requirements Gathering
• Characteristics of Good Requirements
• Components of Software Requirements
• Activities in Requirements Engineering
• Requirements Engineering Framework

1-2

2
De 201 / De Bridge

1-3

3
In Scope Content
• Requirements Engineering
• Requirements Elicitation
• Requirements Management
• InFlux - Business Process Engineering (BPE)
• InFlux Workbench

1-4

4
Out of Scope Content
• Software Estimation
• InFlux UxD (User Experience Design)
• InFlux Architecture

1-5

5
Software Requirements Defined
• IEEE Standard Glossary of Software Engineering Terminology (1997)
1. A condition or capability needed by a user to solve a problem or achieve an
objective.
2. A condition or capability that must be met or possessed by a system or
system component to satisfy a contract, standard, specification, or other
formally imposed document.
3. A documented representation of a condition or capability as in 1 or 2.

• Rational Unified Process

– A condition or capability to which the system must confirm

• Unified Modelling Language (UML)

– A desired feature, property or behaviour of the system

We are solving a problem, meeting objectives and honoring a contract…

1-6

6
 Some Interpretations of “Requirements”
• The statement of needs by a user that triggers the development of a program or
system

• A user need or a necessary feature, function, or attribute of a system that can be

sensed from a position external to that system - [Alan Davis]

• A specification of what should be implemented. They are descriptions of how the

system should behave, or of a system property or attribute. They may be a constraint
on the development process of the system - [Sommerville and Sawyer]

1-7

7
 Importance of Systematic Requirements
Cost of Repair

Unit Test[2] Maintenance[20]

Accept Test[5]
Coding[1] Later in development life cycle that a
Design[0.5] software error is detected, the more expensive
Requirements[0.2] it will be to repair

Typical Requirement Errors

Inconsistency
Ambiguity [5%] [13%]
Omission [31%] Incorrect Facts [49%]
Misplaced Req [2%]

Requirement Errors can be detected

Need to spend more time analysing non-

executable forms of s/w ( Req, Design Other [25%]
docs ). Computer can easily find errors in Inspection [65%] Unit [5%] Integration [5%]
programs.

1-8

8
Distribution of Errors in Project Lifecycle

100

90
80

70

60 56
%
50
40
27
30
20
7 10
10

0
Requirements Design Code Test &
Maintain

Source : ‘Writing Testable Requirements’ by Dick Bender

1-9

9
Impact of Errors on Project Cost

Costs of Correcting Defects (Example)

Source: IEEE Computer Society

$16,000 $14,102

$14,000
$12,000
$10,000 $7,136
$8,000
$6,000
$4,000
$455 $977
$2,000 $139
$0
Requirements Arch & Design Build Test & Implement Maintenance

System Development Phases

Source : IEEE Computer Society

1 - 10

10
Exercise
• If on an average just 20 requirements defects per project get passed on to
implementation phase how much would these errors cost for a company running 40
projects a year ?

1 - 11

11
Risks from Inadequate Requirements Process
• Insufficient user involvement leads to unacceptable products.

• Creeping user requirements contribute to overruns and degrade product

quality.

• Ambiguous requirements lead to ill-spent time and dollars and rework.

• Overlooking the needs of certain user classes leads to dissatisfied

customers.

• Incompletely defined requirements make accurate project planning and

tracking impossible

1 - 12

12
Importance of Requirements …

1 - 13

13
Characteristics of Good Requirements

• Complete
• Correct
• Consistent
• Unambiguous
• Concise
• Feasible
• Verifiable
• Prioritised
• Modifiable
• Traceable
• Agreed

1 - 14

14
Activity: Identify Good Requirements
• Data will be gathered at a maximum of daily in all cases with measures aggregated
on a daily weekly and/or monthly basis depending on the measure.
• The interface must be intuitive and easy to use.
• Customers are restricted to nominating the account number they are recharging.
No other number will be acceptable.
• CCAS Administrator shall have the ability to change user attributes via an admin
screen. User attributes to include (but not limited to) ……
• The DSS platform will keep customers’ data for one month.

1 - 15

15
Business versus Application centric thinking
Conventional IT Approaches Current business-IT initiatives

BPay Recharge for Mobile & Calling Card

DFD, ER Model,
UI, Use case
Object Model ...
Calling Card
Mobile

FOH Mobile
App

Application CC App
Bank 1
Fin App

BPay
Bank 2
Service

ƒ Addresses larger sphere of influence

ƒ Requirements gathered from application
perspective
ƒ Only local departmental needs considered for
automation
ƒ Designed for internal use
ƒ Indirect users not in scope
ƒ Business Services, Operations
ƒ Customer and supplier interactions
ƒ Existing systems
ƒ Needs Business process view
ƒ Needs Enterprise model for common,
unambiguous understanding

1 - 16

16
 Limitations of Conventional Methods
• Not scalable for all initiatives
– Solution does not consider all stakeholders DFD, ER Model,
UI, Use case
• Sub-optimal solution - may not solve business problem Object Model ...
– Risk of applications not meeting the business need is
higher
– Incomplete identification of solution needs - risk of frequent
requirement changes
Application
• Difficult to elicit
– Users can articulate easily how they do their work, not
what they need from the applications
– Not suitable when users are not clear about requirements

1 - 17

17
Components of Requirements
• Technical
– Requirements to be met by a software while it works
– Types of technical requirements
• Functional
• Non-functional
• System Constraints

• Non-Technical
– Constraints that do not affect the software directly
• Schedule
• Cost
• Methodology etc.

The problem to be solved has multiple dimensions…

1 - 18

18
Components of Software Requirements
Business Security
Requirements requirements

Performance
Business Req doc requirements Reliability
requirements

User UI
Information Requirements requirements
Requirements System
Requirements
Use-Case doc

Data Model Supplementary Req Doc

Functional
Requirements

System Non-functional
Constraints Software Requirements requirements
Specification

1 - 19

19
Functional Requirements
• Business domain
• Organization practice
• Extent of automation

Scope has to be decided by all three

1 - 20

20
Non-Functional Requirements
• Performance
• Availability , Reliability
• Usability / Configurability
• Operational scalability
• Design Constraints
• Support for maintenance, re-use , enhancement
• System Constraints
• Hardware / OS platforms or legacy applications
• …

You could miss out non-functional requirements easily!

1 - 21

21
Activity: Classify these requirements
• The Personal Assistant Device (PAD) shall only be sold to customer who has
mobile phone type 1020 or fixed phone service.
• Peak transaction volume(s): 20,000 calls in a busy hour, average duration of 20
secs, grade of service 99.98%.
• Mean time to failure (MTTF) : There should be no more than three “Severity 1”
outages per month.
• Access to the PAD Personal Address Book (PAB) from the web shall be via
abc.com using Single Sign-On.
• Service Deactivation for Non-Payment will remove the PAD product and result in all
access being removed from the customer.

1 - 22

22
Activity: Classify these requirements (contd.)
• Platform logs shall be kept for at least 12 months.
• Online web pages shall conform to the ABC company standards for branding and
usability.
• All ABC company Standards shall apply.
• Incremental daily backup shall be performed.
• Users shall be able to place calls quickly and easily by simply speaking a name and
phone type (ie mobile, home or other) or number (i.e. live dial) into the phone.

1 - 23

23
Requirements - Development & Management
Requirements
Engineering
Requirements Requirements
Development Management

Elicitation Analysis Change Control Version Control

•Define vision & scope •Draw context diagram •Proposing Changes •Identifying
•Identify User classes •Model Requirements •Analysing Impact requirements doc
•Select Product •Create prototypes •Making Decisions versions
champions •Analyse feasibility •Communicating •Identifying
•Identify Use cases •Prioritise reqmts •Incorporating individual
•Hold workshops •Create data dictionary •Measuring requirements versions
•User workflow requirements stability
Specification Verification Req Tracing Status Tracking
•Adopt SRS template •Inspect reqmts docs •Defining links to •Defining reqmt
•Identify sources of •Write test cases from other reqmts statuses
reqmt reqmts •Defining links to •Tracking reqmts that
•Label each reqmt •Write a user manual other system elements have each status
•Record business rules •Define acceptance •Create traceability
criteria matrix

1 - 24

24
Boundary between RD and RM

Marketing, Customers, Management

Analyze,
Document,
Review,
Negotiate
Requirements
Development
Baselined Requirements
Requirements
current Revised Management
baseline baseline

Marketing, Requirements
Customers, Requirement Change
Project Project
Management changes changes Environment
Process

1 - 25

25
De 201 / De Bridge (OOAD) - Framework

1 - 26

26
De 201 / De Bridge (SSAD) - Framework

1 - 27

27
Summary
• Objectives of the workshop – what we will cover, and what we will not
• Definition of requirements
• Importance of requirements in software development process
• Business versus Application centric thinking
• Characteristics of good requirements
• Components of software requirements – functional and non-functional
• Activities in Requirements Engineering - Requirements Development and
Requirements Management
• Requirements Engineering Framework

1 - 28

28