Announcing Cradle-7.7 - start your free trial here

3SL Reference - User Requirements in Systems Engineering

Concept and Purpose

User requirements are statements of the characteristics to be possessed by a product that are visible externally to the product.

User requirements are, by definition, the primary source of product information and so are the starting point for all product development. However, because the language needed in user requirements is not the natural language of you or your customers, we recommend that the information you collect directly from stakeholders is used as needs, and that the user requirements are written from these needs.

  • A set generated internally in your busines
  • A set from each request from each customer

but only a single set of user requirements. Therefore, the transition from needs to user requirements is where you will resolve:

  • Problems of ambiguity, contradiction, imprecision and duplication in each stakeholder’s needs
  • Complementary or contradictory wishes from all the stakeholders

This separates user requirements from each customer’s statements. This is also valuable. It helps you make fundamental decisions of how to resolve complementary or conflicting needs of multiple customers:

  • As a single user requirement that encompasses all needs
  • As several requirements when needs are not compatible

where individual customer needs can be:

  • Accepted, and linked to user requirements
  • Rejected, when not linked to user requirements
  • Combined, when several needs are linked to one user requirement
  • Separated, where a need is linked to several user requirements to allow more precision in the transition between the two sets of data

This distinction is also a simple way to categorise and report accepted and rejected needs, and derive metrics and KPIs from them.

User requirements fulfil the most important role of all database items. They are a re-expression of needs into a form from which system requirements can be created. User requirements specify characteristics that are desired from a product by someone who can only see, and is only concerned with, the external product, not any of its internals.

Content and Creation

These will be the highest level requirements in the database. They will be written by you, not the stakeholders, and will probably be created manually, most likely by copying and rewording needs, and least likely by being captured from documents. The exception will be when existing or legacy data exists, when it should be loaded directly from the external documents into the database.

The purpose of the user requirements is to translate the language of needs (the only source material available for the database) into the language of the functional and non-functional characteristics of your current and new products.

The authors of user requirements must re-express needs into the externally-observable characteristics required of your new and existing products. This is a highly skilled task and, given that the user requirements are the basis for all work on all products, this work must be carefully reviewed.

Most user requirements express the functional and non-functional characteristics required by the users of a product, but user requirements may also be written from the perspective of other stakeholder

Structure and Organisation

Since the user requirements will be derived from the needs, and the needs are organised by project, there will be one hierarchy of user requirements for each project. Each hierarchy will contain a mixture of different types of user requirement. It is the role of requirements engineers to decide how to organise the user requirements in each hierarchy. User requirements could be organised by type, such as:

Organise user requirements

We recommend the last of these examples, that user requirements are structured into hierarchies based on the products’ lifecycle. We believe that this is the easiest approach because:

  • It encourages user requirements to be created from the perspectives of all stakeholders
  • These perspectives are closer to the perspective of the people who create the needs
  • There will be a smaller step between needs and user requirements than if the user requirements were structured in any other way
  • The user requirements will be easier to write and review

This is a different structuring convention to that used for the needs, but we believe that this is outweighed by the advantages listed above.


Each user requirement will be linked to the need(s) from which it has been derived. We propose that only the bottom-level needs are linked to the user requirements. It is likely that the user requirements that are linked to needs will have further decomposition, so that the links between the needs and user requirements will be from the bottom-level needs to middle-level user requirements.

This approach is also a simple way to categorise and report the completeness of the satisfaction of needs by user requirements, and hence to derive metrics and KPIs from them. Finding all bottom-level needs is both simple to do, and, by this approach, identifies the complete set of needs for which traceability to user requirements must be defined.

Projects, Needs and User Requirements

We recommend that traceability matrices are produced between user requirements and needs.

For a full version of this white paper: "Role and Representation of User Requirements in Systems Engineering Using Cradle" click here