UNIT -2

Requirements Engineering
Definition: Software Requirement- The process of establishing the services that the customer requires from a system
and the constraints under which it operates and is developed.
Requirements may serve a dual function
• May be the basis for a bid for a contract - therefore must be open to interpretation.
• May be the basis for the contract itself - therefore must be defined in detail.
Both these statements may be called requirements

Definition: Software Requirement Specification – A structured document setting out detailed descriptions of
the system services written as a contract between client and contractor.

Classification of Software Requirements

1. Functional Requirements
Statements of services the system should provide how the system should react to particular inputs and how the
system should behave in particular situations.
2. Non-Functional Requirements
Constraints on the services or functions offered by the system such as timing constraints, cost constraints, constraints on
the development process, standards etc.
3. System requirements
A structured document setting out detailed descriptions of the system services written as a contract between
client and contractor
4. User Requirements
Statements in natural language plus diagrams of the services the system provides and its operational constraints. It is
written for customers.

Functional Requirements and Non Functional Requirements

Functional Requirements:
*Statements of services the system should provide how the system should react to particular inputs and how the
system should behave in particular situations.
*The Functional requirements of the system describe what the system should do.
*It depends on the type of software, expected users and the type of system where the software is used.
*Functional user requirements may be high-level statements of what the system should do but it should
describe the system services in detail.

Non - Functional Requirements:

*Non-functional requirements may be more critical than functional requirements. If these are not met, the
system is useless.
*Constraints on the services or functions offered by the system such as timing constraints, cost constraints, storage
constraints, constraints on the development process, standards etc.

Classification of Software Requirements

Product requirements
• Requirements which specify that the delivered product must behave in a particular way e.g. execution
speed, reliability etc.
Organizational requirements
• Requirements which are a consequence of organizational policies and procedures e.g. process standards
used, implementation requirements etc.
External requirements
• Requirements which arise from factors which are external to the system and its development process
e.g. interoperability requirements, legislative requirements etc.

Software Requirement Specification

Outline Structure of Software Requirement Specification
 Definition: SRS is a formal document, which acts as a representation of software that enables the users to review whether
it (SRS) is according to their requirements.
A structured document setting out detailed descriptions of the system services written as a contract between
client and contractor.

Various other Purposes served by SRS are listed below.

1. Feedback: Provides a feedback, which ensures to the user that the organization (which develops the software)
understands the issues or problems to be solved and the software behavior necessary to address those problems.
2. Decompose problem into components: Organizes the information and divides the problem into its component parts in an
orderly manner.
3. Input to design: Contains sufficient detail in the functional system requirements to devise a design solution.
4. Basis for agreement between the user and the organization: Provides a complete description of the functions to be
performed by the system.
5. Reduce the development effort: Enables developers to consider user requirements before the designing of the system
commences. As a result, 'rework' and inconsistencies in the later stages can be reduced.
6. Estimating costs and schedules: Determines the requirements of the system and thus enables the developer to have a
'rough' estimate of the total cost and schedule of the project.

Characteristics of SRS
1. Correct: Correctness ensures that all specified requirements are performed correctly to meet the software.
2. Unambiguous: SRS is unambiguous when every stated requirement has only one interpretation. This implies that each
requirement is uniquely interpreted.
3. Complete: SRS is complete when the requirements clearly define what the software is required to do. This includes all
the requirements related to performance, design and functionality.

Components of SRS

Functionality
Environment and System Objectives
System Delivery and Installation
Design constraints
External interface requirements
Conceptually, any SRS should have these components. Now we will discuss them one by one.
1. Functionality:
• Procedures for starring up and closing down the system.
• Operations on Normal condition.
• Operations on abnormal conditions.
2. Environment and System Objectives
• Physical Attributes of the environment : size, shape and locality
• Safety/Security/Hazards
3. System Delivery and Installation
• Examples of these requirements are: Deadlines/ Quality assurance/ document
structure/ standards/training/manuals/ support and maintenance.
4. Design Constraints
• Hardware/Software standards, particular libraries, operating systems to be used and compatibility issues.
5. Functional Constraints
• Properties are: Performance, efficiency, response times, safety, security, reliability, quality and dependability.
The process of establishing the services that the customer requires from a system and the constraints under
which it operates is called Requirement Engineering process.
1. Feasibility study: The study determines whether or not a system is financially worthwhile and
technically feasible.
It is the study that checks A) If the system contributes to organizational objectives. B) If the system can be engineered
using current technology and within budget. C) Based on information assessment (what is required), information
collected a brief report is written.
A feasibility study is conducted to answer many questions like
• 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?

2. Requirement Elicitation and

Analysis: 1. Requirement
Activities involved in Elicitation and Analysis are Discovery
➢ Requirement Discovery
➢ Requirement classification and organization 4.Requirements 2.Requirement
➢ Requirement prioritization and negotiation Classification &
Specification
➢ Requirement Specification
organization
The process involves technical staff working with
customers to find out about the application domain, 3.Requirements
the services that the system should provide and the Prioritization
system’s operational constraints. and Negotiation
It may involve end-users, managers, engineers
involved in maintenance, domain experts, trade
unions, etc. These are called stakeholders.

The various activities involved in Requirement Analysis and Elicitation are :

➢ Domain Understanding : The analyst must understand the Background Knowledge of the application.
➢ Requirement Collection : Gathering the requirement by involving the users and stakeholders.
➢ Requirement classification : Organizing the requirements gathered from different sources.
➢ Requirement conflicts : Involves stakeholders and engineers to solve the problems that contradict
the organization and business rules.
➢ Requirement prioritization : Discovering the most important requirements by interacting with stakeholders
and organizing them into most priority order.
➢ Requirement validation : Checks stakeholder’s expectation on the system with gathered requirements.
Techniques for Requirement Elicitation and Analysis
1. View point oriented elicitation
2. Scenarios
3. Ethnography

1. View point oriented elicitation

Stakeholders represent different ways of looking at a problem or problem viewpoints.
There are 3 types of viewpoints:

1. Interactive View points : Represents people or other systems that interact directly with the system. EX : In a
bank ATM , the banks customer and banks account database.
2. Indirect view points : Represents stakeholders who do not use the system directly but influence the system
in some way. EX : Management of the bank and bank security staff.
3. Domain view points : Represents domain characteristics and constraints that influence system requirements.
EX: Standards that have been developed for inter banking communication like ATM.

The example used here is an auto-teller system which provides some automated banking services. Services include cash
withdrawal, message passing (send a message to request a service), ordering a statement and transferring funds.
Auto- teller Viewpoints
Bank customers
Representatives of other banks
Hardware and software maintenance engineers
Marketing department
Bank managers and counter staff
Database administrators and security staff
Communications engineers
Personnel department

2. Scenarios
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 abstract statement of what they
require from a system.
Scenarios are particularly useful for adding detail to an outline requirements description.
Scenario Descriptions
▪ System state at the beginning of the scenario
▪ Normal flow of events in the scenario
▪ What can go wrong and how this is handled
▪ Other concurrent activities
▪ System state on completion of the scenario

3. Ethnography
Definition: “Ethnography is an observational technique that is used to understand social and organizational requirement.”
Ethnographic studies have shown that work is usually richer and more complex than suggested by simple system models.
These are the Requirements that are derived from the way that people actually work.
Ethnographic requirements are derived from cooperation and awareness of other people’s activities.

Requirements Specification Methods

Specification Method Description
Structured Natural language This approach depends on defining standard forms or templates to express the
requirements specification in natural language.
Design description language This approach uses a language like a programming language but with more abstract
features to specify the requirements by defining an operational model of the system.
Graphical notations It has much complex graphical vocabulary and is most widely used by specialists.

Mathematical specifications These are notations based on mathematical concepts such as finite-state machines or sets.

Requirement Validation
Requirement Validation is concerned with demonstrating the requirements that define the system which customer really
wants. Requirements error costs are high so validation is very important i.e. fixing a requirements error after delivery may
cost up to 100 times the cost of fixing an implementation error.

Requirement Validity Checks

Requirement Validity Checks Description
1.Validity Checks Aims to ensure that the system meets all functional, behavioral and performance
requirements.
2.Consistency Checks Requirements collected must be consistent and should not lead to conflict.
3.Realism Checks These checks take into account the budget and schedule for the system development.
4.Verifiability At the completion of the system, it must be possible to demonstrate that the delivered
system meets all the requirements.

Requirement Validation techniques

1. Requirement Reviews 2.Prototyping 3.Test Case Generation

Requirements reviews
▪ Systematic manual analysis of the requirements
▪ Reviews here can also check for a)Verifiability, b)Comprehensibility, c)Traceability and d)Adaptability
Prototyping
▪ Using an executable model of the system to check requirements.
Test-case generation
▪ Developing tests for requirements to check testability, if a test is difficult or impossible to design that means
requirements are unrealistic.
Requirement

Management
Requirement Evolution
Based on the Requirement Evolution, requirements
are classified into 2 types :
Enduring requirements- Stable requirements derived from the core activity of the customer organization. E.g. a hospital will always have doctors,
nurses, etc. May be derived from domain models.
Volatile requirements - Requirements which change during development or when the system is in use. In a hospital, requirements derived
from health-care policy etc

Identifying risks and drawing up plans to minimize their effect on the project is called Risk management.

Categories of risk can be defined as follows :

Project risks –affects resources/schedule.

Product risks- affects quality /performance of software being developed. 3)Business risks- affects organization development.

Process of risk management

1.Risk Identification: Project, product and business risks are identified. 2.Risk analysis : Consequences of risks are assessed.
3.Risk planning : Addresses the risk either by avoiding it or minimizing its effects. 4.Risk monitoring : Risk is constantly assessed and information about the
risk becomes available.
Risk Identification

This may be carried out as a brainstorming approach or may simply be based on a manager’s experience. They
include :

Technology risks : Risks which derive from the software or hardware technologies.
People risks : Associated with people in the development team.
Organizational risks : organizational environment where the software is being developed.
Requirement risks : derived from changes to the customer requirement.
Estimation risks : management estimates of system characters and resources.

Risk Analysis
It relies on the judgement and experience of the project manager. The probability of the risk might be assessed
as :
Very low (<10%)
low (10-25%)
moderate (25-50%)
high(50-75%)
Very high (>75%)

Risk Planning

The strategies are divided Into 3 :

a)Avoidance strategies – dealing with defective components.
b)Minimization strategies – strategy for staff illness.
Contingency plans – strategy for organizational financial problems.