CHPTER ONE

Fundamentals of Requirement Analysis

Mulugeta A.
Objective
 To understand the concepts of user and system requirements

 To understand the concepts of requirement analysis

 To understand functional / non-functional requirements

 To identify key activities in requirement analysis

 To identify basic requirements of requirement specification

document
 To Understand how requirements are documented (the SRS

document)

2
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

3
Activities in Requirement Engineering
 Stakeholder identification
 Stakeholder interviews
 Contract-style requirement lists
 Measurable goals
 Prototypes
 Use cases

4
What is requirements
 It may range from a high-level abstract statement of a
service or of a system constraint to a detailed
mathematical functional specification
 This is inevitable as requirements may serve a dual function
 May be the basis for a bid for a contract - therefore must be open to
interpretation
 May be the basis for the contract itself - therefore must be defined
in detail
 Both these statements may be called requirements

5
Types of requirement
User requirements
Statements in natural language plus diagrams of the services the system provides and its

operational constraints.
Written for customers

System requirements
A structured document setting out detailed descriptions of the system services.
Written as a contract between client and contractor

Software specification
A detailed software description which can serve as a basis for a design or implementation.
Written for developers

6
Requirement Engineering Process(more on chapter two)

 The processes used for RE vary widely depending on the application

domain, the people involved and the organisation developing the
requirements
 However, there are a number of generic activities common to all
processes
 Requirements elicitation
 Requirements analysis
 Requirement Specification
 Requirements validation/verification
 Requirements management
7
Software Requirement Analysis
 Determining the needs or conditions to meet for a new or
altered product,
 In other words, process of studying and analyzing the customer
and the user/stakeholder needs to arrive at a definition of
software requirements.
 Requirements must be actionable, measurable, testable,
related to identified business needs or opportunities, and
defined to a level of detail sufficient for system design.
 Requirements can be functional and non-functional.

8
Requirements vs. Design
Requirements Design

Describe what will be delivered Describe how it will be done

Primary goal of analysis: Primary goal of design:

UNDERSTANDING OPTIMIZATION

There is more than one solution There is only one (final) solution

Customer interested Customer not interested (Most of

the time) except for external

9
Cont.
 In principle, requirements should state what the system
should do and the design should describe how it does this
 In practice, requirements and design are inseparable
 A system architecture may be designed to structure the
requirements
 The system may inter-operate with other systems that
generate design requirements
 The use of a specific design may be a domain requirement

10
Requirements readers
Client managers
System end-users
User requirements Client engineers
Contractor managers
System architects

System end-users
Client engineers
System requirements
System architects
Software developers

Client engineers (perhaps)

Software design
System architects
specification
Software developers

11
Functional and non-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.

 Non-functional requirements
 Constraints on the services or functions offered by the system such as
timing constraints, constraints on the development process, standards,
etc.

 Domain requirements
 Requirements that come from the application domain of the system and
that reflect characteristics of that domain

12
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 high-level statements of
what the system should do BUT functional system requirements
should describe the system services in detail

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

14
Requirements imprecision
 Problems arise when requirements are not precisely stated
 Ambiguous requirements may be interpreted in different ways
by developers and users
 Consider the term ‘appropriate viewers’
 User intention - special purpose viewer for each different
document type
 Developer interpretation - Provide a text viewer that shows
the contents of the document

15
Requirements completeness and consistency
 In principle requirements should be both complete and
consistent
 Complete
 They should include descriptions of all facilities required

 Consistent
 There should be no conflicts or contradictions in the descriptions of
the system facilities

 In practice, it is very difficult or impossible to produce a

complete and consistent requirements document

16
Non-functional requirements
 Define system properties and constraints e.g. reliability,
response time and storage requirements.
 Constraints are I/O device capability, system representations, etc.

 Non-functional requirements may be more critical than

functional requirements.
 If these are not met, the system is useless

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

18
Non-functional requirement types
Non-functional
requir ements

Product Or ganizational External

requir ements requir ements requirements

Ef ficiency Reliability Portability Interoperability Ethical

requir ements requir ements requirements requirements requirements

Usability Delivery Implementation Standards Legislative

requirements requirements requir ements requirements requirements

Performance Space Privacy Safety

requirements requir ements requirements requirements

19
 Goals and requirements
 Non-functional requirements may be very difficult to state
precisely and imprecise requirements may be difficult to verify.
 Goal
 A general intention of the user such as ease of use

 Verifiable non-functional requirement

 A statement using some measure that can be objectively tested

 Goals are helpful to developers as they convey the intentions

of the system users

20
Examples
 A system goal
 The system should be easy to use by experienced
controllers and should be organised in such a way that user
errors are minimised.

 A verifiable non-functional requirement

 Experienced controllers shall be able to use all the system
functions after a total of two hours training.
 After this training, the average number of errors made by
experienced users shall not exceed two per day.
21
Requirements measures
Property Measure
Speed Processed transactions/second
User/Event response time
Screen refresh time
Size K Bytes
Number of RAM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systems

22
Requirements interaction
 Conflicts between different non-functional requirements
are common in complex systems
 Spacecraft system
 To minimise weight, the number of separate chips in the system
should be minimised
 To minimise power consumption, lower power chips should be used
 However, using low power chips may mean that more chips have

to be used.

 Which is the most critical requirement?

23
Domain requirements
 Derived from the application domain and describe system
characteristics and features that reflect the domain
 May be new functional requirements, constraints on existing
requirements or define specific computations
 If domain requirements are not satisfied, the system may be
unworkable

24
User requirements
 Should describe functional and non-functional requirements so that
they are understandable by system users who don’t have detailed
technical knowledge
 User requirements are defined using natural language, tables and
diagrams

25
Problems with natural language

 Lack of clarity
 Precision is difficult without making the document difficult to

read

 Requirements confusion
 Functional and non-functional requirements tend to be mixed-up

 Requirements amalgamation/unification
 Several different requirements may be expressed together

26
 Cont.

 Ambiguity

 The readers and writers of the requirement must interpret the same

words in the same way. NL is naturally ambiguous so this is very difficult

 Over-flexibility

 The same thing may be said in a number of different ways in the

specification

 Lack of modularisation
 NL structures are inadequate to structure system requirements

27
Structured language specifications
 A limited form of natural language may be used to express requirements
 This removes some of the problems resulting from ambiguity and
flexibility and imposes a degree of uniformity on a specification

Special-purpose forms where designed to

describe the input, output and functions of a
software system

 Often best supported using a forms-based approach

28
Form-based specifications
 Definition of the function or entity
 Description of inputs and where they come from
 Description of outputs and where they go to
 Indication of other entities required
 Pre and post conditions (if appropriate)
 The side effects (if any)

29
Basic Responsibilities of Requirements Analysis
 Defining Stakeholder profiles
 Description - brief description of the stakeholder type
 Type- Qualify their expertise, technical background, degree of sophistication
 Responsibilities - List their key responsibilities with regard to the system
being developed - why a stakeholder?
 Success Criteria - How does the stakeholder define success? How rewarded?
 Involvement - involved in the project in what way? Requirements reviewer,
system tester, ...
 Deliverables* - required by the stakeholder
 Comments/Issues - Problems that interfere w/ success, etc.

30
Cont.
 Defining User Profiles
 Description - of the user type
 Type - qualify expertise, technical background, degree of sophistication
 Responsibilities - user’s key resp.’s w.r.t. system being developed
 Success Criteria - how this user defines success? rewarded?
 Involvement - How user involved in this project? what role?
 Deliverables - Are there any deliverables the user produces? For whom?
 Comments/Issues - Problems that interfere w/ success, etc.
 This includes trends that make the user’s job easier or harder

31
Cont.
 Defining User Work Environment
 Number of people involved in doing this now? Changing?
 How long is a task cycle now? Changing?
 Any unique environmental constraints: mobile, outdoors, in-flight, etc.
 Which system platforms are in use today? future?
 What other applications are in use? Need to integrate?

32
Cont.
 Product Overview
 Put the product in perspective to other related products and the
user’s environment.
 Independent?
 Component of a larger system?
 How do the subsystems interact with this?
 Known interfaces between them and this component?
 Block diagram

33
Cont.
 Other Product Requirements
 Hardware platform requirements --
 System requirements -- supported host o.s.’s, peripherals, companion
software
 Environmental requirements -- temperature, shock, humidity,
radiation, usage conditions, resource availability, maintenance
issues, type of error recovery
 Applicable standards -- legal, regulatory, communications

34
The requirements document
 The requirements document is the official statement of what is
required of the system developers

 Should include both a definition and a specification of

requirements

 It is NOT a design document. As far as possible, it should set of

WHAT the system should do rather than HOW it should do it

35
Users of a requirements document
Speci fy t he req uiremen ts and
read th em to ch eck t hat t hey
Sy st em cus to mers meet th eir n eeds . Th ey
s pecify ch ang es t o th e
requ iremen ts

Us e t he req ui rement s
Manag ers d ocumen t to pl an a bi d for
t he s ys tem an d to pl an th e
sy st em dev elo pmen t p roces s

Us e t he req ui rement s to
Sy st em eng in eers un ders tan d wh at s ys tem i s to
b e dev elo ped

Sy st em tes t Us e t he req ui rement s to

eng in eers d ev elo p val id ati on tes ts fo r
t he s ys tem

Sy st em Us e t he req ui rement s to hel p

main ten ance u nd ers tan d th e sy st em an d
eng in eers t he rel ati on sh ip s b etw een it s
p art s

36
Guidelines for writing requirements
 Invent a standard format and use it for all requirements
 Use language in a consistent way. Use
 shall for mandatory requirements,
 should for desirable requirements

 Use text highlighting to identify key parts of the

requirement

Avoid the use of computer jargon !!!

37
Requirements document requirements
 Specify external system behaviour
 Specify implementation constraints
 Easy to change
 Serve as reference tool for maintenance
 Record forethought about the life cycle of the
system i.e. predict changes
 Characterise responses to unexpected events

38
IEEE requirements standard
 Introduction
 General description
 Specific requirements
 Appendices
 Index
 This is a generic structure that must be
instantiated for specific systems

39
Requirements document structure
 Introduction
 Glossary
 User requirements definition
 System architecture
 System requirements specification
 System models
 System evolution
 Appendices
 Index

40
Software Requirement Specification
 A software requirements specification (SRS) is a complete
description of the behavior of the system to be developed
 A document that clearly and precisely describes, each of the
essential requirements of the software and the external
interfaces.
 (functions, performance, design constraint, and quality attributes)

 Each requirement is defined in such a way that its achievement

is capable of being objectively verified by a prescribed
method; for example inspection, demonstration, analysis, or
test.
41
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

42
Cont.
 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, or in a formal language
 A software requirements document is an agreed statement of the
system requirements.

43
End of Chapter1