#+SETUPFILE: ../../../template/level-2.org
#+TITLE: Requirements Template
#+DATE: <2014-08-13 Wed 00:00>
#+AUTHOR: vaeringjar
#+EMAIL: vaeringjar@land
#+DESCRIPTION: Version of the requirements template.
#+KEYWORDS: template

This template requires needs a format check.

* [Project Title]
** [Subtitle or short description]
** [Authors]
** [Team or organization that is writing this document]
** Versions log
| DATE | V# | VERSION NOTES | [yyyy-mm-dd] |
|------+----+---------------+--------------|
|      |    |               |              |
|      |    |               |              |
|      |    |               |              |
|      |    |               |              |

* Table of contents

* Introduction

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

** Scope of this requirements specification
*** In scope
[what is in the scope]
*** Out of scope
[Put what is out of scope here. This can be very important for
clarifying boundaries. ]

** Stakeholders
End users Developers Sponsor [etc]

* Product/Service Description

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

** 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]

** 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]

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

**  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]

* Requirements

** 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

** 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.]

**  Non-Functional Requirements [Example:
The software for the magic hat must cost less than $1,000.]

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

* 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.

* 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.
