Agile Requirements - Page 2

Rachel Davies, Agile Experience Ltd, UK, http://www.agilexp.com

Freezing

The traditional approach is to document the requirements for the whole system and then freeze the requirements to provide a stable base for implementation to proceed. This assumes that we can come to a complete understanding of the system before developing real code. Perhaps this is possible in simple or well-known domains but this is a risky assumption to make for complex software development projects.

This raises a fundamental question of whether the human brain is capable of building a virtual system in our imaginations that we can explore and document. In a traditional waterfall process, requirements documents are the culmination of an analysis phase, during which the problem space has been explored via abstract models. To make this task manageable, we break the system down into pieces. However, we still need to keep track of all the pieces so that we may compose a coherent system from them. The human mind has limited capacity for complex problems, it is to be expected that when working in the realm of abstract ideas, we may miss scenarios, stakeholders’ needs and functions that need to be supported by the system. It is not clear that we can we fully determine the system requirements without starting to develop some software to explore possible interaction patterns. In his book "Serious Play", Michael Schrage [2] suggests that we can only really determine what we want by interacting with a prototype.

Let’s contrast the traditional approach to requirements in software development with how we operate outside the software domain. For example, if we are investing in home improvements such as a new kitchen or bathroom – do we just place an order based on drawings and make no comment until the installation is complete? Most people would be keen to see samples of new fittings and retain the right to change their mind about some aspects as installation proceeds. We would naturally expect that, as the fittings are installed in situ, we are likely to spot some ergonomic issues that were not apparent from the original two-dimensional plans.

The final flaw with freezing requirements early is that we are developing the system for use in a changing world. Time does not stand still during software development, the world around us changes – new business opportunities may arise during the development. When we freeze requirements early we deny the chance to adapt the system to a changing context.

Agile lifecycle

The core of agile software development is building system features incrementally by working in a collaboratively. Agile methods are all built around a key assumption – we continue to learn about a system and it’s operating environment during the project. When we recognize that our understanding develops during the project then we realize that freezing requirements during early project phases will either cause rework or the delivery of a system that does not meet the customer needs. We need an approach to software development that can embrace change during the project. Agile methods iteratively evolve both requirements and the system under development by planning the development in short cycles (weeks rather than months). This is not a new idea [3].

When we develop the system incrementally then this allows the customer/user to try the software developed during the project rather than waiting until the end. Their feedback can be used to refine the system behaviour.

When we move to an iterative lifecycle, we lose the traditional waterfall phases: analysis, design, code and test. These activities now run in parallel. This has an impact on how we organise a project team. Rather than assembling specialist teams dedicated to waterfall phases with handover artefacts, it makes more sense to form a cross-functional project team; a team of individuals whose task is to shape and deliver a software system together. Business people are needed throughout the project to explain how the system under development will generate business value and support the user community through different scenarios. Technical people are needed throughout the project to translate those requirements into executable code and verify the system meets conditions of satisfaction.

Agile communication

When a team work on analysis and software development in parallel, this creates an opportunity to work with requirements in a different way. Specifically, we can consider other communication channels - we can open up dialog. Agile teams primary means of communicating requirements is conversation. The medium of conversation creates the possibility for information flow between all parties. The problems imposed by communicating via documents drop away.

When agile teams plan development, this done by the whole team in a workshop. If you listen in, you will hear conversation flowing around the group. The whole team are partners in this conversation. They discuss scenarios and development options to explore the requirements before development is planned. The beauty of exploring requirements through team conversation is that we develop a shared understanding and have the opportunity to offer our own ideas. Having a two-way conversation between business and IT and flushing out misinterpretation early may prevent developing code that has to be thrown away.

Stories

The difference is made clear in Extreme Programming (XP) [4]. The use of Stories is a primary practice of XP. An XP story describes a candidate system feature in language that is meaningful to both customer and developer. Stories have three essential parts: Card, Conversation and Confirmation [5]. Stories must be small enough to implement in a single development cycle (XP teams use a one-week cycle).. To support collaborative working, stories are written on index cards. Index cards provide a low ceremony way to document development plans. Each story card represents a conversation that has taken place. Automated tests are defined for each story, which are used to confirm that the system supports that story.

Other agile methods do not explicitly use stories but also emphasis that requirements descriptions need to be short and loose, the bare-minimum needed to plan development. Typically, requirements are listed as one line description maintained in a backlog in priority order. Features may be swapped in and out of this backlog and it is assumed details about each requirements will be determined as part of each development cycle.

Requirements specification documents are usually expressed in impersonal and cold language giving us "whats"without business motivation. This is quite different from the way we tell stories. Using story form we start by describing the context and give background to the players in the story. A story takes the players through a chain of events that communicates a desired outcome. A story breathes life into a limp requirement. Through the story, the listener grows to understand the pain experienced by the users and the burning need for the software – this can have a profound effect on motivation within the software development team. By discussing explicit situations and our reactions to them (via the system under construction) we can achieve a shared understanding. Understanding the big picture can help programmers to develop software solutions that are a better fit.

Page 1    Page 3   Click here to view the complete list of archived articles