REQUIREMENT ANALYSIS

AND SPECIFICATION

Prepared by:
Prof. Sherin Mariam Jijo
Understanding the Requirement
 Most difficult task that a SW Engineer face.
 This tasks lead to an understanding of what the
impact of the SW will be, what the customer wants
& how the end users will interact with the SW.
 Understand what the customer wants before you
begin to design and build a computer based
system.
Requirement Engineering
 Requirement Engineering means that requirements for a
product are defined, managed and tested
systematically.
 Requirements engineering builds a brige to design and
construction.
 Requirements engineering provides the appropriate
mechanism for understanding what the customer wants,
analyzing need, 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.
Tasks
 Inception—ask a set of questions
 Who is behind the request for this work?
 Who will use the solution?
 What will be the economic benefit of a successful solution
 Is there another source for the solution that you need?

This will helps to establish

 basic understanding of the problem

 the people who want a solution

 the nature of the solution that is desired, and

 the effectiveness of preliminary communication and

collaboration between the customer and the developer
Tasks Cont…
• Identify stakeholders.
• Recognize multiple points of view
• Work toward collaboration
 Elicitation—elicit requirements from all
stakeholders.
❖ Draw out the requirements from stakeholders.
❖ Identify a number of problems that are encountered
as elicitation occurs are problems of scope, problems
of understanding, problems of volatility.
Tasks cont…
 Elaboration—create an analysis model that identifies
data, function and behavioral requirements
 Elaboration is driven by the creation and refinement of user
scenarios that describe how the end user (and other actors)
will interact with the system.
 Each user scenario is parsed to extract analysis classes—
business domain entities that are visible to the end user.
 The attributes of each analysis class are defined, and the
services that are required by each class are identified.
 The relationships and collaboration between classes are
identified, and a variety of supplementary diagrams are
produced.
Tasks cont…
Negotiation—agree on a deliverable system that is
realistic for developers and customers,
 The best negotiations strive for a “win-win” result.

 That is, stakeholders win by getting the system or

product that satisfies the majority of their needs and

you (as a member of the software team) win by
working to realistic and achievable budgets and
deadlines.
Tasks cont…
 Specification—can be any one (or more) of the following:
 A written document
 A set of models
 A formal mathematical
 A collection of user scenarios (use-cases)
 A prototype
 Validation—a review mechanism that looks for
 errors in content or interpretation
 areas where clarification may be required
 missing information
 inconsistencies (a major problem when large products or
systems are engineered)
 conflicting or unrealistic (unachievable) requirements.
Tasks cont…
 Requirements management
❖ Manage changing requirements.
❖ Requirements management is a set of activities that
help the project team identify, control, and track
requirements and changes to requirements at any
time as the project process.
❖ Many of these activities are identical to the
software configuration management.
Software Requirement Specification

 A software requirements specifi cation (SRS) is a

work product that is created when a detailed
description of all aspects of the software to be built
must be specified before the project is to
commence.
 It is usually signed off at the end of requirements
engineering phase.
 SRS is also helping the clients to understand their
own needs.
Characteristics of an SRS
 Software requirements specification should be
accurate, complete, efficient, and of high quality, so
that it does not affect the entire project plan.
 An SRS is said to be of high quality when the
developer and user easily understand the prepared
document.
Characteristics of an SRS Cont…
 Correct
 SRS is correct when all user requirements are stated in
the requirements document.
 The stated requirements should be according to the
desired system.
 This implies that each requirement is examined to
ensure that it (SRS) represents user requirements.
 Note that there is no specified tool or procedure to
assure the correctness of SRS. Correctness ensures that
all specified requirements are performed correctly.
Characteristics of an SRS Cont…
 Unambiguous
 SRS is unambiguous when every stated requirement
has only one interpretation.
 This implies that each requirement is uniquely
interpreted.
 In case there is a term used with multiple meanings,
the requirements document should specify the
meanings in the SRS so that it is clear and easy to
understand.
Characteristics of an SRS Cont…
 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.
 Ranked for importance/stability
 All requirements are not equally important, hence each
requirement is identified to make differences among
other requirements.
 For this, it is essential to clearly identify each
requirement. Stability implies the probability of
changes in the requirement in future.
Characteristics of an SRS Cont…
 Modifiable
 The requirements of the user can change, hence requirements
document should be created in such a manner that those
changes can be modified easily, consistently maintaining the
structure and style of the SRS.
 Verifiable
 SRS is verifiable when the specified requirements can be
verified with a cost-effective process to check whether the final
software meets those requirements.
 The requirements are verified with the help of reviews. Note
that unambiguity is essential for verifiability.
Characteristics of an SRS Cont…
 Consistent
 SRS is consistent when the subsets of individual requirements
defined do not conflict with each other.
 For example, there can be a case when different
requirements can use different terms to refer to the same
object.
 There can be logical or temporal conflicts between the
specified requirements and some requirements whose logical
or temporal characteristics are not satisfied.
 For instance, a requirement states that an event 'a' is to
occur before another event 'b'. But then another set of
requirements states (directly or indirectly by transitivity) that
event 'b' should occur before event 'a'.
Characteristics of an SRS Cont…
 Traceable
 SRS is traceable when the source of each
requirement is clear and facilitates the reference of
each requirement in future.
 For this, forward tracing and backward tracing are
used.
 Forward tracing implies that each requirement
should be traceable to design and code elements.
 Backward tracing implies defining each requirement
explicitly referencing its source.
Functional requirements

 These describe the functionality of a system -- how a

system should react to a particular set of inputs and
what should be the corresponding output.
 Given a problem statement, the functional requirements
could be identified by focusing on the following points:
 Identify the high level functional requirements simply
from the conceptual understanding of the problem. For
example, a Library Management System, apart from
anything else, should be able to issue and return books.
Functional requirements Cont…
 Identify the cases where an end user gets some
meaningful work done by using the system.
 For example, in a digital library a user might use
the "Search Book" functionality to obtain
information about the books of his interest.
 If we consider the system as a black box, there
would be some inputs to it, and some output in
return. This black box defines the functionalities of
the system.
Functional requirements Cont…
 For example, to search for a book, user gives title
of the book as input and get the book details and
location as the output.
 Any high level requirement identified could have
different sub-requirements.
 For example, "Issue Book" module could behave
differently for different class of users, or for a
particular user who has issued the book thrice
consecutively.
Non-Functional requirements
 They are not directly related what functionalities
are expected from the system.
 However, NFRs could typically define how the
system should behave under certain situations.
 For example, a NFR could say that the system
should work with 128MB RAM.
Non-Functional requirements Cont…

 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.
Non-Functional requirements Cont…

 External requirements
 Requirements which arise from factors which are
external to the system and its development process
 e.g. interoperability requirements, legislative
requirements, etc.
Table of contents
Requirement Elicitation

 Requirements elicitation combines elements of

problem solving, elaboration, negotiation, and
specification.
 In order to encourage a collaborative, team-
oriented approach to requirements gathering,
stakeholders work together to identify the problem,
propose elements of the solution, negotiate
different approaches and specify a preliminary set
of solution requirements.
Collaborative Requirements Gathering

 The goal is to identify the problem, propose

elements of the solution, negotiate different
approaches, and specify a preliminary set of
solution requirements in an atmosphere that is
conducive to the accomplishment of the goal.
 Meetings are conducted and attended by both
software engineers and other stakeholders.
 Rules for preparation and participation are
established.
Collaborative Requirements Gathering
cont…
 An agenda is suggested that is formal enough to
cover all important points but informal enough to
encourage the free flow of ideas.
 A “facilitator” (can be a customer, a developer, or
an outsider) controls the meeting.
 A “definition mechanism” (can be work sheets, flip
charts, or wall stickers or an electronic bulletin
board, chat room, or virtual forum) is used.
Quality Function Deployment

 Quality function deployment (QFD) is a quality

management technique that translates the needs of
the customer into technical requirements for
software.
 QFD “concentrates on maximizing customer
satisfaction from the software engineering process”.
 QFD identifies three types of requirements normal
requirements, expected requirements, exciting
requirements
QFD cont..
 Normal requirements: If the goal of a product met,
the customer is satisfied. Examples: Requested types
of graphical displays, specific system functions &
defined levels of performance.
 Expected requirements: Implicit to the product or
system and fundamental. Examples: Ease of
human/machine interaction, overall operational
correctness and reliability & ease of Sw installation.
QFD cont..
 Exciting requirements: These features go beyond
the customer's expectations & prove to be very
satisfying when present.
 Example: Sw for a new mobile phone comes with
standard features, but is coupled with a set of
unexpected capabilities.(Eg: multitouch screen,visual
voice mail)that delight every user of the product.
QFD cont…
 Function deployment determines the “value” (as
perceived by the customer) of each function
required of the system
 Information deployment identifies data objects and
events
 Task deployment examines the behavior of the
system
 Value analysis determines the relative priority of
requirements
Elicitation Work Products

 The work products produced as a consequence of

requirements elicitation will vary depending on the
size of the system or product to be built.
For most systems, the work products include
 A statement of need and feasibility.

 A bounded statement of scope for the system or

product.
Elicitation Work Products Cont…
 A list of customers, users, and other stakeholders who
participated in requirements elicitation
 A description of the system’s technical environment.
 A list of requirements (preferably organized by
function) and the domain constraints that apply to
each.
 A set of usage scenarios that provide insight into the
use of the system or product under different
operating conditions.
 Any prototypes developed to better define
requirements.
Building the Analysis Model
 Provide a description of the required informational,
functional, and behavioural domains for a computer
based system.
 Analysis model is a snapshot of requirements at any
given time.
 You should expect it to change.
Building the Analysis Model Cont…
 Elements of the analysis model
 Scenario-based elements
◼ Functional—processing narratives for software functions
◼ Use-case—descriptions of the interaction between an
“actor” and the system
 Class-based elements
◼ Implied by scenarios
 Behavioral elements
◼ State diagram
 Flow-oriented elements
◼ Data flow diagram
Scenario based elements:
 System is decribed from the user’s point of view
using a scenario based approach.
 First part of the model that is developed.
 They serve as input for the creation of other
modeling elements.
 Fig: depicts a UML activity diadram for eliciting
requirements and representing them using use cases.
 Conduct FA ST
m eet ings

Make list s of
f unct ions, classes

Make list s of
const raint s, et c.

f orm al priorit izat ion?

Elic it requirem ent s
yes no

Use QFD t o inf orm ally def ine act ors

priorit ize priorit ize
requirem ent s requirem ent s

draw use-case
writ e scenario
diagram

Creat e Use-cases
com plet e t em plat e
Usage Scenarios

 As requirements are gathered, an overall vision of

system functions and features begins to materialize.
 Users can create a set of scenarios that identify a
thread of usage for the system to be constructed.
 The scenarios, often called use cases.
 A collection of user scenarios that describe the
thread of usage of a system
 Each scenario is described from the point-of-
view of an “actor”—a person or device that
interacts with the software in some way
 Each scenario answers the following questions:
 Who is the primary actor, the secondary actor (s)?
 What are the actor’s goals?
 What preconditions should exist before the story begins?
 What main tasks or functions are performed by the actor?
 What extensions might be considered as the story is described?
 What variations in the actor’s interaction are possible?
 What system information will the actor acquire, produce, or
change?
 Will the actor have to inform the system about changes in the
external environment?
 What information does the actor desire from the system?
 Does the actor wish to be informed about unexpected changes?
Class based approach
 Each usage scenario implies a set of objects that
are manipulated as an actor interacts with the
system.
 These objects are categorized into classes.
 Fig shows the class diagram of library management
systems.
Class diagram
Class diagram Cont…
 A class is represented by a rectangle having three
sections −
 Top section containing the name of the class,
 Middle section containing class attributes.
 Bottom section representing operations of the class.
Class diagram Cont…
 The visibility of the attributes and operations can be
represented in the following ways −
 Public − A public member is visible from anywhere in
the system. In class diagram, it is prefixed by the
symbol ‘+’.
 Private − A private member is visible only from within
the class. It cannot be accessed from outside the class. A
private member is prefixed by the symbol ‘−’.
 Protected − A protected member is visible from within
the class and from the subclasses inherited from this
class, but not from outside. It is prefixed by the symbol
‘#’.
Behavioral elements
 The behaviour of a computer based system can
have a profound effect on the design that is chosen
and the implementation approach that is applied.
 Must provide modeling elements that depict
behaviour.
 State diagram is one method.
State diagram
 A state diagram is used to represent the condition
of the system or part of the system at finite
instances of time.
 It’s a behavioral diagram and it represents the
behavior using finite state transitions.
 Used to model the dynamic behavior of a class in
response to time and changing external stimuli.
Steps to draw a state diagram –

 Identify the initial state and the final terminating

states.
 Identify the possible states in which the object can
exist (boundary values corresponding to different
attributes guide us in identifying different states).
 Label the events which trigger these transitions.
State diagram cont…
Flow oriented elements
 Information is transformed as it flows through a
computer based system.
 The system accepts input in a variety of forms,
applies functions to transform it and produces
output in a variety of forms.
 The flow of data of a system or a process is
represented by DFD.
Data Flow Diagram
 DFD is the abbreviation for Data Flow Diagram.
 It gives insight into the inputs and outputs of each
entity and the process itself.
 Data Flow diagrams are very popular because
they help us to visualize the major steps and data
involved in software-system processes.
Structure of DFD
DFD of Library Management System
Requirements Analysis
 Specifies software’s operational characteristics.
 Indicates software's interface with other system
elements.
 Establishes constraints that software must meet.
Requirements Analysis Cont…
 Requirements analysis allows the software
engineer (called an analyst or modeler in this
role) to:
 Elaborate on basic requirements established
during earlier requirement engineering tasks
 Build models that depict user scenarios,
functional activities, problem classes and their
relationships, system and class behavior, and
the flow of data as it is transformed.
A bridge

system
description

analysis
model

design
model
Rules of Thumb
 The model should focus on requirements that
are visible within the problem or business
domain.
 The level of abstraction should be relatively
high.
 Each element of the analysis model should add
to an overall understanding of software
requirements and provide insight into the
information domain, function and behavior of
the system.
Rules of Thumb Cont…
 Delay consideration of infrastructure and other
non-functional models until design.
 Minimize coupling throughout the system.

 Be certain that the analysis model provides

value to all stakeholders.
 Keep the model as simple as it can be.
Domain Analysis
 Identification, analysis, and specification of common
requirements from a specific application domain,
typically for reuse on multiple projects within that
application domain.
 Object-oriented domain analysis in terms of
common objects, classes, subassemblies, and
frameworks .
Domain Analysis Cont…
 Define the domain to be investigated.
 Collect a representative sample of applications in
the domain.
 Analyze each application in the sample.
 Develop an analysis model for the objects.
Elements of Requirements Analysis
Data Modeling
 Examines data objects independently of processing.
 Focuses attention on the data domain.
 Creates a model at the customer’s level of
abstraction.
 Indicates how data objects relate to one another.
What is a Data Object?
 A representation of almost any composite information that must be
understood by software.
It can be an
 External entity (e.g., anything that produces or consumes information)

 Thing (e.g., a report or a display)

 Occurrence (e.g., a telephone call)

 Event (e.g., an alarm),

 Role (e.g., salesperson),

 Organizational unit (e.g., accounting department),

 Place (e.g., a warehouse),

 Structure (e.g., a file).

 The description of the data object incorporates the
data object and all of its attributes.
 A data object encapsulates data only—there is no
reference within a data object to operations that
act on the data.
 A data object contains a set of attributes that act as
an aspect, quality, characteristic, or descriptor of
the object.
object: automobile
attributes:
make
model
body type
price
options code
What is a Relationship?
 Data objects are connected to one another in
different ways.
 A connection is established between person and car
because the two objects are related.
◼ A person owns a car
◼ A person is insured to drive a car
 The relationships owns and insured to drive
define the relevant connections between
person and car.
 Several instances of a relationship can exist.
 Objects can be related in many different ways.
ER Diagram for University Examination
Class-Based Modeling
 Class-based modeling represents:
 objects that the system will manipulate

 operations (also called methods or services) that

will be applied to the objects to effect the
manipulation
 relationships (some hierarchical) between the
objects
 collaborations that occur between the classes that
are defined.
Potential Classes
 Retained information. The potential class will be
useful during analysis only if information about
it must be remembered so that the system can
function.
 Needed services. The potential class must have
a set of identifiable operations that can
change the value of its attributes in some way.
 Common attributes. A set of attributes can be
defined for the potential class and these
attributes apply to all instances of the class.
Potential Classes cont…
 Multiple attributes. During requirement analysis, the focus
should be on "major" information; a class with a single
attribute may, in fact, be useful during design, but is probably
better represented as an attribute of another class during the
analysis activity.
 Common operations. A set of operations can be defined for the
potential class and these operations apply to all instances of
the class.
 Essential requirements. External entities that appear in the
problem space and produce or consume information essential
to the operation of any solution for the system will almost
always be defined as classes in the requirements model.
Defining Operations
 Operations can be divided into four broad
categories:
 (1) operations that manipulate data in some way
(e.g., adding, deleting, reformatting, selecting)
 (2) operations that perform a computation

 (3) operations that inquire about the state of an

object, and
 (4) operations that monitor an object for the
occurrence of a controlling event.
Class-responsibility-collaborator
(CRC)
 A CRC model is really a collection of standard
index cards that represent classes.
 The cards are divided into three sections.
 Along the top of the card you write the name of the
class.
 In the body of the card you list the class
responsibilities on the left and the collaborators on
the right.
CRC Modeling
Class:
Class:
Description:
Class:
Description:
Class: FloorPlan
Description:
Responsibility:
Description: Collaborator:
Responsibility: Collaborator:
Responsibility: Collaborator:
Responsibility: Collaborator:
defines floor plan name/type
manages floor plan positioning
scales f loor plan for dis play
scales f loor plan for dis play
incorporates walls, doors and windows Wall
shows position of video cameras Camera
DFD for Airlines Reservation System.

 Level 0 dfd
Level1 dfd
Level2 dfd
Swimlane Diagrams
 Allows the modeler to represent the flow of
activities described by the use-case and at the same
time indicate which actor (if there are multiple
actors involved in a specific use-case) or analysis
class has responsibility for the action described by
an activity rectangle
 hom eowner c a m e ra i n t e rf a c e

ent er pas s w ord

and us er ID

valid p asswo r d s/ ID
in valid
p asswo r d s/ ID
s elec t m ajor f unc t ion

o t h er f u n ct io n s prom pt f or reent ry
m ay also b e
select ed

in p u t t r ies
s elec t s urv eillanc e r em ain

n o in p u t
t r ies r em ain

t h u m b n ail views select a sp ecif ic cam er a

s elec t s pec if ic
s elec t c am era ic on
c am era - t hum bnails

generat e v ideo
out put

v iew c am era out put prom pt f or

in labelled w indow anot her v iew

exit t h is
f u n ct io n

see
an o t h er
cam er a
Questions
 Enlist characteristic of SRS.Write a SRS for college
management system.
 Explain Requirement Engineering Tasks.
 Draw the Data Flow Diagram for Hotel Management
System .
 Draw the ER diagram for the system that is known to
you.
 Enlist characteristic of SRS.Write a SRS for Hospital
management system.
Questions cont…
 Write a short note on Requirement
Engineering.
 What is Object Oriented Design of a system?

Draw the Use case diagram and Class

diagram for Library Management system.
 What is activity diagram and Swim-lane?
Draw activity diagram for Billing Counter of a
Shopping Mall.