In 14 days to the customer specification

What belongs in a customer specification?

A customer specification is the “Make a wish” of the customer. It describes the technical requirements of a system to be developed. There are two types of requirements. The difference is simple but essential: the project requirements and the system requirements. Project requirements are requirements that are relevant during the project but become uninteresting immediately after completion. Typical project requirements are budgets, schedules, milestones, capacities etc. System requirements, on the other hand, are those requirements that remain after the development project has been completed. In other words: Nobody is interested in the requirements of the project ten years ago, but the technical system with its system requirements is still in operation after ten years. Consequently, the technical requirements for the system belong in a customer specification. The project requirements, on the other hand, should be recorded in the project order and, if necessary, in a project manual.

And what belongs in a requirements specification?

A requirements specification has a different function than a customer specification. It is, so to speak, a project’s answer to the customer specification. In a requirements specification, the requirements from the specifications are clarified, i.e. rejected, adopted or further detailed. The requirements specification can be available as a “System Requirements Specification” in the classical way or as “User Stories” and “Epics” in an agile environment. The requirements specification and the customer specification must not be mixed up: The customer specification is the responsibility of the customer, e.g. in product management or marketing, and the requirements specification is the response of the development project. If the two specifications are mixed up, two problems arise: On the one hand, you lose the possibility to make a distinction between desired and to be implemented requirements. On the other hand, customer specifications and requirements specifications are often legal components of a contract – here you should definitely avoid legal problems.

In 14 days to the approved customer specification

If you are a systems engineer writing a customer specification, this usually takes between two and six months. To do this in two weeks and get approval, I need a different, more pragmatic approach. And so I have developed a procedure that enables me to arrive at a released specification in 14 days, five steps and with two rules.

• Step 1: Capture
  In a kickoff workshop with the project team I collect and visualise what the system is and what the system requirements are. We then use checklists to record which documents and records exist.

• Step 2: Sorting
  In step 2, the contents must be structured. Here I view all information and evaluate what is useful. Then I fill in my customer specification template, work up the result and check the requirements, grammar etc.

• Step 3: Closing gaps
  In step 3, I fill in the gaps that have become visible by researching further requirements, evaluating them, transferring them and then reworking them.

• Step 4: Checking
  In step 4 I reflect the result, i.e. I give the customer specification for a peer review into the hands of the knowledge carriers. They should go through it and comment on it. Very regularly I receive a lot of additions and information in this step, from which I create new interim versions of the customer specification. A particular advantage of this phase is that by the end of it all participants are familiar with the content of the specification and have already made their comments. This means that almost everything has already been clarified here – and that is exactly my strategy.

• Step 5: Release
  In step 5, the final status has to be created. The project team and I review the final version in a moderated workshop. In the review protocol, everything we noticed is recorded. In addition, a recommendation is made for each change. After all changes have been transferred from the review log, the release and approval is automatically carried out. Thus, a customer specification sheet and a review protocol with all the anomalies that have been corrected are now available. Since everyone has made their contribution, no further signatures are required for the release.

To get through these five steps within 14 days, I use two clearly communicated rules:

1. Who is there, is there. Whoever is not there agrees.
   This rule prevents people who did not attend the workshops from questioning the agreed specification afterwards. Of course, the hints expressed afterwards, often somewhat louder, can be taken into account in later releases. However, this has no significance for the current status of the specifications.
2. No feedback is approval.
   Obtaining approval is rarely easy. If I give out peer-reviewed versions with the request for approval and do not receive any feedback after an agreed period of time, this is considered approval. Again, subsequent feedback can be included in a later release.

The two rules make it easy for everyone involved to decide how important the specification is to them. In practice, this works very well, but it also requires a certain amount of steadfastness.

Can a customer specification be agile?

I am often asked whether a customer specification can be “agile”. The answer is simple: A customer specification is an important artifact in the environment of a development project. As a systems engineer I can create it with a classical or an agile approach. If you create it according to the principles of the Agile Manifesto, you would only have to replace the word “software” with “customer specification”. Of course, a customer specification created within 14 days cannot have the same level of maturity as one created within two to six months. But that’s not the goal either, because an agile specification is all about a pragmatic approach. I need to have a correct, approved specification quickly in order to be able to start implementing it. In the practice of creating agile customer specifications, several runs can be started over time and a new version of the specification can be created each time. Thus this procedure fits perfectly into an agile environment. The requirement specification remains dynamic and describes the current state of the system requirements to the best of our knowledge and belief – no more, but no less!

What does t2informatik actually do? One click and you'll know.