The Requirements Engineering Magazine appears quarterly. It is cost free and provides you with up-to-date articles reflecting the activities of the RE and BA community.
Simply sign up for being notified about new issues of the Requirements Engineering Magazine.
You may unregister at any time by sending a mail to firstname.lastname@example.org from the e-mail address which you have registered with.
When organizations come across agile approaches, they discover the following lines in the agile manifesto :
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 , “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?
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. , 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?
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  a real example where late discovery of dependencies and non-functional requirements in an agile project was an issue.
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”  .
 does mention them, but none of the proposals made to handle them is fully satisfactory. SAFe  — 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 .
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”.
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  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.
The need for a set of requirements, managed alongside the backlog and its user stories, may depend on several factors, such as:
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.