Modules

Requirements are part of the governance in project management. More about what all is included in the project management agenda is here. Requirements are designed so that you can use them to document the assignment, perform analysis, and manage the processing of the entire project.

Input requirements and derived requirements

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 input requirements are derived requirements, i.e. those that have arisen in the project as a result of the analysis of how to implement the project. Derived requirements are any requirements that have arisen from input requirements or other input to the project. The typical input that generates requirements is an obligation, a methodology, rarely something else.

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.

Analytical relationships

User requirements give rise to 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 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.

Requirement states

Requirement processing is controlled by states. Request states are:

New – it has not been analysed and it is 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. Requirement only gets into the state 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 – the requirement cannot be analyzed because something prevents it. Typical reasons why a request is invalid are
*The requirement conflicts with other requirements and therefore cannot all be met
- The requirement conflicts with constraints that cannot be changed. E.g. it conflicts with generally applicable regulations or cannot be implemented in the price of the work
Rejected – the requirement has been excluded from processing. The reason for the rejection should always be given. Typical reasons for rejection are:
- The requirement is duplicative with another requirement that is being processed.
- The requirement has been made by someone who is not authorized to make the requirement
Cancelled – the requirement has been cancelled by a decision of the contracting authority

Synchronising requests to Enterprise Architect

Requirements and other analysis elements can be automatically synchronized to the model in Enterprise Architect. The synchronization lets you combine the benefits of web-based access to specifications for the entire project team with the full analytical capabilities of your favorite tool.