You want to start a new project, the product to be developed is already set in broad terms. You decide that now is the right time to structure these rough ideas, functions and solutions and to write it down. This point in time and the questions that arise now are subsequently examined in more detail. Typical questions and thoughts that you might think about:

• Are requirements nowadays recorded in writing?
• Do textual Requirements imply heavy processes and thousands of pages of documents that anyway nobody reads or understands?
• A picture tells you more than 1000 words!

Are requirements nowadays recorded in writing?

Is the documentation of requirements in textual form still up to date? The answer here is clearly YES! Now the question is: why?

The strength of textual requirements is that it is relatively simple to document the various functionalities of the product. This is especially important if you remember that in general, it is required to demonstrate the correct implementation of the functionality. In order to achieve a complete test, each function must be tested separately, whenever possible. This is the only way to achieve a useful traceability. Again, this is the necessary condition to achieve completeness.
Another argument for textual documentation is that everyone is able to understand it. Complex and specific modeling languages or even more formal models are usually understood only by a very small minority of engineers.
In many cases, the system team or software team which defines the product together with the customer, hasn’t the know-how of a suitable modeling language for this product. The natural language, whether English or German, has the great advantage that each of the parties be involved are able to understand it. In addition to that, there is no suitable graphical form of modeling, for a lot of classic industry projects. In particular, software and systems which are focused in the management and exchange of different data, is much more difficult to specify graphically than the systems with clear mathematical terms (e.g. all kinds of control loops).
In addition to this, in my experience, graphical models and requirements are often good if they describe the detailed design requirements (i.e. they are close to the actual implementation (= software or hardware)) is. These days it is not possible to completely model complex systems like cars or planes. Also, the costs and benefits are out of any proportion, and it is technically not possible to display all of the properties of such a product in a graphical form.

Do textual Requirements imply heavy processes and thousands of pages of documents that anyway nobody reads or understands?

From the previous section it can be concluded that there are many areas in which textual requirements are without alternative. Does this mean at the same time that I have severe processes and must produce a lot of paper, which is not even read and observed by anybody at the end.

Clear answer: NO!

No standard, no functional safety standard requires heavy, sluggish, rigid, unrealistic processes. Least of all is the creation and maintenance of requirements the cause. How to put processes into practice is located in the organization of the team and partly in the organization of the individual employee. Successful are projects which are able to manage the introduction of textual requirements and nevertheless stay being dynamic, fast and flexible. The processes have to be streamlined and reduced to the essentials. The reduction to the essentials means e.g. that you have to lay out a strategy. You have to set priorities and, if necessary, make a conscious decision to a measure, and against any other measure. The topic of processes and what can go wrong (for whatever reason) is very extensive and cannot be treated within this blog.
The argument that the introduction of textual requirements leads to thousands of pages, “senseless” documentation also can be refuted.
The first thing is, that large documents arise only if a lot of requirements are written. Yes, in practice this happens over and over again, but it don’t have to be like this! In my experience across industries there are often written too much Requirements and not too little nowadays.
But if you analyze these projects you can see that this large number of requirements caused more problems than it solves. The reasons you can find in the fact that no strategy and no procedures are created.
The large documents do not arise by the requirements engineering in principle, but due to incorrect practices and strategies.If large documents are created, it is clear that they tend to be difficult to read and not necessarily useful. A requirements document that was created with a clear strategy is usually used actively in the project.

A picture says more than 1000 words!

This sentence is certainly true and can be confirmed from various fields because of the general life experience. But, if this is the truth, why do we write textual requirements instead of using pictures?
This question is valid, but requires a more detailed answer. A simple “yes” or “no” unfortunately does not do justice the complexity of the problem.
First it is fact that in the area of embedded systems the use of images is usually a sign that the requirements arise from architecture and design. Pure functional requirements are often described in textual form. But what is the reason for that?
Well, a software architecture or system architecture is much easier to describe in pictures. The representation of a data flow in textual form is extremely awkward. In a picture, just a few simple strokes with directional arrows are necessary.
But it is also true, that it is very easy to describe single functionalities with textual requirements.
The main disadvantage of using pictures as requirements representation is that they illustrate very complex relationships very quickly. In general this is a huge advantage at first glance, but it does no longer apply, when you try to test these complex relationships completely. To test images and graphics implies to a have lot of test cases very quickly – therefore a problem with the traceability arises. Which part of the image is verified with which test cases? According to this it is very difficult to establish completeness.

In my view, that is not an either-or choice. Rather, I think it is an extremely beneficial division, to formulate the functionality first in textual requirements deliberately and to create the architecture and the design with pictures and graphics parallel to this.

This clear separation has in terms of clarity, comprehensibility, coherence and testability enormous benefits. For me, the non-observance of this fact is a main reason for many problems in the requirements engineering. Unfortunately, there is often no architecture created, because it is believed that textual requirements, which includes everything (architecture, design and functionality) are sufficient and effective enough.

Conclusion:

Are you still writing documents or are you already specifying?

All those who create requirements without any strategy and deliberation, and only do this with the motivation to fulfill a norm or a standard, must be met rather in documentation. In this case, there is a high probability that there exist an enormous room for improvement in the area of requirements engineering.

You are rather on the side of specifying, if you have considered and developed a clear strategy for requirements and traceability. This means that you are using and inserting textual and graphical requirements at the right for each point. In all probability, you will have fewer reruns during testing. And this is a strong sign of high product quality.

Are you ready for a status workshop, to analyse improvement potentials in your requirement engineering, then send a mail to: info[at]heicon-ulm.de or call +49 (0) 7353 981 781.