How do I create a specification sheet?
Correctly formulate wishes and requirements for energy monitoring software
Any company that wants to introduce new energy management software across its operations should think through this resource-intensive investment carefully. Only through careful gathering of requirements and detailed planning can a new system be implemented successfully and efficiently. Before a company makes a hasty decision on a solution, all relevant technical features, functions, legal requirements and other requirements should be consolidated. So once 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 should be considered when creating a specification?
First, you should record the status quo with all relevant contacts: how is work being done today and what is missing or not working?
You should then gather the requirements in terms of resource needs, infrastructure needs, the company's specific IT requirements, and the relevant interfaces. It is important that you do not view your requirements specification in isolation at the IT level, but across all business processes and interfaces. Therefore, define the needs and requirements in the requirements specification with contacts from all specialist departments. Once you have collected all the relevant requirements, these should then be prioritized and recorded in detail.
Introduction of a specification in 4 steps
- Elaboration of the requirements in the team
- Prioritization: Differentiation between mandatory and desirable requirements
- Detailing the requirements
- Structuring and outline of the specification sheet
Typical errors
- Requirements specification vs. specifications: In a requirement specification belong 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 requirements specification. The crucial difference is that although project requirements are also very important, they become historical as soon as the project is completed. In this respect, the requirements for a technical system exist even after the project has been completed. Therefore, it is important not to mix these requirements.
- Missing the flight level: It is a balancing act how detailed you list your requirements in the specifications. If the requirements are too detailed, it 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 intuition.
- 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.