Lecture 1

Software Requirement Engineering

Requirement Engineering Process
2. Requirement Analysis
The purpose of the requirements analysis activity is
 to analyses the gathered requirements
 to remove all ambiguities, incompleteness, and inconsistencies from the
gathered requirements and
 to obtain a clear understanding of the software to be developed
 to produces the requirements specification document.
Before carrying out analysis: The basic questions about the project should
be clearly understood by the analyst.
 What is the problem?
 Why is it important to solve the problem?
 What exactly are the data input to the system and what exactly are the data
output by the system?
 What are the possible procedures that need to be followed to solve the
problem?
 What are the likely complexities that might arise while solving the problem?
 If there are external software or hardware with which the developed software
has to interface, then what should be the data interchange formats with the
external systems?
Three Types of Problems in the Requirements
The Three Types of requirements problems:
1) Anomaly Problems
2) Inconsistency Problems
3) Incompleteness Problems
Anomaly Problems
An ambiguity in a requirement
Example of anomalous requirements – 1
 Requirements for a process control application state that
1
“When the temperature becomes high, the heater should be switched off.”
 If the threshold above which the temperature can be considered to be high is
not specified, then it can be interpreted differently by different developers.
 the words such as “high”, “low”, “good”,“bad” etc. are lack of quantification
and ambiguous requirements
Example of anomalous requirements – 2
 one office clerk described the following requirement:
 “During the final grade computation, if any student scores a sufficiently low
grade in a semester, then his parents would need to be informed.”
 It lacks any well defined criterion as towhat can be considered as a
“sufficiently low grade”.
Inconsistency Problems
Two requirements are said to be inconsistent, if one of the requirements
contradicts the other.
Example 1. Two requirements that were collected from two different
stakeholders in a process control application
 “The furnace should be switched-off when the temperature of the furnace rises
above 500ºC.”
 “When the temperature of the furnace rises above 500ºC, the water shower
should be switched-on and the furnace should remain on.”
 Example 2. Two clerks gave the following requirements
 “A student securing fail grades in three or more subjects must repeat the
courses over an entire semester, and he cannot credit any other courses while
repeating the courses.”
 “There is no provision for any student to repeat a semester; the student should
clear the subject by taking it as an extra subject in any later semester.
Incompleteness Problems
Some requirements have been overlooked / missing.
Example 1. One of the clerks expressed the
following-
 “If a student secures a grade point average (GPA) of less than 6, then the
parents of the student must be intimated about the regrettable performance
2
through a (postal) letter as well as through e-mail.”
 However, on an examination of all requirements, it was found that there is no
provision by which either the postal or email address of the parents of the
students can be entered into the system.
Example 2. In a chemical plant automation software, suppose one of the
requirements is that
 “If the internal temperature of the reactor exceeds
200ºC then an alarm bell must be sounded.”
 However, on an examination of all requirements, it was found that there is no
provision for resetting the alarm bell after the temperature has been brought down
in any of the requirements.
Domain Requirement Analysis

Domain requirements are derived from the application domain, the

environment in which the system operates
 They describe system characteristics and features that reflect the domain
 They are important because they reflect fundamentals of the application
domain.
 If these requirements are not satisfied, the system may be unworkable.
 They may be expressed using specialized domain terminology or reference to
domain concepts.
 Requirements specification has to include a description of how to carry out
some computations.
3
Problems concerning Application-Domain Requirements
Understandability
 Requirements are expressed in the language of the application domain
 This is often not understood by software engineers developing the system
 Implicitness / Tacit knowledge
 Domain specialists understand the area so well that they do not think of
making the domain requirements explicit
 People are often unaware of the tacit knowledge they possess and therefore
cannot express it to others
Domain Requirement Specification
Example: the insulin pump system
 Domain Requirement R:
 “The system safety shall be assured according to standard IEC 60601-
1:Medical Electrical Equipment – Part 1:General Requirements for Basic Safety
and Essential Performance.”
Domain Properties D:
 This requirement is standard to ensure that the system do not violate it.
Constrain C:
 The domain standard constrains both the design of the device and the
development process.
Other requirements have to be checked against this
standard.
Example: Automated train protection system
Domain Requirement R:
 “Stops a train if it goes through a red signal.”
Domain Properties D:
 This requirement is the operation of railway systems and train
characteristics. (how the train deceleration is computed by the system).
Constrain C:
 The deceleration of the train shall be computed as:
D (train) = D (control) + D (gradient)
Requirement Specification

4
The process of writing down the user and system requirements in a
requirements document.
After the gathered requirements are analyzed and has removed all
incompleteness, inconsistencies, and anomalies,
The analyst starts to systematically organize the requirements in the form of an
requirements specification (SRS) document.
SRS document is
the most important document and the toughest to write.
provides the needs of a wide variety of audience/ users.
Three important factors to be considered are:
1. the level of detail
The specification should specify what the system should do rather than how it
should do it.
the specification should ideally be the users’ view of the system rather than
anything about how the system is to be implemented.
2. to whom the document is addressed
the specification has to be understood by two different sets of people – the users
and the developers.
3. the notation used.
to describe the requirement specification to be understood by the users and the
developers.
The users will have a preference for non-technical descriptions expressed in
natural language.
the analysts will probably want to use precise (perhaps mathematical) notation
5
Users of an SRS document

 Users, customers, and marketing personnel

 Software developers
 Test engineers
 User documentation writers
 Project managers
 Maintenance engineers

Why of a well-formulated SRS Document is Importance?

Forms an agreement between the customers and the developers
Reduces future reworks
Provides a basis for estimating costs and schedules

6
Provides a baseline for validation and verification
Facilitates future extensions
Characteristics of a Good SRS Document
IEEE Recommended Practice for Software Requirements
Specifications [IEEE830, 1998]
describes the content and qualities of a good software requirements
specification (SRS).
Some desirable qualities of SRS document are
Concise, unambiguous, consistent, complete
Implementation independent
Traceable
Modifiable
Identification of response to undesired events
verifiable
Attributes of Bad SRS Documents
Try to avoid following problems while writing an SRS document
Over specification
address the “how to” aspects as it restricts the freedom of the designers
E.g., defined records needs to store index on the member’s first name or
memberID
Forward references
should not refer to aspects that are discussed much later in the SRS
document
Wishful thinking
Problems that would be difficult to implement.
Noise
presence of material not directly relevant
Focus of a SRS Document
A requirement specification document contains:
An overview of what the system should do.
A description of the requirements.
A list of the functional requirements.
7
The requirements specification document doesn't contain:
Any information about the algorithms and logic.
Description of the User Interface.
Any detail about data entities.
Meaningless technical specifications.
Poor requirements engineering is one of the reasons why a software
engineering project can fail or produce a highly defective piece of software.
SRS Document

The structure of a Specification Document

A requirements specification will usually be written in natural language
A clear structure to a specification is to partition it into parts.
Software essentially consists of the combination of data and actions.
The corresponding elements are called functional and data requirements
The format of a specification will tend to reflect the system development
method being employed.
Here, we will discuss the IEEE-830, 1998 standard as a guideline for
organizing a requirements specification document that divides requirements
into sections and allows the flexibility of tailoring it
Checklist for the contents of a SRS
1. The functional requirements:
They state what the system should do.
2. The data requirements:
Data requirements have three components: Input Data, Data to be stored, Data
8
transfer
3. Performance requirements:
These are measures of performance, some of which are quantitative, and some
of which can be used as part of testing. Examples are: cost, delivery date,
response times, data volumes (e.g., 10,000 employees). loading levels to be coped
with(e.g. able to cope with 100 transactions per minute ), reliability requirements
(e.g., the system mean time failure of six months), and security requirements
4. Constraints:
Constraints often address implementation of a system (e.g. the specification of
the programming
language).
5. Guidelines:
A guideline provides useful direction for the implementation in a situation
where there may be more than one implementation strategy. e.g., the usage of
main memory should be as small as possible.
Important Categories of Customer Requirements SRS Documents – IEEE-
830
1) Functional requirements
2) Non-functional requirements
— Design and implementation constraints
— External interfaces required
— Other non-functional requirements
3) Goals of implementation.
Goals of Implementation
The ‘goals of implementation’ part of the SRS document offers
some general suggestions regarding the software to be developed
Document issues such as
easier revisions to the system functionalities that may be required in the future,
easier support for new devices to be supported in the future,
reusability issues, etc.
The developers may use these suggestions while choosing among different
design solutions.

9
Software Requirements Specification
Software system requirements are often classified as
1) functional requirements
2) non-functional requirements
These requirements vary depend on
the type of software being developed,
the expected users of the software, and
the general approach taken by the organization
(1)Functional Requirements
Functional Requirements
These are statements of services the system should provide,
describe what the system should do,
how the system should react to particular inputs, and
how the system should behave in particular situations.
Examples -
Search option given to user to search from various invoices.
User should be able to mail any report to management.
Users can be divided into groups and groups can be given separate rights.

Functional requirements are expressed in two types as

1) For system users and managers, describe them in Natural language so that
they can understand the requirement.
2) For system developers, describe them in the system functions, their inputs
and outputs, and exceptions in detail.
Identifying the High-level Functions of the Systems
A high-level function usually involves a series of interactions between the system
and one or more users.
For any given high-level function, there can be different interaction sequences or
scenarios due to users selecting different options or entering different data items.
There can be many types of users of a system and their requirements from the
system may be very different.
So, to Identifying the Functional Requirements
First, identify the different types of users who might use the system and

10
Second, try to identify the different services expected from the software by
different types of users.
How to Document the Functional Requirements?
Once all the high-level functional requirements have been identified, a function
can be documented by identifying the state at which
the data is to be input to the system, its input data domain,
the output data domain, and
the type of processing to be carried on the input data to obtain the output data.
Functional requirements are documented in
a numbered list of requirements, shown in example: ATM software.
Each functional requirement should be numbered uniquely and consistently.

Documenting the Functional Requirements

Example
the withdraw-cash function of an automated teller machine (ATM)
R.1: Withdraw cash
Description: The withdraw cash function first determines the type of account
that the user has and the account number from which the user wishes to withdraw
cash. It checks the balance to determine whether the requested amount is
11
available in the account. If enough balance is available, it outputs the required
cash, otherwise it generates an error message.
How to Document the Functional Requirements?
When user interaction sequences may vary from one invocation from another
depending on some conditions, these different interaction sequences capture
the different scenarios.
To accurately describe a functional requirement, we must document all the
different scenarios that may occur.
Each high-level function can consist of several sub-requirements.
For example, consider the withdraw-cash function of an automated teller
machine (ATM), the different scenarios occur depending on the amount entered
for withdrawal.
Note: documenting functional requirement in SRS
Each functional requirement should have less than seven (7) sub-functions
requirement.
This would not only enhance the readability of the document, but would also
help in design.
How to Document the Functional Requirements?
Example 1. (Document the functional requirement of withdraw cash from
ATM):
Using IEEE-830, 1998
R.1: Withdraw cash
Description: The withdraw cash function first determines the type of account
that the user has and the account number from which the user wishes to withdraw
cash. It checks the balance to determine whether the requested amount is
available in the account. If enough balance is available, it outputs the required
cash, otherwise it generates an error message.
R.1.1: Select withdraw amount option
Input:
“Withdraw amount” option selected
Output:
User prompted to enter the account type
12
How to Document the Functional Requirements?
Example 1. (Document the functional requirement of withdraw cash from
ATM):
Using IEEE-830, 1998
R.1.2: Select account type
Input:
User selects option from any one of the followings—savings/checking/ deposit.
Output:
Prompt to enter amount
R.1.3: Get required amount
Input: Amount to be withdrawn in integer values greater than 100 and less than
10,000 in multiples of 100.
Output: The requested cash and printed transaction statement.
Processing: The amount is debited from the user’s account if sufficient balance
is available, otherwise an error message displayed.
SRS document - the Black-box Specification of the Software
The SRS document
Should describe the system to be developed as a black box, and
Should specify only the externally visible behavior of the system.
For this reason, the SRS document is also called
the black-box specification of the software being developed.

13
Specification of Large Software
When there are large number of functional requirements (much larger than seen),
should they just be written in a long numbered list of requirements?
A better way to organize the functional requirements would be to split the
requirements into sections of related requirements.
For example, the functional requirements of an academic institute
automation software can be split into sections such as
accounts,
academics,
inventory,

Level of Details In Specification

Specify only the important input/output interactions in a functionality
along with the processing required to generate the output from the input.
However, if the interaction sequence is specified in too much detail, then it
becomes an unnecessary constraint on the developers and restricts their choice in
solution.
On the other hand, if the interaction sequence is not sufficiently detailed, it may
lead to ambiguities and result in improper implementation.

14
Traceability of SRS Document
Traceability means that it would be possible to identify (trace)
the specific design component which implements a given requirement,
the code part that corresponds to a given design component, and
test cases that test a given requirement.
Traceability analysis can also be used to assess the impact of a requirements
change.
That is, traceability makes it easy to identify which parts of the design and code
would be affected, when certain requirement change occurs.
Necessary that each functional requirement should be numbered uniquely and
consistently to refer back to function.

(1)Non-functional Requirements
Non-functional requirements
These are constraints on the services or functions offered by the system as a
whole.
They include timing constraints,
constraints on the development process, and
constraints imposed by standards.
For example-
emergent system properties such as reliability, response time, and memory
use.
15
Constraints on the system implementation such as capabilities of I/O devices or
the data representations used in interfaces
Types of Non-functional Requirements

Non-functional Requirements
Non-functional requirements are divided into two main categories:
1) Execution qualities like security and usability, which are observable
at run time.
2) Evolution qualities like testability, maintainability, extensibility, and
scalability that embodied in the static structure of the software system.

16
Non-functional Requirements Metrics

Measurable characteristics of the software system

_ System is tested to check whether or not the system has met its nonfunctional
requirements.
Documenting the Non-functional Requirements
The IEEE 830 standard recommends the non-functional requirements should
be documented in following different sections.
(1) Design and implementation constraints:
constraints can be—corporate or regulatory policies; hardware limitations;
interfaces with other applications; specific technologies, tools, and databases to
be used; specific communications protocols to be used;
(2) External interfaces required:
hardware, software and communication interfaces, user interfaces, report
formats, etc.
(3) Other non-functional requirements:
performance requirement, reliability issues, accuracy of results, and security
issues.

17
IEEE 830-1998 Standard for SRS Document
The IEEE 830, 1998 standard
 A guideline for organization a requirements specification document
into sections
 Depending on the type of project, some sections can be omitted,
introduce, or interchanged as may be considered prudent by the
analyst.
 However, the three basic issues that any SRS document should
discuss are_
1) Functional requirements,
2)Non-functional requirements, and
3)Guidelines for system implementation

Title of Standard
« IEEE Recommended Practice for Software Requirements Specifications »
Describes the content and qualities of a good software requirements
specification (SRS)
Presents several sample SRS outlines
Objectives
Help software customers to accurately describe what they wish to obtain

18
Help software suppliers to understand exactly what the customer wants
Help participants to:
• Develop a template (format and content) for the software requirements
specification (SRS) in their own organizations
• Develop additional documents such as SRS quality checklists or an SRS
writer’s handbook
IEEE 830-1998 Standard for SRS Document
The IEEE 830, 1998 standard
A guideline for organizing a requirements specification document into sections
Depending on the type of project, some sections can be omitted, introduced, or
interchanged as may be considered prudent
by the analyst.
However, the three basic issues that any SRS document should discuss are—
1) Functional requirements,
2) Non-functional requirements, and
3) Guidelines for system implementation
IEEE 830-1998 Standard – Section 1 of SRS

19
IEEE 830-1998 Standard – Section 2 of SRS

IEEE 830-1998 Standard – Section 3 of SRS1

20
IEEE 830-1998 Standard – Section 3 of SRS2

Section 3 (Specific Requirements) may be organized in many

different ways based on
• Modes
• User classes
• Concepts (object/class)
• Features
• Stimuli
• Organizations
Functional requirements in SRS document
the IEEE 830 standard suggests the Functional requirements section based on the
functionalities classification
the functionalities invoked by different users, (OR )
the functionalities that are available in different modes,

Functional requirements by users

1. User class 1
21
(a) Functional requirement 1.1
(b) Functional requirement 1.2
2. User class 2
(a) Functional requirement 2.1
(b) Functional requirement 2.2
Functional requirements by modes
1. Operation mode 1
(a) Functional requirement 1.1
(b) Functional requirement 1.2
2. Operation mode 2
(a) Functional requirement 2.1
(b) Functional requirement
IEEE 830, 1998 Template for Section 3 - Functional Requirements

22
The Organization of SRS Document
An in-house software SRS:
The requirements document for this software product will leave out many of
detailed chapters suggested above.
The requirements document can be less detailed and the focus will be on
defining the user requirements and high-level, nonfunctional system
requirements. The system designers and programmers use their judgment to
decide how to meet the outline
user requirements for the system.
An outsource software SRS:
The system is to be developed by a separate company (e.g., through
outsourcing), the system specifications need to be detailed and precise.
A Critical systems SRS:
These systems need detailed requirements because safety and security have to be
analyzed in detail to find possible requirements errors.

23
 The Software Requirement Specification Template for project sample

 Figure shows outline of the important sections that an SRS document

should contain as suggested by the IEEE 830 standard
 For each section of the document, we also briefly discuss the aspects
that should be discussed in it.

CASE STUDIE 2.2

Personal Library Software SRS Document
CASE STUDIE 2.2 Personal Library Software
Documenting Functional Requirement Specification
The Personal library software is proposed to develop a software that would be
used by individuals to manage their personal collection of books.
An informal description of the requirements of this software as worked out by
the marketing department is described in the text books.
Possible functional requirements are documented in a numbered list.
1. Manage own books
24
2. Manage friend details
3. Manage borrowed books
4. Manage statistics
Some Non-functional requirements such as Database, OS platform and
development
environment support.
Documenting these Requirement Specification is shown in textbook. (Please
read it)
Techniques for Representing
Complex Logic for High-level Function in SRS Document
Techniques for Representing Complex Logic
A high-level function might involve complex processing logic that involves
different steps to be undertaken as a consequence of some decisions made after
each step.
There are two main techniques available to analyses and represent complex
processing logic—
1) Decision Trees
2) Decision Tables.

Decision Tree

Figure 1.15 Decision Tree for A library membership management software (LMS) Problem

25
A decision tree gives a graphic view of the processing logic involved in
decision making and the corresponding actions taken.
The edges of a decision tree represent conditions and
the leaf nodes represent the actions to be performed depending on the outcome
of testing the conditions.
Decision table

A decision table shows the decision making logic and the corresponding
actions taken in a tabular or a matrix form.
The upper rows of the table specify the variables or conditions to be evaluated
and
the lower rows specify the actions to be taken when an evaluation test is
satisfied.
A column in the table is called a rule. A rule implies that if a certain condition
combination is true, then the corresponding action is executed.
4. Requirements Validation
The process of checking that requirements define the system that the
customer really wants.
During RE phase:
validation mainly checks consistency between different requirements and
detecting conflicts in the requirements.
During design phase:
26
validation refers back to the specification of the system or software
requirements
During the requirements validation process,
different types of checks should be carried out on the requirements in the
requirements document.
Requirements Validation

The Requirements Checking

1. Validity checks: These check that the requirements reflect the real needs of
system users.
2. Consistency checks: Requirements in the document should not conflict. That
is, there should not be contradictory constraints or different descriptions of the
same system function.
3. Completeness checks: The requirements document should include
requirements that define all functions and the constraints intended by the system
27
user.
4. Realism checks: By using knowledge of existing technologies, the
requirements should be checked to ensure that they can be implemented within
the proposed budget and schedule for the system development.
5. Verifiability: To reduce the potential for dispute between customer and
contractor, system requirements should always be written so that they are
verifiable. This means that you should be able to write a set of tests that can
demonstrate that the delivered system meets each specified requirement.
Requirement Validation Technique
(1)Requirements reviews:
The requirements are analyzed systematically by a team of reviewers who check
for errors and inconsistencies.
2) Prototyping:
This involves developing an executable model of a system and using this with
end-users and customers to see if it meets their needs and expectations.
Stakeholders experiment with the system and feedback requirements changes to
the development team.
3) Test-case generation:
Requirements should be testable.
If the tests for the requirements are devised as part of the validation process, this
often reveals requirements problems.
If a test is difficult or impossible to design, this usually means that the
requirements will be difficult to implement and should be reconsidered.
Developing tests from the user requirements before any code is written is an
integral part of test-driven development.
Requirement Checking
Validity checks
Consistency checks
Completeness checks
Realism checks
Verifiability
Requirement Validation Techniques
Requirements reviews
28
Prototyping
Test-case generation

Requirements Validation

What is the right system to build ?

5. Requirements Change

29
The requirements for large software systems are always changing.
 A formal process for making change proposals and linking these to system
requirements, called “requirements management process”
 As requirements are evolving, you need to keep track of individual requirements
and maintain links between dependent requirements so that you can assess the
impact of requirements changes.

Requirements Change Management Process

There are three principal stages to a change management process:
 1. Problem analysis and change specification
 identified requirements problem with a specific change proposal.
 2. Change analysis and costing
 The effect of the proposed change is assessed using traceability information and
general knowledge of the system requirements.
 The cost of making the change is estimated in terms of modifications to the
requirements document and,
 3. Change implementation
 The requirements document and, where necessary, the system design and
implementation, are modified.

SUMMARY OF Lecture – 1
30
Requirements for a software system set out what the system should do and
define constraints on its operation and implementation.
 The requirements engineering process includes requirements elicitation and
analysis, requirements specification, requirements validation, and requirements
management.
 Requirements elicitation and analysis is an iterative process that can be
represented as a spiral of activities— requirements discovery, requirements
classification and organization, requirements negotiation, and requirements
documentation.
 Requirements specification is the process of formally documenting the user
and system requirements and creating a software requirements document.
 The software requirements document is an agreed statement of the system
requirements. It should be organized so that both system customers and software
developers can use it.
Functional requirements are statements of the services that the system must
provide or are descriptions of how some computations must be carried out.
 Non-functional requirements often constrain the system being developed and
the development process being used. These might be product requirements,
organizational requirements, or external requirements. They often relate to the
emergent properties of the
system and therefore apply to the system as a whole.
 Requirements validation is the process of checking the requirements for
validity, consistency, completeness, realism, and verifiability.
 Requirements management is the process of managing and controlling these
changes. Business, organizational, and technical changes inevitably lead to
changes to the requirements for a software system.

Team Lab Assignment – 1

Create a team with maximum 3 students.
 Discuss among team selecting team group project that must include at least
three main functional activities.
 Define project titles and work out the feasibility study and write feasibility

31
report on main feasibility factors such as technical, operational and financial
feasibilities.
 Make team presentation for project title and feasibility study in class.
 Submit the feasibility study report.
 Due date: 2 weeks after this lecture is finished.
 Earn points for this assignment – 10 marks (this points count in the project
- 25%)
 Each students in team will earn same points if they all participate in
activities.
Team Lab Assignment – 2
Work out the requirement gathering activities using techniques study in the
lectures.
 Define the problem description.
 Work out the requirement analysis and write a requirement specification
document (SRS).
 Make team presentation for project’s requirement specification in class.
 Submit the software requirement specification report.
 Due date: 2 weeks after the first feasibility study presentation.
 Earn points for this assignment – 20 marks (this points count in the project
-25%)
 Each students in team will earn same points if they all participate in
activities.

32