 Author: Doug Akers
The main benefit of today’s Agile development methodologies such as Scrum or XP is the promise of delivering more in a shorter period of time and the value derived from having the flexibility to adjust your course mid-way through a development effort. But does this type of approach allow for requirements management? Is RM necessary given the shorter development windows – sprints, milestones, stories, whatever you call them?
Well -- does the need to deliver what the requirement originally requested go away? Does the desire to control change to the requirement go away? Of course not, and neither does the need for requirements management under these newer methodologies. The nature of RM will change, certainly, but the fundamental principles will not.
Reading
the trade press today and listening to some of the industry experts I find
myself wondering whether the term requirements management really means what
people think it means. The term ‘requirements management’ is being used to
describe a whole slew of different processes, tools, capabilities that have
absolutely nothing to do with managing requirements – which is probably the
contributing factor to some believing that RM has no place in an Agile world.
Within an
Agile environment, let’s take Scrum as an example, you need the ability to
define an overall requirements backlog or requirements pool which houses all
outstanding requests. Sounds very much like a “repository” of requirements to
me. The job of a Product Manager would be to constantly sift through that pool of requirements to identify candidates for
a given project or release. Project and Development Managers draw requirements
from this “pool” and use them in
scheduling individual sprints for that release. Requirements management
doesn’t go away under this methodology - it is just as important to ensure that
the requirement is met, tested, and controlled in terms of change over the
shorter development periods that these methodologies represent. A requirements management solution offers a
repository for requirements – a place to store the pool of requirements from
which each sprint is pulling from, and with inherent workflow capabilities, an
RM solution can bring forth the visibility necessary to ensure that
requirements are prioritized appropriately, reflect the current needs of the
business and are adequately scoped to enable the engineers to design and
develop.
What the Agile
methodologies are also doing is that they are forcing requirements to be
decomposed much earlier in the lifecycle such that their scope can be
understood and mapped to a schedule. We find ourselves moving away from a
system of Business Requirements documents tracing to Technical Requirements
documents tracing to System Requirements documents to one where the Business,
Technical and System requirements for a given feature or request are fully
defined and become the new Requirements Document from which development builds the system. It is taking the
horizontal aggregation of requirements and flipping it into a vertical
decomposition of features. The project or release is defined by several self
contained requirements documents for each delivered feature rather than a
series of decomposed requirements documents.
Under this
environment the Development and Test (QA) teams have greater visibility into
the entire request from the business level through to the system level and can
make design and test decisions armed with that knowledge. Furthermore,
requirements traceability becomes about how these requests and the features
themselves relate to each other rather than how the high level requirements are
decomposed into lower level requirements.
All that
said, the requirements within these documents still need to be managed – scope
and change to them needs to be controlled and more importantly communicated –
and they still need to be linked to the rest of the application development
lifecycle - the designs, the test cases and the source code. See Brad
Appleton’s article exploring the need for traceability and transparency
in Agile development in his article - "Lean Traceability" (see http://cmwiki.com/AgileSCMArticles).
Remember, software
methodologies need to be applied in a way that matches the strategy of your
business. Whether Waterfall, Iterative, Agile or some combination of all of
them, you still need to define what your customer wants, even when they change
their minds (and they will!), -- you need to know what you are building and how
to adapt to those changes. In the end, you need to be able to match the
deliverable back to what the customer originally asked for, and this requires a repository and change
management for requirements, with traceability over the requirements throughout
the lifecycle – sounds like RM to me.
Trackback(0)
Comments 
Write comment
 |
Requirements Articles 
TrackBack URI for this entry
Subscribe to this comment's feed
