Software development is fun! Which software development team is not happy to quickly turn a challenging customer request into an exciting solution and to present a first prototype? On the other hand, any motivation of a development team is quickly gone if you say that a project will be implemented in the waterfall model in the next 2 years and that all requirements will first be collected in the initial phase. In the following article, a change of perspective is suggested with the inverted V-model, with the aim of significantly increasing the practical benefit of requirement engineering in projects.

In functional safety projects there is a high pressure to apply a more complex development process. Despite the (claimed!) normative requirements, it is observed in many of these projects that rapid prototyping is preferred to the creation of requirements, architecture and traceability.

Since this is a very widespread phenomenon, I would like to question the whole thing in this article. Are there perhaps even good reasons to proceed in this way, as seen in practice. After all, one can ask the question: Can thousands of developers and project managers really be wrong as many consultants and some theoretical papers would like to make us believe?

Sources of errors in software projects

Let’s first take a look at the statistics on the causes of errors in software projects. Here we see that most of the mistakes that are made in a project have their root cause in the requirements. The pie chart shown is only one of many. All studies I have ever seen on this topic show very similar results. Requirements play an important role when it comes to improving the quality of products.

The design phase translates the “what” of the functions defined in requirements into the “how”, i.e. the software design represents the solution. Model-based development has brought great progress here in recent years. In the meantime, tool-supported, consistent and correct models can be designed. In many cases, the models are so good that it is possible to automatically generate source code from them. Both models and source code are based on mathematical rules. Thus, correctness and consistency can be mathematically verified. This leads to a significant reduction in bugs.

Unfortunately, this is not yet possible for requirements. The requirements are the interface between the client (customer/user/etc.) and the contractor (service provider/development team/etc.). This is an interface only between people. Again, the only comprehensively available means of communication between humans is natural language. Natural language does not fulfill any of the properties actually desired for Requirements:

• consistency
• correctness
• uniqueness
• completeness

Requirements engineering tries to minimize these weaknesses. As the error statistics show, this obviously succeeds only to a very limited extent.

Prototypes – The customer is not aware of his needs!

The error statistics shown are familiar to every software project manager these days, and yet the specification phase is often skipped or only carried out superficially. We can even go one step further: With agile software development, an approach that rejects a document-heavy approach has gained acceptance in recent years. Instead of extensive specification documents, agile projects place much more emphasis on quick and short feedback loops with the customer and user of the product.

These short feedback loops in agile development represent a practical answer to the weaknesses of the requirements engineering method with regard to the specification of systems. However, a second point, which is very important for practice, is added. In industry-relevant projects, neither the user nor the development team of the product knows all required functionalities completely at the beginning. The longer and the larger the project, the larger the gap.

Requirement Engineering method weakness

This second point can also be interpreted as a weakness of the requirements engineering method. Many books deal extensively with the (systematic) elicitation of requirements. If one takes the lived practice as a benchmark, then the various creative techniques for requirements elicitation defined in theory do not seem to be very attractive and successful.

As mentioned at the beginning of the post, naturally software teams like to develop source code. If you do that in a truly lived agile development process, you can very systematically develop a prototype of the system.

The key is to really apply the agile methods. Use cases and user stories, but also requirements specifications, are the ideal lightweight documentation for prototypes.

I also intentionally call requirement specifications lightweight documentation, because the customer/user creates the requirement specification – not the development team. If there is no requirement specification, then the development teams just create short meaningful use cases and user stories.

A typical example for a requirement specification looks like this:

• The heating control shall control the output signal abc.

The inverted V-model

If you do not have any documented product properties at all, you actually turn the V-Modell completely upside down. You start a software development only with what you verbally and thus superficially think you have understood as product properties.

The many decades of software development have proven that this approach is almost inevitably doomed to failure. In the end, the resulting product is too far removed from the customer’s needs. Extensive rework, which in retrospect is equivalent to a new development, is necessary. The even bigger problem with this approach is that no planning is possible. This leads to great frustration for all project participants.

So we could conclude that agile development with lightweight documentation and fast and short feedback loops is the solution.

The smaller, shorter in duration and less security-relevant the projects are, the more likely this is correct.

Prototyping in functional safety projects?

Prototypes supported by a lightweight form of specification such as use cases, user stories, etc. should always be used at the beginning of a larger, more complex project when there is still a great deal of uncertainty about the functionality of the product to be developed. This also applies to functional safety projects. No functional safety standard requires a continuous, consistent specification and traceability in early project phases. Here, it is much more important that, for example, an assessor can understand that you have a plan and know what you are doing and why.

You must also not equate a safety concept at the beginning of a project with a testable functional specification. A concept takes care of the big picture. A safety concept therefore deliberately does not distinguish between functionality and architecture.

Especially in very innovative functional safety projects, a prototype phase following the creation of a safety concept, supported by lightweight, rough requirements, is a real secret to success.

It is crucial that the prototype phase also comes to an end. As soon as the open points regarding functionality have been clarified by the prototype. The knowledge gained through the prototype should then be written down in functional black box requirements. In this phase, you have gathered enough knowledge to formulate the requirements in sufficient detail to make them testable. Functional Blackbox Requirements means that these are the system requirements. In most functional safety projects, a second level of textual, testable requirements is needed. More on this later.

An example of a testable system requirement looks like this:

• The system shall set the output signal Vent_a to 5 volts 2 minutes after the temperature has dropped below 5°C.

When shall requirements and traceability be ready in functional safety projects?

There are many misunderstandings here. No functional safety project requires a waterfall development! Rather, requirements can change in the course of a project, just as the source code does.

What this means in practice for the system requirements, we have already discussed in the last section.

Beside the completion of the requirements, the prototype supplies naturally also information about the architecture.  With this information the system engineer documents then in graphic form the system and software architecture. Typically an architecture has several views. One view should be designed to identify the functional blocks of the software.

For complex functional blocks, it is often again a good idea to extend the prototype accordingly and document the software requirements from the insights gained and then establish traceability to the system requirements.

For the traceability into the source code, the system-/software engineer should use the architecture. The level of detail of the architecture ultimately determines the quality and accuracy of the traceability to the source code.

The procedure shown corresponds to a parallelization of the source code development with the requirements and traceability. All of this shall be finished, consistent and correct when the project is completed. Not before!

Also not all system requirements must be finished, before the system-/software engineer starts with the architecture and the software requirements. It is much more important to proceed in a systematic way.

Conclusion

In summary, pure waterfall development always fails when projects become large and complex. On the other hand, the projects also fail when coding is started without a concept regarding the specification of the system.

This is also true for functional safety projects. No one can write correct, complete and testable specifications at the beginning of a project that never need to be changed.

A project shall be complete and comprehensible in detail above all at the end. The way to achieve this goal is quite variable in practice. In the meantime, the variant of parallel development and documentation as described in the article is considered to be very efficient and effective. The better the respective feedback loops are organized, the more successful the project will be, especially in terms of time and costs.

Related HEICON Blog posts

• Requirement Engineering – Aspects which even not considerd in theory!
• Requirement Engineering 2.0 – Approaches how the method needs to be enhanced!