Requirements  Specifications  ….. Use cases, tests classes, … Requirements must be: --complete --consistent --unambiguous --correct

Another way to organize requirements (text)--FURPS: Functional requirements: *F—functionality Nonfunctional requirements: “Quality”: *U—Usability *R—Reliability (Dependability—reliability, robustness, safety) *P—Performance *S—Supportability “Constraints”: *implementation requirements Operations requirements, packaging requirements, legal requirements * = important this quarter

Steps to turn requirements into specifications: --identify actors --identify scenarios (specific examples of use cases) --identify use cases --refine use cases as appropriate (extends / includes)—don’t overdo this --identify relationships among actors and use cases --can now begin to identify objects needed (  design) --also need to identify nonfunctional requirements

Use case writing guide (p. 137 of text): --each use case should be traceable to requirements --name should be a verb phrase to indicate user goal --actor names should be noun phrases --system boundary needs to be clearly defined --use active voice in describing flow of events, to make clear who does what --make sure the flow of events describes a complete user transaction ---if there is a dependence among steps, this needs to be made clear --describe exceptions separately --DO NOT describe the user interface to the system, only functions --DO NOT make the use case too long—use extends, includes instead --as you develop use cases, develop associated tests

Example—bank simulation (Horstmann) Teller 1 Teller 2 Teller 3 Teller 4 Customer 1Customer 3Customer 2 Horstmann, Mastering Object- Oriented Design in C++, Wiley, 1995

Use Cases--Bank Goal: Develop a tool to simulate the bank to decide on optimal values for number of tellers, number of customer queues, etc. Use cases?