/ 1(7)
Group no.
Date

Project <Project title>

Help:Delete or hide (Tools->Options->View) all blue text before formatting and printing your document.

Help:

What is a requirements definition?

A requirements definition is valid at a certain time point. It contains selected and prioritized requirements that you intend to implement to a certain version of the product/component/function in question.

Distribution

Help:Fill in the distribution list.

Steering group:

<N.N>

Project group:

<N.N>

Others:

<N.N>

CONTENTS

1Introduction

1.1Background

1.2General Description

1.3Definitions

1.4Related Documents

2Interfaces

3Use Case Model

4Requirements

4.1How the Requirements Are Organized in the Document

4.2Main Requirements

4.3Additional Requirements

5Future Development

1Introduction

1.1Background

Help:Introduce the motive for the product/component/function to be developed, refer to Development Items, Product Maintenance Requests, etc.

Also, delineate the purpose of this document and specify the intended audience.

1.2General Description

Help:Explain in short what the product/component/function will do and, if necessary, will not do. Describe the application very briefly.

1.3Definitions

Help:List the special terms used, if any. Make references to other documents with definitions.

Terms / Definitions

1.4Related Documents

Help:If applicable, provide a list of documents related to the product/component/function, This could be documents that this document is based on or that explain a specific requirement more in details. Only include documents that do exist.

Document identity / Document title

2Interfaces

Help:This chapter should describe the interfaces of the system, i.e., things that are externally visible by humans or other systems. This in particular involves user interfaces and hardware connections (if any). Here you should put “things” that “exist” in the system. For hardware, here would also be specified any restrictions on materials, size, tolerance to interference, and similar. Everything describing a function should be in Section “Requirements” (next section), and this section may be emtpy, and should in that case be removed.

Examples: “the system shall have a touchscreen”, the system shall have a web interface”, “the system shall communicate via CAN”, “the system will have a DSUB connector (with definitions of the signal on each pin)”. Choose a presentation format that makes sense, e.g., drawings of the product describing physical sizes, tables with lists of pins and voltages, and similar.

3Use Case Model

Help:In some cases, it is important to understand the usage of the system as a background to requirements, or part of requirements. If so, put this section here instead ofbeing in the design document (cut & paste from the design template).

4Requirements

Help:In this chapter, describe the specific requirements. The range of a requirement can vary from being comprehensive to being very detailed. This must be decided for each individual case. Consider the following:

  • Give each requirement an identity, priority, and description.

For identity, define how it is put together (must be unique within the document). The identity as such does not exist until the requirement has been defined. It is created by the writer of the requirements definition and should not be mixed up with the identity of development items, etc.

For priority, 1 (one) is always the highest priority.

The description shall include a headline, a definition, and a motivation. The level of detail depends on the scope of the requirements definition; requirements on a system might be more general than requirements on a sub function.

  • If applicable, introduce the source of a requirement.

The source can be a department, a specific customer, a document, another requirement (from which it is derived), etc. Or, the source can be the identity of a proposed development plan or a proposed development item. If so, include the name of the database.

  • A requirement must be possible to validate.

Outline a requirement so it becomes measurable. Example: ”The function shall accept PROM-sizes up to 16 Mbyte without any parameter setting.”

  • Requirements should not be contradictory.

Requirements can sometimes appear to be contradictory, in some cases you can use the priority to differentiate them.

  • Requirements must be understandable by both parties; the receiver of the results and the development personnel.

You can, for example, use the following checklist to help make sure all aspects are covered, as you define the requirements. Some items in the list, like Operations, have a different meaning depending on the product/component/function and what situation you are describing:

Cost goal
Time goal
User interface
Hardware interface
Software interface
Communication interface
External interfaces
Performance, dimensions, size constraints
Compatibility
Functionality
Capacity
Reliability and availability
Security
Maintainability
Error and exception handling
Data storage, type directory
Operations
Development environment
Site adaptations
Constraints/conditions regarding other existing products/components/functions or their development
Standard compliance
Design constraints
Input/output

4.1How the Requirements Are Organized in the Document

Help:Describe the basic structure you have used to group the requirements. For example, you might have chosen to arrange the requirements in sections and subsections by category. The organization of the requirements should reflect the structure of the product/component/function in question.

4.2Main Requirements

Help:A main requirement is a requirement that must be fulfilled. If not, there is no point in developing the product/component/function. Hence, main requirements always have the highest priority (1).

Keep the number of main requirements down!

List the requirements in tables like this one (IMPORTANT: You have to list revised requirements also in the revision table on the last page):

Identity / Prio. / Description / Source
PC-U-001 / 1 / Folder structure
Definition: The environment must have a Folder/Catalog structure identical to that of the Mac environment.
Motivation: Learning to handle a new structure would involve substantial difficulties. / ML
PC-U-002 / 1 / Portable environment
Definition: The environment must support local work when travel ling or at home, i.e. be portable without additional work (no manual swap of configuration files).
Motivation: Laptop computers are frequent among the Mac users. / ML
Identity / Prio. / Description / Source
1 / <Headline>
Definition:
Motivation:
1 / <Headline>
Definition:
Motivation:
1 / <Headline>
Definition:
Motivation:

4.3Additional Requirements

Help:List the additional requirements. Although the intention must be to fulfill all these requirements, they can still be reprioritized. If an additional requirement cannot be fulfilled, it does not jeopardize the whole product/component/function. Additional requirements have priority 1 or lower.

Example:

Identity / Prio. / Description / Source
PC-I-013 / 1 / Local fax support
Definition: For portable PCs, the environment must support local fax software and a fax server connection.
Motivation: Users must be able to send fax when travelling or at home. / ML
Identity / Prio. / Description / Source
1 / <Headline>
Definition:
Motivation:
2 / <Headline>
Definition:
Motivation:
2 / <Headline>
Definition:
Motivation:

5Future Development

Help:This chapter is optional. It can be used to include a requirement or intended functionality that has been discussed but for some reason is not prioritized and implemented right now.

REVISION

Rev.
ind. / Page (P)
Chapt.(C) / Description / Date
Initials