Options:

Sven van der Zee

Requirements Engineering and Agile

Paying attention to requirements in an agile work environment


These days a growing number of people are becoming interested in agile product development. Many people work in an agile environment, or would like to do so. Some people think in an agile way; others think they are agile. It is agile to value people in interactions over processes and tools. In many agile situations people still choose to work according to a set of rules offered by a standard framework. Scrum is currently the most popular such framework.

Scrum is very powerful due to its simplicity: it gives team members the freedom to determine how the product is actually developed. In practice, however, people often find it hard to keep thinking about how to do their work (e.g. understanding requirements, designing, programming, testing, deploying) and how their way of working can be improved. Quite often people simply repeat indiscriminately the prescribed development techniques (or those that are most popular in the market). It is not easy to be agile, nor is it easy to deal with the freedom that Scrum allows: you need people with the right expertise.

Requirements engineering is a field of expertise that is applicable in various situations and processes. It is useful even in agile product development and can help to provide more substance to the Scrum framework. Who, though, should bring this expertise to an agile team, is a subject for discussion.

In Scrum, the Product Backlog is a dynamic set of requirements, with the Product Owner responsible for its content and management. This should be done continuously and in collaboration with both stakeholders and the Development Team. In practice there is quite some variation in the profiles of people that fulfill the very demanding role of Product Owner. Depending on their expertise the kind of support they require from Development Team members or business analysts also varies. Furthermore, the people that support the Product Owner do not themselves always possess sufficient requirements engineering expertise.

To engineer or not to engineer

Requirements engineering provides a rich collection of techniques together with the rules that bind them. Is it, though, really engineering? Regardless of the answer to this question requirements engineering has great potential to raise the level of both soft and hard skills in order to build the right product. Sometimes you hear that requirements are dead or that they no longer play a role in agile: perhaps a better view is that thorough requirements expertise is necessary to bring the essence of requirements engineering into agile teams.

The core of this field of expertise can be found by looking for similarities between the application of requirements engineering in traditional and agile work environments. This provides insights that help in selecting and applying requirements techniques that suit the type of process. A good understanding of the differences is, though, also crucial in achieving success.

Similarities in goals and thinking

A classical misconception concerning requirements engineering is that it only concerns the documentation of requirements. The ultimate goal of requirements engineering is in fact to facilitate a common view and a shared understanding of the requirements amongst all parties involved in the development effort. These requirements can vary from business requirements to detailed software requirements and take various forms, such as stakeholder needs or expected system behavior in both functional and non-functional terms.

To achieve a common view of requirements some form of documentation is useful, whether this be a Software Requirements Specification (SRS) or a collection of user stories. In either form it is good to be specific and to use rules like “the active voice”. Experience shows that it is at least as important to talk about these requirements together in order to really share the understanding. Face-to-face communication is something that is heavily embraced in the agile community, where this shared understanding receives an even greater emphasis. Although the requirements engineering road may vary in traditional and agile approaches, the ultimate goal remains the same, and it is important to keep this goal in mind so as not to get lost when applying specific techniques.

It is useful also to be conscious of the way we think. The generic ways of thinking within requirements engineering are very similar in traditional and agile work, as we see in the following examples:

Differences in timing and techniques

The difference between requirements engineering in a traditional work environment and in an agile work environment lies both in the different timing and in a preference for different techniques.

Different timing

It is not agile to specify all requirements in detail at once. In the Sprints of Scrum the Development Team only works on a limited set of requirements at a given time. In an agile team you have to take care that everybody understands what has to be built just before the development of the next version of the working product. In agile you do just enough, just-in-time requirements. The details of requirements will be dealt with during the Sprint, or just before the Sprint, in refinement sessions. By picking up a small set of stakeholder needs and translating these into a working solution rapid feedback is obtained. Frequent feedback makes it possible to learn more about the requirements and to adapt the requirements process accordingly. As the requirements work is spread over time, the alignment with technical and financial concerns is an ongoing activity and not something that takes place solely in an initial development phase.

Different techniques

Agile requirements techniques support the idea of a joint effort around a limited set of requirements, in contrast with the traditional situation where a specialist typically works on a comprehensive requirements document. Agile teams prefer to capture requirements in a way that strongly supports interaction and the desired flexibility. Well-known examples are: user stories on sticky notes or index cards [1], story maps [2] or vision boards [3].

The active voice is used in user stories, formulated with a user role as the subject. In traditional requirements the active voice is often also used, however with the system as the subject. In a traditional setting it is common to differentiate between functional and non-functional requirements, typically within separate sections of the requirements document. This differentiation is intended to ensure the completeness of the requirements collection. In an agile environment both functional and non-functional aspects are captured together by analyzing each individual requirement (typically a separate user story), for example with the help of the 7 Product Dimensions of Ellen Gottesdiener and Mary Gorman [4]. This leads to a better understanding amongst the involved parties, additional details like acceptance criteria and also frequently to new requirements (splitting of user stories).

In a traditional work environment the complete requirements set will be judged in terms of both feasibility and cost; in agile the emphasis is placed on the added value and risks of each requirement.

Team effort

In many agile frameworks the delivery of requirements is considered to be an autonomous process, as if stakeholders simply come up with their requirements by themselves. In practice this process requires a great deal of creativity and craftsmanship. It is an art to get good input for the product development process, and this craftsmanship has long been known as requirements engineering. This expertise does not have to be owned exclusively by one specialist. To use a popular sentence structure in agile requirements:

“As an agile team, I want the team to have sufficient requirements engineering expertise, so that requirements get the attention they deserve.”

References and Links



Sven van der Zee

Sven is senior consultant|trainer at inspearit|cibit academy. He has worked on aligning business and IT at various organisations for more than 20 years. Both at profit and non-profit organisations Sven has helped teams and individuals to reach improvements in processes and results. He masters and applies several methods and techniques. Sven has helped many persons to achieve more with the right use of requirements engineering techniques and with agile ideas and frameworks. He loves to share his experience with others.