[Project Name Qualification]

Document Abstract (Use Body Abstract tag)

Maintain document history information in the table below. The Document Status Sheet (DSS) provides a history of issues and revisions of the document with a comment indicating the reason for the revision. Note that the Document Title and the Document Reference Number should never change from one revision to another.

Record all changes between this and previous revision in a Document Change Record (DCR) table. A new DCR per revision is required.

Guidelines are provided for each section. Each section may be organized in subsections as necessary.

Specify special terms, acronyms and abbreviations used in the document. The subsections may be re-organized as necessary. For each definition, acronym or abbreviation use a paragraph pair of either DL1 Term and DL1 Description paragraphs, or, of DL1 Term RIH and DL1 Description paragraphs.

List all external documents referenced in this document

Provide an overview of the document.

Describe related external systems and subsystems.

Describe the main capabilities required and why they are needed

Describe the main constraints that apply and why they exist.

Describe who will use the software and when.

Describe what external systems do and their interfaces with the product.

Describe the assumptions upon which the requirements depend.

List all specific requirements, with attributes.

User requirements fall into two categories: capabilities needed by users to solve a problem or achieve an objective; constraints placed by users on how the problem is to be solved or the objective achieved.

Each user requirement must include the attributes listed below.

Identifier - each user requirement shall include an identifier, to facilitate tracing through subsequent phases.

Need - essential user requirements shall be marked as such. Essential user requirements are non-negotiable; others may be less vitally important and subject to negotiation.

Priority - for incremental delivery, each user requirement shall include a measure of priority so that the developer can decide the production schedule.

Stability - some user requirements may be known to be stable over the expected life of the software; others may be more dependent on feedback from the SR, AD and DD phases, or may be subject to change during the software life cycle. Such unstable requirements should be flagged.

Source - the source of each user requirement shall be stated. This may be a reference to an external document (e.g. system requirement document) or the name of the user, or user group, that provided the user requirement.

Clarity - a user requirement is clear if it has one, and only one, interpretation. Clarity implies lack of ambiguity. If a term used in a particular context has multiple meanings, the term should be qualified or replaced with a more specific term.

Capability requirements describe functions and operations needed by users. Quantitative statements that specify performance and accuracy attributes should form part of the specification of a capability.

Space and time dimensions can be useful for organising capability requirements. It is often convenient to describe capability requirements in terms of a sequence of operations.

Constraint requirements place restrictions on how software can be built and operated. For example, definitions of external communications, hardware and software interfaces may already exist, either because the software is a part of a larger system, or because the user requires that certain protocols, standards, computers, operating systems, library or kernel software be used.

Constraints that users may wish to place on the software include the quality attributes of adaptability, availability, portability and security. The user shall describe the consequences of losses of availability, or breaches of security, so that developers can fully appreciate the criticality of each function.

The user may choose to make additional standards applicable; such requirements are additional constraints on the development.