Statistics: (1670 Views) (0 Comments) Print Posted: Tuesday, July 31, 2007 Categories: Requirements Analysis (BABOK KA), Agile Methods

In the last few years, the agile software development movement has created a paradigm shift in how we work to understand system requirements. Agile teams shape software systems using a collaborative process, with executable software at its heart and documents marginalised to a peripheral role. This creates a fundamental shift away from tools for managing requirements artefacts. Instead, we need tools that support collaboration and the gradual distillation of business rules into automated test suites.

Agile software development is a general descriptive term for an approach that is implemented by a number of different software development methods, such as XP, Scrum and DSDM. The common ground shared by agile methods is that they support the values and principles embodied in the Agile Manifesto [1]. Agile software development evolved in response to deficiencies with document-heavy waterfall development. It is useful to begin by outlining some of the limits of the traditional approach to requirements before moving on to the main subject of this article, Agile Requirements.

On traditional software development projects we talk about capturing the requirements -as if we are engaged in a hunt to cage some wild beasts that lurk in the jungle. What is actually meant by this phrase is a less exciting activity - producing documents, which specify a system in sufficient detail that software development can proceed by reference to these documents alone. If you cast your mind back and imagine all the requirements documents that you have ever read piled up, it is likely to be a hefty stack and the hours spent poring over those documents innumerable. Although, it is theoretically possible to capture my knowledge in a document from which the reader can extract the same knowledge without distortion, this may not be a practical or efficient way to communicate requirements for complex software systems.

In determining our process for developing software it is important to remember that the primary purpose of a development project is to deliver is a software system that generates value to a business. Models and documents are essentially by-products of the development; they do not generate value directly. If we are to optimize the flow of value from software development then we need to think seriously about eliminating process inventory and waste.

Author: Rachel Davies