Enterprise Requirements Management
Enterprise Requirements Management entails taking the Requirements Management approaches we use for a single project, and adapting them to suit an enterprise view. The objectives of requirements management as we discussed on our Requirements Management page are:
- Managing the scope of the project (or iteration)
- Managing changes to requirements
- Managing risk
- Validating requirements
An additional objective of Enterprise Requirements Management is to ensure that requirements for all projects are consistent with each other, and aligned with the organisation's strategic objectives. Another objective is to allow requirements to be captured and held whilst there is, as yet, no project defined to implement them (This is often the result of legitimate requirements being discovered during the analysis of a project, but which are sooner or later deemed to be out of scope).
It is relatively straightforwared to adapt our existing Requirements Management practives to meet these additional objectives.
The first step is to allow all requirements to be managed collectively. This means that whatever tool or mechanism is being used to store the requirements must be scaled to cater for all the enterprise's requirements with an enterprise-wide categorisation scheme. It is important that requirements are able to be moved easily between projects, so this scheme must be project-independent. If you have a functional decomposition of the enterprise (see Enterprise Business Modelling), or some other enterprise-wide subject area categorisation scheme, then use that. Any scheme can be used so long as it covers the whole enterprise, is independent of projects and organisational structure, and can stand the test of time.
The second step is to provide a mechanism to link requirements to projects. This is an extension of the "Manage Scope" objective to allow requirements to be "drawn-down" from the enterprise pool into a project's scope. This is easily done by the addition of one or two additional attributes.
The third thing is to look at the "Stakeholder Needs" requirement type. All the (other) requirement types in the solution space describe the system to be built. These requirements are written in such a way that once the system has been built, they accurately describe the system. Similarly, Stakeholder Needs should describe a standing need that the stakeholders have, and always will have. We then augment the description of the need with a description of the current and proposed solutions. Sometimes, however, stakeholder needs are not written this way, but are written as a point-in-time description of something that we wish to change. Whilst we may get away with this on a single project, it is not workable in an enterprise requirements managment scheme. It is important that the Needs be able to stand the test of time. We emphasise this by naming them "Business Needs". A single heirarchy of Business Needs is maintained and preserved in our enterprise requirements repository, and the feature requirements of the various systems are traced to them. A useful attribute for Business Needs is a "Target Project" or "Target System" which identifies the current or proposed solution to the need. The highest-level needs in the heirarchy should be easily identifiable as directly supporting the organisation's strategic objectives. It desired, this can be made explicit by defining a "Strategic Objective" requirement type, and tracing the top-level Business Needs to it.
The pool of as-yet unsolved business needs, and unassigned features can be useful in identifying and scoping new projects.
