Requirements Specification for Lab3 COP4331 and EEL4884 OO Processes for Software Development © Dr. David A. Workman School of Computer Science University of Central Florida March 19, 2010

Lab3 Statement of Work The purpose of Lab3 is to redo Lab1 to correct or “fix” the problems you experienced in your first attempt to write a requirements document. Lab3 differs in the format of the document to be produced, although the Lab3 format is very similar to that of Lab1. In fact, some sections of your Lab1 document can be reused (with corrections and/or enhancements). The Lab3 business case should be given more attention – conduct surveys to justify features and price range for your product. Those surveys should be documented in the Appendices. The team should conduct a careful review of the document before submitting it. I would also invite each team to seek out one other team to review your document. As was the case with Lab1, consider me a resource. I will give you as much help as you need – provided it is within my capabilities to do so. Finally, each team member should read the Feedback document I produced for Lab1 – this should answer many questions you might have. March 19, 2010(c) Dr. David A. Workman2

February 18, 2010(c) Dr. David A. Workman3 Use Case Model Outline Title : (System Name, Team # and members, Assignment, Course, Pub. Date) –TOC –List of Figures and Tables 1.System Summary –Overview of System Purpose and Context –Business Case ( business need and how this system will address this need ) –System Operation Use Case Diagram (static view of system, use cases, and actors) Activity Diagram showing flow of use cases at the system level. Supporting narrative (explains diagrams: operational flow, actor roles ) –System Interfaces ( External Interfaces with Actors ) 2.Use Case Specifications (one subsection for each use case) 1.Purpose ( function from user’s perspective ) Communication diagram (flow of interactions between actors and system boundary objects ) Narrative summary of use case purpose or function 2.Precondition (system states (data available) & triggering events ) 3.Flow of Events (nominal flow of interaction events between actor and interface objects) 4.Alternative Paths (error processing flows; special case flows ) 5.Post Condition (system states (data produced) & completion events ) 6.Special Requirements (non-functional : performance and quality )

February 18, 2010(c) Dr. David A. Workman4 Use Case Model Outline 3. Glossary Define product-related terms needed to understand requirements and the system in general. 4. Requirements Statements The specification of a requirement or group of related requirements (that is the "requirements statement(s)") should be followed by a rationale that justifies the requirement(s) with respect to the prototype – these could be statements justifying why (or why not) a prototype feature is included in the spec. Rationale statements should draw on justification from the business case. 2.1 Functional Requirements 2.2 Performance Requirements 2.3 Safety Requirements 2.4 Other Requirements (e.g. design constraints, industry standards, other quality requirements) 5.Appendices Include competitor survey data. Include target customer surveys and data.

February 18, 2010(c) Dr. David A. Workman5 Use Case Model: Detail Title Page and Format Document type, System Title, Author, Publication Date, Course, Assignment Table of Contents (TOC) Table of Figures (TOF) Table of Tables (TOT) 1.System Summary 1.Scope and purpose of document ( Document content, Intended audience ) 2.Business case: motivation for building the system; how it meets needs of users and organization. Discuss surveys taken and summarize results to justify features and cost. 3.Concept of Operation Use Case Diagram (Static view of System with use cases and actors) Activity Diagram showing the flow of Use Cases. Narrative explaining the flow of use cases and their relationships. Identifies all actors and introduces their roles with respect to the use case(s) they engage in. Should also identify all major problem data elements consumed, manipulated, or produced by use cases of the system. 4.System Interfaces For each interface: identify the actors and use cases that exercise that interface, the problem data content, flow direction, medium and/or mechanism. For each interface: supporting diagrams illustrating actor interface

February 18, 2010(c) Dr. David A. Workman6 Use Case Model: Detail 2.Use Case Specifications This section should include a subsection (2.xx) for each use case identified in section 1.3. Each use case should have the following format and organization. An introductory section should be included giving a diagram and narrative describing system states and their transitions. 1.Purpose: Specify the purpose of the use case – what it accomplishes from the view of the actors involved and the service the system provides these actors. Support with a communication diagram. 2.Preconditions: Specify the system states that must hold before the use case is defined or can begin, AND the triggering event(s) that mark the beginning of the use case. 3.Interaction Scenario: In conjunction with collaboration and state diagrams, present the primary or normal flow of interaction events that accomplish the purpose of the use case. The communication diagram identifies the boundary objects involved in the scenario. 4.Alternative Scenarios: In conjunction with communication diagram, present possible alternative flows of interaction events. This subsection can be used to describe error handling scenarios and/or alternative sub-use cases as appropriate. 5.Post conditions: Specify the system states that result after the use case has completed, AND the event(s) that mark the end of the use case. 6.Other Requirements: resource constraints, other qualify factors (e.g. reliability and safety).

March 19, 2010(c) Dr. David A. Workman7 Requirements Specification Template 4. Requirements Statements In this section you identify the sources of requirements and enumerate all requirements statements. A source must be associated with each requirement. This is best presented in the form of a table. 1.List all sources of requirements statements. A source can be a document, an interview with some individual (customer or user or expert), or a web site, etc. Each source should be uniquely identified (by number or acronym ). Sources should include competitor and potential customer surveys. Include a copy of surveys and raw data in an appendix. Ref[1] Customer Requirements for Jiffy Stop Simulation System Ref[2] Personal interview with Dr. David Workman, CEO of COP A Table should be constructed, such as the one shown below, where a statement of the requirement is given (“shall” statement) and a reference to the source containing or implying the requirement statement. Each requirement statement should be uniquely identified; for example, "F1" for Functional requirement #1. Statements of Functional RequirementsRequirements Source F1: “The system shall simulate a convenience store customer engaged in the activity of purchasing gasoline from the time the customer leaves the automobile to the time the customer returns to the automobile upon completing the scenario.” Ref[1] pp12, line 4. F2: “The pay-by-credit scenario shall support credit cards only – no debit cards.” Ref[2].