Documentation Standards

SRS Outline

• The Software Requirements Specification (SRS) sections given in this outline are guidelines to the contents of your SRS.
• Include at least these sections, using exactly the section numbering given below.
• Your team may have good reasons for wanting to deviate from this proposed outline. In this case, you must motivate any deviations to the instructor before writing your document.
• If a section is not applicable in your case, do not delete it; instead, include the topic heading and write "Not applicable."

1. Introduction

Purpose of this section: General background and reference information

1.1 Purpose of this Document

Full description of the main objectives of this SRS document in the context of this project

(e.g., "This SRS describes the function and performance requirements allocated to the XYX system. The XYX is a stand-alone component of a navigation system ...")

1.2 Scope of the Development Project

Identifies the product to be developed by name and function, lists limitations (if any), highlights distinct features, lists benefits as clearly and precisely as possible. This will provide the basis for the brief description of your product.

1.3 Definitions, Acronyms, and Abbreviations

Include any specialized terminology dictated by the application area or the product area. This will help the reader understand the rest of the text. Be sure to alphabetize the terms! If this section becomes longer than one page, move the definitions, etc. to an appendix and provide a pointer from this section.

1.4 References

Mention books, articles, web sites, worksheets, people who are sources of information about the application domain, etc. Use proper and complete reference notation. Give links to documents as appropriate. If this section becomes longer than one page, move the references to an Appendix and provide a pointer in this section. Alphabetize by last name of author. For examples, see documents from previous years of CS4500.

1.5 Overview of Document

A short yet informative description of how the rest of the SRS is organized and what can be found in the rest of the document. This is not simply a table of contents!! Briefly describe and motivate the various parts!

---

2. General Description

Purpose of this section: an "executive overview" but very client-oriented

2.1 User Personas and Characteristics

A persona is the profile of a fictional user that represents the intended audience(s) for this product. A persona should share characteristics with real people, but should not directly describe any real person. Taken together, the personas you define should represent as wide a variety of characteristics as possible. For this concept to be effective, your team will use these personas throughout the design and V&V process to provide a point of reference.

Your team will define a minimum of two personas in the SRS. The detailed descriptions will appear in appendices. This section of the SRS summarizes your team's personas and their characteristics. For example, a product for sixth graders could present personas for

• User A, an 11-year-old power-user
• Teacher, who is relatively competent in the use of computers.

Create the detailed description for each of the personas. Uniquely identify each persona, either with a descriptive label or with a name. If you wish, invent a picture of each persona. For each persona, describe their relevant personal characteristics and their general goals with respect to this product. Be sure that the characteristics that distinguish personas from one another are clear. If the personas are particularly long (e.g., a page or more each), then the detailed descriptions can be moved into an appendix.

For more information on the idea of personas, see the book The Inmates are Running the Asylumby Alan Cooper.

2.2 Product Perspective

• If the product is stand-alone, give the relationship to other products.
• If the product is part of a larger product, then identify its interface to the other products.
• Identify the product's external interfaces with its environment.
• If the product uses existing hardware, describe the hardware.
• If the product requires new hardware, give a detailed explanation of the hardware.

2.3 Overview of Functional Requirements

A short description of the functions to be performed by the software, i.e., what the product should do. This description must be in a form understandable to users, operators, and clients. The detailed requirements specifications are left to Section 3.2 in this SRS. Number the Functional Requirements in a systematic manner to make it easier for you to refer to them in Section 3.2 of the SRS, in the SDS, and in the V&V documents. This section should not be design-oriented, a common mistake.

2.4 Overview of Data Requirements

Describe data that are input or output from the product as well as any data that are stored within the system for example in files or on disk. This section should only cover data requirements from the user's point of view. Once again, this should not be design-oriented.

2.5 General Constraints, Assumptions, Dependencies, Guidelines

This section describes non-functional requirements, those factors that impose constraints on the implementation of the software product. This can include hardware limitations or requirements, the amount of memory available, response times, policies, interfaces to other application software, networks, environmental limitations, compliance with relevant standards. This section can also provide guidance in situations when there may be more than one implementation strategy.

Examples:

"The product will only work with certain operating systems
"The product will only work within a particular network environment."
"The product must be Web-based."
"The product cannot require persistent data."

2.6 User View of Product Use

This section will provide a user's-eye-view of the product. Use the personas you defined in section 2.1 to make the descriptions concrete. Describe the setting, sketch the possible appearance of the screen(s), give samples of the data that is stored, entered, or output, and invent dramatic scenarios that demonstrate the product in operation. If this section becomes longer than about two pages, break some parts into Appendices and provide pointers from within the text of this section.

---

3. Specific Requirements

Purpose of this section: Technical information needed to design the software

3.1 External Interface Requirements

• operator/user interface characteristics from the human factors point of view
• characteristics required of the interface between the software product and each of the hardware components
• interfaces with other software components or products, including other systems, utility software, databases, and operating systems

3.2 Detailed Description of Functional Requirements

This section must be customized to reflect the particular needs of your project. The first section should always be a presentation of the template that your team will use in defining the functional requirements. The exact categories that you use in your template will depend on the approach you are taking to your design.

3.2.1 Template for describing functional requirements

This is a typical template you can use to describe each of the functional components that were identified in Section 2.3. These sections should be at least the following:

purpose	a description of the functional requirement and its reason(s)
inputs	which inputs; in what form/format will inputs arrive; from what sources input will be derived, legal domains of each input element
processing	describes the outcome rather than the implementation; include any validity checks on the data, exact timing of each operation (if needed), how to handle unexpected or abnormal situations
outputs	the form, shape, destination, and volume of the output; output timing; range of parameters in the output; unit measure of the output; process by which the output is stored or destroyed; process for handling error messages produced as output

3.2.2 through 3.2.x

The description of each functional requirement, using the template your team defines in section 3.2.1

3.3 Performance Requirements

Issues such as number of connections to the system, number of simultaneous users, response time, number of files, size of files and tables, number of files, size of files and tables, number of transactions per interval (all defined in terms of acceptable ranges)

3.4 Quality Attributes

Issues such as security, availability, reliability, maintainability; to these extent possible, these should be specified in a quantifiable way so they can be accurately measured in the end product.

3.5 Other requirements

If there are no other requirements, then write "None at this time" rather than leaving this section blank.

Primary references used in preparing this outline:

• Software Engineering Fundamentals by Ali Behforooz and Frederick J. Hudson (Oxford University Press, 1996).
• Software Engineering, A Programming Approach by Doug Bell, Ian Morrey, and John Pugh (2nd Edition, Prentice Hall, 1992).
• Personas, Geoff Glaze, October 18, 1999; based on the book The Inmates are Running the Asylum, Alan Cooper,