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