Requirements Specification Outline

Note this outline is based on the outline in Software Engineering, 4th Edition, by Pfleeger and Atlee, ISBN 9780136096726, weblink.

Requirements Specification for [Project/Product Name]

1. Introduction

1.1 Purpose of Product

A one-paragraph description of your product’s purpose.

1.2 Scope of Product

A short description of your product’s scope (what it includes and what it does not include). Part of your problem statement might be useful here, but focus on the scope of the product.

1.3 Acronyms, Abbreviations, Definitions

Any important terms that are required to understand your project documents.

1.4 References

Any external references needed to understand your project documents. Use URL links if possible.

2. General Description of Product

This section contains a longer but not exhaustive description of your product. Perhaps a page long.

2.1 Context of Product

Context or environment that your product will be in.

2.2 Domain Model with Description

Display and describe your domain model. A domain model is a UML class diagram where the classes are the problem domain entities (concepts, objects) that are important to your problem. A domain model is not a design diagram of your system! Connecting associations are extremely important, along with cardinalities and naming where needed. Class attributes are important, but class operations are typically not in a domain model.

2.3 Product Functions (general)

Basic overview of the capabilities of your product. This is not your list of functional requirements, but an overview. Part of your problem statement might be good here.

2.4 User Characteristics and Expectations

Describe your users and their abilities.

2.5 Constraints

Describe any constraints on your system.

2.6 Assumptions and Dependencies

Does your system depend on external software packages? System assumptions? If so, describe them.

3. Functional Requirements

In a standard requirements document, this would be a LONG list of functional requirements. Probably half to two-thirds of the whole document would be this section. In my courses I have you develop user stories for your functional requirements, and so you should put a link to your user story page here. When functional requirements are listed here, they should each have a unique identifier, such as F.3.2.4 (which would be the 4th sub-requirement under the 2nd top requirement in this section (section 3)). The F indicates “functional”.

4. System and Non-functional Requirements

4.1 External Interface Requirements (User,Hardware,Software,Communications)

Describe what kinds of interfaces your product has, and what they do. Then list specific requirements using item numbers as NF.4.1.X.

4.2 Performance Requirements

Describe your product’s performance needs. Then list specific requirements using item numbers as NF.4.2.X.

4.3 Design Constraints

Describe external requirements that will constrain your design choices. Then list specific requirements using item numbers as NF.4.3.X.

4.4 Quality Requirements

What quality expectations do your users have? Is your system life-critical? Describe such issues, then list specific requirements using item numbers as NF.4.4.X.

4.5 Other Requirements

Anything else you need to say. Use item numbers NF.4.5.X.

5. Appendices

Include external documents that describe domain or constraints or any necessary information. Use URL links if possible.