With the right definition of requirements
you keep costs under control

Share this post

The three principles of success

Requirements specification is made for procurement.

In the implementation phase, specification and design descriptions are produced for construction, which are based on the requirement definition and specify it. The acquisition is based on an operational need, the solution of which requires an information system reform.

What exactly does the activity need? Which part of it will be implemented by the acquired information system?

The need for action can be described according to three principles:

1. user-oriented

so that all relevant usage situations (use cases) are revealed

2. systematically

so that all potential suppliers understand "steak" correctly

3. comprehensively

so that the description covers the necessary functions of the operational process.

In this way, suppliers know how to offer the best solution based on their own starting points, and comparison of offers is easy and fair.

In the best case, the delivery is planned so that piloting and use can be done in stages. In this case, experiences and benefits are gained right from the start. This requires that the most important entities in terms of operation have been identified in connection with the definition of requirements.

Signs of danger, recognize and eliminate!

The following features often lead to an unsuccessful solution:

1. Various features that the system should implement have been described.

Not describing user needs, but a subset of some solution based on the assumed implementation method.
The descriptions are not systematic and the method of description varies.

2. Some of the descriptions are related to the functions and configurations of the old system.

For example, screenshots, layered architecture drawing of the old system, data model of the current database or implementation-level specifications of individual functions (even software source code).
We imagine that the more detailed the specifications, the better.

3. A list of requirements has been prepared in Excel, in which the different persons of the customer have briefly listed their wishes as new desired features.

The rows of the list are described in one Excel cell and there is no comprehensive description that would reveal the functional entity to which the requirement is related (e.g. usage situation).
In retrospect, it is not known where each claim originates from. If the demarcation of the system changes, it is not possible to name which requirements are then relevant.

4. All requirements are marked as mandatory.

If the list of requirements is difficult to interpret, it is simplest (and fastest) to mark everything as mandatory.

5. The coverage of descriptions and requirements cannot be guaranteed.

If operating processes and use cases have not been systematically reviewed, the descriptions and requirements are based on what comes to mind.

6. The demarcation of the system has not been described precisely. What is the system responsible for and how is it related to other systems?

Different user groups have a different understanding of what is considered to belong to the system. Someone thinks of it as a register, another as a calculation system, a third as a transaction system and a fourth as a case management system.

7. Wrong image of agile development.

There is no need for descriptions, things are resolved during the agile implementation phase!"

8. Non-functional requirements have not been identified and described

The operating environment may impose requirements, which would be good to bring up already in the tendering phase. The information may include, for example, that at certain times of the year the performance is tested, or there may be certain industry-related regulations and other regulations that must be taken into account

Focus on the big picture

Don't get bogged down in the details. For a good result, you need:

- Comprehensive analysis of what activities the information system should support.

Essential use situations should be presented systematically, e.g. as use cases, not as system features. Previous descriptions and wish lists can be used to support the work and serve as auxiliary materials.

- List of requirements

Only some of the requirements can be mandatory and you should know where they come from for each requirement. The coverage of the requirements and possible contradictions must be checked. The implementation should be described as an MVP (Minimum Viable Product), i.e. the smallest functional product that can be used to support operational processes. Even if the information system is implemented using agile methods, the requirements must still be described.

- Description of the object of acquisition.

The object of the procurement must be described so that the customer's different user groups agree on the procurement and the suppliers know how to offer good solutions. If things are left open for an agile implementation project, then the customer must allocate time to solve the questions during the implementation project. Then you have to take a stand on open matters and the customer's representative must know how to communicate the needs of all user groups. The situation can escalate and the completion is delayed, because typically the customer's representative participates in the implementation project only in addition to his other work. Systematically described requirements in advance make the implementation project easier, where you can focus on defining and planning a more precise implementation.

- Users

The key is user orientation. The business representatives describe the needs, and an experienced requirements specifier prepares a sufficient description to get to the procurement preparation. The IT expert does not know how to describe the needs of the operation and the representatives of the operation are not experienced in defining requirements. That's why it's worth defining requirements interactively together with different stakeholders and a separate requirements specifier.

Read the latest:

Irina Rekiranta-Luukkonen projektipäällikkö & vastuullisuusasiantuntija

Graniitti Insights

Our experts

With us, you will find the strongest experts in the field to successfully bring your project to the finish line.