Team Skill 5: Methods for Specifying Requirements

1. Team Skill 5: Methods for Specifying Requirements

2. When Not to use Natural Language • Using Other Specification Methods • When ambiguity is not tolerable • When erroneous behavior can have extreme legal and financial consequences

3. Different Technical Methods • Pseudo code • Finite State Machines • Decision Trees • Activity Diagrams(Flow Charts • Entity Relationship Models • Object Oriented Analysis • Structured Analysis

4. Pseudo code • Quasi Programming Language • Combines • Informality of natural language • Strict syntax and control structures of a programming language. • Consists of • Imperative sentences with a single verb and a single object • A limited set, typically not more than 40-50 of action oriented verbs from which the sentences must be constructed • Decisions represented with a formal IF-ELSE-ENDIF structure • Iterative activities represented with Do-WHILE or FOR-NEXT structures.

5. Example • The algorithm for calculating deferred-service revenue earned for any month is: • Set SUM(x)=0 • FOR each customer X • IF customer purchased paid support • AND ((Current month) >= (2 months after ship date)) • AND ((Current month) <= (14 months after ship date)) • THEN Sum(X)=Sum(X) + (amount customer paid)/12 • END

6. Finite State Machines • In response to an input, such as data entry from the user or an input from an external device, the machine changes its state and then generates an output or carries out an action • Both the output and the next state can be determined solely on the basis of understanding the current state and the event that caused the transition. • Hardware designers have used FSMs for decades • Problems of consistency, completeness and ambiguity can be reduced • State Transition diagram is a popular notation for FSM

7. Example

8. Decision Trees and Decision Tables • When we have a lot of combinations of inputs • If A is true, then if B and C are also true, generate output X, unless E is true in which case the required output is Y • To write all combinations of inputs in a table and describe them explicitly • For above situation if all inputs can have either true or false then we have 2 ^5 equal to 32 combinations.

9. Example

10. Graphical Decision Tree

11. Activity Diagram • Similar to Flow Chart • Easily understood by non technical people • Provides visual representation, easy to understand • Problem: Difficult to keep up to date

12. Example

13. Entity Relationship Models • When requirements within a set involves a description of the structure and relationships among data within the system. • Provides high level architectural view of the data • Correctly focus on external behaviors of the system • Difficult for non technical reader to understand.

14. Example

15. Object Oriented Modeling • When requirements that must be refined involve description of structure and relationship among entities within the system • Object can have • Attributes • Services • It is becoming famous with popularity of OO and rapid adoption of UML

16. Example

17. Structured Analysis: Data Flow Diagrams • To show structure and organization of atomic requirements and also the input/output relationship between them. • Difficult to understand like ERD • Can be further decomposed into lower level DFDs

18. Example