We previously wrote about how to successfully implement credit management software. In this post, we mentioned requirements and the elaboration during the implementation. We want to focus on specifying requirements. Why it’s important and how to do it.
Specifications vs requirements
When you purchase software or add new functionalities, you have requirements that it must meet. For example, supporting an approval process. Part of the purchasing process is therefore that suppliers answer which requirements they can meet. That way you can explore whether a product is a suitable solution.
A requirement describes high level what you want to do. In our example, you want the software to support a process for approving “something”. This is sufficient for the first stage. For the implementation you need additional information and that is where specifications come into play. Specifications zoom in on the details. What needs to be approved, what data is required, what is the authorization matrix, and so on.
Specifications describe in detail what you expect a functionality — requirement — does within the software. This distinction is often underestimated. While there are few people who know what and how to develop something based on just the words “approval process”. That is why you need specifications.
The level of detail
Specifications are the starting point for developing and configuring software. The way of specifying depends on how you implement software.
You can describe each part in detail upfront — the waterfall method —, but we prefer not to use that method. After all, you are going to a new situation, where you come to new insights along the way. When you record every detail in advance, you can’t act on those new insights.
At CE-iT we don’t use a strict methodology, but we use what works for us and our customers. You can call our approach Agile. We specify requirements to a level that is sufficient for the developer. What we don’t do is describe each item in detail upfront. So, we don’t describe the size of a button and its position. That is part of the actual the implementation.
The advantage of the Agile approach is that there is still room for progressive insight. With the Waterfall method, you — in theory — know exactly what you will get in advance, but there is no room for processing new insights. Applying the latter can take your product from sufficient to good or even great.
Specifications describe how software should work. We list the main’ advantages of specifying.
Writing asks for clear thinking
You can’t work with people without communicating. Specifying is also a form of communication because you explain your requirements. It forces you to think about what you actually want. What do you need? What outcome do you expect from a process?
But thinking alone is not enough. You should also write down the specifications.. Provide diagrams or other forms that clarify it if necessary. Where specifying forces you to think, writing forces you to formulate clearly. And clear formulation reduces the chance of different interpretations.
One more note on this item. Images can provide context, but text is leading. You therefore describe what is happening in the image. This is to ensure that the focus is on the specification and not the design. Because the design is not part of this phase.
The developer knows what is expected
With clear specifications, the developer knows what the expected end product should be able to do. This means that developers focus on the development instead of interpretation. And that’s what you want because otherwise, chances are you won’t get what you want.
Testing is easier
What goes for development also goes for testing. It becomes easier because the tester(s) know what to test based on the specifications.
Testing without specifications can lead to faulty tests and rejections based on expectations. These might be insufficiently communicated expectations or changed views. You filter that by testing against specified requirements. It better reflects the quality of the work delivered.
Specifications also define the scope. It helps to meet deadlines, because it filters out new requirements and ideas. You can add those items to the next iteration. This prevents delays in the project.
It saves money and produces better products
We conclude that specifications provide clarity. The lack of specifications is building without knowing what you are building. As a result the product probably won’t meet expectations.
Specified requirements lead to better products, in less time and at lower costs.
How to specify
The way you write specifications depends on your situation. Are you implementing new software or is it a change? For the latter, you start with the describing the current situation and then the changes. It should tell you what changes and how it affects existing functionalities.
Break processes into pieces
Each requirement consists of one or more parts and specifying starts with identifying the different parts. Breaking up a process creates mini-processes, which people — who are unfamiliar with the process — understand faster. And when you understand something, you design, develop and test better.
You go through each step chronologically, which reduces the chance that you forget something. You may sometimes have to go back to an earlier step, but that is okay.
Depending on the process, it may be useful to outline the steps. It helps when people see the bigger picture.
Work with scenarios
In addition to writing out processes, we also work with scenarios for providing context. In theory, a process is based on a standard, but in practice you see variations.
Take, for example, a repayment plan on a loan. The agreement with a customer is that it pays € 100 each month and that this must be received on the first day of the month. This is straightforward, but in everyday situations you see that it is less simple. That is why customers often work with additional rules. For example, the following scenarios in which a payment is marked as fulfilled:
- The total amount is received on the first day of the month.
- The amount was received on the first day of the month with a maximum margin of € 3.
- The total amount is received no later than three working days after the first day of the month.
- The amount is received with a maximum margin of € 3 and no later than three working days after the first day of the month.
Scenarios are a real-world explanation of a process. It puts the rules in context for better understanding.
In most cases, more than one person uses a product, and this leads to different use cases. For a complete overview, you therefore have to collaborate with the various stakeholders. It also prevents a tunnel vision of one person.
We frequently use workshops and interviews for specifying. An advantage of a workshop is the opportunity for discussion. Interviews are more personal, so people sometimes speak more freely.
Reviews should not be skipped in the specification process. It is the check if it is complete and correct, but it also offers room for new insights. People can forget something during a workshop or come to an idea when they read it as a whole.
An additional advantage of specifying is that you gain insight into which parts of a requirement are required and which are optional. This enables you to prioritise, with which you can control both costs and planning. Something that is practically impossible with only a requirement.
Specifying requirements has several pitfalls, two of which we will highlight:
- Not every detail, such as people’s names, is important. It is important that you define all steps of a process, including its preconditions.
- Specifying is not the same as designing. Visual characteristics such as the use of color and the position of buttons are not relevant in this phase. There are standards for this and, moreover, it can be easily adjusted.
If you want control over your future product, you cannot bypass specifying. It is a means with which you manage the result and expectations. At the same time, it helps manage costs.