This template requires needs a format check.

1 [Project Title]

1.1 [Subtitle or short description]

1.2 [Authors]

1.3 [Team or organization that is writing this document]

1.4 Versions log

2 Table of contents

3 Introduction

3.1 Purpose and Background

[short description about the purpose and background of the project and its requirements]

3.2 Scope of this requirements specification

3.2.1 In scope

[what is in the scope]

3.2.2 Out of scope

[Put what is out of scope here. This can be very important for clarifying boundaries. ]

3.3 Stakeholders

End users Developers Sponsor [etc]

4 Product/Service Description

4.1 Product Context

[Anything that does not go into the introduction but seems noteworthy should go here. ]

4.2 Assumptions

[Put a list of the assumptions here. Sometimes this will overlap with non-functional requirements, though these should be moved to the appropriate section when possible.] [etc]

4.3 Constraints

The following is a list of constraints for the specification. [Example: While we are developing for an international release, we will only be supporting English, Spanish, and Japanese as per the language skills of our developers and our contract terms. ] [etc]

4.4 Dependencies

[Example: This project requires a magical hat to be delivered by the sponsor before completion of all of the functional requirements. ]

4.5 User Stories

[Example: As an end user, when I put on the magic hat, I want to be able to see into the future.] [Example2: $stakeHolder DOES fuctionality() RETURN $someValueOrOutput] [etc]

5 Requirements

5.1 Priority Definitions

The following definitions are intended as a guideline to prioritize requirements. Priority 1 – The requirement is a “must have” as outlined by policy/law Priority 2 – The requirement is needed for improved processing, and the fulfillment of the requirement will create immediate benefits Priority 3 – The requirement is a “nice to have” which may include new functionality

5.2 Functional Requirements

[Example: The magic hat must provide battery usage on the user’s laptop.] [Example: The magic hat must let me know when I am not happy anymore.]

5.3 Non-Functional Requirements [Example:

The software for the magic hat must cost less than $1,000.]

6 References

[I recommend using APA since this is not strictly a prose document.]

7 Appendices

[Anything that you want to hold onto that is related to the requirements should go here, unless it is large enough to break off into another document. ] Acknowledgements This template originated from a sample requirements document from OMSE 531 in early 2011 by my professor, Manny Gatlin, under program director Kal Toth. This document resembles little, if any, of the original, though it retains the spirit of consistent and clear documentation.

8 License

© 2012 Alan Shea Anderson-Priddy Provided the License section remains intact, though you may add addendums for documentation purposes, anyone may use this document, modify or redistribute it under the licenses either the GNU-FDL 1.3 (or later) or CC-BY 2.0 (or later), whichever pleases the user.