User Modules

Project input requirements are requirements that come from the external environment, typically from the customer, the project sponsor, or the team that conceived the project. They are generally called user requirements.

In contrast to the input requirements are the derived requirements, which are created during the analysis of the primary (or other derived) requirements.

Requirements are similar to the project obligations but they are not equal. Requirements are approved, prioritized and sometimes even rejected. Obligations are beyond the project team influence.

Types of requirements

The division into input derived requirements results from how the requirements were generated. A more detailed division, described below, is usually used for derived requirements. Of course, only certain types of requirements make sense in a project, depending on what the purpose (product) of the project is.

User – These has been already described. These are always input requests
Systemic – Requirements that concern the whole solution, the system (of course, only if a system is created in the project, so it is still the case)
Software – Requirements that the software being developed in the project has to/needs to meet. These are not requirements for the software used to implement the project, but the software being created
Hardware – Requirements to be fulfilled by the electronic part of the project, generally hardware
Engineering – Requirements to be met by the designs produced or developed in the project. Depending on the type of project, this may be a mechanical component being developed, or perhaps a construction project in progress
Process – Requirements for the process of implementing the requirement. These are specific requirements for how a particular activity or stage is to be implemented, who is to participate, etc. Note that they should not repeat the methodology by which the project is implemented. Thus, if there is a requirement for a process action, e.g. a review, which is given by the methodology, it should not be necessary to write it again as a process requirement (it can be found as an obligation or sample task in the methodology).
Tests / Examinations – Requirements for testing, verifying and examining any project deliverables. The requirements should collectively define everything to be performed to verify the quality of the work. (Depending on the methodology, this may include tests of input equipment, e.g., calibration of measuring equipment. However, in most cases, these input checking requirements are directly part of the methodology, or should be process requirements because they are in-process checks, not output checks.)
Business / Business – Requirements resulting from the business aspect of the project. Typically, these are requirements resulting from business needs (may relate to design, production costs, etc.). Note the distinction between requirements and responsibilities. For example, if the business requirement is that the developed product has a production cost of less than 10€, it is good to understand it as an obligation that the project must meet. This obligation is reflected in all activities from project planning to supplier selection, and cannot be clearly said to be fulfilled by anything.

Requirements analysis

If the requirements and especially the system being developed are complex, it is not possible to develop/implement a project directly based on user requirements. These requirements need to be thought through, broken down according to where, how and by whom they will be implemented and often analysed in more detail. These steps are called analysis. In the analysis, derived requirements are created from the input requirements.

Requirements traceability

User requirements give rise to system (system) requirements
From system requirements arise requirements for individual parts of the system, often already divided according to the nature of each part of the system (engineering design – technological part, software, hardware).
Requirements for parts of the system may further break down into sub-requirements, but it is better to try to avoid this and not create another layer. However, if it is a large system, this may be necessary
Testing requirements can be both input and derived requirements. If they are derived, they are the result of an analysis of what needs to be verified in order to meet typical quality criteria.

How to document relationships

Relationships are documented with the trace/trace binding. A binding always results in a requirement that gives rise to a new, derived requirement. Bindings are easily created using command buttons in the request details.

Request states

Request processing is controlled by states. Request states are:

New – not yet analyzed and waiting to be processed
In Analysis – analysis in progress but not yet completed
Analyzed – Analysis done but should be validated.
Verified (verified) – Checked as analyzed. Request only gets into step if it is analyzed by someone other than the person in charge (the person in charge is specified in the request). If it is analyzed directly by the person in charge, the validation step is skipped
Finished – Analysis done. Finished status does not mean that the analyzed solution is realized, but that the analysis of how to execute is completed
Invalid – Request cannot be analyzed because something prevents it. Typical reasons why a request is in a mess are
Request is in conflict with other requirements and so not everything can be fulfilled
Request is in conflict with restrictions that cannot be changed. For example, it is in conflict with generally applicable regulations or cannot be implemented in the price of the work
Rejected – the request has been excluded from processing. The reason for exclusion should always be stated. Typical reasons for exclusion are:
The request is duplicate with another request that is being addressed
The request was made by someone who is not entitled to make the request
Cancelled – the request was cancelled by the contracting authority by its decision

Read more about then requirements management.