Requirements management in an agile environment

The recently published article on the agile systems engineering was very well received. The response clearly showed that the topic of agile is still highly topical.

Registration for the Modeling Craftsmanship Camp on 18.11. in Hanover (Registration >>), and the  systems.camp North the GfSE on 7.10. in Hamburg is already half booked (Registration >>)

Requirements engineering is a very important part of systems engineering. Since Maik Pfingsten recently talked to Michael Mahlberg about this topic at Zukunftsarchitekten, I would like to take up the topic here.

The conversation was interesting and worth listening to. In some places, I couldn't agree with the two of them unqualifiedly at first. However, as the podcast progressed, I realized that this was probably because the context was not explicitly set. Mike's questions alluded to using agile RE in embedded and functional safety. Michael's answers implied that he was thinking more of pure software development in areas where safety plays a subordinate role. Agile RE can be used in both areas, but the development requirements differ considerably. It is precisely such nuances that make such recordings interesting and stimulate thought.

Who is responsible for the requirements in agile RE?

Maik's key question was how RE in an agile environment differs from a traditional environment. It was implicitly assumed that the audience was at least rudimentarily familiar with RE in the traditional environment. Against this background, the question arises as to who is actually responsible for the requirements in an agile environment, as the role of requirements engineer does not usually exist. Anyone familiar with agile development would guess the Product Owner, but according to Michael, this is neither desirable nor realistic, as they rarely combine all the necessary skills. Instead, he sees it as teamwork to process the requirements.

It is neither desirable nor realistic - given the real cast of this role - for the Product Owner to describe all requirements alone (Michael Mahlberg) [tweetthis]It is usually neither desirable nor realistic for the Product Owner to describe all requirements alone @MMahlberg[/tweetthis]

Requirements are also not finalized and then implemented. An analogy was drawn here with the traditional requirements specification, which is handed over to the implementer and answered in the form of a functional specification. Instead, he compared the requirements to a lump that is reshaped in the course of the project. The question arose as to which element types are used in an agile environment. The answer was that in an agile environment, the artifacts tend to consist of "elements stapled together in a wiki".

At this point, I have a different opinion: in an agile environment, dealing with changes is a key success factor. However, in order to be able to deal with changes, we need clear boundaries between information elements and clearly defined relationships (traceability). The approach described here can certainly work for small projects. But I see scaling problems here, especially if the development includes aspects of functional safety. And in the area of functional safety, such an approach is not acceptable. Which, by the way, was also taken up later by Maik.

Lifecycle: An important difference in agile RE

There is a significant difference in terms of the development lifecycle. Traditionally, Michael sees many things upstream ("waterfall"), whereas in agile RE many requirements only arise during the process. He also pointed out small but important differences between the various approaches, e.g. Scrum vs. lean. I think this is also a very important aspect, because not all agile approaches are the same. One point of discussion was the time required to create a specification sheet, with a duration of 6-9 months being mentioned, which is quite common in traditional practice. However, according to Michael, this can also occur in an agile environment, whereby the writing of the requirements specification is not upstream, but rather a transformation process from requirements specification to functional specification, which runs parallel to the development. Here, too, I don't quite agree: for me, the problem and the solution should remain separate even in an agile environment.

Dealing with changes

It was only late in the discussion that a topic came up that I consider extremely important in an agile environment: Baselines, traceability and change management derived from them.

Michael argued that baselines can be overkill for revision security, since in a (e.g.) wiki-based system every page is versioned anyway and therefore the history is easily accessible. He's quite right, but in my opinion this is only one possible use case for baselines. The trick with baselines is that a group of elements is summarized. The classic use case is that one baseline is compared with another, or with the current status. In this scenario, I am not interested in all the small changes, but only in the difference between the two baselines. If a single element becomes conspicuous, its history can be examined in detail.

The same applies to the question of traceability. Here, Michael saw the application primarily in estimating the effects of changes, i.e. classic impact analysis. He saw less value in tracing changes retrospectively - primarily because of the conversion process mentioned at the beginning: the information to be traced may have already disappeared after further development.

I also have a tree from the rough requirement to the detail in the agile environment, only at a much later point in time (Michael Mahlberg) [tweetthis]I also have a tree from the rough requirement to the detail in the agile environment, only much later[/tweetthis]

This is the reason why I consider a clear separation of problem and solution to be so important - especially in an agile environment: While the solution can (and will) change very quickly, the problem remains relatively stable. However, if the problem changes, it is all the more important to check all the implications of this. The classic means of almost all RE tools are the "suspicious links". Specific example from the podcast: "The user must authenticate themselves." A solution can now be developed iteratively. If the solution approach changes during development, this is irrelevant for the problem definition. However, if the problem definition is supplemented, e.g. "with 2-factor authentication", it is important to mark all dependent solution elements as "suspicious". Otherwise, the second factor might be forgotten in the password recovery link.

During the podcast, I had to laugh because Maik remarked, "You described something that is a highly iterative V-model in my world". Again, I can fully agree with that: That is also what I had described in the article "agile system development". However, in order to be able to live something like this, artifacts must be cleanly separated and cleanly linked.

Agile RE is a highly iterative V-model in my world (Maik Pfingsten) [tweetthis]Agile RE is a highly iterative V-model in my world[/tweetthis]

Conclusion

The podcast was full of good ideas. The sometimes contradictory statements could be recognized by the fact that agile RE was illuminated from two different directions: Both from the well-known field of agile software development and from the perspective of embedded development, where agile RE is not yet so widespread. These differences, which are not explicitly stated, may lead to confusion for the listener.

But with this difference in mind, Maik's comments on functional safety and systems engineering made sense. Michael, on the other hand, talked about input masks and software code. A wiki can be quite sufficient for such developments.