Modelling

Module-2

Requirements Analysis and

Specification
The Software Requirement
• The software requirements are the description
of features and functionalities of the target
software/system/model.

• Requirements convey the expectations of users

from the software product.

• The requirements can be obvious or hidden,

known or unknown, expected or unexpected
from the client’s point of view.

• The requirements provided by customer

ultimately reflect in the quality of the final
product.
• Requirement engineering is the process of
gathering, analyzing, documenting and
managing requirements.
 Steps involved in Requirements Engineering

Documentation/
Elicitation Specification
(Gathering of user requirements
through interaction) (write requirements in well-
formatted document)
Requirement
s
Analysis and Engineering Validation
negotiation (check SRS document for scope of
(analyze the set of requirements for any kind of misinterpretation of
any inconsistency, conflict or requirements, relation between
irrelevance) requirements, etc.)

Management
Organize requirements in tabular
manner/categorization
Requirements elicitation
• It is the most difficult, crucial and error-prone phase.
• Intensive communication is required with customers and stake-
holders.
• Can be succeeded through an effective customer-developer
relationship.

Difficulties:
Problems of scope.
Problems of understanding
 customer is not sure about actual requirement
 Lack of full understanding of customer regarding problem domain

Problems of volatility (customer requirements change over time)

Different methods of requirement elicitation

• Study existing documentation (understanding state-of-

the-art)
• Interview
• Brain storming
• Delphi technique
• FAST (Facilitated Application Specification Technique)
• QFD (Quality Function Deployment)
• Use-case approach.
Interview (one-to-one discussion)
 Both parties would like to understand each
others.
 Types:
 open ended (no agenda-context free
question)
 Structured (agenda is pre-set)

Brain-storming (group discussion)

 Kind of group discussion, which lead to ideas

quickly and helps to promote innovative
creation.

 All participants are encouraged to put their own

ideas and discuss on it.
Delphi-technique
1. Participants wite their ideas/requirements in a
paper and exchange it to others.
2. Every participant give feedback/comment to
others requirements.
3. Process executed till final consensus is
reached.
FAST
 This approach encourages the creation of joint
teams of customer and developer, who works
together to understand correct set of
requirements for the product.
 Everyone is asked to prepare a list of:
 What surrounds the system.
 What produces by the system.
 Used by the system.
 List of services, constraints and performance
criteria.
QFD
Its emphasize to incorporation of customer requirements as per
importance/priority into the final product.
Then according to the importance of requirements, a value indicating degree
of importance has been given
As per that value developing team consider that for system product.
Very important : 5 point
Important : 4 point
Not important but nice to have: 3 point
Not important: 2 point
Unrealistic for now, need further explanation: 1 point
Irrelevant : 0 point
Use-case diagram
These are structured description of user
requirements.
It is a narrative which describes the
sequence of events from user’s
perspective.
Use case diagram is a graphical
representation of how system works and
behaviour.
Requirement analysis and negotiation
• In this phase analysis of requirements takes place to find any
inconsistency, ambiguity or conflict.
• Obtain a clear understanding of the software to be developed.
• Following question should be clearly understood by the analyst
before start requirement analysis.
 What is the problem?
 Why is it important to solve the problem?
 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?
 Do any requirements conflict with other requirements
During requirements analysis, the analyst needs to identify and resolve three
main
Types of problems in the requirements:
• Anomaly or ambiguity
• One requirement of customer is “When the temperature becomes high, the heater
should be switched off.”
• Here, high can be subjectively interpreted.
• Inconsistency
• The furnace should be switched-off when the temperature of the furnace rises above
500 degree C.
• When the temperature of the furnace rises above 500 degree C, the water shower
should be switched-on and the furnace should remain on.
• Incompleteness
• 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 through a (postal) letter
as well as through e-mail.

• However, it was found that there is no provision by which either the postal or e-mail
address of the parents of the students can be entered into the system.
Software Requirement Specification (SRS)
• A specification can be a written document, a graphical model, a
formal mathematical model, a collection of usage scenarios, a
prototype, or any combination of these.
• The SRS document usually contains all the user requirements in a
structured though an informal form.

• SRS document is probably the most important document and is

the toughest to write.

• One reason for this difficulty is that the SRS document is

expected to cater to the needs of a wide variety of audience.
Ways of writing a system requirements
Specification
Why Spend Time and Resource to Develop an SRS
Document?
Forms an agreement between the customers and the developers.
Reduces future reworks
 Reduce the chance of redesign, recoding and retesting in later stage if SRS
is written carefully.
Provides a basis for estimating costs and work-schedules.
Provides a baseline for validation and verification
Facilitates future extensions.
Characteristics of a Good SRS Document
• Concise
• complete, unambiguous
• Implementation-independent
• only mention the functionalities, no implementation
details
• Traceable.
• Modifiable
• SRS should be modified with change of requirements
• Identification of response to undesired events
• Verifiable.
• “the system should be user friendly” -is not verifiable
• “When the name of a book is entered, the software should
display whether the book is available for issue or it has
been loaned out” is verifiable

Attributes of BAD SRS

• Over-specification
• Forward references
• Wishful thinking
• Noise
Users of a SRS Document
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.

Examples
•It is able to record sales in the sales
system
•Integration of software with banking API
•Automatic customer verification
Non-functional
• Non-functional requirements define the
Requirements
attributes of software quality.
• The non-functional requirements capture those
requirements of the customer that cannot be
expressed as functions (i.e., accepting input data
and producing output data).

Examples
•The first password cannot be reused.
•The ability of the system to process a certain
number of user requests without functional
Types of non-functional requirements
• User interface: interface should provide easy understanding of system for users
• Scalability: how the system performs when number of users is getting increased.
• Capacity: maximum amount of work that system can perform in a given time
• Portability and compatibility : Which hardware, operating systems, and browsers,
along with their versions does the software run on? Does it conflict with other applications
and processes within these environments
• Recoverability: how fast the system can recover from any crash or failure
• Availability: the amount of time that the system remains operational under normal
circumstances in order to serve its functionalities.
• Maintainability: modification of a software product after delivery to correct faults, to
improve performance or other attributes
• Throughput: a measure of how many units of information a system can process in a given
amount of time
• Security: how well the system and its data protected from risk or attacks?
Comparison table of Functional and Non-
functional Requirements
Metrics for specifying nonfunctional
requirements
The Structure of a Requirements Document (SRS)
The Structure of a Requirements Document
Requirement Validation
Requirements Validation Techniques are used to ensure that the software
requirements are complete, consistent, and correct.
SRS should satisfy users needs.
Various stakeholders are involved in making SRS, resulting unclear
requirements, errors, incorrect fact, inconsistency, etc.
Validation ensures that correct and clear statement of requirements in the SRS
document.
Methods of requirement validation
 Review process:
 it performs by group of people from both client and developer side, who adhere some rules
and procedure for reviewing.
 Checks completeness and consistency.
 Follow up the review process.
 Final document is revised for acceptance or re-review.
• Inspection:
 It inspects the document to detect defects at early stage.
 Inspector understand the SRS and inspects.
 The producer who developed the SRS, explain it in front of inspectors to make them understand the
document.
 Defects are collected, documented and compiled.
 If needed re-inspection is done.
 Costly process.
• Test-case generation:
• Requirements are validated using test-cases.
• Black box test cases are applied that require knowledge of the requirements instead of internal
details.
• Reading:
Readers applies their knowledge to identify defects.
Ad hoc-based
Check-list based : some set of questions have been asked to readers.
• Prototyping
• Create a prototype and incorporate customer suggestion to validate the requirements.
Requirement management

Requirement management refers to systematically collecting, organizing,

documenting, prioritizing, and negotiating on requirements of a project.
This process deal with frequent requirement changes
Activities:
 Collect initial requirements from stakeholders
 Analyse requirements
 Define and record requirements
 Prioritize requirements
 Agree on and approve requirements
 Trace requirements to work items
 Query stakeholders after implementation on needed changes to requirements
 Utilize test management to verify and validate system requirements
 Assess impact of changes
 Revise requirements
 Document changes
UML building blocks

Use-case : Use cases are used to represent high-

level functionalities and how the user will handle
the system

Actor: The actor is an entity that interacts with

the system by accessing use cases.

Class: static structure of an object.

It includes attributes and methods
(operations)
UML diagram

This diagram represents

different views of the
system from different
perspectives
Use case relationships
 Includes: the use case is mandatory
and part of base use case
 Extends: optional use case of base use
case
 Generalizations: inherits the
properties of base or parent use case
Class relationship
Classes in a programming solution can be related to each other in
the following four ways:
 Inheritance
 Association and link
 Aggregation and composition
 Dependency
Inheritance
• The inheritance feature allows one to define a new class by incrementally
extending the features of an existing class.
• The original class is called the base class (also called superclass or parent class )
and the new class obtained through inheritance is called the derived class (also
called a subclass or a child class ).
• The derived class is said to inherit the features/properties of the base class.
Association:
 Association is a common type of relation among classes.
 When two classes are associated, they can take each others help (i.e. invoke each
others methods) to serve user requests.
 We can indicate the multiplicity of an association by adding multiplicity adornments
to the line denoting the association. It indicates how many instances of a class is
associated with another class.
Aggregation and composition
 Aggregation and Composition are
subsets of association meaning they
are specific cases of association. In
both aggregation and composition
object of one class "owns" object of
another class.
 Aggregation implies a relationship
where the child can exist
independently of the parent. Aggregatio
Example: Class (parent) and n
Student (child). Delete the Class
and the Students still exist.
 Composition implies a relationship
where the child cannot exist
independent of the parent.
Example: House (parent) and Room
(child). Rooms don't exist separate
to a House.

Composition
Dependency
Dependencies in UML indicate that a source
element, also called the client, and target
element, also called the supplier, are related so
that the source element makes use of, or
depends upon, the target element. Changes in
the behaviour or structure of the target may
mean changes in the source.
Use case diagram of library
management system

Use-case scenarios-
description of different scenario
of use cases.

 System
 Use case name and
number
 Participating actors
 Description of use case
 Precondition
 Post condition
 Flow of events
 Non-functional
requirements
 Reference documents
Scenario 1: Request an new book
System Library management system
Use case name Request new book
Participating actor Users (both student and staff)
Description Request for issuance of new book that allows the
student to get book from library
Precondition User should be a registered person of any organization
and library
Postcondition Issuing slip has to be filled by the user with details of the
book
Flow of event 1. Member will request to librarian to get a new book
2. Librarian ask the user to fill a slip with details of the
book
3. Librarian issue a the requested book
Nonfunctional An understandable request slip has to be provided to
requirements user
Reference documents User should be given a user manual/CD with the book
 Class diagram of Library management
system
class –
User Class –
It manages all operations of user.
Librarian Class – It manages all
operations of Librarian.
Book Class –
It manages all operations of books.
Account Class –
It manages all operations of account.
Library database Class –
It manages all operations of library
database.
Staff Class –
It manages all operations of staff.
Student Class –
It manages all operations of student.
Behavioural/interaction View

Behavioural diagrams depict

interactions of objects and their
relationships. They also include the
messages passed between them.
Sequence diagram
Sequence diagrams are interaction
diagrams that illustrate the ordering of
messages according to time.
 These diagrams are in the form of
two-dimensional charts.
 The objects that initiate the
interaction are placed on the x–axis.
 The messages that these objects send
and receive are placed along the y–
axis, in the order of increasing time
from top to bottom.
 Collaboration diagram

• This diagram also used to represent the object

interaction.
• Objects that communicates in the collaboration
through message passing are called
collaborators.
 Objects. These are shown as rectangles with
naming labels inside. If an object has a
property or state that specifically influences
the collaboration, this should also be noted.
 Actors. These are instances that invoke the
interaction in the diagram. Each actor has a
name and a role, with one actor initiating the
entire use case.
 Links. These connect objects with actors and
are depicted using a solid line between two
elements. Each link is an instance where
messages can be sent.
 Messages between objects. These are
shown as a labelled arrow placed near a link.
These messages are communications between
objects that convey information about the
activity and can include the sequence number.
Activity diagram
 Activity diagram is basically a flowchart to
represent the flow from one activity to another
activity.
 The activity can be described as an operation
of the system.
 It captures the dynamic behaviour of the
system.
 It does not show any message flow from one
activity to another.
 Activity diagram is sometimes considered as
the flowchart.
 The activity diagram is made to understand
the flow of activities and is mainly used by the
business users.
Elements of activity diagram:
 Activities
 Association
 Conditions
 Constraints
 Component diagram

The UML component diagram shows how a

software system will be made up of a set of
deployable components,

Components represents the physical artefacts

of a system.

Software components can be dynamic-link

library (DLL) files, database, codes, executable
files, or web services.

Using well-defined interfaces, these

components communicate with each other.

Steps :
1. Finalize the Function and Processes of the Software.
2. Put the Components included.
3. Add the Dependencies (Ports and interfaces)
Deployment diagram
• A deployment diagram shows how a software
system will be physically deployed in the
hardware environment.
• That is, which component will execute on which
hardware component and how they will they
communicate with each other.
• Suitable for large and complex projects, where
software solutions are run on hardware
systems.
• It provides a static deployment view of a
system.
Building elements of deployment
diagram
Structured analysis model
1. Also refers to data flow modelling.
2. It represents the behaviour of the system in abstract manner.
3. Data flow diagram (DFD) describes the flow of data through a system
and functionalities of the system.

• Symbols Used in DFD

• Square Box: A square box defines source or destination
of the system. It is also called entity. It is represented by
rectangle.
• Arrow or Line: An arrow identifies the data flow i.e. it
gives information to the data that is in motion.
• Circle or bubble chart: It represents as a process that
gives us information. It is also called processing box.
• Open Rectangle: An open rectangle is a data store. In
this data is store either temporary or permanently.
Levels of DFD
• DFD uses hierarchy to maintain transparency thus multilevel DFD’s can be
created. Levels of DFD are as follows:
• 0-level DFD: It represents the entire system as a single bubble and provides
an overall picture of the system.

• 1-level DFD: It represents the main functions of the system and how they
interact with each other.

• 2-level DFD: It represents the processes within each function of the system
and how they interact with each other.

• 3-level DFD: It represents the data flow within each process and how the
data is transformed and stored.
DFD for ATM
Online Food order system(OFOS)

DFD level 0 (context

diagram)

1. Registered customer can

enter into the OFOS to
access its service.

2. Administrator keeps
monitor the system, handle
order details and manages
suppliers.
3. Suppliers receive order
details and send food to
customer through system.
DFD level 1
OFOS functional and non-functional requirements
Functional
 Registration of customer.
 Search for suppliers
 Select food and add to cart
 Place order
 Generate report
 Payment
 Manage delivery of food
Nonfunctional
 Availability
 Traceability
 Reliability
 Maintainability
 Usability