Requirement Engineering

Topics
Problem recognition
Requirement Engineering Tasks
Processes
SRS
Use cases and Functional specification
Requirement validation
Requirement Analysis
Modeling and types
Requirement ?
A requirement can range from high level abstract
statement of a service or of a system constrain to a
detailed mathematical specification.
Req. themeselves are the descriptions of the system
services & constraints that are generated during the
Req. Eng process
Requirement engineering ?
Is the process of

 Establishing the services that the customer

requirement from system
 The constraints under which it operates and is
developed
In Req. Eng.
There is a systematic use of principles, techniques and
tools for cost effective analysis, documentation and
user needs.
Both the s/w eng. And customer take an active role in
req. eng.
Types of Req.
1. User – collection of statement written for customer.
2. System – structured document gives detailed
description. Contract between client and contractor.
3. Software specification – software description for
design implementation.
Problem Recognition

Sys Req Sw design

engineering analysis
How is Req. analysis helpful?
Analyst
- Help analyst to refine software allocation
Designer
- After R.A. design can design for data, component level
designs, interface
Developer
-using req. spec. & design actual s/w can be developed
What are req. Ana. Efforts?
Problem Recognition
- Need of the system
Evaluation
Modeling
Specification
- SRS must be built
Review
- SRS must be reviewed by project manager
 Role of system analyst
What is system analyst ???
Cont..
“Is a person who starts requirement
gathering and requirement analysis
activity by collecting all the
information from the customer.”
cont..
What is the problem ?
What is the need to solve the problem ?
What could be the solutions to the problem ?
What sort complexities or problem that might arise
while solving the problem ?
What kind of input or output would be for the system ?
 Requirements Engineering Tasks
 Requirement Engineering is the process characterized for achieving
following goals-
- Understanding customer requirements and their needs
- Analyzing the feasibility of the requirement
- Negotiating the reasonable solutions
- Specification of an unambiguous solution
- Managing all the requirement
- Finally transforming the requirements of the project
 Seven distinct tasks
 Inception
 Elicitation
 Elaboration
 Negotiation
 Specification
 Validation
 Requirements Management
13
 Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management

14
 Inception Task

Inception means specifying the beginning of the software project.

Most of the s/w projects get started due to the business requirement.

There exist several stakeholders who define the business idea.

What is stakeholder?

During inception, the requirements engineer asks a set of questions to

establish…

1. A basic understanding of the project

2.Find out all possible solutions and to identify the nature of the solution
15
3. Establish effective communication between the customer and the
 Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management

16
 Elicitation Task
Before the req. can be analyzed and modeled they
must undergo through the process of elicitation.
Eliciting requirements is difficult because of
Scope of the Project
Understanding the Problems.
Problems of volatility
Elicitation may be accomplished through two
activities
Collaborative requirements gathering
Quality function deployment

17
 Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management

21
 Elaboration Task
 The information about the requirements is expanded and
refined
 This information is gained during inception and elicitation
 Goal: to prepare a technical model of s/w functions,
features and constraints
 Consists of several modeling and refinement tasks.
 It is an analysis modeling task
Use cases are developed
Domain classes are identified along with their attributes
and relationships
State machine diagrams are used to capture the life on an
object
 The end result is an analysis model that defines the
22 functional, informational, and behavioral domains of the
problem
 Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management

26
 Negotiation Task
During negotiation, the software engineer
reconciles the conflicts between what the customer
wants and what can be achieved given limited
business resources
Requirements are ranked (i.e., prioritized) by the
customers, users, and other stakeholders
Risks associated with each requirement are
identified and analyzed
Rough guesses of development effort are made and
used to assess the impact of each requirement on
project cost and delivery time
Using an iterative approach, requirements are
eliminated, combined and/or modified so that each
27 party achieves some measure of satisfaction
 The Art of Negotiation
Recognize that it is not competition
Map out a strategy
Listen actively
Focus on the other party’s interests
Don’t let it get personal
Be creative
Be ready to commit

28
 Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management

29
 Specification Task
A specification is the final work product produced
by the requirements engineer
It can be written document, mathematical or
graphical model, collection of use case scenarios
It is normally in the form of a software
requirements specification
It serves as the foundation for subsequent software
engineering activities
It describes the function and performance of a
computer-based system and the constraints that
will govern its development
It formalizes the informational, functional, and
behavioral requirements of the proposed software
30
in both a graphical and textual format
 Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management

32
 Validation

Task
It is an activity in which req. specification is analyzed in
order to ensure that the req. are specified unambiguously
 During validation, the work products produced as a result
of requirements engineering are assessed for quality
 The specification is examined to ensure that
all software requirements have been stated
unambiguously
inconsistencies, omissions, and errors have been detected
and corrected
the work products conform to the standards established
for the process, the project, and the product
 The formal technical review serves as the primary
requirements validation mechanism
Members include software engineers, customers, users,
and other stakeholders
33
 Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management

36
 Requirements Management Task
It is the process of managing changing requirements
during the requirements engineering process and
system development.
Why requirements get change?
- req. are always incomplete and inconsistent. New
req. occur during the process as business needs
change and a better understanding of the system is
developed
- Customers may specify the req. from business
perspective that can conflict with end user req.
- During the development of the system, its business
& the technical environment may get changed

37
Requirement Management Process
following things should be planned :

Requirement Requirements are individually identified

identification

Change Management Process plan followed when analyzing a req. change

Process

Traceability The amount of information about req. relationship is

Policies maintained

Case tool The tool support which is required to manage req. changes
Support
Requirement Engineering Processes
 Is process in which various activities such as discovery,
analysis, validation are done.
 Begins with feasibility study
 Ends with req. validation
 Finally a document is prepared
 This process is a 3 stage activity, in which activities are
arranged in iterative manner
 Generic activities:
1. Req. Elicitation
2. Req. Analysis
3. Req. Validation
4. Req. Management
Requirement Engineering Processes
Req.
Feasibility
Elicitation &
study
Analysis

Feasibility
Req. Req.
Report
Specification Validation
System
Models

User & Sys.

Req.

Req. Doc.
Spiral Model of Req. Eng. Process
 Cont..
It can also be viewed as structured analysis
method
Along with creation of system models some
additional information
Requirement Specification
S/w Req. Document is the specification of the system
Should include both a definition & a specification of req.
Not a design document
It is the set of what the system should do rather than
how it should do
Provide a basis for creating the Software Requirement
Specification (SRS)
 SRS
Use:
- In estimating cost
- Planning team activities
- Performing tasks
- Tracking team progress
s/w designers use IEEE STD 830-1998 as the basis for
S/w Spec.
Software Requirements Specification
Who needs the SRS and for what purpose?
Users, customers and marketing personnel
SRS will meet their needs
Software developers
Develop the exact functionality which is specify in SRS
document
Test engineers
SRS provide meaningful functionality for making test
templates.
User documentation writers
Understand the SRS documents well enough to be able to
write user’s manual.
Project managers
Estimate the cost easily and planning
 Software Requirements Specification

 SRS document should clearly document the following aspects of a

system:
Functional requirement
Non functional requirement
Goals of implementation
 Functional requirement
High level functional requirements
Sub requirements
 Non functional requirement
This include aspects concerning maintainability, portability and usability.
Also include reliability issues, accuracy of results, human-computer
interfaces issues.
 Goals of implementation
Give some general suggestions regarding development.
Characteristics of a good SRS documents
Concise
The SRS document is to the point at the same time
unambiguous, consistent and complete. Irrelevant
description reduce reliability and increase error in srs.
Structured
The SRS document should be well structured.
Black-box view
The SRS should specify the externally visible behavior of
the system.
Conceptual integrity
The SRS document should exhibit conceptual integrity so
that the reader can easily understand the contents.
Verifiable
Whether or not requirements have been met in an
implementation.
 Organization of the SRS document

Depends on system analysist

Depends on Project type
Depends on company polices and rules

So SRS document is always differ organization to

organization.
Software Requirements Specification Format
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms and Abbreviations
1.4 References
2. Overall Description
2.1 Product Perspective
2.2 Product Features
2.3 User classes
2.4 operating environment
2.5 Design and Implementations constraints
2.6 Assumptions and dependencies
Cont..
3. System Features
3.1 System feature 1
3.2 System Feature 2 (and so on)
4. External Interface Requirements
4.1 User Interface
4.2 H/w interface
4.3 s/w interface
4.4 Communication Interface
5. Other Nonfunctional Requirements
5.1 Performance Requirements
5.2 Safety Requirements
5.3 Security Requirements
5.4 SQA
6. Other Requirements
Introduction.
The following subsections of the Software
Requirements Specifications (SRS)
document should provide an overview of the
entire SRS. The thing to keep in mind as
you write this document is that you are
telling what the system must do – so that
designers can ultimately build it. Do not
use this document for design!!!
Purpose

Identify the purpose of this SRS and its

intended audience. In this subsection,
describe the purpose of the particular
SRS and specify the intended audience
for the SRS.
 Scope
In this subsection:
 Identify the software product(s) to be produced by name
 Explain what the software product(s) will, and, if
necessary, will not do
 Describe the application of the software being
specified, including relevant benefits, objectives, and
goals
 Be consistent with similar statements in higher-level
specifications if they exist
This should be an executive-level summary. Do not
enumerate the whole requirements list here.
Definitions, Acronyms, and Abbreviations.
Provide the definitions of all terms,
acronyms, and abbreviations required to
properly interpret the SRS. This information
may be provided by reference to one or more
appendices in the SRS or by reference to
documents. This information may be
provided by reference to an Appendix.
 References
In this subsection:
(1) Provide a complete list of all documents referenced
elsewhere in the SRS
(2) Identify each document by title, report number (if
applicable), date, and publishing organization
Specify the sources from which the references can be
obtained.
SRS Example
Library Management System
In word document
Hospital management system
 1. Introduction

 The SRS is produced at the culmination of the

analysis task. The function and performance
allocated to software as part of the system
engineering and refined by establishing a
complete information description, a detailed
functional description, a representation of system
behavior, indication of performance
requirements and design constrains, appropriate
validation criteria and the other information
related to requirements.
 The SRS is technical specification of
requirement of Hospital Management
system. This specification describes what
the proposed system should do without
describing how it will do it. It also
describes complete external behavior of
proposed system.
 1.1. Purpose:-

The main purpose of our system is to

make hospital task easy and is to develop
software that replaces the manual hospital
system into automated hospital
management system. This document
serves as the unambiguous guide for the
developers of this software system.
 1.2. Scope:-

 The document only covers the

requirement specification for the hospital
management system. This document does
not provide any references to the other
component of the hospital management
system. All the external interfaces and the
dependencies are also identified in this
document.
 1.3. Feasibility Study:-

The overall scope of the feasibility study

was to provide sufficient information to
allow a decision to be made as to whether
the hospital management system project
should proceed and so, its relative
priority in the context of the other
existing hospital management system.
 The feasibility study of this project had
undergone through various steps which as
describe as under:
Identify the origin of the information at
different level.
Identify the expectation of user from
computerized system.
Analyze the drawback of existing system.
 1.4. Definition,Acronyms,Abbreviations:-

 CFD: - Context Flow Diagram

 DFD: - Data Flow Diagram
 IDE: - Integrated Development Environment
Java:-
PlatformIndependent,Object_orientedprogramming
language
 SQL: - Structured Query Language
 SRS: - Software Requirement Specification.
 1.5. Reference:-

1) An integrated approach to software

engineering, Third edition by Pankaj jalote
2) Java – Balaguruswamy
3) SQL server 2005 – JosephL Jordan
 1.6. Overview:-
 Hospital Management System is a
process of implementing all the activities
of the hospital in a computerized
automated way to fasten the performance.
 This project is to maintain the patient
details, lab reports and to calculate the bill
of the patient. You can also manually edit
any patient details and issue bill receipt to
patient within few seconds.
 2. OVERALL DESCRIPTION
2.1. Product perspectives:-
 This project gives the procedural
approach how a patient gets treatment,
details about date of treatment and finally
depending on different criteria like room
allocated, lab reports, treatment and
medicine taken…..etc,how billing is
calculated. During billing health card
facility is also considered.
 2.2. Product Function:-
The data represented in hospital management
application will perform the following major
function:-
Patient Details: - It includes inpatient and
outpatient details.
Lab reports
Billing Details
This software will help to calculate the bill
much quicker and simpler way. This enables the
organization to keep the information in efficient
and systematic way.
 2.3. User Characteristics:-

 This software is developed such that

total appearance of the product to make it
more user friendly. The operator will be
provided with loginid and password.
General users with basic computer skills
can use this software.
 2.4. General Constraints:-

 Any update regarding the patients

information from the hospital are to
be recorded to have updated and
correct values.
 2.5. Assumption and Dependencies:-

All the data entered will be correct and

up_to_date.This software package is
developed using java as front end which
is supported by sun micro system, MS
SQL server 2005 as the back end which
is supported by Microsoft windows xp.
 3. SPECIFIC REQUIREMENTS

 It describes all the details that the

software developer need to know for
designing and developing the system.
This is typically the largest and most
important part of the document.
 3.1. External Interface Requirements:-
3.1.1. User Interface:-
User interface is designed in a user
friendly manner and the user, in
another end he has to give the order,
for that he will interface with
keyboard and mouse.
 3.1.2. Hardware Interface:-

 1) OS – windows XP
 2) Hard disk – 80 GB
 3) RAM – 1 GB
 4) Keyboard – Standard QWERTY keyboard
for interface
 5) Mouse – Standard mouse with 2 buttons
 3.1.3. Software Interface:-

1) Front end – Java language

 2) OS – Net Beans IDE 6.9.1
 3) Back end – SQL Server 2005
 3.1.4. Communication Interface:-

Windows
Linux
 3.2. Functional Requirements:-
3.2.1. Administration module:-
This module enables the user to insert,
update, view and delete the patient
information.
 3.2.2. Patient module:-

PatientId,Name,Age,Sex,Address,Phone
Number,Weight
 This module has following 2 sub modules:-
 3.2.2.1. Inpatient module:-

 This sub module is used to store information

about patients who were admitted in the hospital
on doctors advice.
PatientId, Dept depending on disease, Doctor,
Room no, Date of admitted, Advance, Date of
discharge.
Updation like deletion and modification is done.
 3.2.2.2. Outpatient module:-

PatientId,New_Case,Old_Case,Date,Deptdepe
ndingon disease,Doctor .
Updation like deletion and modification is
done
 3.2.3. Lab module:-

This module used to store or produce the

laboratory reports.
PatientId, Weight, Category, Doctor,
Inpatient/Outpatient, Date.
Updation like deletion and modification is
done.
 3.2.4. Billing module:-
3.2.4.1. Inpatient module:-
 PatientId, doctors charge, health card
amount, room bill, medicine bill, total
amount, No of days, Service charge,
Operation theatre, Nursing care, Lab bill .
 3.3. Performance Requirements:-

 The capability of the computer depends

on the performance of the software. The
software can take any number of input
provided the database size is large
enough. This would depend on the
available memory space.
 3.4. Design Constraints:-

 This will help the doctors or users to view

the records of the patients immediately
whenever necessary. They can also calculate
the bill of the particular patients. This
software also has the ability to add, update
and delete the record whenever needed. This
project will help to smoother the process of
the hospital activites.
Requirement Validation
It is a process in which it is checked that
whether the gathered requirements represent the
same system that customer really wants
In this the req. errors are fixed
Req. Error cost are high so validation is very
important.
Fixing a req. error after delivery may cost upto
100 times the cost of fixing an implementation
errors.
Cont..
Req. checking can be done in following manner
–
1. validity: does the system provide the function
which best support the customer’s needs?
2. Consistency: are there any req. conflicts?
3. Completeness: Are all functions required by the
customer?
4. Realism: can the requirements be implemented
according to budget and technology?
5. Verifiability: can the requirements be checked?
Req. validation Techniques
1. Requirements Reviews: is a systematic manual analysis
of the requirements.
- The req. review should be taken only after formulation of
req. definition. And both the customer and contactor staff
should be involved in reviews
- Reviews may be formal (with completed documents) or
informal
- Good communications should take place between
developers, customers and users
- Such a healthy communication helps to resolve problems
at an early stage
Cont..

Requirement
s
reviews

Test Requirement
Case s
generatio Validation
n technique

Prototypin
g
 Cont…
2. Prototyping
- The req. can be checked using executable model of
system
3. Test case generation
- In this technique, the various tests are developed for
requirement.
- The requirement check can be carried out with:
1. Verifiability : is the req. realistically testable?
2. Comprehensibility: is the req. properly understood?
3. Traceability: is the origin of the req. clearly tested?
4. Adaptability: can the req. be changed without a large
impact on their req.?
Requirement Analysis
After req. elicitation, the req. analysis is done
Following are some principles that must be used while using
analysis methods
1. It is necessary to understand the information domain of
the problem because of which goals and objectives of the
system can be well understood.
2. Various functions that can be performed by the software
must be defined
3. Behavior of the s/w must be represented
4. The data, functions and behavioral models should depict
the information in layered manner, so that all the necessary
information can be systematically exploited
5. the analysis method should proceed in such a way that
necessary information can be easily transformed into
Modeling
It is used to represent the actual entity so that
its functionality can be understood properly
Any s/w model must be capable of representing
information of the s/w that gets transformed
within it, functions & behavior.
Types of modeling
Based on req. analysis 2 types of models are
there:
1. Functional model
2. Behavioral model
1. Functional model
Used to represent the flow of information in
any computer based system
Used to represent 3 generic functionalities:
input, process,output
When functional model is prepared the s/w
engineer focuses on problem specific functions
The basic model is prepared and over the series
of iterations more and more functional details
are provided.
In structured analysis approach the functional
modeling is done by using the data flow
2. Behavioral Model
Used to describe the overall behavior of a
system
The state transition diagram are used
The state transition diagram:
- Basically a collection of states and events
- The events cause the system to change its state
- What actions are to be taken on occurrence of
particular event