Software

Requirements
Analysis and
Modeling
Module-02
Requirement Engineering
• The process of establishing the services that the customer
requires from a system and the constraints under which it
operates and is developed.

• The requirements themselves are the descriptions of the

system services and constraints that are generated during the
requirements engineering process.
What is a requirement?
• It may range from a high-level abstract statement of a service
or of a system constraint to a detailed mathematical
functional specification.

• This is inevitable as 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.
Types of requirement
• User requirements
• Statements in natural language plus diagrams of the services the
system provides and its operational constraints. Written for
customers.
• System requirements
• A structured document setting out detailed descriptions of the
system’s functions, services and operational constraints. Defines
what should be implemented so may be part of a contract
between client and contractor.
Readers of different types of
requirements specification
Functional 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.
• May state what the system should not do.
• Non-functional requirements
• Constraints on the services or functions offered by the system
such as timing constraints, constraints on the development
process, standards, etc.
• Often apply to the system as a whole rather than individual
features or services.
• Domain requirements
• Constraints on the system from the domain of operation
Functional requirements
• Describe functionality or system services.

• Depend 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.

• Functional system requirements should describe the system

services in detail.
Functional requirements for
the MHC-PMS
• A user shall be able to search the appointments lists for all
clinics.

• The system shall generate each day, for each clinic, a list of
patients who are expected to attend appointments that day.

• Each staff member using the system shall be uniquely

identified by his or her 8-digit employee number.
Requirements imprecision
• Problems arise when requirements are not precisely stated.

• Ambiguous requirements may be interpreted in different ways

by developers and users.

• Consider the term ‘search’ in requirement 1

• User intention – search for a patient name across all
appointments in all clinics;
• Developer interpretation – search for a patient name in an
individual clinic. User chooses clinic then search.
Requirements completeness
and consistency
• In principle, requirements should be both complete and
consistent.
• Complete
• They should include descriptions of all facilities required.
• Consistent
• There should be no conflicts or contradictions in the descriptions
of the system facilities.
• In practice, it is impossible to produce a complete and
consistent requirements document.
Non-functional requirements
• These define system properties and constraints
• e.g. reliability, response time and storage requirements.
Constraints are I/O device capability, system representations,
etc.

• Process requirements may also be specified mandating a

particular IDE, programming language or development
method.

• Non-functional requirements may be more critical than

functional requirements. If these are not met, the system may
be useless.
Types of nonfunctional
requirement
Non-functional requirements
implementation
• Non-functional requirements may affect the overall
architecture of a system rather than the individual
components.

• For example, to ensure that performance requirements are met,

you may have to organize the system to minimize
communications between components.

• A single non-functional requirement, such as a security

requirement, may generate a number of related functional
requirements that define system services that are required.
• It may also generate requirements that restrict existing
requirements
Non-functional classifications
• Product requirements
• Requirements which specify that the delivered product must
behave in a particular way e.g. execution speed, reliability, etc.
• Organisational requirements
• Requirements which are a consequence of organisational 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.
Examples of nonfunctional
requirements in the MHC-PMS
• Product requirement
• The MHC-PMS shall be available to all clinics during
normal working hours (Mon–Fri, 08.30–17.30).
Downtime within normal working hours shall not exceed
five seconds in any one day.

• Organizational requirement
Users of the MHC-PMS system shall authenticate
themselves using their health authority identity card.

• External requirement
The system shall implement patient privacy provisions as
set out in HStan-03-2006-priv.
OBJECTIVES OF
REQUIREMENTS ANALYSIS

• To establish and maintain agreement with the customers and

other stakeholders on what the system should do.
• • To provide system developers with a better understanding
of the system requirements.
• • To define the boundaries (scope) of the system.
• • To provide a basis for estimating cost and time to develop
the system.
• • To define a user-interface for the system, focusing on the
needs and goals of the users.
REQUIREMENTS
ENGINEERING
• Requirements engineering is the broad spectrum of tasks and
techniques that lead to an understanding of requirements.

• Requirements engineering provides the appropriate

mechanism for
• understanding what the customer wants,
• analysing needs,
• assessing feasibility,
• negotiating a reasonable solution,
• specifying the solution unambiguously,
• validating the specification, and
• managing the requirements as they are transformed into an
operational system.
• Requirements engineering encompasses seven distinct tasks:

• 1) inception,
• 2) elicitation,
• 3) elaboration,
• 4) negotiation,
• 5) specification,
• 6) validation, and
• 7) management.
1. Inception is understanding of
• the problem,
• the people who want a solution,
• the nature of the solution that is desired, and
• preliminary communication and collaboration between the
other stakeholders and the software team.
2. Elicitation is to identify objectives for the system or product
are,
• what is to be accomplished,
• how the system or product fits into the needs of the business,
and
• finally, how the system or product is to be used on a day-to-
day basis.
3. Elaboration is refinement of information obtained from the
customer during inception and elicitation
4. In negotiation,
• Customers, users, and other stakeholders are asked to rank
requirements and then discuss conflicts in priority.
• Using an iterative approach that prioritizes requirements,
assesses their cost and risk, and requirements are eliminated,
combined, and/or modified so that each party achieves some
measure of satisfaction.
5. Specification is a written document for specification is
created with
• a set of graphical models,
• a formal mathematical model, and
• a collection of usage scenarios, a prototype, or any
combination of these.
6. Validation – It validates that
• all software requirements for unambiguous (without any
inconsistencies, omissions, and errors) and
• the work products conform to the standards established for
the process, the project, and the product.
7. Requirements management
• helps the project team identify, control, and track
requirements and changes to requirements at any time as the
project proceeds.
Some of these tasks occur in parallel and all are adapted to the
needs of the project.
REQUIREMENTS ELICITATION (REQUIREMENTS
GATHERING)

Requirements elicitation (requirements gathering) consists of

▪ problem solving,
▪ elaboration,
▪ negotiation, and
▪ specification.

• The following techniques can be applied to collect and elicit

relevant information from the stakeholders:
• 1. interviews
• 2. document analysis/review
• 3. brainstorming
• 4. observation
• 5. prototyping
• 6. requirements workshop/Joint Application Development (JAD)
• 7. questionnaires/surveys
• 1. Interviews-
• Interviews are the most common technique for gathering
requirements, as well as one of the primary sources of
requirements.
• There are different types of interviews and interview questions.
• Types of interviews can be One-on-One interviews and Group
interviews.
• Interviews can be structured interview or unstructured interviews.
• If the interviewer has a predefined set of questions, then it’s called a
structured interview.
• If the interviewer is not having any particular format or any specific
questions, then it’s called an unstructured interview.
2. Brainstorming
It is used to get as many ideas as possible from group of people.
Generally used to identify possible solutions to problems, and clarify details of
opportunities.
3. Document Analysis / Reviews
Analyzing or reviewing existing documents can prove to be a useful technique in
requirement gathering.
Reviewing the current process and documentation can help the analyst
understand the business, or system, and its current situation.
Existing documentation will provide the analyst the titles and names of
stakeholders who are involved with the system.
This will help the analyst formulate questions for interviews or questionnaires to
ask of stakeholders, in order to gain additional requirements.
4. Observation
To get a better understanding of a user in their current work environment, the
analyst may observe the user themselves.
User observation is helpful in assisting the analyst by getting a full grasp of how the
user interacts with the system, firsthand.
• 5. Prototyping
• Prototyping is used to identify missing or unspecified requirements.
• In this technique, frequent demos are given to the client by creating
the prototypes so that client can get an idea of how the product
will look like and work.
• Prototypes can be used to create a mock-up of sites, and describe
the process using diagrams.
• 6. Requirements Workshop / Joint Application Design (JAD)
• These are structured meetings involving end-users, project
managers and other stake holders.
• This is used to define, clarify, and complete requirements.
• JAD is usually conducted in at a location other than the place where
the people involved work. This helps to reduce distractions.
7. Questionnaires / Surveys
Questionnaires or surveys allow an analyst to collect
information from many people in relatively short amount of
time.
This is especially helpful when stakeholders are spread out
geographically, or there are many respondents whose input will
be needed to help establish system requirements.
When using questionnaires, the questions should be focused
and organized by a feature or project objective.
Questionnaires should be not be too long, to ensure that users
will complete them
Requirements Modelling

• The requirement model is a snapshot of requirements at any

given time.

• The model changes dynamically as the system is built, and

other stakeholders understand more about what they really
require.

• (1) to describe what the customer wants,

• (2) to establish a basis for the creation of a software design
• (3) to define a set of requirements that can be validated once
the software is built.
Requirement Models
The requirements modeling action results in one or more of the
following types of models:
1. Scenario-based models
2. Class-oriented models
3. Flow-oriented models
4. Behavioral models
Elements of the
Requirements Model
1. Scenario-based elements
• The system is described from the user’s point of view using a
scenario-based approach.
• They are represented using actors, use cases and their
corresponding use-case diagrams.

2. Class-based elements
• Each usage scenario implies a set of objects that are
manipulated as an actor interacts with the system.
• These objects are categorized into classes (a collection of
things that have similar attributes and common behaviors).
• They are represented using class diagrams and collaboration
diagrams.
3. Behavioral elements
• They represent the behavior of a system.
• They are represented using state diagram and sequence
diagrams.

4. Flow-oriented elements
• In a computer-based system, information gets transformed
into different forms as it flows through system.
• The system accepts input in a variety of forms, applies
functions to transform it, and produces output in a variety of
forms, regardless of size and complexity.
• They are represented using data flow diagrams.
SCENARIO-BASED
APPROACH
• The system is described from the user’s point of view using a
scenario-based approach.
• • Scenario-based elements are represented using actors, use
cases and their corresponding use-case diagrams.
DEVELOPING USE CASES
• Use Cases
• After requirements are gathered, the developers and end
users can create a set of scenarios that identify a usage of the
system to be constructed.
• These scenarios are called use cases.
• The use cases provide a description of how the system will be
used.
• A use case is a description about how an end user (playing
one of a number of possible roles) interacts with the system
under a specific set of circumstances.
• A use case depicts the software or system from the end user’s
point of view.
Actors in use cases

• The first step in writing a use case is to define the set of

“actors” that will be involved in the system usage.
• Actors are the different people or non-human
entities/devices that use the system or product within the
context of the function and behaviour that is to be described.
• An actor is the UML term to identify someone or something
that communicates with the system or product and that is
external to the system itself.
• Every actor has one or more goals when using the system.
Representing actors in use
cases
• Symbol for representing actor is "stick man" icon with the
name of the actor below the icon.

• Actors represent the roles that people or devices/ non-

human play as the system operates.
Human as actors can be
• customer (bank, shop, hotel)
• member (library, sports_club, association)
• user (ATM, vending machine)
• patient, doctor, nurse
• student , teacher

Non-human entities/devices as actors can be

• bank, hospital, college, organisation
• server
• ATM machine
• payment system (cash, card, online)
• web client
Types of Actors
• Primary actors-
They interact to achieve required system function and derive
the intended benefit from the system. They work directly and
frequently with the software.

• Secondary/ supporting actors –

They support the system so that primary actors can do their
work.
Identifying Use cases
• Use cases capture the functional requirements of a system.
• Use cases describe what happens in the system when an
actor interacts with the system to execute the use case.
• They specify the behavior of a system or some subset of a
system.
• Each of use cases represents a specific flow of events.

Use cases are graphically represented as an oval with the name

of its functionality written in oval.
• Use cases for library management system can be represented
as
USE CASES DIAGRAMS
• Diagrams with actors, use cases, and relationships among
them are called use-case diagrams and illustrate relationships
in the use-case model.
• It describes a system's requirements in terms of use cases.
Example- Course
Registration System

• PROBLEM STATEMENT:
• This system will maintain a course registration database which
will allow the student to view the course details and to
register the course.
• Identify actors involved
• • Student: User who view courses and register the course
• • Admin: To add courses and details
Identify use-cases :
• Login
• Add courses
• View courses
• Register for course
TYPES of USE CASE
RELATIONSHIPS
Three types of relationships exist among use cases:
• Include relationship
• Extend relationship
• Generalization/specialization relationship
Include relationship
• Include relationships are used to depict common behaviour
that are shared by multiple use cases.
• Notation for include relationships
• Include relationship is depicted by a dashed arrow with a
«include» stereotype from the including use case to the
included use case.
Extend relationship
• The extend relationship is used to include optional behavior
from an extending use case in an extended use case.
• Notation for extend relationships
• Extend relationship is depicted by a dashed arrow with a
«extend» stereotype.
Generalization relationship

• Generalization relationship are used to represent the

inheritance between
• • use cases and
• • actors
• Generalization relationship between use cases
• Here a child use case inherits the behavior and meaning of
the parent use case. The child may add or override the
behavior of the parent.
• Notation for generalization relationships
• Generalization relationship is depicted by a arrow from the
derived use case to the base use case.
• Example- Search Book use case with search by author name
or book title
Generalization relationship
between actors
• The generalization of actor refers to the relationship which
exist between two actors and which shows that one actor
(descendant) inherits the role and properties of another actor
(ancestor).
• Example - a library member may be student and faculty
• Use case diagram for issue book(scenario) Usecase
DATA FLOW DIAGRAM
• A data flow diagram (DFD) is a graphical representation of
the "flow" of data through an information system, modelling
its process aspects.

• A DFD shows what kind of information will be input to and

output from the system, how the data will advance through
the system, and where the data will be stored.

• It does not show information about process timing or

whether processes will operate in sequence or in parallel.
DFD Levels
• Level-0 DFD (context diagram ) : system as a single process

• Level-1 DFD: multiple sub-processes

• Level-2 DFD: deeper into parts of level-1 DFD.

Graphical notations for Data
Flow Diagram
External Entity
• A producer or consumer of data

• Examples: a person, a device, a sensor

• Data must always originate somewhere and must always
be sent to something
Process
• A data transformer (changes input to output)

• Examples: compute taxes, determine area, format report,

display graph

• Data must always be processed in some way to achieve

system function
Data Flow
• Data flows through a system, beginning as input and
transformed into output.

base
compute
triangle area

height area
Data Flow Diagramming:
Guidelines
• all icons must be labeled with meaningful names
• the DFD evolves through a number of levels of detail
• always begin with a context level diagram (also called level 0)
• always show external entities at level 0
• always label data flow arrows
• do not represent procedural logic
• create a level 0 DFD
Level 0 DFD Example

processing
user request requested
video
digital signal
video monitor
processor
video
source NTSC
video signal
Constructing a DFD—I
• write a narrative describing the transform
• “balance” the flow to maintain data flow continuity
• develop a level 1 DFD
• use a 1:5 (approx.) expansion ratio
a b
x P y level 0

a c p2
f
p1

p4 b
d 5
p3 e g
level 1
DFD for Library Information
System
For level-0 DFD (Context Diagram) -
• External entities are
• Member
• Library staff

• Data stores are

• Member database
• Book database

• Process 0 is Library Information System.

Level-0 DFD
For level-1 DFD
Sub-processes for “process 0” (Library Information System) may
be
• Add member
• Add book
• Remove book
• Issue book
• Return book
Food Ordering System
• Level -0
• Level - 1
Level 2 DFD –
Detailed information about
“Processing of an Order”
SOFTWARE REQUIREMENT
SPECIFICATION (SRS)
• It is a document that

• describes the nature of a project, software or application,

• contains description of all aspects of the software to be built
that must be specified before the project is to commence and
• is also known as SRS report, software document.
Contents of SRS template

purpose
• scope
• functional requirements
• non-functional requirements
• software requirements
• hardware requirements
• environmental conditions required
• safety and security requirements
• software quality attributes of the project and etc.
IEEE Template for SRS
• Table of Contents
• Revision History
• 1. Introduction
• 1.1 Purpose
• 1.2 Document Conventions
• 1.3 Intended Audience and Reading Suggestions
• 1.4 Project Scope
• 1.5 References
• 2. Overall Description
• 2.1 Product Perspective
• 2.2 Product Features
• 2.3 User Classes and Characteristics
• 2.4 Operating Environment
• 2.5 Design and Implementation Constraints
• 2.6 User Documentation
• 2.7 Assumptions and Dependencies
• 3. System Features
• 3.1 System Feature 1
• 3.2 System Feature 2 (and so on)
• 4. External Interface Requirements
• 4.1 User Interfaces
• 4.2 Hardware Interfaces
• 4.3 Software Interfaces
• 4.4 Communications Interfaces
5. Other Non-functional Requirements
5.1 Performance Requirements
5.2 Safety Requirements
5.3 Security Requirements
5.4 Software Quality Attributes
6. Other Requirements
Appendix A: Glossary
Appendix B: Analysis Models
Appendix C: Issues List
Example SRS-
Problem statement for Library Information System (LIS)
• An institute has proposed to develop a Library Information System (LIS)
for students and employees.
• LIS will enable the members to borrow a book (or return it) with ease
while sitting at his desk/chamber.
• Issuing or returning books is restricted to valid users (members) of LIS
only.
• The system also enables a member to extend the date of his borrowing,
if no other booking for that particular book has been made.
• The librarian can enter a new record into the system when a new book
has been purchased, or remove a record in case any book is taken off the
shelf.
• Any non-member is free to use this system to browse/search books
online.
• No password should not be stored in system as a plain text.
• The final software would a web application (using the recent HTML 5),
used within the institute LAN.
Identification of functional
requirements
The functional requirements of the system can be:
• New user/member registration
• Search book
• User/member login
• Issue book
• Return book
• Re-issue book
• Add book
• Delete book
Identification of non-
functional requirements
Performance Requirements:
• This system should remain accessible 24x7.
• At least 50 users should be able to access the system altogether at any
given time.

Security Requirements: • This system should be accessible only within the

institute LAN.

• The database of LIS should not store any password in plain text - a
hashed value has to be stored.

• Software Quality Attributes

• Reliability
• Availability
• Security
• Portability
• Database Requirements
• File Format (data shall be stored in text-based flat files)
• Accessibility and security

• Design Constraints:
• The LIS has to be developed as a web application, which
should work with Firefox 5, Internet Explorer 8, Google Chrome
12.
• The system should be developed using HTML 5.