Page 1 Requirements Specification Document Outline 1. Introduction The document begins with an introductory description of the desired system. Except as noted below, the system is described in present tense, third person, active voice. The purpose of using present tense is to render this document historically rele- vant throughout the lifetime of the system. That is, the requirements specification is a permanent part of the system doc- umentation record, before the system is implemented, during implementation, and afterward. In subsections 1.4 and 1.5 only, the system is referred to in future tense in order to distinguish between the state of operations before and after system installa- tion. 1.1. Problem Statement The problem statement is a succinct presentation of the specific problem(s) to be solved and the needs to be met by the system. 1.2. System Personnel The description of system personnel defines all of the people involved with the system and its development. Personnel cate- gories include some or all of the following: a. system end users b. paying customers c. project managers d. domain experts e. system analysts f. system developers Membership among these groups may overlap. 1.3. Operational Setting The operational setting is the environment in which the system is to be used. The discussion includes how operations are conducted in the environment before and after the system is installed. The following questions are addressed in the discussion of the opera- tional setting: a. What computer-based support is in use prior to installa- tion of the new system? b. Does the new system need to interface with existing sys- tem(s) or are the existing system(s) to be replaced entirely? 1.4. Impact Analysis The impact analysis assesses the impacts of the system within its operational setting. Both positive impacts (e.g., increased Page 2 productivity, higher product sales) as well as negative impacts (e.g., job displacement, potential negative legal impacts) are addressed. 1.5. Related Systems Related systems are those computer systems in use elsewhere that provide functionality similar or related to the functionality of the system being specified here. Both commercially available and public domain systems are considered and the following issues are addressed: a. What is good about related systems? b. What is bad? c. What is missing? If appropriate, related systems can be overviewed in a feature comparison matrix. 1.6. Feasibility Analysis The feasibility analysis addresses issues related to the user community and, if appropriate, the commercial market for which the system is targeted. Some or all of the following techniques can be used in the feasibility analysis: a. user/customer surveys b. customer demographic analysis c. cost/benefit/risk analysis d. prototype usage studies, where potential customers use a system prototype to test reactions 2. Functional Requirements Functional requirements define the specific functions that the software system performs, along with the data operated on by the functions. The functional requirements are presented in scenar- ios that depict an operational system from the perspective of its end users. Included are one or more examples of all system fea- tures and an enumeration of all the specific requirements associ- ated with these features. 2.1. User Interface Overview The user interface overview presents the initial user screen with a brief description of the top-level functionality. For example, if the system uses a command menu as the top-level interface, each of the menus is exposed and each menu item is briefly described. 2.2. System-Specific Requirements Specific functional requirements for the system are presented in user-oriented scenarios. Scenarios are organized into subsec- tions to an appropriate depth (e.g., 2.2.1, 2.2.3.4.5). Page 3 . . . 2.n. System-Specific Requirements Ibid. 3. Non-Functional Requirements Non-functional requirements address aspects of the system other than the specific functions it performs. These aspects include system performance, costs, and such general system characteris- tics as reliability, security, and portability. The non-func- tional requirements also address aspects of the system develop- ment process and operational personnel. 3.1. System-Related Non-Functional Requirements Non-functional system requirements include some or all of the following: a. performance i. time ii. space b. operational environment i. hardware platform ii. software platform iii. external software interoperability c. standards conformance d. general characteristics i. reliability ii. robustness iii. accuracy of data iv. correctness v. security vi. privacy vii. safety viii. portability ix. modifiability and extensibility x. simplicity versus power 3.2. Process-Related Non-Functional Requirements Non-functional process requirements include some or all of the following: a. development time b. development cost c. software life cycle constraints d. system delivery i. extent of deliverables ii. deliverable formats e. installation i. developer access to installed environment ii. phase-in procedures to replace existing system Page 4 f. standards conformance g. reporting h. marketing i. pricing ii. target customer base i. contractual requirements and other legal issues 3.3. Personnel-Related Non-Functional Requirements Non-functional personnel requirements include some or all of the following: a. for developers: i. credentials ii. applicable licensing, certification b. for users: i. skill levels ii. special accessibility needs iii. training 4. Developer Overview The developer overview is an executive summary oriented towards the system design and implementation team. Included are high- level descriptions of the major objects and operations specified in Section 5 below, specifically: a. an executive summary of each major object and operation defined in the formal specification; b. appropriate diagrammatic views of the system, such as dataflow diagrams, object hierarchy diagrams, entity-rela- tionship diagrams, object class diagrams. 5. Formal Specifications The formal specification defines all objects and operations of the system, including formal specification of all quantifiable requirements. 6. Requirements and Specification Rationale The rationale discusses important development decisions that were made and why. The discussion addresses development alternatives that we considered and why they were rejected. Appendix A: Preliminary Users Manual The preliminary users manual is a terse version of the require- ments scenarios. The manual describes all user-level commands and data, with little or none of the explanatory text and exam- ples that appear in the scenarios. Page 5 Appendix B: ... ... Appendix Z: ... Additional appendices are provided as necessary. For example, an extended feature comparison table can appear as an Appendix.