Rodolphe Arthaud

Is requirements engineering still needed in agile development approaches?

When every new iteration can violate previously satisfied requirements

When organizations come across agile approaches, they discover the following lines in the agile manifesto ^[1]: We have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation…
They may bypass or misinterpret the conclusion: While there is value in the items on the right, we value the items on the left more.
They sometimes come to the rapid conclusion that items “on the right” can, from there on, be totally ignored: that they are no longer necessary, thanks to the “better ways of developing software by doing it and helping others do it”. As stated in ^[2], “this has resulted in a perception of the agile community when looking into the ‘old-fashioned’ descriptions of the discipline requirements engineering as: ‘old stuff, useless, we have to do it differently’”.

Is that so? Are they right? Is requirements engineering a set of obsolete practices inherited from waterfall methods? Or should it just be done “differently”, and how?

Why some believe that formal requirements are no longer necessary

Most, if not all agile methods require proximity between users and developers ^[a]. Among other benefits, it favors communication, thus minimizing the need for written requirements. Short iterations and continuous feedback help in spotting misunderstandings (unclear requirements) and facilitate alignment with actual needs rather than frozen requirements (which include frozen wrong requirements, frozen unrealistic requirements, missing requirements, etc.) Early discovery of errors in the development is key to the success of agile methods, since it has such a positive impact on costs and delay. Waterfall sometimes allows rigorous development of design, code and tests according to the wrong requirements: early detection of these would have minimized rework.

In Scrum or Extreme Programming, User Stories are used to capture the users’ expectations with “good enough” precision. Before they are allocated to a sprint, they are associated to test cases, needed to verify whether a user story is actually implemented or not. Such tests clarify the user story and remove ambiguity. So, in a way, user stories can be seen as “a kind of” requirement. ^[3], a bestseller on Scrum in France, states that “With the emergence of agile methods, we no longer speak of requirements, the central element becomes the story” ^[b]. According to the same source, traceability is not an issue, since traceability is established between stories, features, tasks and tests.

Lastly, the very fact that working software is delivered continuously makes it arguably less necessary to have a comprehensive description of the software: when it is possible to discuss the real thing, why would you need requirements, which are only an abstract representation of it?

So, what might be missing if we work without formal, managed requirements?

Examples

Imagine we are to develop a system that will store records. One of our requirements could be:

R1: “The system shall store records for at least twenty years”.

To satisfy such a requirement, you will first need to estimate the size of an individual record, and to have some indications of the number of records expected. The correct solution will imply a combination of lower level software and hardware requirements, and even requirements on data formats; for example, you may require that storage can be extended easily, preferably without the need to migrate data, that technologies used in the system can be replaced when they become obsolete with minimal costs, and that any format used to store data will still be readable in twenty years, to avoid costly and error-prone conversions.

So: it cannot simply be captured as a user story that will be selected to be implemented in a single iteration ^[c]. And it does require several layers of requirements, traceability to software and hardware components as well as among requirements from different layers. Simply rephrasing it in a “user story” style “As the person in charge of hosted data, I will be able to store all records for at least 20 years to comply with regulations” will not help. Nor will short iterations — unless they are specifically conducted to elaborate or validate the low-level requirements.

R2: “Records classified ‘Z’ shall be accessible only to selected people directly connected through the intranet, without the possibility to copy or print them”. Such a requirement must be refined into lower level requirements concerning authentication features of the software, but also the underlying components and layers, down to the operating system, infrastructure and possibly the physical connections between the intranet and the internet. Once again, there is a real need for layered requirements, and corresponding requirements traceability — at least if the system is to be maintained.

Another important point is the fact that such a requirement, even if satisfied at a given moment, cannot be considered as “implemented” or “done” after an iteration, since it can be violated later by an increment — e.g. requiring more disk space or using a non-standard technique for storage, thus missing R1, or introducing a breach in security, thus breaking R2.

The reader will find in ^[4] a real example where late discovery of dependencies and non-functional requirements in an agile project was an issue.

“Value on the right”: Why requirements and requirements management are still necessary in agile development

The above examples are related to scalability, life expectancy and security. Such requirements are frequently called “non-functional” requirements, subdivided into “constraints” and “quality requirements” ^{[5] [6]}.

^[3] does mention them, but none of the proposals made to handle them is fully satisfactory. SAFe ^[7] — Scaled Agile Framework — calls them “NFR” and proposes storing them in a dedicated place, as constraints that apply to the backlog as a whole, and may constrain zero, some or many backlog items ^[8].

• Such a requirement is typically not “implemented” in one place, and cannot be allocated to a dedicated user story.
• Conversely, if the requirement is forgotten, any user story will potentially violate the requirement (for example, introduce a breach in security, or increase storage needs).
• Some allocation to individual components may be required to determine the exact values of component requirements in lower layers. For example, bandwidth, CPU or storage available for one functionality may depend on what is left by another one. Thus, in an agile approach, it may happen that one or more iterations are needed to determine what is used by some critical functionality, and what remains for future increments to use. Typically, one needs to manage the usage of shared critical resources by each iteration, functionality and component.
• Such requirements cannot be verified at the end of one iteration. Instead, they may have to be verified continuously, iteration after iteration, each time a user story with potential impact on the requirement’s satisfaction is implemented.

We have used two quality requirements as obvious examples, but the same situation can also occur for functional requirements. For instance, in some applications I use, each individual function works in a satisfactory way, but I have to go back to the home screen and to navigate elsewhere to perform certain operations on an object, though it is currently displayed on the screen: this particular path was not identified in a user story (is it possible to find them all?); however, a navigability requirement ^[d] could have stated that all objects displayed on a screen can be clicked or tapped to trigger applicable functions from any screen. And such a generic requirement, of course, would have been a constraint potentially applicable to all the user stories in the backlog. A requirement that the application is usable by color-blind people ^[e] could also be violated at any point in time; you can never mark it as “done”.

The agile spirit brought to Requirements Engineering

We plan to dedicate another paper — at least — to this topic, but at this stage, we give a few clues on how to perform requirements engineering in an agile context, on what it means “to do it differently”.

Since we want to preserve all the benefits of agility, we do not want to impose that a complete set of frozen requirements is available before allowing development ^[f]! Thus, new requirements can be discovered and existing requirements modified or dropped at any point in time, e.g. during the demo of a release. Actually, it can even be the goal of a specific sprint to clarify a given requirement, to determine acceptable values, or to check its feasibility — in XP and SAFe, a sprint may include so-called spikes ^[9] which increase knowledge about a certain concern and, in my view, can produce new requirements and alter existing ones ^[g].

In other words, a key difference between waterfall and agile development is that requirements can sometimes be an output of development, in particular of early iterations.

Another point is that requirements, though they are traditionally published in thick specification and design documents, do not have to be published that way ^[h]: like user stories, they are just elementary items that can be managed appropriately, in a requirements repository, next to the backlog.

Last: of course, user stories do contain a number of more or less implicit functional requirements that do not need to be extracted and managed separately, since attached test cases may be enough to detail the intent. Only some requirements, those that cannot be captured in user stories and implemented in a single sprint — noticeably non-functional requirements — have to be managed in a repository of their own.

What questions should you ask yourself?

The need for a set of requirements, managed alongside the backlog and its user stories, may depend on several factors, such as:

• Scaling – What is the size of the team? What is the number of teams? Do you practice scrum of scrums? If so, it may be useful to make explicit those requirements that are shared between teams, perhaps uncovered by one team and impacting others (such as interface requirements), or requirements to be met collectively, possibly implying allocation.
• Technical complexity — What is the size of the system? Does it imply multiple technologies (e.g. a database, a sophisticated user interface, networking…)? Is it “pure software”, or do other elements such as infrastructure (hardware, network) play a key role in meeting customer needs? If so, you may also need to trace requirements to several components.
• Life expectancy — Is your system expected to have a short life? Or is it supposed to be maintained for years? Will it be maintained only by the people who initially developed it, or is it likely to involve a totally different team? It is worth asking yourself whether requirements that can remain implicit during development should not be remembered in the future.

Conclusions

Are user stories and requirements different names for the same thing?
YES and NO. User stories do correspond to one or more functional requirements. However, user stories can be estimated, selected for implementation in a sprint, and validated at the end of a sprint, whereas some requirements (and particularly non-functional requirements) may constrain more than one user story, and therefore have to be verified each time a user story potentially impacts compliance with the requirement.

Are formal, managed requirements and traceability still needed in agile development?
YES, at least sometimes, for complex systems, large teams and systems with a long life expectancy.

Is requirements management executed differently in agile and waterfall approaches?
YES, since it must be executed in an agile way, concurrently with development, rather than producing a frozen baseline prior to development, and then managing changes; early sprints are used to elicit, refine and validate requirements, and requirements are sometimes the output of an iteration rather than an input.

• [a] Preferably physical proximity, at least frequent contacts with adequate technical means.
• [b] « Avec l’avènement des méthodes agiles, on ne parle plus d’exigence, l’élément central devient la story ».
• [c] It is worth noting that some authors ^[10] insist on the fact that in Scrum, the product backlog contains items, which may be user stories or other items. However, as far as we know, they do not address topics such as the need for requirements allocation to components, traceability, and other essential aspects of requirement engineering.
• [d] To be more precise: navigability can arguably be considered as a class of quality requirements, but it potentially constrains all functional requirements.
• [e] Same remark: accessibility is a class of quality requirements constraining functional requirements.
• [f] We must clarify one point: the intent of a waterfall approach is to have, as much as possible, a set of validated, frozen requirements before starting developments… but “as much as possible” is important! Even in a strict waterfall approach, changes happen. The key difference is that in a waterfall approach, any change that occurs in the development phase is handled by a specific change management process, with formal impact analysis, whereas in an agile approach, changes are welcome — at least, according to the manifesto ^[1]! Whether you follow a strict waterfall, iterative or agile approach, the requirements management process spans from the very beginning to the very end of the development; actually, it even continues afterwards, during acceptance, then deployment…
• [g] This can also happen in a waterfall approach, but less frequently, through prototyping for example. I think of prototyping as a bubble of agility in a waterfall process.
• [h] Though documentation is not always superfluous…

References and Literature

• [1] "Manifesto for Agile Software Development," 2001. [Online]. Available: agilemanifesto.org/.
• [2] R. Grau and K. Lauenroth, "Requirements Engineering and Agile Development - collaborative, just in time, just enough, sustainable," 2015. [Online]. Available: www.ireb.org/content/downloads/20-requirements-engineering-and-agile-development/reandagile.pdf.
• [3] C. Aubry, «13.6 Améliorer l'ingénierie des exigences,» chez SCRUM - Le guide pratique de la méthode agile la plus populaire, Dunod, 2010, p. 176.
• [4] G. Rogers, "How agile can Requirements Engineers really be?," March 2014. [Online]. Available: re-magazine.ireb.org/issues/2014-3-gaining-height/requirements-engineers/.
• [5] Wikipedia, "Non-functional requirement," [Online]. Available: https://en.wikipedia.org/wiki/Non-functional_requirement.
• [6] M. Glinz, "A Glossary of Requirements Engineering Terminology," May 2014. [Online]. Available: www.ireb.org/content/downloads/1-cpre-glossary/ireb_cpre_glossary_16_en.pdf.
• [7] D. Leffingwell, "Scaled Agile Framework 3.0," 2015. [Online]. Available: scaledagileframework.com/.
• [8] D. Leffingwell, "Nonfunctional Requirements Abstract," 2011. [Online]. Available: www.scaledagileframework.com/nonfunctional-requirements/.
• [9] D. Leffingwell, "Spikes Abstract," [Online]. Available: www.scaledagileframework.com/spikes/.
• [10] P. Deemer, G. Benefield, C. Larman and B. Vodde, "The Scrum Primer: A Lightweight Guide to the Theory and Practice of Scrum (Version 2.0)," [Online]. Available: www.scrumprimer.org/.