Requirements Specification for Lab1 COP4331 and EEL4884 OO Processes for Software Development Dr. David A. Workman School of Computer Science University

Embed Size (px)

DESCRIPTION

February 10, 2009(c) Dr. David A. Workman3 Requirements Specification Template Title (System Name, Team # and members, Assignment, Course, Pub. Date) –TOC –List of Figures 1.System Summary –Overview of System Purpose and Context –Business Case ( business need and how this system will address this need ) (stakeholders)(target market) –System Operation (story of how the system is used/works ) –System External Interfaces and Features 2.Statement of Requirements 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. 2.1 Functional Requirements 2.2 Performance Requirements 2.3 Safety Requirements 2.4 Other Requirements (e.g. industry standards, other quality requirements) 3.Glossary Define product-related terms needed to understand requirments and the system in general.

Citation preview

Requirements Specification for Lab1 COP4331 and EEL4884 OO Processes for Software Development Dr. David A. Workman School of Computer Science University of Central Florida January 26, 2010 February 10, 2009(c) Dr. David A. Workman2 Requirements Capture Input Client approaches Developer with a problem and or product concept. This may be expressed verbally or in the form of a document (Statement of Work (SOW)) (Request for Proposal (RFP)) Activities Developer interacts with Client and Users to elicit product requirements. This involves face-to- face meetings and possibly the exchange of technical documents. The Developer must determine as completely and precisely as possible the following information: Stakeholders (who has a vested interest in this product what are their concerns?) cost and time constraints target system platform and operational environment user groups functional capabilities non-functional constraints: quality and performance Client and User's needs (as opposed to "wants") Outputs A complete understanding of the problem the Client and Users need to have solved. Client should be in agreement with the Developers assessment of the problem. This shared view of the system is captured in the form of a UML Use Case Model. February 10, 2009(c) Dr. David A. Workman3 Requirements Specification Template Title (System Name, Team # and members, Assignment, Course, Pub. Date) TOC List of Figures 1.System Summary Overview of System Purpose and Context Business Case ( business need and how this system will address this need ) (stakeholders)(target market) System Operation (story of how the system is used/works ) System External Interfaces and Features 2.Statement of Requirements 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. 2.1 Functional Requirements 2.2 Performance Requirements 2.3 Safety Requirements 2.4 Other Requirements (e.g. industry standards, other quality requirements) 3.Glossary Define product-related terms needed to understand requirments and the system in general. February 10, 2009(c) Dr. David A. Workman4 Requirements Specification Template 2. 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 ). 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]. February 10, 2009(c) Dr. David A. Workman5 View1 Carafe Control Panel Power cord Carafe Cavity Hot Plate February 10, 2009(c) Dr. David A. Workman6 View2 LED Display Power Control Auto Brew Control Time Control Programmed Time Control February 10, 2009(c) Dr. David A. Workman7 View3 Water Level Indicator Water Level Display February 10, 2009(c) Dr. David A. Workman8 View4 Top Lid Steam Vent Safety warning February 10, 2009(c) Dr. David A. Workman9 View5 Raise Lid Coffee Basket Cavity Water Tank Coffee Grounds Basket Handles Drip Control Switch February 10, 2009(c) Dr. David A. Workman10 View7 Basket Alignment Notch & Steam Vent Port