User Requirements Document

Name of the group (edit)

Contents

1. Purpose of the document

The purpose of this document is to define requirements for system XXXXXXX (name of the system).

The intended audience of this document is described in table 1.

Table 1: Intended audience of this document.

2. Business goals

This section describes the business problem (or business goals), in other words the reasons why the customer wants to develop a new system.

Describe shortly the current way of doing business and the potential improvements the customer expects from the new system.

3. Main domain concepts

This chapter gives a brief introduction to the problem domain. It might include

• Textual definitions of the most important domain concepts
• A conceptual data model defining the relationship between the most important domain concepts

Table 2. Main domain concepts of the users

4. System overview

This section is a high level description of the intended solution (=the system). It might include

• a list of essential features of the system
• a graph (for example a use case diagram) that defines the users and the main functions of the system

5. User groups

This section describes intended users of the system.

Table 3. Users of the system

6. Functional requirements

This section defines the functionality (services) that the system must provide in order to meet the business goals.

Functional requirements can be organized in several ways, e.g. by feature or by use case. The layout can be determined by each group – the example layout below can be used.

7. Non-functional requirements (quality requirements, properties)

Non-functional requirements are documented in this section. The layout can be determined by each group – the example layout below can be used.

8. User requirements (use cases)

Use cases are strongly recommended to be used in documenting user requirements. The following sections are typically included in use case descriptions:

• Name: Unique name of the use case (the same as the name in the use case diagram)
• Summary: Short description of the use case
• Actors: List of users and the other systems that interacts directly with a system
• Preconditions: Description of "start situation" and goals of the users
• Basic sequence: Description of main actions
• Exceptions: Descriptions of special situations, violations of business rules etc.
• Post conditions: Description of "end situation"
• Priority
• Status
• Traces to requirements
• Traces to test cases

9. Constraints

In this section, solution constraints are listed. These might include

• Standards
• Software constraints
• Hardware constraints

10. Solution ideas

A list of possible solution ideas that came up during requirements definition - and possibly a short description of each idea. Keep it short!

11. Acronyms and abbreviations

A glossary explaining the special terms and abbreviations used in this document are explained here.

Table x. Acronyms

12. References

List here all the documents that have been used as an information source and are necessary for understanding of this document. List also other specifications that have been used as a reference.

Table x. A list of all other relevant documents