Presentation is loading. Please wait.

Presentation is loading. Please wait.

Capturing the requirements

Similar presentations

Presentation on theme: "Capturing the requirements"— Presentation transcript:

1 Capturing the requirements
Eliciting requirements from our customers Types of requirements Notations and methods for capturing requirements Reviewing requirements to ensure their quality Documenting the requirements for use by the design and test teams Chapter 4

2 Requirements Requirement: a feature of the system or a description of something the system is capable of doing in order to fulfill the system’s purpose Three kinds of requirements: those that absolutely must be met those that are highly desirable but not necessary those that are possible but could be eliminated Chapter 4

3 Process of determining requirements
Chapter 4

4 Requirements documents
Requirements definition: complete listing of what the customer expects the system to do Requirements specification: restates the definition in technical terms so that the designer can start on the design Configuration management: supports direct correspondence between the two documents Chapter 4

5 Configuration management
Set of procedures that track requirements that define what the system should do design modules that are generated from requirements program code that implements the design tests that verify the functionality of the system documents that describe the system Chapter 4

6 Activities of the software development process
Chapter 4

7 Functional vs. non-functional requirements
Functional: describes an interaction between the system and its environment Examples: System shall communicate with external system X. What conditions must be met for a message to be sent Non-functional: describes a restriction or constraint that limits our choices for constructing a solution Examples: Paychecks distributed no more than 4 hours after initial data are read. System limits access to senior managers. Chapter 4

8 Types of requirements Physical environment Interfaces
Users and human factors Functionality Documentation Data Resources Security Quality assurance Chapter 4

9 Source of possible requirements
Chapter 4

10 Characteristics of requirements
Are they correct? Are they consistent? Are they complete? Are they realistic? Does each describe something the customer needs? Are they verifiable? Are they traceable? Chapter 4

11 Static descriptions of requirements
Indirect reference Example: k equations in n unknowns Recurrence relations Example: F(0)=1; F(1)=1; F(n+1)=F(n)+F(n-1) Axiomatic definition Expression as a language Example: Backus-Naur form Chapter 4

12 Chapter 4

13 Data abstraction Chapter 4

14 An abstract class and object relationship
Chapter 4

15 Dynamic descriptions Decision tables Chapter 4

16 Dynamic descriptions (2)
Functional descriptions and transition diagrams f(Si, Cj) = Sk Chapter 4

17 Transitioning among states
Chapter 4

18 Fence diagram showing state transitions
Chapter 4

19 UML notation for state transitions
Chapter 4

20 Transition diagram for hotel reservations
Chapter 4

21 Jakson’s finite state machine example
Chapter 4

22 Dynamic descriptions (3)
Event tables Chapter 4

23 Parallel processing Sequential (single-threaded):
f(State A, Event)  State S Parallel: f(State A, Event 1, Event 2,…,Event N)  State S f(State A, Event 1, Event 2,…,Event N)  State 1, State 2,…,State M Chapter 4

24 Petri nets: Three types of transitions
Chapter 4

25 Petri nets: Tokens associated with firing rules
Chapter 4

26 Object-oriented specifications
Each entity in the system is an object. A method or operation is an action that can be performed directly by the object or can happen to the object. Encapsulation: the methods form a protective boundary around an object. Class hierarchies of objects encourage inheritance. Polymorphism: same method for different objects, each with different behavior Chapter 4

27 Multiple inheritance Chapter 4

28 Additional notations Hierarchical techniques Data flow diagrams
Warnier diagrams Data flow diagrams Software Requirements Engineering Methodology (SREM) Structured Analysis and Design Technique (SADT) Z Chapter 4

29 Prototyping requirements
Throw-away prototypes Evolutionary prototypes Rapid prototypes Chapter 4

30 Interface prototypes Chapter 4

31 Requirements documentation
Requirements definition document: what the customer wants general purpose background and objectives of system description of customer-suggested approach detailed characteristics operational environment Requirements specification document: what the designers need to know Chapter 4

32 Example Chapter 4

33 Participants in requirements process
Contract monitors Customers and users Business managers Designers Testers Requirements analysts Chapter 4

34 Chapter 4

35 Chapter 4

36 Requirements review Review goals and objections of system.
Compare requirements with goals and objectives. Describe operational environment. Examine interfaces information flow functions Check for omissions, incompleteness, inconsistency. Document risk. Discuss how system will be tested. Chapter 4

37 Measuring requirements readiness
Chapter 4

38 Choosing a specification technique
Applicability Implementability Testability/simulation Checkability Maintainability Modularity Level of abstraction/expressibility Soundness Verifiability Run-time safety Tools maturity Looseness Learning curve Technique maturity Data modeling Discipline Chapter 4

39 Warnier diagram Chapter 4

40 Data flow diagram for physician visit
Chapter 4

41 Requirements network Chapter 4

42 RSL encoding of R-net Chapter 4

43 SREM steps Chapter 4

44 SADT overview of tax calculation
Chapter 4

45 Z example Chapter 4

Download ppt "Capturing the requirements"

Similar presentations

Ads by Google