Requirements Specifications Use cases tests classes Requirements must

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

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, lecal requirements * = important this quarter 2

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 3

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 4