Requirements Analysis Concepts & Principles

NCST

1

Requirements Analysis and Specification
3 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
3

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.

3

NCST

6

Requirements Analysis Activities
Study System Specification & SW Project plan 3 Problem Recognition 3 Evaluation & Synthesis 3 Modeling 3 Specification 3 Review
3 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 3 Rules for preparation & participation 3 Agenda – formal + informal 3 Facilitator controls meeting 3 Definition mechanism 3 Identify problem, propose solution, negotiate approaches, specify set of solution requirements
3 NCST 9

Requirement Elicitation contd.
Quality Function Deployment - quality management technique

Normal requirements 3 Expected requirements 3 Exciting requirements
3    

Function Deployment : function values Information Deployment : data objects + events Task deployment : system behavior Value Analysis : requirement priorities
10

NCST

Requirement Elicitation contd.
Use Cases(usage scenario)
Approves leave Manages Projects HOD Approves vouchers
<<uses>>

Validates leave

NCST

11

Requirement Elicitation contd.
Scenarios perceived differently by different actors 3 Use QFD : Priority value assigned for each use case 3 System functionality priorities
3

NCST

12

Analysis Principles
Information domain must be represented 3 Functions to perform must be defined 3 Behavior as consequence of external events must be represented 3 Models depicting information, function & behavior must be partitioned to uncover detail in layered fashion 3 Analysis process should move from essential information to implementation detail
3 NCST 13

Analysis Principles
Understand the problem before creating analysis model 3 Develop prototypes 3 Record the origin & the reason for every requirement 3 Use multiple views of requirements 3 Rank requirements 3 Work to eliminate ambiguity
3 NCST 14

Analysis Principles (contd.)
Information Domain
Information contents & relationships (Data Model 3 Information Flow : data + control changes 3 Information structure : internal organization
3

NCST

15

Analysis Principles (contd.)
Functional Models 3 Behavioral Models
3

NCST

16

Modeling
A model is an abstract representation of a view of the system 3 Build different models of the system to-be 3 Benefits of modeling
3

– 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 prototype y prototype Yes Yes Yes/No No Yes Yes Yes Yes Yes/No Yes No No Additional Preliminary Work reqd. No No No Yes Yes yes 19

Appn. domain understood? Can problem be modeled? Customer know basic reqts? Reqts established & stable? Requirements ambiguous? Contradicting requirements? NCST

Software prototyping (contd.)
Methods & Tools 3 4GLs 3 Reusable software components 3 Formal specs and prototyping environments

NCST

20

Analysis Models
Pro ptio n sS ces esc ri

a ific pec

obj ect d

Dat a

Entity Relationship diagram

Data flow diagram Data Dictionary

tion

State-transition Diagram NCST Control Specification 21

Analysis Models
3

Data Flow Diagram Entity Relationship Diagram State Transition Diagram

functional view Stored Data view

3

3

Time-dependent behavior view
22

NCST

Data Flow Diagram (DFD)
A DFD depicts the flow of information within a system and between the system and the outside world. 3 It does not show sequence and control information. 3 A Data Flow Diagram (DFD) contains:
3

– External entities, Processes, Data flows, Data stores
NCST 23

DFD Example
Books Orders Publishers

Customer

Verify Order

Assemble PO

PO

Publisher

Customer

Pending Orders 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 multiple pages. NCST 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 Create Order OCopy1 Cust Folder OrderFile (Copy2,3) OCopy 4,5 Warehouse Select Goods OCopy5

BinCards

OCopy4 Delivery Folder

Inv Copy2 Sales Accounts Signed File Invoice OCopy5 Warehouse OCopy5 Raise Invoice Confirm Delv. InvCopy1 CompletedOrders InvCopy2 Cust Folder Delivery Folder NCST 27

Example: Current Logical DFD
Order credit status Customer Create Order Select Goods ItemStock Delivery Order

Order Accepted Order Confirm Delv. Order NCST

Order

Create Invoice Invoice 28

Invoice

A Complex DFD

NCST

29

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

Context Diagram
Example: Context Diagram The System

• Represents an entire system as a single process

• Shows the scope of the system
• Highlights the interfaces between the system and the outside terminators (external entities)
NCST 31

Context Diagram The System

Leveled DFDs
1 * 2 * Level-1 DFD

3

Level-2 DFD 3.1 * NCST 3.2 * 32

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

DFD Guidelines (contd)
3

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 3 Balance DFDs across levels 3 Data flows and stores must be described to the Data dictionary. 3 Processes must be supported either by a lower level DFD or a mini-specification.
3

NCST

35

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

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 Order Cost>Rs 1 lac y Membership > 5yrs y Actions Priority treatment Normal treatment
X y y n y n y y n n n y y n y n n n y n n n

X

X X

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. 3 Major components: – Entities – Relationships between entities – Cardinality & Modality
3

one-to-one one-to-many many-to-many
NCST

recursive relationship super type -subtype
40

Example: ERD
Member places Order setup_for

Product

NCST

41

The Data Dictionary
3

3

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
42

NCST

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
3

State Transition Diagram Entity Life Histories (used in SSADM)

3

NCST

44

State Transition Diagram (STD)
It highlights the time-dependent behavior of a system. 3 It shows ‘what’ happens ‘when’ 3 Major components
3

– States – Transitions between states
3

Useful for describing behavior of
– real-time systems, interactive systems
45

NCST

Example: State Transition Diagram
RButton-down / display PopUp Menu

Idle
RButton-up / erase PopUp Menu

Menu visible

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. 3 An Event may effect entity occurrences 3 An effect can be to:
3

– Create, Modify, Delete
3

To construct ELH, first construct Entity/Event Matrix
47

NCST

Example: Entity/Event Matrix
Events Entities Member Grade C M M New Grade Approved Credit limit Change New Member Appl. Member det. Changed Membership expired C M D M

NCST

48

Example: Entity Life History
Member Entity

New Member Appl

Member Det. Changed Events

Membership expired

NCST

49

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

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. 3 Entity names on the ERD and data store names on the DFD must match. 3 The data dictionary entries must apply to both the DFD and the ERD data elements.
3

NCST

51

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

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

Function Based Metrics for analysis model
1. 2. 3. 4. 5. 6. 7.

Needs reliable backup/recovery? Needs data communications? Are there distributed processing functions? Is performance critical? System runs in existing heavily utilized operational environment? System requires on line data entry? ON line entry requires I/p transaction over multiple screens/operations?
53

NCST

Function Based Metrics for analysis model
1. 2. 3. 4. 5. 6. 7.

Are master files updated on line? Are I/Ps ,O/Ps , files or enquiries complex? Is the internal processing complex? Is the code designed to be reusable? Are conversion & installation included in the design? Is system designed for multiple installations in diff. Organizations? Is application designed to facilitate change & ease of use by the user?
54

NCST

Function Based Metrics for analysis model
Scale 0 (not important/applicable) – 5 (absolutely essential) 3 Errors/FP 3 Defects/FP 3 $ /FP 3 Pages of documentation/FP 3 FP/person-month
3 NCST 55

Specification Quality Metrics
3 3

3

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
56

NCST

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. NCST of state transitions in STD

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  Relationship connections (REi) NCST 58

Sign up to vote on this title
UsefulNot useful