How to successfully create a specification sheet in 7 steps

"A specification sheet is far too much work, the specification sheet is far too inflexible, we don't need a specification sheet - we work agile" Does this sound familiar?

The requirements specification is the basis for collaboration with all departments and external service providers. Creating a specification sheet is also worthwhile for supposedly simple projects, such as a website relaunch. You have an overview of the project at all times, can keep everyone involved informed, have enough time for agile sprints and full budget control.

In this article, our guest author Melanie Morello shows you how to create a requirements specification and which steps are necessary.

These are the differences between requirement and functional specifications

The requirements specification, often also the requirements catalog, describes the task and the project from the client's point of view. The functional specification is the answer to the requirements specification and is created by the contractor. It describes how the requirements can be implemented and solved. A specification sheet is created as a basis for comparable offers in tenders, e.g. for CD development or a communication campaign. Requirement and functional specifications are also used for extensive software projects, such as an ERP introduction, software updates in the online store or website relaunches.

Checklist: What belongs in a specification sheet?

This checklist shows you how to create a specification sheet.

1. Introduction

This is where you explain the project considerations, i.e. why this project exists, what your motivation and objectives are. It should be clearly and simply formulated what the project is about and how you envision the project process.

2. Describe the initial situation and current status

This is the current starting situation, the status quo. In addition to technical details for software projects, you should also list and outline problems and circumstances, such as performance optimization in the online store. All relevant stakeholders are listed here, including technical and functional responsibilities. In addition to the interface details, the system boundaries are defined in this area. This is where you record the initial information for the technical framework conditions and any legal requirements. Use simple and clear formulations and only use technical terms to describe the relevant facts and in the correct context.

3. Functional requirements and target status description

Very tricky and important - now it's time for the biggest and most challenging part of creating the vices. In this step, you need to precisely specify and describe the skills you want in order to solve your problems and tasks. This section should be as detailed as possible and as rough as necessary, i.e. you should not specify any solutions here, as this is the contractor's task and belongs in the specifications.

But how do you proceed here? Here, too, you don't have to do everything on your own, but get the requirements and wishes of your colleagues from the departments. You ask all users, affected parties and other stakeholders. In workshops and surveys, you can collect and prioritize the requirements and derive user cases or data models.

4. Non-functional requirements

All requirements, e.g. usability and performance or other points that do not correspond to the technical specifications of the functional requirements in point 3), are specified in this area.

5. Overall system architecture and functional security requirements

At this point, the big picture, i.e. the overall structure of existing systems and interfaces, including the new system, is described. What is the area of application, e.g. are there new security-related requirements due to the expansion of the existing systems?

6. Scope of delivery and acceptance criteria

The prerequisites and, for example, measurable criteria for the requirements and completion of the phases must be defined here. It is primarily about the required functions and the quality requirements. This area is very tricky - please describe very precisely which prerequisites and acceptance criteria, e.g. for the test phase, must be present. This area is coordinated with the service provider during the project phases, especially in agile sprints in area 4) Functional requirements.

7. Glossary

Many companies and industries use special abbreviations and technical terms or have certified processes, funding and DIN standards that can be explained here.

Templates and tools for specifications

Do you have a suitable project and want or need to create a specification sheet? No problem, there are plenty of good specification sheet templates in Word or Excel. If you want to use the contents of the specifications in your PM software, you should check in advance which file format you need. You can find an overview of project management tools on our software evaluation platform OMR-Reviews. You can also access suitable Excel and Word templates for creating a specification sheet.

These are helpful project management tools that support you in creating a specification sheet:

Asana

Jira

Trello

Slack

Miro

If you want to integrate graphics or screenshots into your specifications, we recommend that you create the specifications in Word. It's easier and faster than in Excel, you can simply send the finished document as a PDF by email and really anyone can work with it and add comments.

For points 3) and 4), it is very important to prioritize the requirements and cases, i.e. what is a "must-have" and what is a "nice-to-have". Here it is very, very important to describe exactly what the requirements are so that there are no misinterpretations.

Important to-dos and practical tips

Here are the most important to-dos for creating your specifications and practical tips at a glance:

• Start in good time before the project begins and allow plenty of time for adjustments during the course of the project.
• Get professional support for the software area and the technical specifications.
• Work with agile sprints in the software phases.
• Don't forget your customers, legal requirements and data protection.
• Simple and precise description of the tasks, especially in the area of the target state.
• Plan sufficient buffer zones in the project planning, especially for IT and test phases.
• Agree an extra contingency budget for additional expenses - you will need it.
• The requirements specification is your basic communication, i.e. you need to know what is in it and make it accessible to everyone involved.
• Use several software solutions for planning, e.g. Asana or Jira for the entire project and Trello for agile sprints and smaller projects.
• Avoid email distribution lists and use Slack for your communication.
• Document important decisions and changes directly in the specifications and create discussion notes.
• Actively request status feedback, which you can also use for documentation and reporting.
• Use programs such as Miro to visualize processes, cases or milestones.
• Print out the most important phase milestones on paper and create a project wall. This gives you an additional overview of everything and allows you to "tick off" your steps.
• Plan coordination meetings pragmatically and according to project requirements.
• Red alert for these sentences "Could we add ...?" or "I've heard that this feature ..."! Check carefully whether these special requests can be implemented now or in a second project phase.
• Communicate immediately if something is not working or if considerable additional work is required.