Software Engineering

outline

Software Requirement Engineering

• Software requirements
• Types of Requirements
• Requirement Engineering
• Activities in Requirement Engineering
• Characteristics of requirements
• The requirements document
The objectives of this activity are:
 To introduce the concepts of user and system
requirements
 To describe functional and non-functional
requirements

Software requiremnet engineering

 To explain processes of requirement engineering

 To explain how software requirements may be

organised in a requirements document

2
I NTRODUCTION
 If you are required to develop a library
information software system, what will you do
firstly?

Software requiremnet engineering

⚫ What functions that the system may have?
⚫ What behaviors that the system may have?
⚫ What performances that the system may have?
⚫ What is the scope and boundary of the software?
⚫ ...

3
S OFTWARE REQUIREMENTS

 To understand customers‘ requirements about the

software to be developed is extremely important.
 Software requirement is the descriptions of the

Software requiremnet engineering

system services and constraints.
 Sample of software requirements
⚫ Function: borrow book, renew book, …
⚫ Performance: the time of query book must be lower 1
second
⚫ Constraints: software should be deployed and run under
windows O S
⚫ Schedule: development period is 6 months

4
 C ONT ‘ D …
 Customers are unable to express requirements
explicitly
⚫ Typically, they can not tell you what they want
clearly.

Software requiremnet engineering

 Stakeholders (Business and Technical groups)
speak different languages.
 Software requirements are often extremely
complex and large scale.
 The requirements that customers or end-users
present are often: incomplete, inaccurate, and
inconsistent.
 That is why engineering requirements is needed

5
 R EQUIREMENT E NGINEERING
 Is the process of establishing
- the services that are required of the system, and
- the constraints under which it operates and is
developed.

Software requiremnet engineering

 It covers all activities involved in discovering,
documenting and maintaining a set of
requirements for a computer- based system.
 Helps software engineers to better understand the
problem they will work to solve.
 can influence the development cost, time, effort
and quality.

6
 T YPES OF R EQUIREMENTS
1. User requirements
⚫ Often referred to as user needs, describe what
the user does with the system, such as what

Software requiremnet engineering

activities that users must be able to perform.
⚫ Are statements, in a natural language plus
diagrams, of what services the system is
expected to provide and the constraints under
which it must operate.
⚫ The term user requirements to mean high-level
abstract requirements of what the system should
do
7
Problems with natural language
 Lack of clarity & Ambiguity
⚫ Precision is difficult without making the document clear to
read; readers and writers may not interpret words in the
same way
 Over-flexibility

Software requiremnet engineering

⚫ –The same thing may be expressed in a number of different
ways
 Requirements amalgamation & confusion
⚫ –Several different requirements may be expressed together;
functional and non-functional requirements may be mixed
together
 Lack of modularization
⚫ –NL structures are inadequate to structure system
requirements
8
2. System requirements
⚫ system requirements to mean the detailed
description of what the system should do
⚫ set out the system‘s functions, services and
operational constraints in detail.
⚫ The system requirements document (sometimes

Software requiremnet engineering

called a functional specification).
⚫ It should define exactly what is to be implemented.
⚫ It may part of the contract between the system buyer
and the software developers.
⚫ System requirements are the building blocks
developers use to build the system.
⚫ System requirements may be expressed using system
models
9
3. Software specification

⚫ A detailed software description which can serve

as a basis for a design or implementation.
⚫ Bridges the gap between requirements and
design.

Software requiremnet engineering

⚫ Written for developers

10
Example definition & specification

 User Requirements definition: requirements described

in the language of problem domain
⚫ Example: The software must provide a means of
representing and accessing external files created by

Software requiremnet engineering

other tools
 System Requirements specification: requirements
described in the language of software engineering.
 Example:
⚫ It should allow the user to define the type of files.
⚫ It should be able to process every type of file defined.
⚫ Each file is to be displayed by an icon uniquely
associated with its type.
It should allow the user to choose the icon associated 11
with each file type.
 Different levels of system specification are useful
because they communicative information about
the system to different types of readers.
• Client Managers
• System end-users

Software requiremnet engineering

User Requirements
• Client engineers
• Contractor managers
• System Architects

• System end-users
• Client engineers
System Requirements
• System Architects
• Software developers

Software design • Client engineers

Specification • System Architects
• Software developers 12
 F U N C T I O N A L A N D N ON - F U N C T I O N A L R E Q U I R E M E N T S

 Software system requirements are often classified as

functional requirements, non-functional requirements.

Functional requirements - related to functional

Software requiremnet engineering

aspect of software
⚫ are statements of services the system should
provide
⚫ how the system should react to particular inputs a
⚫ how the system should behave in particular
situations.
⚫ In some cases, the functional requirements may also
explicitly state what the system should not do. 13
 Functional requirements describe functionality or
system services.
⚫ What inputs the system should accept?
⚫ What outputs the system should produce?
⚫ What data the system should store that
other systems might use?

Software requiremnet engineering

⚫ What computations the system should perform?
⚫ The timing and synchronization of the above
 Examples:
⚫ 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,
which the user shall be able to copy to the
account‘s14 permanent storage area.
Non-functional requirements- are not related to
functional aspect of software.
⚫ are constraints on the services or functions offered
by the system.
⚫ They include timing constraints, storage
requirements, reliability constraints on the

Software requiremnet engineering

development process and standards.
⚫ Non-functional requirements often apply to the
system as whole. They do not usually just apply to
individual system features or services.
 Non-functional requirements may be more critical
than functional requirements.
⚫ If these are not met, the system is useless

 Non-functional requirements may be very difficult to

state precisely and imprecise requirements may be
difficult to verify. 15
The types of non-functional requirements
are:
 Product requirements
⚫ These requirements specify product behavior.

Software requiremnet engineering

⚫ Example include performance requirements on how
fast the system must execute and how much
memory it requires; reliability requirements that set
out the acceptable failure rate; portability
requirements; and usability requirements.
 Organizational requirements
⚫ These requirements are derived from policies and
procedures in the customer‘s and developer‘s
organization.
16
 ⚫ Examples include process standards that must be
used; implementation requirements such as the
programming language or design method used;
and delivery requirements that specify when the
product and its documentation are to be delivered.
External requirements

Software requiremnet engineering


⚫ This broad heading covers all requirements that
are derived from factors external to the system
and its development process. These may include
interoperability requirements that define how the
system interacts with systems in other
organization; legislative requirements that must
be followed to ensure that the system operates
within the law; and ethical requirements.
17
Non-functional requirement types

Software requiremnet engineering

18
 Metrics for specifying non-functional requirements

Prope rty Mea sure

Sp eed Processed transaction s/seco nd
User/Ev ent resp onse time
Screen refresh t ime

Software requiremnet engineering

Size K Byt es
Number of RAM ch ip s
Ease o f use Training t ime
Number of help frames
Reliability Mean time t o failure
Probabilit y of unavailability
Rate o f failure occurren ce
Availabilit y
Ro bustn ess T i m e to restart after failure
Percentage of events causin g failure
Probabilit y of dat a corrup tion on failure
Portabilit y Percentage of target dependent statements
Number of target sy st ems 19
 D OMAIN REQUIREMENTS
 Domain requirements are derived from the
application domain rather than from specific needs
of system users.

Software requiremnet engineering

 Describe system characteristics and features that
reflect the domain
 They usually include specialized terminologies or
reference to domain concept.
 They may be new
⚫ functional requirements,
⚫ constraints on existing requirements or
⚫ define specific computations.
 If domain requirements are not satisfied, the 20
system may be unworkable.
 Example: Library System domain requirements

⚫ There shall be a standard user interface to all

databases which shall be based on the Z39.50
standard.
is design constraint that specifies user interface to the

Software requiremnet engineering


database must be implemented according to specific
library standard.
⚫ Because of copyright restrictions, some received on-
line documents must be deleted immediately after
arrival. Depending on the user‘s requirements,
these documents will either be printed locally on the
system server for manually forwarding to the user
or routed to a network printer.

21
Domain Requirement Issues

 Understandability
⚫ Requirements are expressed in the language of the
application domain.

Software requiremnet engineering

⚫ This is often not understood by software engineers developing
the system.
⚫ Involvement of domain expert may resolve the
problem.
 Implicitness
⚫ Domain specialists understand the area so well that
they do not think of making the domain requirements
explicit.
22
R EQUIREMENT E NGINEERING
 Goal: Obtain and understand software
requirements in a complete, consistent and
accurate way, and generate software requirement
specification (SRS) document.

Software requiremnet engineering

 Scope:
⚫ Communication
⚫ Planning Requirement
Engineering
⚫ Modeling
 Analysis of requirements
 Design of software

⚫ Construction
 Coding
 Testing

⚫ Deployment 23
 A CTIVITIES IN R EQ U IREMENT E NGINEERING

 The processes used for R E vary widely depending

on the application domain, the people involved and
the organisation developing the requirements.

Software requiremnet engineering

 However, there are a number of generic
activities common to all processes
⚫ Feasibility
studies
⚫ Requirements elicitation and analysis
⚫ Requirement specification
⚫ Requirements validation
⚫ Requirements change management

24
 R EQUIREMENT E NGI NE E RI NG P R O CE S S …

Software requiremnet engineering

Feasibility
study

Determining
if running the
project is
feasible

25
FEASIBILITY STUDY

A feasibility study decides whether or not

the proposed system is worthwhile.
 A short focused study that checks;

Software requiremnet engineering

⚫ If the system contributes to organisational
objectives;
⚫ If the system can be engineered using current
technology and within budget;
⚫ If the system can be integrated with other
systems that are used.

26
C ONT ‘ D …

 Based on information assessment (what is

required), information collection and report
writing.

Software requiremnet engineering

 Questions for people in the organisation
⚫ What if the system wasn‘t implemented?
⚫ What are current process problems?
⚫ How will the proposed system help?
⚫ What will be the integration problems?
⚫ Is new technology needed? What skills?
⚫ What facilities must be supported by the
proposed system?
27
 R EQUIREMENTS ELICITATION & A NALYSIS
 Requirements elicitation is the practice of collecting the
requirements of a system from users, customers and
other stakeholders.
 Sometimes referred to as "requirement gathering― or
requirements discovery.

Software requiremnet engineering

 Involves technical staff working with other stakeholders
to find out about
 the application domain
 the services that the system should provide

 the system‘s operational constraints

 Multi-disciplinary and human-centred activity.

 The most difficult, most critical, most error-prone,
and most communication-intensive aspect of
software development.
 Requirement Analysis has some tool support 28

⚫ E.g. RequisitePro, M S Visio

Problems of requirements elicitation

 Why Requirements elicitation and analysis is

a difficult process? Because
⚫ Stakeholders often don‘t know what they really
want from the computer system.

Software requiremnet engineering

⚫ Stakeholders naturally express requirements in
their own terms.
⚫ Different stakeholders have different requirements.
⚫ Political factors may influence the requirements of
the system.
⚫ The requirements change during the analysis
process. New stakeholders may emerge and the
business environment change
29
 Requirements elicitation & analysis process activities
involves:
⚫ Domain understanding
⚫ Requirement collection

Software requiremnet engineering

⚫ Classification (into coherent clusters)
⚫ Conflict resolution and identification of
unpractical requirements
⚫ Prioritization
⚫ Requirement checking (e.g. Eliminate, combined
and modified requirements)

30
 R EQUIREMENTS ANALYSIS

 Different models may be produced during the

requirements analysis activity.
 Requirements analysis may involve three

Software requiremnet engineering

structuring activities which result in these
different models
⚫ Partitioning. Identifies the structural (part-of)
relationships between entities
⚫ Abstraction. Identifies generalities among entities
⚫ Projection. Identifies different ways of looking at a
problem
 System models are covered in detail later.

31
 R EQ U I REMENTS ELICITATION T ECHNIQUES
• Requirements Elicitation is the process to find out the
requirements for an intended software system by
communicating with client, end users, system users

Software requiremnet engineering

and others who have a stake in the software system
development.
⚫ There are various ways to discover requirements
⚫ Interview
⚫ Brainstorming
⚫ Prototyping
⚫ Delphi Technique
⚫ Ethnography
⚫ Scenarios
⚫ Use cases
32
 I NTERVIEW
 Conducted through formal or informal interviews,
the R E team puts questions to stakeholders about
the system that they use (if any) and the system to

Software requiremnet engineering

be developed.
⚫ Ask about specific details
⚫ about the stakeholder‘s vision for the future
⚫ Ask if they have alternative ideas
⚫ Ask for other sources of information
⚫ Ask them to draw diagrams

 Don‘t ask questions like what do you want‘.

33
 I NTERVIEW ….
 Interviewers should be open-minded, willing to
listen to stakeholders and should not have pre-
conceived ideas about the requirements.

Software requiremnet engineering

 There are two types of interview
⚫ Closed interviews where a pre-defined set of
questions are answered.
⚫ Open interviews where there is no pre-defined
agenda and a range of issues are explored with
stakeholders.
 Normally a mix of closed and open-ended
interviewing are used together.
34
 I NTERVIEW …
 Interviews are good for getting an overall
understanding of what stakeholders do and how
they might interact with the system.

Software requiremnet engineering

 Interviews are not good for understanding domain
requirements.
⚫ Requirements engineers cannot understand specific
domain terminology;
⚫ Some domain knowledge is so familiar that people
find it hard to articulate or think that it isn‘t worth
articulating.

35
 B RAINSTORMING

 Brainstorming refers to the process of systematic

and liberal generation of a large volume of ideas
from a number of participants.

Software requiremnet engineering

 In a brainstorming session you (moderator) gather
together a group of people, create a stimulating and
focused atmosphere, and let people come up with
ideas without risk of being ridiculed.
 The facilitator notes down all ideas on a whiteboard.

 J o i n t Application Development ( J A D ) is a
technique based on intensive brainstorming sessions.
36
 P ROTOTYPING
 Software customers and end users usually find it
very difficult to express their real requirements
 Prototyping provide insight to the new

Software requiremnet engineering

functionalities by demonstrating a new prototype
⚫ The simplest kind: paper prototype.
 a set of pictures of the system that are shown to users
in sequence to explain what would happen
⚫ The most common: a mock-up of the system‘s U I
 Written in a rapid prototyping language
 Does not normally perform any computations, access any
databases or interact with any other systems
 May prototype a particular aspect of the system
37
 Can be combined with other techniques
 Software requiremnet engineering
38
P ROTOTYPING …
D ELPHI T ECHNIQUE
 The Delphi technique is an iterative technique
in which information is exchanged in a written
form until a consensus is reached.
 For example participants may write down their

Software requiremnet engineering

requirements, sorted in order of importance.
 The sets of requirements obtained are
distributed to all participants, who reflect on
them to obtain a revised set of requirements.
 The procedure will be repeated several times
until sufficient consensus is reached .

39
 E THNOGRAPHY
 Ethnography is an observational technique that
can be used to understand social and
organizational requirements.

Software requiremnet engineering

 A social scientists spends a considerable time
observing and analysing how people actually work.
 People do not have to explain or articulate their
work.
 Social and organisational factors of importance
may be observed.
 Ethnographic studies have shown that work is
usually richer and more complex than suggested
40
by simple system models.
Other requirement elicitation techniques involves:
⚫ Read documents (organizational charts,
procedures, rules, etc), manuals (user or

Software requiremnet engineering

operational manuals) and discuss requirements
with users
⚫ Shadowing important potential users as they do
their work
 ask the user to explain everything he or she is doing
⚫ Session videotapeing

41
 S CENARIOS
 Scenarios are descriptions of how a system is used
in practice.
 They are helpful in requirements elicitation as
people can relate to these more readily than

Software requiremnet engineering

abstract statement of what they require from a
system.
 Scenarios are particularly useful for adding detail
to an outline requirements description
 Scenarios descriptions include
⚫A description of the starting situation;
⚫ A description of the normal flow of events;
⚫ A description of what can go wrong;
⚫ Information about other concurrent activities;
⚫ A description of the state when the scenario finishes.42
Scenario Example: ATM

 Scenario
⚫ Tiruwork uses an ATM

Software requiremnet engineering

⚫ She enters her card and P I N into the ATM
⚫ She requests withdrawal of 4000 ETB
⚫ Tiruwork receives a printed receipt, takes out her bank
card and the money and leaves

 Observations
⚫ Describes a single instance of using the system
⚫ Does not describe all possible ways the system can be
used
43
 U S E CASES
 Use cases are a scenario-based technique for
describing requirements
 Use cases are more effective in capturing functional
requirements

Software requiremnet engineering

 Use cases identify the users of the system (actors)
 Use cases identify the tasks (use cases)
 Use cases relate the users and the tasks
 Use cases are typically illustrated with U M L as stick
figures or similar diagrams
U M L(unified Modelling Language) is a standard for
modelling object-oriented software requirements and design.
 A set of use cases should describe all possible
interactions with the system
 Sequence diagrams may be used to add detail to use-
cases by showing the sequence of event processing in 44
the system.
Software requiremnet engineering
45
Use Case Example: Withdraw

Software requiremnet engineering

Withdraw

<<include>>

Authen
ticate

. <<include>> stereotype to include use cases

Details in textual description

46
Example: Withdraw Use Case Event Flow

Actor steps System steps

1. Authenticate [Link] displays options

Software requiremnet engineering

3. Client selects ―Withdraw‖ 4. ATM queries amount

5. Client enters amount 6. ATM returns bank card

7. ATM outputs specified
amount in ET B

47
 S OFTWARE REQUIREMENTS CHARACTERISTICS

 Gathering software requirements is the

foundation of the entire software development
project. Hence they must be clear, correct and well
– defined.

Software requiremnet engineering

 Should say what, not how. Why?

 A complete Software Requirement Specifications

must be:
⚫ Correct: does what the client wants, according to
specification.
 This quality is like motherhood and apple pie—How can
you accomplish this?
 Ask the client: keep a list of questions for the client

 Prototyping: explore the risky aspects of the system with 48

the client
C ONT ‘ D ..
⚫ Verifiable/Testable: can determine whether the
requirements have been met
 But how do verify a requirement like ―user-friendly‖ or ―it
should never crash‖?

Software requiremnet engineering

⚫ Unambiguous: every requirement has only one
interpretation
⚫ Consistent: no internal conflicts
 If you call an input "Start and Stop" in one place, don't call it
"Start/Stop" in another
⚫ Complete: has everything designers need to create
the software

49
C ONT ‘ D ..

⚫ Understandable: stakeholders understand it

well enough to buy into it
 Deal only with the problem- requirements should state

Software requiremnet engineering

―what‖ is required at the appropriate system level, not
―how‖
 Can there be a tension between understandability and
the other desiderata?
⚫ Modifiable: requirements change!
 Changes should be noted and agreed upon, in the
specification.
⚫ Traceable
 Each requirement should be contained in a single,
numbered paragraph so that it may be referred to in 50
other documents
 S OFTWARE R EQUIREMENT S PECIFICATION
 It is a document created by system analyst after
the requirements are collected from various
stakeholders
 Is a complete description of the behavior of the system

Software requiremnet engineering

to be developed.
 The requirements specification document states in
precise and explicit language those functions and
capabilities a software system must provide, as well
as stating any required constraints by which the
system must abide.
 Recommended approaches for the specification of
software requirements are described by I E E E 830-
1998.
51
 G UI D E LI NE S FOR WRITING R EQUIREMENT
S PECIFICATION
 User requirements must be written in natural
languages because they have to be understood by
people who are not technical experts.

Software requiremnet engineering

 Invent a standard format and use it for all
requirements.
 Use language in a consistent way. Use shall for
mandatory requirements, and should for desirable
requirements.
 Use text highlighting to identify key parts of the
requirement.
 Avoid the use of computer jargon. 52
 C ONT ‘ D …

 However natural-language specification has

problems
⚫ Ambiguity

Software requiremnet engineering

The readers and writers of the requirement must
interpret the same words in the same way. N L 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 modularization
N L structures are inadequate to structure system
requirements
53
Alternatives to natural language

 To avoid/minimize limitations of N L specification we

have the following alternative.
⚫ Structured natural language
depends on defining standard forms or templates to express

Software requiremnet engineering


requirements specification
 E.g. Form-based node specification
⚫ Design description languages
 similar to programming languages but with additional,
more abstract features
 E.g. Program Description language (PDL)

⚫ Graphical notations
 a graphical language, supplemented by text
annotations, is used to define functional requirements
(e.g. use-case diagrams 54
 Mathematical/formal specifications
⚫ based on mathematical concepts such as finite-state
machines or sets; unambiguous specifications reduce
arguments between customers and contractors but most

Software requiremnet engineering

customers don't understand formal specifications

55
Example: structured Natural Language

Software requiremnet engineering

56
Design description languages
 uses a language like a programming language but
with more abstract features to specify the
requirements by defining an operational model of

Software requiremnet engineering

the system.
 E.g. Program Description language (PDL)
⚫ PDL- is a language derived from a programming
language like Ja va and Ada.
⚫ PDLs results in a very detailed specifications and,
sometimes, they are too close to the implementation
for inclusion in a requirement document.
⚫ This notation is only understandable to people with
programming language knowledge 57
Example: Part of an ATM specification in PDL

Software requiremnet engineering

58
Graphical notations
⚫ A graphical language, supplemented by text annotations
is used to define the functional requirements for the
system.
⚫ Examples: Structured Analysis and Design Technique
(SADT) and use-case descriptions.

Software requiremnet engineering

Mathematical specifications
⚫ notations based on mathematical concepts such as finite-
state machines or sets.
⚫ Is unambiguous specifications which reduce the
arguments between customer and contractor about
system functionality.
⚫ However, most customers don‘t understand formal
specifications and are reluctant to accept it as a system
contract. 59
R EQ U IREMENT S VALIDATION

 Concerned with demonstrating that the

requirements define the system that the

Software requiremnet engineering

customer really wants.
 Requirements error costs are high so
validation is very important
⚫ Fixinga requirements error after delivery may
cost up to 100 times the cost of fixing an
implementation error.

60
 R EQUIREMENTS VALIDATION …

 During the requirements validation process,

different types of checks should be carried out on
the requirements in the requirement document.
⚫ Validity. Does the system provide the functions

Software requiremnet engineering

which best support the customer‘s needs?
⚫ Consistency. Are there any requirements
conflicts?
⚫ Completeness. Are all functions required by the
customer included?
⚫ Realism. Can the requirements be implemented
given available budget and technology?
⚫ Verifiability. Can the requirements be checked?

61
R EQUIREMENTS VALIDATION TECHNIQUES

 Requirements reviews
⚫ Systematic manual analysis of the requirements.
 Prototyping

Software requiremnet engineering

⚫ Usingan executable model of the system to check
requirements .
 Test-case generation
⚫ Developing tests for requirements to check
testability.
 Automated consistency analysis
⚫ Checkingthe consistency of a structured
requirements description 62
R EQ U IREMENT S MANAGEMENT

 Requirements management is the process of

managing changing requirements during the
requirements engineering process and system

Software requiremnet engineering

development.
 Requirements are inevitably incomplete and
inconsistent
⚫ New requirements emerge during the process as
business needs change and a better understanding
of the system is developed;
⚫ Different viewpoints have different requirements
and these are often contradictory.
63
R EQU IREMENTS MANAGEMENT …
 Requirements change for the following
reasons:
⚫ The priority of requirements from different

Software requiremnet engineering

viewpoints changes during the development
process.
⚫ System customers may specify requirements
from a business perspective that conflict with
end-user requirements.
⚫ The business and technical environment of the
system changes during its development.

64
R EQUIREMENTS MANAGEMENT PLANNING

 Duringthe requirements engineering process,

you have to plan:

Software requiremnet engineering

⚫ Requirements identification: How requirements are
individually identified;
⚫ A change management process: The process
followed when analysing a requirements change;
⚫ Traceability policies: The amount of information
about requirements relationships that is
maintained;
⚫ C A S E tool support: The tool support required to
help manage requirements change; 65
T RACEABILITY
 Traceability is concerned with the relationships
between requirements, their sources and the
system design

Software requiremnet engineering

 Source traceability
⚫ Links from requirements to stakeholders who
proposed these requirements;
 Requirements traceability
⚫ Links between dependent requirements;
 Design traceability
⚫ Links from the requirements to the design;
66
CASE TOOL SUPPORT

 Requirements storage (Data Dictionary)

⚫ Requirements should be managed in a secure,
managed data store.
 Change management

Software requiremnet engineering

⚫ The process of change management is a workflow
process whose stages can be defined and
information flow between these stages partially
automated.
 Traceability management
⚫ Automated retrieval of the links between
requirements.

67
R EQUIRE ME NTS C H A N G E MANAGEMENT

 Should apply to all proposed changes to the

Software requiremnet engineering

requirements.
 Principal stages
⚫ Problem analysis. Discuss requirements problem
and propose change;
⚫ Change analysis and costing. Assess effects of
change on other requirements;
⚫ Change implementation. Modify requirements
document and other documents to reflect change.
68
 Software requiremnet engineering
69
MANAGEMENT
CHANGE
 T H E REQUIREMENTS DOCUMENT
 The software requirements document (sometimes called
the software requirements specification or SRS) is an
official description of a software system to be developed,
laying out functional and non-functional requirements,
and may include a set of use cases that describe

Software requiremnet engineering

interactions the users will have with the software.
 It should include both the user requirements for a
system and a detailed specification of the system
requirements.
 It is N O T a design document. As far as possible, it
should set of WHAT the system should do rather than
H O W it should do it
 Should include both a definition and a specification of
requirements.

70
 The requirements document should
⚫ specify external system behaviour
⚫ specify implementation constraints
⚫ easy to change

Software requiremnet engineering

(but changes must be managed)
⚫ serve as reference tool for maintenance
⚫ record forethought about the life cycle of the
system (i.e. predict changes)
⚫ characterise responses to unexpected events

 The requirements document has diverse set of

users ranging.
71
Users of a requirements document

Specify the requirements and

r e a d t h e m to c h e c k that they
System customers m e e t their n e e d s . T h e y
specify changes to the
requirements

U s e the requirements

Software requiremnet engineering

Managers d o c u m e n t to p l a n a b i d for
the s ys t e m a n d to p l a n the
system development process

U s e t h e r e q u i r e m e n t s to
S ystem engineers u n d e r s t a n d w h a t s y s t e m i s to
be developed

S y s t e m test U s e t h e r e q u i r e m e n t s to
engineers d e v e l o p validation tests for
the system

System U s e the r e q u i r e m e n t s to help

maintenance understand the system and
engineers t h e r e l a t i o n s h i p s b e t w e e n its
parts
72
 R EQ UIREMENTS L E V E L O F S PECIFICATIONS

• Survey shows that one of the problems with requirements

specifications was the uneven level of specification
• Different writing sytles
• Difference in experience

Software requiremnet engineering

• Different formats
• Overspecifying requirements
• Underspecifying requirements
• Recommendations to reduce unevenness
• Write each clause so that it contains only one requirement
• Avoid having one requirement refer to another requirement
• Collect similar requirements together

73
I E E E R E Q U I R E M E N T S STANDAR D
1. Introduction to the Document
1. Purpose of the Product
2. Scope of the Product

Software requiremnet engineering

3. Acronyms, Abbreviations, Definitions
4. References
5. Outline of the rest of the S R S
2. General Description of Product
1. Context of Product
2. Product Functions
3. User Characteristics
4. Constraints
5. Assumptions and Dependencies

74
3. Specific Requirements
1. External Interface Requirements
1. User Interfaces
2. Hardware Interfaces
3. Software Interfaces

Software requiremnet engineering

4. Communications Interfaces
2. Functional Requirements
1. Class 1
2. Class 2
…
3. Performance Requirements
4. Design Constraints
5. Quality Requirements
6. Other Requirements
4. Appendices
5. Index
75
 S UMMARY
 Requirements set out what the system should do and
define constraints on its operation and implementation
 Functional requirements set out services that the
system should provide

Software requiremnet engineering

 Non-functional requirements constrain the system
being developed or the development process.
 User requirements are high-level statements of what
the system should do
 User requirements should be written using 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
76
natural language, a P D L or in a formal language
 The requirements engineering process includes a
feasibility study, requirements elicitation and analysis,
requirements specification, requirement validation and
requirements management.
 Requirements elicitation and analysis is iterative
involving domain understanding, requirements

Software requiremnet engineering

collection, classification, structuring, prioritisation and
validation.
 Systems have multiple stakeholders with different
requirements.
 Social and organisation factors influence system
requirements.
 Requirements validation is concerned with checks for
validity, consistency, completeness, realism and
verifiability.
77
• Business changes inevitably lead to changing requirements.
• Requirements management includes planning and change
management.
• A software requirements document is an agreed statement of the
system requirements

Software requiremnet engineering

78