Requirements Analysis Concepts

& Principles

NCST 1
 Requirements Analysis and
Specification
✦ Many projects fail:
– because they start implementing the
system:
– without determining whether they are
building what the customer really wants.

NCST 2
 System
Engineering
Software
Requirements
Analysis

Software
Design

NCST 3
 User requests
User requests User requests

Problem Analysis

A relatively good understanding of user’s

requirements

System Description

Software Requirements Specification

NCST 4
 Anonymous infamous customer
“ I know you believe you understood what
you think I said, but I am not sure you
realize that what you heard is not what I
meant”

NCST 5
 SW Requirements Analysis
✦ A study of user needs for a problem to arrive at a
definition of WHAT the software will do without
describing how it will do it.

✦ A Software Requirements Specification (SRS) is

a document containing software requirements
specification for a system.

NCST 6
 Requirements Analysis Activities
✦ Study System Specification & SW Project
plan
✦ Problem Recognition
✦ Evaluation & Synthesis
✦ Modeling
✦ Specification
✦ Review

NCST 7
 Requirement Elicitation
Fact Gathering Techniques
– Interviews
– Questionnaires
– Analyzing documents
– Observation
– ...

NCST 8
 Requirement Elicitation contd.

Facilitated Application Specification Technique

✦ Meeting at neutral site
✦ Rules for preparation & participation
✦ Agenda – formal + informal
✦ Facilitator controls meeting
✦ Definition mechanism
✦ Identify problem, propose solution, negotiate
approaches, specify set of solution requirements

NCST 9
 Requirement Elicitation contd.
Quality Function Deployment - quality management technique
✦ Normal requirements
✦ Expected requirements
✦ Exciting requirements

 Function Deployment : function values

 Information Deployment : data objects + events
 Task deployment : system behavior
 Value Analysis : requirement priorities
NCST 10
 Requirement Elicitation contd.
Use Cases(usage scenario)
<<uses>>
Approves Validates
leave leave

Manages
Projects

HOD
Approves
vouchers

NCST 11
 Requirement Elicitation contd.

✦ Scenarios perceived differently by different

actors
✦ Use QFD : Priority value assigned for each
use case
✦ System functionality priorities

NCST 12
 Analysis Principles
✦ Information domain must be represented
✦ Functions to perform must be defined
✦ Behavior as consequence of external events must
be represented
✦ Models depicting information, function &
behavior must be partitioned to uncover detail in
layered fashion
✦ Analysis process should move from essential
information to implementation detail
NCST 13
 Analysis Principles
✦ Understand the problem before creating analysis
model
✦ Develop prototypes
✦ Record the origin & the reason for every
requirement
✦ Use multiple views of requirements
✦ Rank requirements
✦ Work to eliminate ambiguity

NCST 14
 Analysis Principles (contd.)
Information Domain

✦ Information contents & relationships (Data

Model
✦ Information Flow : data + control changes
✦ Information structure : internal organization

NCST 15
 Analysis Principles (contd.)

✦ Functional Models
✦ Behavioral Models

NCST 16
 Modeling
✦ A model is an abstract representation of a
view of the system
✦ Build different models of the system to-be
✦ Benefits of modeling
– focus on important system features while
downplaying less important features
– discuss changes and corrections to the user’s
requirements with low cost and minimal risk
– verify that Analyst correctly understands the
user’s requirements
NCST 17
 Partitioning

- Horizontal
- Vertical

NCST 18
 Software prototyping
Select prototyping approach :
- close ended (throwaway) - open ended (evolutionary)

Concern Throwaway Evolutionar Additional

prototype y prototype Preliminary
Work reqd.
Appn. domain understood? Yes Yes No
Can problem be modeled? Yes Yes No
Customer know basic reqts? Yes/No Yes/No No
Reqts established & stable? No Yes Yes
Requirements ambiguous? Yes No Yes
Contradicting Yes No yes
requirements?
NCST 19
 Software prototyping (contd.)

Methods & Tools

✦ 4GLs
✦ Reusable software components
✦ Formal specs and prototyping environments

NCST 20
 Analysis Models

Pro
n
ptio

ces
ri

sS
esc

pec
d

Entity Data flow

ect

ific
Relationship diagram
obj

a
tion
diagram
a

Data
Dat

Dictionary

State-transition
Diagram

NCST Control Specification 21

 Analysis Models
✦ Data Flow Diagram functional view

✦ Entity Relationship Stored Data view

Diagram

✦ State Transition Time-dependent

Diagram behavior view

NCST 22
 Data Flow Diagram (DFD)
✦ A DFD depicts the flow of information
within a system and between the system and
the outside world.
✦ It does not show sequence and control
information.
✦ A Data Flow Diagram (DFD) contains:
– External entities, Processes, Data flows,
Data stores

NCST 23
 DFD Example
Books Publishers

Orders PO
Customer Verify Order Assemble PO Publisher

Pending Orders
Customer

Fulfilled Orders Pending Orders

NCST 24
 DFD Primitives
External Entity represents a source or sink for
data. These are usually outside the
scope of the area under study.
Process transforms or manipulates data

Data flow carries data between a terminator

and a process, a process and a store,
or between two processes
Data Store represents a repository of data
Connector symbols are used if the diagram spans
NCST
multiple pages. 25
 Types of DFDs
Current Physical DFD
produced in the early stages of analysis
to describe the existing system.

Current Logical DFD

derived from the above, after removing
physical elements.

NCST 26
 Example: Current Physical DFD
OrderForm Sales OCopy 4,5 Warehouse OCopy5
Create Order Select Goods
OCopy1

OCopy4
Cust Folder BinCards Delivery Folder
OrderFile (Copy2,3) Inv
Sales Copy2Accounts
Signed
OCopy5 Raise Invoice
OCopy5 Warehouse File Invoice

Confirm Delv. InvCopy1

CompletedOrders InvCopy2
Cust Folder
Delivery Folder
NCST 27
 Example: Current Logical DFD
Delivery
Order Order
Create Order Select Goods
credit
status
Customer ItemStock Order
Order

Accepted
Order Invoice
Create Invoice
Confirm Delv.
Order
Invoice
NCST 28
 A Complex DFD

NCST 29
 DFD Hierarchy
✦ DFD can be used at different levels of abstraction.
✦ The highest level DFD is called a Context Diagram
✦ A process may be exploded into a lower level DFD
to show more detail.
✦ In such a case, the net input and output flows must
be balanced across the DFD levels.
✦ The lower level DFD may have data stores that are
local to it, and not shown in the higher level DFD.

NCST 30
 Context Diagram
Example: Context Diagram
• Represents an entire system
The as a single process
System

• Shows the scope of the system

• Highlights the interfaces

between the system and
the outside terminators
(external entities)

NCST 31
 Leveled DFDs
Context Diagram
Level-1 DFD
The 1 * 2 *
System

Level-2 DFD

3.1 * 3.2 *

NCST 32
 DFD Guidelines
✦ Ideally, a DFD at any level, should have no more
than half a dozen processes and related stores.
✦ Choose meaningful names for processes, flows,
stores, and terminators
– use active unambiguous verbs for process
names such as Create, Calculate, Compute,
Produce, etc.
✦ Number the processes

NCST 33
 DFD Guidelines (contd)
✦ Make sure that DFD is internally consistent
– avoid infinite sinks
– avoid spontaneous generation processes
– beware of unlabeled flows and unlabeled
processes
– beware of read-only or write-only stores

NCST 34
 DFD Guidelines(contd)
✦ Avoid overly complex DFDs
✦ Balance DFDs across levels
✦ Data flows and stores must be described to the
Data dictionary.
✦ Processes must be supported either by a lower
level DFD or a mini-specification.

NCST 35
 Lowest Level Processes in a
DFD
✦ A process that cannot be exploded further
has an associated mini specification.
✦ Mini spec can be in:
– Structured English
– Action Diagram
– Decision Table/Decision Tree

NCST 36
 Example: Process Specification in
Structured English
FOR EACH item in the Indent DO
IF Item is on Rate-Contract
prepare PO to Rate-Contract vendor
ELSE IF Item is proprietary
prepare PO to manufacturer
ELSE
prepare regular PO to registered vendor
END FOR

NCST 37
 Example: Decision Table
Conditions
Good payment record y y y y n n n n
Order Cost>Rs 1 lac y y n n y y n n
Membership > 5yrs y n y n y n y n

Actions
Priority treatment X X X X
Normal treatment X X X X

NCST 38
 Types of DFDs
New Logical DFD
contains proposals for new requirements
to be implemented.

Proposed DFDs
a set of DFDs with different man-machine
boundaries.

New Physical DFD

the one chosen from among the above; this
is the basis for design.
NCST 39
 Data Modeling
Entity Relationship Diagram (ERD)
✦ It gives a logical view of the data and the
relationships between them in a system.
✦ Major components:

– Entities
– Relationships between entities
– Cardinality & Modality
one-to-one recursive relationship
one-to-many super type -subtype
many-to-many
NCST 40
 Example: ERD
places
Member Order

setup_for

Product

NCST 41
 The Data Dictionary
✦ The data dictionary is an organized listing of all
data elements pertinent to the system with precise
rigorous definitions so that both user and SA will
have common understanding of all data elements.
✦ It describes:
– meaning and composition of data flows,
data stores
– relevant values and units of elementary data
elements
– details of relationships between stores that are
highlighted in a ERD
NCST 42
 Data Dictionary Notation
Example:
customer-name = title + first-name +
(middle-name) + last-name
title = [Mr. | Miss | Ms. | Mrs.| Dr. | Prof. ]
first-name = {legal-character}
order = customer-name + shipping-addr
+ {item}

NCST 43
 Modeling Time-Dependent
System Behavior

✦ State Transition Diagram

✦ Entity Life Histories (used in SSADM)

NCST 44
 State Transition Diagram (STD)
✦ It highlights the time-dependent behavior of
a system.
✦ It shows ‘what’ happens ‘when’
✦ Major components
– States
– Transitions between states
✦ Useful for describing behavior of
– real-time systems, interactive systems

NCST 45
 Example: State Transition Diagram

RButton-down
/ display PopUp Menu
Idle Menu visible
RButton-up
/ erase PopUp Menu

Cursor-moved
/ highlight Menu item

NCST 46
 Entity Life History (ELH)
✦ An ELH represents all the permitted
sequences of events that may occur during
the life of an occurrence of an entity.
✦ An Event may effect entity occurrences
✦ An effect can be to:
– Create, Modify, Delete
✦ To construct ELH, first construct
Entity/Event Matrix

NCST 47
 Example: Entity/Event Matrix
Entities Member Grade
Events

New Grade Approved C

Credit limit Change M
New Member Appl. C M

Member det. Changed M

Membership expired D M

NCST 48
 Example: Entity Life History
Entity
Member

New Member Appl Member Det. Changed Membership

expired

Events

NCST 49
 Cross Checking the different Models
✦ Balancing ERD against the DFD, Process specs.
✦ Balancing DFD against the STD
✦ Balancing ERD against Data dictionary
✦ Balancing DFD against Data dictionary

NCST 50
 Balancing ERD and DFD, Process Specs.
✦ Every store on the DFD must correspond to
an entity or a relationship or a combination
of an entity and relationship on the ERD.
✦ Entity names on the ERD and data store
names on the DFD must match.
✦ The data dictionary entries must apply to
both the DFD and the ERD data elements.

NCST 51
 Function Based Metrics for analysis model
Measurement Count Simple Average Complex
Parameter WF WF WF
No. of user inputs 3 3 4 6 9
No. of user outputs 2 4 5 7 8
No. of user inquiries 2 3 4 6 6
No. of files 1 7 10 15 7
No. of external I/fs 4 5 7 10 20
Total count 50

FP = 50 * [0.65 + 0.01* (Fi)]

NCST 52
 Function Based Metrics for analysis model
1. Needs reliable backup/recovery?
2. Needs data communications?
3. Are there distributed processing functions?
4. Is performance critical?
5. System runs in existing heavily utilized
operational environment?
6. System requires on line data entry?
7. ON line entry requires I/p transaction over
multiple screens/operations?
NCST 53
 Function Based Metrics for analysis model
1. Are master files updated on line?
2. Are I/Ps ,O/Ps , files or enquiries complex?
3. Is the internal processing complex?
4. Is the code designed to be reusable?
5. Are conversion & installation included in the
design?
6. Is system designed for multiple installations in
diff. Organizations?
7. Is application designed to facilitate change &
ease of use by the user?
NCST 54
 Function Based Metrics for analysis model

✦ Scale 0 (not important/applicable) – 5

(absolutely essential)
✦ Errors/FP
✦ Defects/FP
✦ $ /FP
✦ Pages of documentation/FP
✦ FP/person-month

NCST 55
 Specification Quality Metrics
✦ Nr = Nf + Nnf
✦ Q1 = Nui / Nr
– Nui = no. of requirements for which all reviewers
had identical representations
– Closer to 1 lower the ambiguity
✦ Q2 = Nu / [Ni * Ns] (% of Necessary functions spec)
– Nu = no. of unique functions requirements.
– Ni = no. of I/Ps - Ns = no. of states
Q3 = Nc / [Nc + Nnv] (degree of validation)
- Nui = no. of requirements Validated
- Nnv = no. of requirements not yet been Validated

NCST 56
 The Bang Metric for analysis model
 Functional Primitives (FuP)
No. of transformations on lowest level DFD
 Data Elements (DE)
No. of attributes of a data object
 Objects (OB)
No. of data objects
 Relationships (RE)
No. of connections between data objects
 States (ST)
No. of user observable states in STD
 Transitions (TR)
No. of state transitions in STD
NCST 57
 The Bang Metric for analysis model
 Modified Manual function Primitives (FuPM)
Functions outside sys boundary but need to be
modified
 Input data elements (DEI)
Data elements I/p to the sys
 Output data elements (DEO)
Data elements o/p to the sys
 Retained data elements (DER)
Data elements retained by the sys
 Data Tokens (Tci)
Data tokens at the boundary of ith functional primitive

NCSTRelationship connections (REi) 58