Requirement Analysis

You might also like

Download as pdf or txt
Download as pdf or txt
You are on page 1of 20

Requirement Analysis

1
Requirement Analysis Phase
Goal
Clearly understand the customer requirement
Systematically organize the requirements into Software
Requirement Specification (SRS) document
SRS is the final outcome of this phase

Main activities
Requirement gathering and analysis
Requirement specification
2
Requirement gathering (elicitation)
• Collect requirements from stakeholders
• Techniques
• Studying existing document – Statement of purpose (SOP)
• Interview
• Task analysis-generate hierarchy of subtask
• Scenario analysis
• Form analysis

3
Requirement Analysis
• Identify and resolve
• Anomaly
• Inconsistency
• Incompleteness

4
Characteristics of good SRS
• Concise
• Implementation-independent
• Traceable
• Modifiable
• Identification of response to undesired events
• Verifiable

5
Bad SRS
• Over specification
• Forwarded reference
• Wishful thinking

6
Categories of requirement [IEEE 830]
• Functional requirement f:I -> O
• Non-functional
• Design and implementation constraints
• External interfaces required
• Other non-functional requirements
• Goal of implementations

7
Decision Tables
• Representation of logic that is part of the processing
• Based on a set of conditions, different actions will be performed
• Can be simplified by removing impossible actions

8
Structure of Decision Table

9
Example of Decision Table

10
Constructing Decision Table
• Name the conditions and the values each condition can assume
• Name all possible actions that can occur
• List all possible rules
• Define the actions for each rule
• Simplify the decision table

11
Simplified Decision Table

12
Decision Trees
• Graphical technique representing decisions using a series of nodes
and branches
• Each node is a decision point - a choice has to be made
• Each branch has a corresponding value to the decision choice
• Subsequent action is the result

13
Example of Decision Tree
Yes
1 Pay base salary

No Yes Pay hourly


2 wage;
Absence report
No
Yes
Legend: 3 Pay hourly wage
1) Salaried?
2) Hours worked < 40? No Pay hourly wage;
3) Hours worked > 40? Pay overtime
wage
14
Mathematical Methods
• Implicit Equations
• Specific equations relevant to software
• Includes other equation details e.g. data type, matrix size,
algorithm
• Regular Expressions
• To specify syntactic structure of string codes
• Example: <id> ::= <yr><course><number>
• <number> ::= <digit><digit><digit><digit>
• <digit> ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

15
Mathematical Methods (Continued)
• Recurrence Relations
• Consist of initial part and one or more recursive parts
• Example: Fibonacci sequence
• F(0) = 1
• F(1) = 1
• F(N) = F(N-1) + F(N-2) N>=2
• Useful for generation of repeated items, e.g. account number

16
Advanced Mathematical Methods
• Axiomatic Definition
• specify basic system properties (axioms) and how the
system generate new properties
• Example:
• REPLACE(stk,itm) = if EMPTY(stk) then error else
(PUSH(POP(stk),itm))
• Formal specifications
• Use of mathematically based techniques
• Sets, Operators, Sequences, Logic Operators

17
Axiomatic: Example

Specify the pre- and post conditions of a function that takes


a real number as argument and returns half
The input value if the input is less than or equal to 100,
or else returns double the value.

f(x : real) : real


Pre : x Ɛ R
Post : {(x ≤ 100) ^ (f(x) = x/2)} v {x>100) ^ (f(x) = 2 *x)}
18
Traceability Methods
• All requirements should be assigned a unique number
• Requirements should explicitly identify related requirements by
referring to their number
• Each requirement should contain a cross-reference matrix showing
related requirements

19
References
• “Fundamentals of Software Engineering” , R Mall, 5th
edition, 2018
• “Software Engineering: A Practitioner’s Approach” 5th
Ed. by Roger S. Pressman, Mc-Graw-Hill, 2001
• “Software Engineering” by Ian Sommerville,
Addison-Wesley, 2001

20

You might also like