Modification history:

Team Name: <your team name here>

Team Members:

• <person1 and that person's e-mail and web page>
• <person2 and that person's e-mail and web page>
• ...

Contents of this Document

SECTION 1: Introduction

• <one paragraph to identify the software produced(s) to be produced.. Refer the reader to the reference documents for more information>

• Concept of Operations <include link here>
• Project Plan <include link here>
• <any other relevant documents; include full reference information or link>

• <You do not have to repeat the standards included in the project plan. This is where you cite any standards that are specific to the system requirements.>

 Definitions, Acronyms, and Abbreviations:

• <include any that are needed to read this document (or "None" if document is self-explanatory and no acronyms or abbreviations will be used>

SECTION 2: Product Overview

• <List all the assumptions the developers are making. For example: assumptions about other systems this product will interface with; assumptions about the technological environment in which the product will operate (how much memory, what type of processor, ...); assumptions about availability and capability of COTS, GOTS, or other re-used products, ...>
• ...

• <A stakeholder is anyone who has an interest in the software to be developed. For example, the customer, the various classes of users, applicable regulatory agencies, ... List each category of stakeholder and give a phrase or a sentence to describe their interest or concerns>

• <An event table identifies all the external events to which the software must respond. This is a first step in determining the required overall system functionality. The event list should be consistent with the context diagram and the interest of each stakeholder. Make sure that exceptions are considered.>
• <Use the following table format:>

• <Include a use case diagram here. It should be consistent with all the above work For reference, see materials presented in class.Your text also has a little information.>

• <Briefly describe each use case included in the above diagram. Make sure that exceptions are considered. For reference, see materials presented in class. class.Your text also has a little information >

SECTION 3: Specific Requirements

3.1 Functional Requirements:

• < Describe the fundamental actions that the software must perform. Functional requirements can be partitioned into subfunctions or subprocesses. Note: the software design partition does not have to correspond with the functional requirements partition. Functional requirements include:
• validity checks on the inputs,
• exact sequence of operations,
• responses to abnormal situations, including: overflow, communication facilities, and error handling and recovery
• effect of parameters
• relationship of outputs to inputs, including: input/output sequences, formulas for input to output conversion
• ...>

• < Describe the interactions of the software with other entities. Interface requirements include a precise description of the protocol for each interface:
• what data items are input
• what data items are output
• what is the data type, the format, and the possible range of values for each data item? (i.e. what is the "domain" of this data item?)
• how accurate must each data item be?
• how often will each data item be received or sent?
• timing issues (synchronous/asynchronous)>
• how many will be received or sent in a particular time period?
• how accurate must the data be?
• ...>

• < Describe the environment in which the software must run. Physical environment requirements include:
• type of equipment on which the software must run
• location of the equipment
• environmental considerations: temperature, humidity, ...
• ...>

• <Describe the users and their constraints:
• What different types of users must the system support?
• What is the skill level of each type of user? What type of training and documentation must be provided for each user?
• Do any users require special accommodations (large font size, ...)
• Must the system detect and prevent misuse? If so, what types of potential misuse must the system detect and prevent?
• ...>

• <Describe what documentation is required:
• on-line, printed, or both?
• what is the assumed skill level of the audience of each component of documentation?
• ...>

• <Describe any data calculations: what formula will be used? to what degree of precision must the calculations be made? >
• <Describe any retained data requirements: exactly what must be retained?
• ...>

• <Describe the system resources:
• skilled personnel required to build, use, and maintain the system?
• physical space, power, heating, air conditioning, ...?
• schedule?
• funding?
• hardware/software/tools?
• ...>

• <Describe any security requirements:
• must access to the system or information be controlled?
• must one user's data be isolated from others?
• how will user programs be isolated from other programs and from the operating system?
• how often will the system be backed up?
• must the backup copies be stored at a different location?
• should precautions be taken against fire, water damage, theft, ...?
• what are the recovery requirements?
• ...>

• <Describe quality attributes:
• What are the requirements for reliability, availability, maintainability, security, portability ...?
• How must these quality attributes be demonstrated?
• Must the system detect and isolate faults? If so, what types of faults?
• Is there a prescribed mean time between failures?
• Is there a prescribed time the system must be available?
• Is there a maximum time allowed for restarting the system after a failure?
• What are the requirements for resource usage and response times?
• ...>

• <Here is where you put all your analysis work from which you derived the above requirements. It may include UML or other diagrams, notes, memos, etc.)