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.
but only a single set of user requirements. Therefore, the transition from needs to user requirements is where you will resolve:
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:
where individual customer needs can be:
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.
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
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:
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:
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.
We recommend that traceability matrices are produced between user requirements and needs.