UNIT-2

Software Requirements
Analysis and
Specification
Anoop M.B
Department of computer application
BCMCAV353

1
  Problem of scale is a key issue for SE
2  For small scale, understand and
specifying requirements is easy
 For large problem - very hard;
probably the hardest, most
problematic and error prone
 Input : user needs in minds of people
 Output : precise statement of what the
future system will do
  Identifying and specifying req
3
necessarily involves people
interaction
 Cannot be automated
 Requirement (IEEE)= A condition or
capability that must be possessed by a
system
 Req. phase ends with a software
requirements specification (SRS)
document
 SRS specifies what the proposed
system should do
  Requirements understanding is hard
4  Visualizing a future system is difficult

 Capability of the future system not

clear, hence needs not clear

 Requirements change with time

 …

 Essential to do a proper analysis

and specification of requirements
 1) Need for SRS
5

 SRS establishes basis of agreement

between the user and the supplier.
 Users needs have to be satisfied, but

user may not understand software

 Developers will develop the system,

but may not know about problem

domain
 SRS is the medium to bridge the

commn. gap and specify user needs in

a manner both can understand
 Need for SRS…
6
 Helps usezr understand his needs.
 users do not always know their needs

 must analyze and understand the potential

 the goal is not just to automate a manual

system,
but also to add value through IT
 The req process helps clarify needs

 SRS provides a reference for validation of the final

product
 Clear understanding about what is expected.

 Validation - “ SW satisfies the SRS “

 Need for SRS…
7

 High quality SRS essential for high Quality SW

 Requirement errors get manifested in final sw
 to satisfy the quality objective, must begin with
high quality SRS
 Requirements defects are not few
 25% of all defects in one case; 54% of all defects found
after UT
 80 defects in A7 that resulted in change requests
 500 / 250 defects in previously approved SRS.
 Need for SRS…
8

 Good SRS reduces the development cost

 SRS errors are expensive to fix later
 Req. changes can cost a lot (up to 40%)
 Good SRS can minimize changes and errors
 Substantial savings; extra effort spent during
req. saves multiple times that effort
 An Example
 Cost of fixing errors in req. , design , coding ,
acceptance testing and operation are 2 , 5 ,
15 , 50 , 150 person-months
 Need for SRS…
9

 Example …
 After req. phase 65% req errs detected in design , 2%
in coding, 30% in Acceptance testing, 3% during
operation
 If 50 requirement errors are not removed in the
req. phase, the total cost
32.5 *5 + 1*15 + 15*50 + 1.5*150 = 1152 hrs
 If 100 person-hours invested additionally in req to
catch these 50 defects , then development cost could
be reduced by 1152 person-hours.
 Net reduction in cost is 1052 person-hours
10
2) Requirements Process
 Sequence of steps that need to be performed to
convert user needs into SRS
 Process has to elicit needs and requirements
and clearly specifies it
 Basic activities
 problem or requirement analysis
 requirement specification
 validation
 Analysis involves elicitation and is the hardest
 Requirements Process..
11

needs

Analysis

Specification

Validation
 Requirement process..
12

 Process is not linear, it is iterative and

parallel
 Overlap between phases - some parts
may be analyzed and specified
 Specification itself may help analysis
 Validation can show gaps that can lead
to further analysis and spec
 Requirements Process…
13

 Focus of analysis is on understanding the

desired systems and it’s requirements
 Divide and conquer is the basic strategy
 decompose into small parts, understand each part
and relation between parts
 Large volumes of information is generated
 organizing them is a key
 Techniques like data flow diagrams, object
diagrams etc. used in the analysis
 Requirements Process..
14

 Transition from analysis to specs is hard

 in specs, external behavior specified
 during analysis, structure and domain are
understood
 analysis structures helps in specification, but
the transition is not final
 methods of analysis are similar to that of
design, but objective and scope different
 analysis deals with the problem domain,
whereas design deals with solution domain
 3) Problem Analysis
15

 Aim: to gain an understanding of the needs,

requirements, and constraints on the software
 Analysis involves
 interviewing client and users
 reading manuals
 studying current systems
 helping client/users understand new possibilities
 Like becoming a consultant
 Must understand the working of the
organization , client and users
 Problem Analysis…
16

 Some issues
 Obtaining the necessary information
 Brainstorming: interacting with clients to
establish desired properties
 Information organization, as large amount of
info. gets collected
 Ensuring completeness
 Ensuring consistency
 Avoiding internal design
 Problem Analysis…
17
 Interpersonal issues are important
 Communication skills are very important
 Basic principle: problem partition
 Partition w.r.t what?
 Object - OO analysis
 Function - structural analysis
 Events in the system – event partitioning
 Projection - get different views
 Will discuss few different analysis techniques
5) Informal Approach
 Informal methods of validation and
verification are some of the more
frequently used in modeling and
simulation. They are
called informal because they are more
qualitative than quantitative. ... In some
cases, informal methods offer the
convenience of quick testing to see if a
model can be validated.
 There are several reasons why an informal
method might be chosen.
 In some cases, informal methods offer the
convenience of quick testing to see if a
model can be validated. 
 Inspection is a verification method that is used
to compare how true the conceptual model
matches the executable model.
 Depending on the resources available, the
members of the inspection team may or may
not be part of the model production team.
 6) Structured Analysis

 Structured Analysis is a development method that allows

the analyst to understand the system and its activities in a
logical way
 It is a systematic approach, which uses graphical tools that
analyze and refine the objectives of an existing system and
develop a new system specification which can be easily
understandable by user.
 It has following attributes −
 It is graphic which specifies the presentation of application.
 It divides the processes so that it gives a clear picture of
system flow.
 It is logical rather than physical i.e., the elements of system
do not depend on vendor or hardware.
 It is an approach that works from high-level overviews to
lower-level details.
 Structured Analysis Tools
 Data Flow Diagrams
 Data Dictionary
 Decision Trees
 Decision Tables
 Structured Query
 Pseudo code
 you can see next page diagram
 It shows the flow of data between various functions of
system and specifies how the current system is
implemented.
 It is an initial stage of design phase that functionally
divides the requirement specifications down to the
lowest level of detail.
 Its graphical nature makes it a good communication
tool between user and analyst or analyst and system
designer.
 It gives an overview of what data a system processes,
what transformations are performed, what data are
stored, what results are produced and where they flow.
23
Data flow diagrams

 A DFD shows flow of data through the

system
 Views system as transforming inputs to
outputs
 Transformation done through
transforms
 DFD captures how transformation occurs
from input to output as data moves
through the transforms
 Not limited to software
24 Data flow diagrams…

 DFD
 Transforms represented by named
circles/bubbles
 Bubbles connected by arrows on which
named data travels
 A rectangle represents a source or sink and
is originator/consumer of data (often
outside the system)

Requirements
25 DFD Example
26
Data Dictionary

 In a DFD arrows are labeled with data items

 Data dictionary defines data flows in a DFD
 Shows structure of data; structure becomes
more visible when exploding
 Can use regular expressions to express the
structure of data

Requirements
 7) Prototyping
27
 Prototyping is another approach for problem
analysis
 Throwaway prototyping
 prototype only used as a demonstration of product
requirements
 finished software is engineered using another paradigm
 Evolutionary prototyping
 prototype is refined to build the finished system
 Customer resources must be committed to evaluation and
refinement of the prototype
 Customer must be capable of making requirements decisions in a
timely manner.
 8) Requirement Specification
 A software requirements specification (SRS) is
a document that captures complete description
about how the system is expected to perform. It
is usually signed off at the end of requirements
engineering phase.
The below diagram depicts the various types of
requirements that are captured during SRS.
 9)Characteristics of an SRS
30

 What should be the characteristics of a good

SRS? Some key ones are
 Complete
 Unambiguous
 Consistent
 Verifiable
 Ranked for importance and/or stability
 31
Characteristics…
 Correctness
 Each requirement accurately represents some
desired feature in the final system
 Completeness
 All desired features/characteristics specified
 Hardest to satisfy
 Completeness and correctness strongly
related
 Unambiguous
 Each req has exactly one meaning
 Without this errors will creep in
 Important as natural languages often used
 Characteristics…
32

 Verifiability
 There must exist a cost effective way of
checking if sw satisfies requirements
 Consistent
 two requirements don’t contradict each
other
 Ranked for importance/stability
 Needed for prioritizing in construction
 To reduce risks due to changing
requirements
 10)Components of an SRS
33

 What should an SRS contain ?

 Clarifying this will help ensure
completeness
 An SRS must specify
requirements on
 Functionality
 Performance
 Design constraints
 External interfaces
Requirements
 11) Specification Language
34

 Language should support desired char

of the SRS
 Formal languages are precise and
unambiguous but hard
 Natural languages mostly used, with
some structure for the document
 Formal languages used for special
features or in highly critical systems

Requirements
 Functional Requirements
35

 Heart of the SRS document; this forms the

bulk of the specs
 Specifies all the functionality that the system
should support
 Outputs for the given inputs and the
relationship between them
 All operations the system is to do
 Must specify behavior for invalid
inputs too
Requirements
 Performance Requirements
36

 All the performance constraints on the

software system
 Generally on response time ,
throughput etc => dynamic
 Capacity requirements =>
static
 Must be in measurable terms
(verifiability)
 Eg resp time should be xx
90% of the timeRequirements
 Design Constraints
37

 Factors in the client environment that

restrict the choices
 Some such restrictions
 Standard compliance and compatibility with
other systems
 Hardware Limitations
 Reliability, fault tolerance, backup req.
 Security

Requirements
 External Interface
38

 All interactions of the software with

people, hardware, and sw
 User interface most important
 General requirements of
“friendliness”
should be avoided
 These should also be verifiable

Requirements
 12) structure of requirement
document
 Requirements have to be specified using some
specification language
 Though formal notations exist for specifying specific
properties of the system, natural languages are now
most often used for specifying requirements. 
 All the requirements for a system, stated using a
formal notation or natural language, have to be
included in a document that is clear and concise.
 The IEEE standards recognize the fact that different
projects may require their requirements to be
organized differently, that is, there is no one method
that is suitable for all projects.
 General structure of an SRS

The introduction section contains the purpose, scope,

overview, etc., of the requirements document.
 Figure 3.3: One organization for specific requirements

In the functional requirements section, the functional capabilities

of the system are described. In this organization, the functional
capabilities for all the modes of operation of the software are
given.
42
13)Validation
 Lot of room for misunderstanding
 Errors possible
 Expensive to fix req defects later
 Must try to remove most errors in SRS
 Most common errors

 Omission - 30%
 Inconsistency - 10-30%
 Incorrect fact - 10-30%
 Ambiguity - 5 -20%
Requirements
43 14)Requirements Review

 SRS reviewed by a group of people

 Group: author, client, user, dev team rep.
 Must include client and a user
 Process – standard inspection process
 Effectiveness - can catch 40-80% of req.
errors

Requirements
 14) Requirements Views
Essential view
presents the functions to be accomplished and the
information to be processed while ignoring
implementation
Implementation view
presents the real world realization of processing
functions and information structures
 A v o i d the temptation to move directly to t
implementation view and assuming that the essence
of the problem is obvious.
 Structure of an SRS
45

 Introduction
 Purpose , the basic objective of the system
 Scope of what the system is to do , not to do
 Overview
 Overall description
 Product perspective
 Product functions
 User characteristics
 Assumptions
 Constraints

Requirements
 Structure of an SRS…
46

 Specific requirements
 External interfaces
 Functional requirements
 Performance requirements
 Design constraints
 Acceptable criteria
 desirable to specify this up front.
 This standardization of the SRS was done by
IEEE.
Requirements
 Functional Specification with Use
Cases

 Traditional approach for fn specs – specify

each function
 Use cases is a newer technique for specifying
behavior (functionality)
 I.e. focuses on functional specs only
 Though primarily for specification, can be
used in analysis and elicitation
 Can be used to specify business or org
behavior also, though we will focus on sw
 Well suited for interative systems 29
48
Use Cases Basics

 A use case captures a contract between

a user and system about behavior
 Basically a textual form; diagrams are
mostly to support
 Also useful in requirements elicitation as
users like and understand the story
telling form and react to it easily
49
Basics..
 Actor: a person or a system that interacts with the
proposed system to achieve a goal
 Eg. User of an ATM (goal: get money); data entry

operator; (goal: Perform transaction)

 Actor is a logical entity, so receiver and sender actors
are different (even if the same person)
 Actors can be people or systems
 Primary actor: The main actor who initiates a UC
 UC is to satisfy his goals

 The actual execution may be done by a system or

another person on behalf of the Primary actor

50
Basics..

 Scenario: a set of actions performed to

achieve a goal under some conditions
 Actions specified as a sequence of steps
 A step is a logically complete action
performed
either by the actor or the system
 Main success scenario – when things go
normally and the goal is achieved
 Alternate scenarios: When things go wrong
and goals cannot be achieved
51
Basics..

 A UC is a collection of many such

scenarios
 A scenario may employ other use cases
in a step
 I.e. a sub-goal of a UC goal may be
performed by another UC
 I.e. UCs can be organized
hierarchically
Requirements
52
Basics…
 UCs specify functionality by describing
interactions between actors and system
 Focuses on external behavior
 UCs are primarily textual
 UC diagrams show UCs, actors, and
dependencies
 They provide an overview
 Story like description easy to understand by
both users and analysts
 They do not form the complete SRS, only the
functionality part
53
Example

Use Case 1: Buy stocks

Primary Actor: Purchaser
Goals of Stakeholders:
Purchaser: wants to buy stocks
Company: wants full transaction info
Precondition: User already has an
account
Requirements
54
Example …

 Main Success Scenario

1. User selects to buy stocks
2. System gets name of web site from user for
trading
3. Establishes connection
4. User browses and buys stocks
5. System intercepts responses from the site and
updates user portfolio
6. System shows user new portfolio stading

Requirements
55
developing Use Cases

 UCs specify functional requirements

 Other req identified separately
 A complete SRS will contain the use
cases plus the other requirements
 Note – for system requirements it is
important to identify UCs for which the
system itself may be the actor

Requirements
56
Developing Use Cases

 UCs form a good medium for

brainstorming and discussions
 Hence can be used in elicitation and
problem analysis also
 UCs can be developed in a stepwise
refinement manner
 Many levels possible, but four naturally
emerge

Requirements
57
Developing…
 Step 1: Identify actors and goals
 Prepare an actor-goal list
 Provide a brief overview of the UC
 This defines the scope of the system
 Completeness can also be evaluated
 Step 2: Specify main Success Scenarios
 For each UC, expand main scenario
 This will provide the normal behavior of the
system
 Can be reviewed to ensure that interests of all
stakeholders and actors is met

Requirements
58
Developing…
 Step 3: Identify failure conditions
 List possible failure conditions for
UCs
 For each step, identify how it may
fail
 This step uncovers special situations
 Step 4: Specify failure handling
 Perhaps the hardest part
 Specify system behavior for the
failure conditions
 New business rules and actors may
emerge
59 Data Flow Modeling

 Widely used; focuses on functions

performed in the system
 Views a system as a network of data
transforms through which the data flows
 Uses data flow diagrams (DFDs) and
functional decomposition in modeling
 The SSAD methodology uses DFD to
organize information, and guide analysis
Requirements
60 DFD Conventions

 External files shown as labeled straight lines

 Need for multiple data flows by a process
represented by * (means and)
 OR relationship represented by +
 All processes and arrows should be
named
 Processes should represent transforms,
arrows should represent some data
61
Data flow diagrams…

 Focus on what transforms happen , how

they are done is not important
 Usually major inputs/outputs shown,
minor are ignored in this modeling
 No loops , conditional thinking , …
 DFD is NOT a control chart, no
algorithmic design/thinking
 Sink/Source , external files
 Drawing a DFD

 If get stuck , reverse direction

 If control logic comes in , stop and restart
 Label each arrows and bubbles
 Make use of + & *
 Try drawing alternate DFDs
Leveled DFDs :
 DFD of a system may
be very large
 Can organize it
hierarchically
 Start with a top level DFD
with a few bubbles 57
63
Drawing a DFD for a system
 Identify inputs, outputs, sources, sinks for the
system
 Work your way consistently from inputs to
outputs, and identify a few high-level
transforms to capture full transformation
 If get stuck, reverse direction
 When high-level transforms defined, then
refine each transform with more detailed
transformations

Requirements
64
Drawing a DFD for a system..

 Never show control logic; if thinking in

terms of loops/decisions, stop & restart
 Label each arrows and bubbles;
carefully identify inputs and outputs of
each transform
 Make use of + & *
 Try drawing alternate DFDs

Requirements
65 Leveled DFDs

 DFD of a system may be very large

 Can organize it hierarchically
 Start with a top level DFD with a few bubbles
 then draw DFD for each bubble
 Preserve I/O when “ exploding” a bubble so
consistency preserved
 Makes drawing the leveled DFD a top-down
refinement process, and allows modeling
of large and complex systems

Requirements
66 Data Dictionary Example

 For the timesheet DFD

Weekly_timesheet – employee_name + id +
[regular_hrs + overtime_hrs]*
Pay_rate = [hourly | daily | weekly] +
dollar_amt
Employee_name = last + first + middle
Id = digit + digit + digit + digit
Requirements
67 DFD drawing – common errors

 Unlabeled data flows

 Missing data flows
 Extraneous data flows
 Consistency not maintained during
refinement
 Missing processes
 Too detailed or too abstract
 Contains some control information
Requirements
Component and Connector View

 Two main elements – components and connectors

 Components: Computational elements or data stores
 Connectors: Means of interaction between comps
 A C&C view defines the comps, and which comps are
connected through which connector
 The C&C view describes a runtime structure of the
system – what comps exist at runtime and how they
interact during execution
 Is a graph; often shown as a box-and-line drawing
 Most commonly used structure

Software Architecture 68
Components
 Units of computations or data stores
 Has a name, which represents its role,
and provides it identity
 A comp may have a type; diff types rep
by diff symbols in C&C view
 Comps use ports (or
interfaces) to communicate
with others
 An arch can use any symbols to rep
components; some common ones are
shown
69
Some Component examples…

Software Architecture 70
Connectors
 Interaction between components happen
through connectors
 A connector may be provided by the runtime
environment, e.g. procedure call
 But there may be complex mechanisms for
interaction, e.g http, tcp/ip, ports,…; a lot of sw
needed to support them
 Important to identify them explicitly; also
needed for programming comps properly

71
Connectors…
 Connectors need not be binary, e.g. a
broadcast bus
 Connector has a name (and a type)
 Often connectors represented as
protocol –
i.e. comps need to follow some conventions
when using the connector
 Best to use diff notation for diff types of
connectors; all connectors should not
be shown by simple lines
Software Architecture 72
Connector examples

Software Architecture 73
An Example
 Design a system for taking online survey of
students on campus
 Multiple choice questions, students submit
online
 When a student submits, current result of the
survey is shown
 Is best built using web; a 3-tier architecture
is proposed
 Has a client, server, and a database
components
(each of a diff type)
 Connector between them
Software are also of diff types
Architecture 74
Example…

Software Architecture 75
Example…

 At arch level, details are not needed

 The connectors are explicitly stated,
which implies that the
infrastructure should provide http,
browser, etc.
 The choice of connectors imposes
constraints on how the components are
finally designed and built
Software Architecture 76
Extension 1

 This arch has no security – anyone can

take the survey
 We want that only registered students
can take the survey (at most once)
 To identify students and check for one-only
submission, need a authentication server
 Need to use cookies, and server has to be
built accordingly (the connector between
server and auth server is http with cookies)
Software Architecture 77
Extension 1…

Software Architecture 78
Extension 2

 It was found that DB is frequently down

 For improving reliability, want that if DB
is down, student is given an older
survey result and survey data stored
 The survey data given can be outdated
by at most 5 survey data points
 For this, will add a cache comp, which
will store data as well as results

Software Architecture 79
Extension 2…

Software Architecture 80
 Preliminary design

 Preliminary Design is the first step of software

design.

 During this phase, a high-level design concept that

meets the requirement specification is created.

 The concept is expressed as a set of components with

clear interfaces.
 Preliminary Design Goals

 Establish the system boundaries.

 Define system and component interfaces.

 Define component scope and responsibilities.

 Structured Design

 Structured design is a conceptualization of

problem into several well-organized elements of
solution. It is basically concerned with the
solution design. Benefit of structured design is,
it gives better understanding of how the
problem is being solved. Structured design also
makes it simpler for designer to concentrate on
the problem more accurately.

 Structured design is mostly based on ‘divide

and conquer’ strategy where a problem is
broken into several small problems and each
small problem is individually solved until the
whole problem is solved.
 A good structured design always follows
some rules for communication among
multiple modules, namely -
 Cohesion - grouping of all functionally related
elements.
 Coupling - communication between different
modules.
 Software Design Levels

 Architectural Design - The architectural design is the

highest abstract version of the system. It identifies the
software as a system with many components interacting
with each other. At this level, the designers get the idea of
proposed solution domain.
 High-level Design- The high-level design breaks the ‘single
entity-multiple component’ concept of architectural design
into less-abstracted view of sub-systems and modules and
depicts their interaction with each other. High-level design
focuses on how the system along with all of its components
can be implemented in forms of modules. It recognizes
modular structure of each sub-system and their relation and
interaction among each other.
 Detailed Design- Detailed design deals with the
implementation part of what is seen as a system and its
sub-systems in the previous two designs. It is more
detailed towards modules and their implementations. It
defines logical structure of each module and their
interfaces to communicate with other modules.
 Modularization

 Modularization is a technique to divide a software system into

multiple discrete and independent modules, which are expected to
be capable of carrying out task(s) independently. These modules
may work as basic constructs for the entire software. Designers
tend to design modules such that they can be executed and/or
compiled separately and independently.
 Advantage of modularization:
 Smaller components are easier to maintain
 Program can be divided based on functional aspects
 Desired level of abstraction can be brought in the program
 Components with high cohesion can be re-used again
 Concurrent execution can be made possible
 Desired from security aspect
 Cohesion

 When a software program is modularized, its

tasks are divided into several modules based on
some characteristics. As we know, modules are set
of instructions put together in order to achieve
some tasks. They are though, considered as single
entity but may refer to each other to work
together. There are measures by which the quality
of a design of modules and their interaction among
them can be measured. These measures are called
coupling and cohesion.
 There are seven types of cohesion, namely –
 Co-incidental cohesion - It is unplanned and random
cohesion, which might be the result of breaking the
program into smaller modules for the sake of
modularization. Because it is unplanned, it may serve
confusion to the programmers and is generally not-
accepted.
 Logical cohesion - When logically categorized elements
are put together into a module, it is called logical
cohesion.
 Temporal Cohesion - When elements of module are
organized such that they are processed at a similar point
in time, it is called temporal cohesion.
 Procedural cohesion - When elements of module are
grouped together, which are executed sequentially in
order to perform a task, it is called procedural cohesion.
 Communicational cohesion - When elements of module
are grouped together, which are executed sequentially
and work on same data (information), it is called
communicational cohesion.
 Sequential cohesion - When elements of module are
grouped because the output of one element serves as
input to another and so on, it is called sequential
cohesion.
 Functional cohesion - It is considered to be the highest
degree of cohesion, and it is highly expected. Elements
of module in functional cohesion are grouped because
they all contribute to a single well-defined function. It
can also be reused.
 Design Verification
 The output of software design process is design documentation,
pseudo codes, detailed logic diagrams, process diagrams, and
detailed description of all fu
 The next phase, which is the implementation of software,
depends on all outputs mentioned above.
 It is then becomes necessary to verify the output before
proceeding to the next phase. The early any mistake is detected,
the better it is or it might not be detected until testing of the
product..
 If the outputs of design phase are in formal notation
form, then their associated tools for verification
should be used otherwise a thorough design review
can be used for verification and validation.nctional or
non-functional requirements
 A good design review is important for good software
design, accuracy and quality.
ANY
DOUBT