Software Engineering

Activity # 6 & 7

Software Requirement Engineering

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

engineering
Software requiremnet
system requirements
 To describe functional and non-functional

requirements
 To explain processes of requirement

engineering
 To explain how software requirements may be

organised in a requirements document 2

INTRODUCTION

 If you are required to develop a library

engineering
Software requiremnet
information software system, what will you do
firstly?
 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

 ...
 SOFTWARE REQUIREMENTS
 To understand customers‘ requirements about
the software to be developed is extremely

engineering
Software requiremnet
important.
 Software requirement is the descriptions of the
system services and constraints.
 Sample of software requirements
 Function:borrow book, renew book, …
 Performance: the time of query book must be lower 1
second 4
 Constraints: software should be deployed and run
under windows OS
 Schedule: development period is 6 months
 CONT‘D…
 Customers are unable to express
requirements explicitly

engineering
Software requiremnet
 Typically, they can not tell you what they want
clearly.
 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, 5
and inconsistent.
 That is why engineering requirements is

needed
 REQUIREMENT ENGINEERING
 Is the process of establishing
- the services that are required of the system, and

engineering
Software requiremnet
- the constraints under which it operates
and is developed.
 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
6
the problem they will work to solve.
 can influence the development cost, time,
effort and quality.
 TYPES OF REQUIREMENTS

1. User requirements

engineering
Software requiremnet
 Often referred to as user needs, describe
what the user does with the system,
such as what 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
7
which it must operate.
 The term user requirements to mean high-level
abstract requirements of what the system should
do
Problems with natural language
 Lack of clarity & Ambiguity
 Precisionis difficult without making the document clear to
read; readers and writers may not interpret words in the

engineering
Software requiremnet
same way
 Over-flexibility
 –The same thing may be expressed in a number of
different ways
 Requirements amalgamation & confusion
 –Severaldifferent requirements may be expressed
together; functional and non-functional requirements may 8
be mixed together
 Lack of modularization
 –NL structures are inadequate to structure system
requirements
2. System requirements
 system requirements to mean the detailed
description of what the system should do
 set out the system‘s functions, services and

engineering
Software requiremnet
operational constraints in detail.
 The system requirements document
(sometimes
called a functional specification).
 It should define exactly what is to be
implemented.
 It may part of the contract between the system
9
buyer and the software developers.
 System requirementsare the building
blocks developers use to build the
system.
 System requirements may be expressed using
system models
3. Software specification
 A detailed software description which can serve
as a basis for a design or implementation.

engineering
Software requiremnet
 Bridges the gap between requirements and
design.
 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

engineering
Software requiremnet
representing and accessing external files created
by 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 11

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

engineering
Software requiremnet
User Requirements  System end-users
 Client engineers
 Contractor managers
 System Architects
 System end-users
System Requirements  Client engineers
 System Architects
 Software developers

Software design  Client engineers

Specification  System Architects
12
 Software developers
 FUNCTIONAL AND NON-FUNCTIONAL REQUIREMENTS
 Software system requirements are often classified as
functional requirements, non-functional requirements.

engineering
Software requiremnet
Functional requirements -related to
functional aspect of software
 are statements of services the system
should provide
 how the system should react to particular
inputs a 13
 how the system should behave in particular
situations.
 In some cases, the functional requirements
may also
explicitly state what the system should not
do.
 Functional requirements describe functionality or
system services.
 What inputs the system should accept?
 What outputs the system should produce?

engineering
Software requiremnet
 What data the system should store that
other systems might use?
 What computations the system should
perform?
 The timing and synchronization of the
above
 Examples:
14
 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
Non-functional requirements- are not related
to functional aspect of software.
 are constraints on the services or functions
offered by the system.

engineering
Software requiremnet
 They include timing constraints, storage
requirements, reliability constraints on
the 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.
15
 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.
The types of non-functional requirements
are:
 Product requirements
 These requirements specify product behavior.

engineering
Software requiremnet
 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 16
 These requirements are derived from policies and
procedures in the customer‘s and developer‘s
organization.
  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

engineering
Software requiremnet
delivered.
 External requirements
 Thisbroad 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 17
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.
 Software requiremnet

1
8
engineering

requirement types
Non-functional

18
 Metrics for specifying non-functional
requirements
Prope rt y Mea sure
Sp eed Pr ocessed tr ansaction s/seco nd User /Ev en t resp
onse time Screen r ef resh t ime

engineering
Software requiremnet
Size K Byt es
Number of RAM ch ip s
Ease o f use T r aining t ime
Number of h e l p frames
Reliability M e a n t i m e t o failure
Pr obabilit y of unavailability Rate o f failure
o ccurr en ce Availabilit y

Ro bustn ess 19
T i m e t o restart a f t e r failure Percent age of events
causin g failur e
Pr obabilit y of dat a co rr up tion on f ailur e
Po rt abilit y Percent age of t ar get dependent statemen ts
Number of t ar get sy st ems
 DOMAIN REQUIREMENTS
 Domain requirements are derived from the
application domain rather than from specific needs
of system users.

engineering
Software requiremnet
 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, 20
 constraints on existing requirements or
 define specific computations.
 If domain requirements are not satisfied, the
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.

engineering
Software requiremnet
 is design constraint that specifies user interface to the
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 21

the system server for manually forwarding to the

user or routed to a network printer.
Domain Requirement Issues
 Understandability
 Requirements are expressed in the language of the

engineering
Software requiremnet
application domain.
 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 22
they do not think of making the domain requirements
explicit.
REQUIREMENT ENGINEERING
 Goal: Obtain and understand software
requirements in a complete, consistent and
accurate way, and generate software

engineering
Software requiremnet
requirement specification (SRS) document.
 Scope:
Requirement
 Communication Engineering
 Planning
 Modeling
 Analysis of requirements
 Design of software 23
 Construction
 Coding
 Testing

 Deployment
 ACTIVITIES IN REQUIREMENT ENGINEERING
 The processes used for RE vary widely depending
on the application domain, the people involved
and the organisation developing the

engineering
Software requiremnet
requirements.
 However, there are a number of generic
activities common to all processes
 Feasibility
studies
 Requirements elicitation and analysis
 Requirement specification 24
 Requirements validation
 Requirements change management
 REQUIREMENT ENGINEERING PROCESS…

engineering
Software requiremnet
Feasibilit
y
study

Determining
if running the
project is
feasible

25
FEASIBILITY STUDY

A feasibility study decides whether or not the

engineering
Software requiremnet
proposed system is worthwhile.
 A short focused study that checks;
 If the system contributes to organisational
objectives;
 If the system can be engineered using current
technology and within budget;
26
 If the system can be integrated with other
systems that are used.
CONT‘D…
 Based on information assessment (what is
required), information collection and report

engineering
Software requiremnet
writing.
 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?
27
 What facilities must be supported by the
proposed system?
 REQUIREMENTS ELICITATION & ANALYSIS
 Requirements elicitation is the practice of collecting the
requirements of a system from users, customers and
other stakeholders.

engineering
Software requiremnet
 Sometimes referred to as "requirement gathering― or
requirements discovery.
 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 28
most communication-intensive aspect of software
development.
 Requirement Analysis has some tool support
 E.g. RequisitePro, MS Visio
 Problems of requirements elicitation

 Why Requirements elicitation and analysis is a difficult

engineering
Software requiremnet
process? Because

 Stakeholders often don‘t know what they really

want from the computer system.
 Stakeholders naturally express requirements in their own
terms.
29
 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
 Requirements elicitation & analysis process
activities involves:
 Domain understanding

engineering
Software requiremnet
 Requirement collection
 Classification (into coherent clusters)
 Conflict resolution and identification
of unpractical requirements
 Prioritization
 Requirement checking (e.g. Eliminate, combined
and modified requirements) 30
 REQUIREMENTS ANALYSIS
 Different models may be produced during
the requirements analysis activity.
 Requirements analysis may involve three

engineering
Software requiremnet
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
31
a problem
 System models are covered in detail later.
 REQUIREMENTS ELICITATION TECHNIQUES
• Requirements Elicitation is the process to find out
the requirements for an intended software
system by communicating with client, end users,

engineering
Software requiremnet
system users and others who have a stake in the
software system development.
 There are various ways to discover requirements
 Interview
 Brainstorming
 Prototyping
 Delphi Technique 32
 Ethnography
 Scenarios
 Use cases
 INTERVIEW

 Conducted through formal or informal interviews,

engineering
Software requiremnet
the RE team puts questions to stakeholders about
the system that they use (if any) and the system
to 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 33

 Ask them to draw diagrams

 Don‘t ask questions like ‗what do you want‘.
 INTERVIEW….
 Interviewers should be open-minded, willing to
listen to stakeholders and should not have
pre- conceived ideas about the requirements.

engineering
Software requiremnet
 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.
34
 Normally a mix of closed and open-
ended interviewing are used together.
 INTERVIEW…
 Interviews are good for getting an overall
understanding of what stakeholders do and how

engineering
Software requiremnet
they might interact with the system.
 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 35
articulating.
 BRAINSTORMING
 Brainstorming refers to the process of systematic
and liberal generation of a large volume of ideas
from a number of participants.

engineering
Software requiremnet
 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.
36

 Joint Application Development (JAD) is a

technique based on intensive brainstorming
sessions.
 PROTOTYPING
 Software customers and end users usually find it
very difficult to express their real requirements
 Prototyping provide insight to the new

engineering
Software requiremnet
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 UI
37
 Can Written
be combined
in a rapidwith other techniques
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
 Software requiremnet

3
8
engineering

38
PROTOTYPIN
G…
DELPHI TECHNIQUE
 The Delphi technique is an iterative technique
in which information is exchanged in a written
form until a consensus is reached.

engineering
Software requiremnet
 For example participants may write down their
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
 ETHNOGRAPHY
 Ethnography is an observational technique that
can be used to understand social and
organizational requirements.

engineering
Software requiremnet
 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 40
by simple system
may be observed.
models.
 Ethnographic studies have shown that work is

usually richer and more complex than

suggested
Other requirement elicitation techniques involves:
 Read documents (organizational charts,
procedures, rules, etc), manuals (user or

engineering
Software requiremnet
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
 SCENARIOS
 Scenarios are descriptions of how a system is
used in practice.
 They are helpful in requirements elicitation as

engineering
Software requiremnet
people can relate to these more readily than
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; 42

 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

engineering
Software requiremnet
 She enters her card and PIN 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 43

 Does not describe all possible ways the system can

be used
43
 USE CASES
 Use cases are a scenario-based technique
for describing requirements
 Use cases are more effective in capturing
functional requirements

engineering
Software requiremnet
 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 UML as stick
figures or similar diagrams
 UML (unified Modelling Language) is a standard for
modelling object-oriented software requirements and
44
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 the system.
Software requiremnet

4
5
engineering

45
Use Case Example:
Withdraw

engineering
Software requiremnet
Withdraw

<<include>>

Authen
ticate

. <<include>> stereotype to include use 46

cases Details in textual description
Example: Withdraw Use Case Event Flow

Actor steps System steps

engineering
Software requiremnet
1. Authenticate 2.ATM displays options

3.
5. Client
Client selects ―Withdraw‖ 6.
enters amount 4. ATM
ATM returns
queriesbank
amount
card
7. ATM outputs
specified amount in
ETB
47
 SOFTWARE REQUIREMENTS CHARACTERISTICS
 Gathering software requirementsis the
foundation of the entire software
development

engineering
Software requiremnet
project. Hence they must be clear,
correct and well
– defined.
 Should say what, not how. Why?

 A complete Software Requirement

Specifications must be:

48
 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
CONT‘D..
 Verifiable/Testable:can determine whether the
requirements have been met
 But how do verify a requirement like ―user-friendly‖ or ―it

engineering
Software requiremnet
should never crash‖?
 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 49
 Complete: has everything designers need to
create the software
CONT‘D..
 Understandable: stakeholders understand it
well enough to buy into it

engineering
Software requiremnet
 Deal only with the problem- requirements should state
―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. 50

 Traceable
 Each requirement should be contained in a single,
numbered paragraph so that it may be referred to in
other documents
 SOFTWARE REQUIREMENT SPECIFICATION
 It is a documentcreated by system analyst after
the requirements arecollected from
various stakeholders

engineering
Software requiremnet
 Is a complete description of the behavior of the
system
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. 51

 Recommended approaches for the specification of

software requirements are described by IEEE 830-
1998.
 GUIDELINES FOR WRITING REQUIREMENT
SPECIFICATION
 User requirements must be written in natural
languages because they have to be understood

engineering
Software requiremnet
by people who are not technical experts.
 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.
52
 Use text highlighting to identify key parts of the

requirement.
 Avoid the use of computer jargon.
 CONT‘D…
 Howevernatural-language specification has
problems

engineering
Software requiremnet
 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
53
 Lack of modularization
NL structures are inadequate to structure system
requirements
Alternatives to natural
language
 To avoid/minimize limitations of NL specification we
have the following alternative.
 Structured natural language

engineering
Software requiremnet
 depends on defining standard forms or templates to
express 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)
(e.g. use-case
 Graphical 54
notations
diagrams
 a graphical language, supplemented by text

annotations, is used to define functional requirements

 Mathematical/formal specifications
 basedon mathematical concepts such as finite-state
machines or sets; unambiguous specifications reduce

engineering
Software requiremnet
arguments between customers and contractors but
most customers don't understand formal specifications

55
 Desalegn Software requiremnet

5
6
A engineering

Example: structured
Natural Language

56
Design description
 uses a language like a programming language
languages
but with more abstract features to specify the

engineering
Software requiremnet
requirements by defining an operational model of
the system.
 E.g. Program Description language (PDL)
 PDL- is a language derived from a programming
language like Java and Ada.
 PDLs results in a very detailed specifications and,
sometimes,
programming they are too close to the
language 57
implementation
knowledge for inclusion in a requirement
document.
 This notation is only understandable to people with
Example: Part of an ATM
specification in PDL e
s
a
le
gn
A

So
ft
w
a
re
re
qu
ire
m
ne

t
en
58g
in
e
eri
n
g
Graphical
 A graphical language, supplemented by text
notations
annotations is used to define the functional
requirements for the system.
 Examples: Structured Analysis and Design Technique

engineering
Software requiremnet
(SADT) and use-case descriptions.

Mathematical specifications
 notations based on mathematical concepts such as finite-
state machines or sets.
 Is unambiguous specifications which reduce the
arguments
contract between customer and contractor about 59
.system functionality.
 However, most customers don‘t understand formal
specifications and are reluctant to accept it as a system
REQUIREMENTS VALIDATION
 Concerned with demonstrating that the

engineering
Software requiremnet
requirements define the system that the
customer really wants.
 Requirements error costs are high so

validation is very important

 Fixing
a requirements error after delivery may
cost up to 100 times the cost of fixing an
60
implementation error.
 REQUIREMENTS VALIDATION…
 During the requirements validation process,
different types of checks should be carried out
on the requirements in the requirement

engineering
Software requiremnet
document.
 Validity. Does the system provide the functions
which best support the customer‘s needs?
 Consistency. Are there any requirements
conflicts?
 Completeness. Are all functions required by the
customer included? 61
 Realism. Can the requirements be implemented
given available budget and technology?
 Verifiability. Can the requirements be checked?
REQUIREMENTS VALIDATION TECHNIQUES
 Requirements reviews
 Systematic manual analysis of the requirements.

engineering
Software requiremnet
 Prototyping
 Using
an executable model of the system to
check requirements.
 Test-case generation
 Developing tests for requirements to check
testability.
62
 Automated consistency analysis
 Checkingthe consistency of a structured
requirements description
REQUIREMENTS MANAGEMENT
 Requirements management is the process of
managing changing requirements during the

engineering
Software requiremnet
requirements engineering process and
system 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; 63

 Different viewpoints have different requirements

and these are often contradictory.
REQUIREMENTS MANAGEMENT …
 Requirements change for the following
reasons:

engineering
Software requiremnet
 The priority of requirements from different
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
64
system changes during its development.
REQUIREMENTS MANAGEMENT PLANNING
 Duringthe requirements engineering process,
you have to plan:

engineering
Software requiremnet
 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 65
help manage requirements
maintained;
change;
 CASE tool support: The tool support required to
TRACEABILITY
 Traceability is concerned with the relationships
between requirements, their sources and the

engineering
Software requiremnet
system design
 Source traceability

 Linksfrom requirements to stakeholders who

proposed these requirements;
 Requirements traceability
 Links between dependent requirements; 66
 Design traceability
 Links from the requirements to the design;
CASE TOOL SUPPORT
 Requirements storage (Data Dictionary)
 Requirements
should be managed in a secure,
managed data store.

engineering
Software requiremnet
 Change management
 The process of change management is a
workflow process whose stages can be defined
and information flow between these stages
partially automated.
 Traceability management
 Automatedretrieval of the links between
requirements. 67
REQUIREMENTS CHANGE MANAGEMENT

 Should apply to all proposed changes to

engineering
Software requiremnet
the 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 68

document and other documents to reflect

change.
 Software requiremnet

6
9
engineering

MANAGEMENT

69
CHANGE
 THE 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

engineering
Software requiremnet
requirements, and may include a set of use cases that
describe 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 NOT a design document. As far as possible, it
should set of WHAT the system should do rather than 70
HOW it should do it
 Should include both a definition and a specification of
requirements.
 The requirements document should
 specify external system behaviour
 specify implementation constraints

engineering
Software requiremnet
 easy to change
(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 71

 The requirements document has diverse set

of users ranging.
Users of a requirements
document Specify the requirements and
System customers r ead t h e m to c h e c k that t h ey
m e e t their n e e d s . T h e y
specify changes to the
requirements
Use the requirements

engineering
Software requiremnet
Managers d o c u m e n t to p l a n a b i d for
the s y s t e m a n d to p l a n the
system development process
U s e the r e q u i r e m e n t s to
System engineers u n d e r s t a n d w h a t s y s t e m is to
be developed

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

System U s e the r e q u i r e m e n t s to h e l p
m a in te n a n c e understand the system an d
engineers the relationships b e t w e e n its
parts 72
 REQUIREMENTS LEVEL OF SPECIFICATIONS
• Survey shows that one of the problems with
requirements specifications was the uneven level of
specification

engineering
Software requiremnet
• Different writing sytles
• Difference in experience
• Different formats
• Overspecifying requirements
• Underspecifying requirements
• Recommendations to reduce unevenness
• Write each clause so that it contains only one requirement
73
• Avoid having one requirement refer to another requirement
• Collect similar requirements together
IEEE REQUIREMENTS STANDARD
1. Introduction to the Document
1. Purpose of the Product

engineering
Software requiremnet
2. Scope of the Product
3. Acronyms, Abbreviations, Definitions
4. References
5. Outline of the rest of the SRS
2. General Description of Product
1. Context of Product
2. Product Functions
3. User Characteristics
4. Constraints 74
5. Assumptions and Dependencies
3. Specific Requirements
1. External Interface Requirements
1. User Interfaces
2. Hardware Interfaces

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

engineering
Software requiremnet
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
 User requirements should be written using natural
language, tables and diagrams 76
natural language,
 System a PDL
requirements areorintended
in a formal language
to communicate
the functions that the system should provide
 System requirements may be written in structured
 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

engineering
Software requiremnet
involving domain understanding, requirements
collection, classification, structuring, prioritisation and
validation.
 Systems have multiple stakeholders with different
requirements.
 Social and organisation factors influence system
requirements. 77
 Requirements validation is concerned with checks for
validity, consistency, completeness, realism and
verifiability.
• 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

engineering
Software requiremnet
78
Software requiremnet

8
0
engineering

79