How do I create a specification sheet?

Formulating the wishes and requirements for energy monitoring software correctly

Every company that wants to introduce new energy management software across all its operations should think this resource-intensive investment through carefully. A new system can only be implemented successfully and efficiently by carefully compiling requirements and detailed planning. Before a company makes a hasty decision on a solution, all relevant technical features, functions, legal requirements and other requirements should be consolidated. As soon as the management has approved the go-ahead for the introduction of an energy monitoring system, a catalog of requirements can be drawn up with all the necessary contacts, the so-called specifications.

What needs to be considered when creating a specification sheet?

First of all, you should record the status quo with all relevant contacts: how do you work today and what is missing or not working?

You should then collect the requirements in terms of resource requirements, infrastructure requirements, the company's specific IT requirements and the relevant interfaces. It is important that you do not look at your requirements specification in isolation at IT level, but across all business processes and interfaces. You should therefore define the needs and requirements in the specifications together with contact persons from all specialist departments. Once you have collected all relevant requirements, these should then be prioritized and recorded in detail.

Introduction of a specification sheet in 4 steps

1. Development of the requirements in the team
2. Prioritization: Differentiation between mandatory and desired requirements
3. Detailing the requirements
4. Structuring and organizing the requirements specification

Typical errors

• Requirements specification vs. functional specification: A requirement specification includes the wishes and requirements from the customer's or client's point of view. No solution is described here; this is part of the requirements specification.

• Product vs. project: Only the requirements for a technical system and not for the entire project belong in a specification sheet. The key difference here is that project requirements are also very important, but become historical as soon as the project is completed. In this respect, the requirements for a technical system continue to exist even after the project has been completed. It is therefore important not to mix up these requirements.

• Missing the mark: It is a balancing act how detailed you list your requirements in the specifications. If the requirements are too detailed, this can lead to delays in the project. Requirements that are too superficial can lead to misunderstandings. Finding the right level of detail often requires experience and a sure instinct.

• No system delimitation: It is important to describe the relevant system and also to delimit it from systems that are not affected by the software implementation