Rodolphe Arthaud

An “agile” lifecycle for requirements

When requirements and the product are elaborated concurrently

In a previous article ^[1], we claimed that at least in certain circumstances, for certain types of systems, the requirements management discipline is still necessary in an agile framework. “But what is the impact of agility?” we asked. Should requirements management be done differently, and how? This article explores the necessary changes to the lifecycle of requirements in the agile framework.

A starting point: Scrum lifecycle for user stories

In Scrum, the product to be developed is described by the backlog, a set of items — generally user stories, but not necessarily; backlog items are selected according to priorities for implementation in successive iterations — which Scrum calls sprints. According to ^[2], a user story in Scrum goes though the following states:

Created → Accepted → Estimated → Planned → Ongoing → Done

This is only the nominal path; this simplified view does not represent all the possible sink states, nor the loops that may occur: items that are “Created” but never “Accepted”, “Ongoing” stories that appear not to be feasible within constraints when one attempts to implement them, requirements that are found to be not so useful or not usable once developed, etc.

We add two superstates to highlight two phases: Maturing (the requirement or user story is being elaborated and analyzed), and Selected (it is actually implemented in the product). We also add states Issue and Dismissed to cope with refusal from stakeholders and defects not corrected in the current iteration. We obtain the following diagram:

Proposed changes to this lifecycle

We are not fully satisfied with the initial proposal presented in Figure 1. In this section, we will expose our reservations and propose various improvements.

The sequencing of states should not be so rigid

Developments should sometimes start with immature requirements to produce a demonstration of the proposed feature and to collect feedback to validate or improve the initial requirements — and this is an essential principle of agile approaches. Quick development is, then, a particular requirement elicitation technique, and a requirement analysis and validation technique as well: the validated requirement is then the result of the development, rather than a precondition. It makes prototyping a more frequent practice than in the linear approaches ^[b].

In some cases, starting to develop something is even the best way to check ideas, to verify feasibility or to obtain better estimates. This is very much a part of the agile attitude, and was formalized in XP and SAFe ^[3] as spikes ^[4]: development to gain knowledge. Thus, our agile lifecycle should sometimes allow a requirement to be “Planned”, then “Ongoing”, before being “Accepted” or “Estimated”.

Thus, our agile lifecycle should support “develop to specify” as well as “specify to develop”.

“Estimated” should not appear as a state for customer requirements or user stories

Customer requirements or user stories are statements of the problem to address, and development costs result from activities needed to develop the solution. Taking a shortcut from problem to solution, then from solution to activities, is certainly applicable to simple systems, but not to more complex ones in which architecture and generic components represent a large amount of the work to do, and that do not directly relate to user stories.

Some requirements should never be considered as “done”

In a previous article ^[1], I explained why, at the end of an iteration, some requirements should not be marked as “done”, even after they have been verified successfully. Most examples I found of such requirements are non-functional requirements, i.e. quality requirements and constraints. SAFe calls them NFR and manages them in a dedicated place, as items that “may constrain zero, some or many backlog items” ^[5]. ^[6] also mentions non-functional requirements (§2.6) and recommends conducting “End of Lifecycle Testing” (§3.5) before each release.

I prefer calling them “neverdone” requirements, because not all non-functional requirements fall into this category, and because I can think of some “neverdone” functional requirements.

In short, neverdone requirements are requirements that could easily be undone in a future iteration and must be verified before each delivery. While this may not be a concern in a pure waterfall approach, because all requirements are implemented together, then shipped together after a global, complete verification, it may become one for agile approaches with multiple development iterations and, more importantly, multiple deliveries following partial verifications.

Thus, we want our agile lifecycle to allow a special treatment for these neverdone requirements ^[c].

Revised lifecycle for requirements in an agile development approach

Our expectations for an “agile lifecycle” for requirements

Our revised lifecycle must satisfy the following requirements:

1. It shall of course be possible to follow the “classic” way: to start developments from Validated requirements, i.e. after checking that the requirement is well-formed, desirable, feasible, verifiable, etc.
2. It shall also be possible to start developments from immature requirements, and to obtain Validated requirements as a result of development and verification of the product against the requirement.
3. It shall be possible to prevent certain requirements from reaching the state “done”.

Formalization as a UML statemachine

The principle in Figure 2, below, is to consider requirements maturation and development as parallel, interacting processes, rather than sequential phases.

For readers not familiar with UML statemachines, the diagram can be read as follows: the state Considered runs three nested statemachines in parallel. The actual statemachine is the product of three statemachines: Maturity status × Implementation status × Lifecycle policy. A requirement in state Considered is simultaneously in one substate of each statemachine. For example, the initial state of a requirement, starting from the left, is (In Progress; Not Implemented; Undetermined).

Note that not all combinations of states are valid (see also Practical implementation in a requirements repository, below), but our intent is to illustrate several paths that developments can follow, particularly — but not only — in agile approaches. Let us review all states and substates in more detail…

Maturity status

The actual substates can be adapted to the requirements validation process of each organization or to the specific stakeholders of a project.

• In Progress: The requirement is being worked on by its originator(s).
• Proposed: The requirement is considered final by its originator(s), and proposed for review.
• Validated: The requirement is considered to have all the required qualities; it is desirable, feasible within constraints, verifiable, etc.
  In a pure waterfall approach, this is a precondition for starting development. However, the Validated requirement may also be the result of a preliminary implementation, used to evaluate the feature, the technical solution, to determine reachable performance… This will be the case when prototyping is used in a waterfall approach, or spikes in an agile approach such as XP or SAFe.
• Issue: Something prevents using this requirement until the issue is addressed. The issue may be raised in the maturation process (e.g. in a review), but it may also be the conclusion of a first attempt to implement the requirement, demonstrating it is not feasible within constraints, or not satisfactory in some way.

Implementation status

There too, the actual substates may need to be adapted to the implementation and verification process applicable within the organization, to follow the process imposed by the customer, and may depend on the technologies used to develop and verify a specific product or component.

• Not Planned: Not assigned to a specific release or iteration.
• Planned: Assigned to a particular release, iteration, or whatever is used to plan deliveries.
• To be Verified: Implemented, compliance of the product against this requirement must now be verified.
• Verified: The product was successfully verified against the requirement.
• Violated: Product verification against the requirement failed.

Note that it is possible to go through all these states even when Maturity status is Proposed or Issue, when implementation is used as a technique to make poor requirements evolve. Eventually, the requirement is rephrased, fine-tuned, according to the findings and measurements made thanks to actual software. Nominally, an implemented requirement must be finalized and marked as Validated to be also Verified: a product can be perfectly compliant with irrelevant requirements, but it should lead to dismissal of the requirement.

Lifecycle policy

• Undetermined: The policy applicable to the requirement is not decided yet.
• Backlog item: Once verified, the requirement can be shipped, it is considered non-volatile, and does not need any further re-verification before future releases of the product are shipped ^[d].
• Neverdone: Even if the product has been verified once successfully at the end of an iteration, compliance must be verified again before any future shipment. In an agile approach, this means before all deliveries deployed to customers. In a waterfall approach, it means that these requirements will have to be verified again in future projects producing new releases.

Done

Once compliance with a requirement has been successfully verified ^[e], if it was decided that the Backlog item Lifecycle policy applies to it, it can be marked as Done. It is no longer in the set of requirements to be implemented or verified (or backlog) — unlike the neverdone requirements.

Dismissed

The requirement was rejected, either when it was analyzed in state Proposed, or later, at implementation time, because of some issue that could not be addressed within constraints.

Figure 3 illustrates that this new representation captures two paths:

• the “classic” development path, in which a requirement or story is stabilized before starting development (a sprint or iteration in agile approach, the development phase in a waterfall approach)
• an alternative path, where development is used as a means to clarify or validate immature requirements, (XP spikes, mockups and prototypes in a waterfall approach)

The reader will find more examples at the end of this article in Appendix 1 — Selected examples of the multiple paths that a requirement can follow.

Practical implementation in a requirements repository

As complex as it may appear at first sight, the statemachine in Figure 2 can easily be represented by three attributes that are modified independently by the requirements manager as their status evolves:

• Maturity status = {In progress, Proposed, Validated, Issue, Dismissed}
• Implementation status = {Not Planned, Planned, To be Verified, Violated, Verified, Done}
• Lifecycle policy = {Undetermined, Backlog item, Neverdone }

This will of course allow irrelevant combinations such as (In progress; Verified; x) or (x; Done; Neverdone) and illegal transitions, but requirements management is executed by human beings supposed to understand the meaning of each attribute — not by a compiler. These attributes are solely used to record the status decided by authorized people, not for automation; thus complete formalization and automated control is superfluous.

Applicability to waterfall projects

It is interesting to observe that the statemachine in Figure 2, though it was revised with the intent to support agile practices better, is perfectly suitable in a waterfall context:

• The possibility to develop a feature to check its relevance, its feasibility, to select a technical solution or to refine estimates, before finalizing a requirement or a set of requirements also exists in the waterfall model — if not in the theoretical one, at least in actual practice: it is called prototyping!
• The concept of neverdone requirements, proposed for agile developments, because of the numerous iterations and multiple deliveries that can impact previously satisfied requirements , also applies in a waterfall approach at a lower frequency: neverdone requirements are those that you decide to verify again in future projects that will produce new releases of the product.

Readers are invited to read Appendix 2 — What lifecycles do not show about agility for a development on the differences and similarities between waterfall and agile approaches from the perspective of requirements and their respective lifecycles.

Conclusions

We first examined the lifecycle for Scrum user stories and proposed to modify it
: first, to support some key aspects of agility, particularly the “develop to specify” path; second, to introduce the concept of “neverdone” requirements, those that cannot be managed in the backlog. Last, we proposed a general lifecycle for requirements, applicable to backlog items as well as neverdone requirements, supporting both “specify to develop” and “develop to specify” paths.

Appendix 1 — Selected examples of the multiple paths that a requirement can follow

Classic, nominal path for a backlog item or a requirement in a waterfall approach

1…3: The requirement follows the usual maturation process, and is eventually planned.

4, 5: Once Validated, it is implemented (with all other requirements selected for the release, in the case of a waterfall approach; with a few other requirements, in the case of an agile approach).

6, 7: After checking that the requirement is not a “neverdone” requirement, it is marked as done.

“Develop to specify” path, for a spike or a requirement validated through prototyping

1…3: The requirement is first elaborated, but cannot be validated because of doubts regarding its relevance, its feasibility or its verifiability. While its Maturity status is Issue, it appears that trying to implement the requirement will be the best way to finalize and validate it, or to reject it. It is therefore planned, though it is (or rather, because it is) immature.

4, 5: The requirement is implemented in actual code, the code is verified against the requirement, which is eventually considered Validated — possibly after modifications to reflect results of the experiment.
6, 7: After checking that the requirement is not a “neverdone” requirement, it is marked as done.

Classic, nominal path for a neverdone requirement

1…5: This path is identical to the nominal path for a backlog item…

6: … except that once it is marked as “neverdone”, it cannot be marked as “done”. Thus, it will have to be checked again when the product is modified.

Ideally, traceability links establish a relationship between this requirement and stories in the backlog that may violate the requirement later. Similarly, traceability links to components will trigger this requirement’s verification when they are touched.

New sprint in an agile approach, new release in an agile or waterfall approach

7: When a new iteration is executed, the requirement is put back to the state To be Verified. This may be because a specific story is implemented, because a specific component is modified (assuming this story or this component have been identified as risks to alter compliance with the requirement), or simply because this requirement is in the goals of non-regression testing.

8: It may happen that the requirement is no longer satisfied in this new release, because it was undone by the modifications made in this iteration.

9: After corrections in the code, the requirement is To be Verified, again.

Appendix 2 — What lifecycles do not show about agility

Comparison of waterfall and Scrum lifecycles for requirements

A classic waterfall approach — not describing prototyping and neverdone requirements — could be represented as follows:

This description, largely inspired by ^[7], will not be discussed in detail; it is only provided to highlight some particular points. What is illustrated in Figure 4 is that we have two main, sequential phases ^[f]:

• a first one (corresponding to the state here named Maturing) is dedicated to requirements elaboration, refinement and validation, resulting in a subset of validated requirements, candidates for implementation;
• and a second one (corresponding to the state here named Selected) in which a selection of validated requirements is implemented and verified.

During phase I, all requirements are being worked on, and none is being implemented; their statements evolve to reach their “ideal” formulation and values, so as to meet customer expectations and to be realistic, given constraints of all kinds. In a waterfall approach, the end of this phase is signified by a project milestone authorizing developments to start.

During phase II, the requirements should ideally not change. When a requirement is added or modified in this phase, this is formalized by a change request, initiating a potentially costly impact analysis, possibly causing heavy rework. The intent of the waterfall approach is precisely to try to avoid that situation as much as possible ^[g]. A core principle of a waterfall approach is that most requirements should be identified and validated (frozen) at a given milestone, before allowing developments ^[h]. As suggested by the two words “ideally” and “most” in the preceding sentences, changes will in fact happen. We have not modelled here the management of change requests, which is handled separately, since a change request may concern a requirement in any state.

Compare Figure 4 with Figure 1. Lifecycle of a backlog item in Scrum: both look very similar, though one is meant to describe the lifecycle of an agile user story, and the other the lifecycle of a “classic” requirement in a waterfall approach. How can that be?

Though Figure 1 and Figure 4 look similar, the meaning of the two superstates is very different. In a waterfall approach:

1. all requirements are first Maturing, then individually Validated or Dismissed
2. then, all Validated requirements are either Selected or Postponed
3. then, all Selected requirements are implemented, then Verified (or Postponed or Dismissed in case of failure without proper correction)
4. then, all Verified requirements are shipped together

On the contrary, in an agile approach as Scrum, presented in Figure 1,

1. there can simultaneously be requirements in all states, some can be already Ongoing or Done while other are still being Created
2. intermediate releases are frequently delivered and, if possible, actually deployed

Thus, one of the key differences between waterfall and agile approaches does not show in the lifecycle, because it relates to the management of sets of requirements, rather than individual requirements. The following two diagrams will illustrate this:

In a waterfall approach, as said before, all requirements are expected to be frozen before a certain project milestone (first red rectangle), which allows the beginning of development — and of the formal change management process. Ideally, no new requirement will be added, no requirement will be modified after the milestone is passed — and as the word “ideally” suggests, this will happen anyway, which is why a formal change management process is put in place. Eventually, all Verified requirements are shipped together (second red rectangle) ^[i].

In an agile approach, a few items from the product backlog are selected at each iteration — a sprint in Scrum. Only requirements implemented in the current iteration (the sprint backlog) are frozen, the product backlog continues to evolve until the end of the project. As a matter of fact, it is even intended to evolve as a result of past iterations. This is not seen as an exceptional situation to be avoided; on the contrary, agile principles favor the early collection of feedback on the demonstrator resulting from the first iterations.

In other words, in a waterfall approach repository, most requirements nominally move during the initial phase, but only a few are modified later as a result of issues; in an agile approach, they move individually, during the whole development: requirement maturation and product implementation are interleaved; requirements maturation goes on after development has started. There is no milestone to split the project in two phases, the “phase of changing requirements” and the “phase of development based on mostly stable requirements”; instead, the backlog progressively migrates from its initial state to its final state, as its items migrate individually, each in its own time, from Accepted to Done. After some iterations, Done requirements are taken from the backlog and integrated to a new release of the product (red ovals in Figure 6) which is shipped and deployed, as shown by the triangular shape of the "Shipped" (blue) area.

Maturity of individual requirements

Another difference that does not show in the statemachines is the amount of work needed to reach a certain level of maturity for a requirement or backlog item in both approaches. The arrows representing transitions between states may look the same in Figure 4 and Figure 1, but they do not have the same weight!

For complex systems, writing a good requirement with sound statement and values may require a considerable amount of work: modelling, simulation, mockups, multiple reviews… Writing a user story will generally require less work, and for the kind of systems built with agile approaches, it is often acceptable, or even preferable, to start implementation with relatively immature requirements ^[j], and to use the resulting demonstrator to refine and improve the initially poor requirements. This can only be the case when the cost of developing the product (coding) and describing it (writing requirements) are of the same order of magnitude.

---

• [a] In this UML statemachine — or state-transition diagram — most triggers have been omitted on transitions for the sake of readability, since they can be easily guessed by the reader.
• [b] This is recommended when the cost of developing a function is of the same order of magnitude as the cost for specifying — which should be a key criterion for choosing an agile approach.
• [c] One of our readers has rightfully stated that “all requirements are of kind neverdone”, i.e. products should be verified against all requirements associated to intolerable risks before each delivery. However, future iterations are likely to violate certain requirements — typically nonfunctional requirements, and negative functional requirements like “if , it shall not be possible to…”, but they will not accidentally “unimplement” an existing function. Future iterations may introduce bugs impacting those functions, which is entirely different. Non regression testing uses requirements coverage just as other coverage criteria (code coverage, interfaces coverage, etc.) to increase the probability to uncover bugs, not to check the requirements themselves. Indeed, most bugs found in testing (e.g. “crash after launch”) are not directly attached to a specific requirement violation. “Neverdone” requirements are those against which you specifically want to verify the product before each delivery, because they are both critical and easily violated by increments.
• [d] As explained earlier, non-regression tests may nevertheless use requirements coverage as a means to ensure completeness and to increase the probability to discover unknown bugs, but the intent is not to verify that the requirements themselves are still implemented.
• [e] Definition of Done in Scrum can go far beyond that, and include code reviews, various quality checks, etc. We leave it to the reader to determine which interpretation suits the context of the project better.
• [f] Actually, the two lower-level state machines in Maturing and Selected are often monitored using distinct attributes in a requirements repository, e.g. “maturity status” and “implementation status”, but the two attributes are not independent, since “implementation status” is applicable only to Validated requirements. For example, in [7], there are four distinct attributes, solely to monitor requirements status with respect to agreement, qualification, satisfaction and review! This is mainly because there are distinct stakeholders for the various phases in a waterfall approach, and because monitoring first focuses on maturity, then on implementation. This is not the case in an agile approach.
• [g] The fact that heavy documentation and formal approvals do not always succeed in guaranteeing that all requirements are identified and finalized, nor in preventing late changes and rework, is precisely what makes agility worth considering for lightweight projects, but even more when needs are unclear, and prototypes or spikes when there are concerns about the technical solution.
• [h] Prototyping is a noticeable exception to these principles, since it consists in doing some developments before requirements are stable: prototypes and mock ups are precisely means to elicit, to finalize and/or to validate requirements — or to abort unviable projects with limited consequences. Prototyping is a touch of agility in waterfall approaches.
• [i] Waterfall projects can also deliver intermediate releases without applying agile principles; there are multiple hybrid approaches, but in this paper, we will compare “pure waterfall” to agile projects for the sake of clarity.
• [j] We mean “acceptable” from a methodological point of view, but there can be other obstacles, like contractual considerations, as explained in ^[9] and ^[8].

References and Literature

• [1] R. Arthaud, "Is requirements engineering still needed in agile development approaches?," IREB, 2015-03. [Online]. Available: www.re-magazine.ireb.org/issues/2015-3-thinking-without-limits/are-requirements-still-needed/.
• [2] C. Aubry, «§5.3.3 Cycle de vie d'un élément,» chez SCRUM - Le guide pratique de la méthode agile la plus populaire, Dunod, 2010, p. 62.
• [3] D. Leffingwell, "Scaled Agile Framework 3.0," 2015. [Online]. Available: www.scaledagileframework.com/.
• [4] D. Leffingwell, "Spikes Abstract," [Online]. Available: www.scaledagileframework.com/spikes/.
• [5] D. Leffingwell, "Nonfunctional Requirements Abstract," 2011. [Online]. Available: www.scaledagileframework.com/nonfunctional-requirements/.
• [6] Scott Ambler Associates, "Agile Testing and Quality Strategies: Discipline Over Rhetoric," Ambysoft, 2014. [Online]. Available: www.ambysoft.com/essays/agileTesting.html#NonFunctionalRequirements.
• [7] M. E. C. Hull, K. Jackson and A. J. J. Dick, in Requirements Engineering, Springer, 2002, pp. 80, 167, 170.
• [8] G. Harde, "Agility and Obligation: Part 2: The Art of Assigning Software Development," 02 2015. [Online]. Available: www.re-magazine.ireb.org/issues/2015-2-bridging-the-impossible/agility-and-obligation-part-2/.
• [9] G. Harde, "Agility and Obligation: Part 1: Why Fixed Price Projects Fail," 01 2015. [Online]. Available: www.re-magazine.ireb.org/issues/2015-1-ruling-complexity/agility-and-obligation/.