Business Analysis Notes

Requirements engineering

The Requirements Management Plan

4 min read · Updated

In short A requirements management plan (RMP) sets the rules for handling requirements on a project: how they are identified and traced, which attributes and statuses they carry, when baselines are set, and how changes are requested and decided. Write it early, keep it short, and make sure someone owns each rule.

Based on: IBM RUP Requirements Management Plan template; K. Wiegers, J. Beatty, Software Requirements, 3rd ed., ch. 27; Yu. A. Maglinets, Analysis of Requirements for Information Systems, lecture 7; D. Leffingwell, D. Widrig, Managing Software Requirements, ch. 31 and 34; IIBA, BABOK® Guide v3, tasks 3.3 and 3.4.

On this page

Key ideas#

Where it fits#

In RUP, the RMP describes how requirements are collected and changes controlled, and how the team works with the customer. In the BABOK® Guide, these decisions belong to two planning tasks: Plan Business Analysis Governance (3.3) and Plan Business Analysis Information Management (3.4).

Wiegers and Beatty divide requirements management into four activities: version control, change control, status tracking and tracing. Their warning is blunt: if nobody is named as responsible for these, they will not happen, and if “everyone” is responsible, they will not happen either.

What the plan decides#

  • Roles: who owns the requirements, who talks to the customer, who sits on the change control board (CCB).
  • Identification: how artifacts and requirements are named and numbered.
  • Traceability: which artifact types link to which, with a rule for each link. The RUP template uses a chain from stakeholder requests (STR) to stakeholder needs (NEED) and features (FEAT) in the Vision, then to use cases (UC) and supplementary requirements (SUPP). A typical rule: every approved feature traces to at least one use case.
  • Attributes: the RUP set is status, benefit, effort, risk, stability, target release, assigned to and reason. Wiegers lists more, such as origin, rationale, verification method and priority. Maglinets passes on Wiegers’ advice to start with no more than about five and add others when a real need appears.
  • Baselines: the agreed set of requirements the team commits to for a release or iteration. RUP typically sets them at phase boundaries.
  • Change control: how requests are submitted, analysed and decided, and who decides.

Statuses that tell you something#

Wiegers and Beatty offer a status set: Proposed, In Progress, Drafted, Approved, Implemented, Verified, Deferred, Deleted and Rejected. Use only those you need. Counts per status say more than a “percent complete” figure, which tends to sit at 90% for weeks.

For agile teams they cite Leffingwell’s story statuses (in backlog, defined, in progress, completed, accepted, blocked) and the burndown chart of remaining story points; a rise in it signals scope growth, not an error.

Change: assess the impact before saying yes#

Impact analysis, as Maglinets summarizes Wiegers, covers side effects (new features may slow the system unacceptably), the documents, models and code that must change, and the tasks and effort involved. Do it before anyone says “sure, no problem”. Wiegers offers “not now” (a later release) as a softer “no”; Maglinets adds asking “why?” to make the requester weigh the real benefit.

Leffingwell and Widrig separate external causes of change (the problem, users’ minds or the environment shift; the new system creates new needs) from internal ones (the right people were not asked; there was no change process). Requirements that slip in through unofficial channels, “leaked” requirements, can by their account reach half of a project’s scope. Their remedy: accept change, baseline, run every change through one channel, and record every request.

Practical details#

  • Manual versioning: without a tool, Wiegers and Beatty suggest “1.0 draft 1, draft 2…”, then “1.0 approved”, then “1.1 draft 1” for a small change or “2.0 draft 1” for a large one. Otherwise testers end up reporting approved changes as defects because they tested against an old spec.
  • Requirement problems go in a tracker: questions, missing, wrong or duplicate requirements. A whiteboard note gets wiped.
  • Explicit and implicit links: Leffingwell and Widrig note that some links follow from structure (63.1 belongs to 63). In a traceability matrix, an empty row or column signals something redundant, missing or misunderstood.
  • Two kinds of change request: an example plan from training materials separates new features from improvements to existing ones, and links detailed requirements back to the Vision’s features.

How to apply it#

  1. Name an owner for each of the four activities.
  2. Define artifact types, IDs and the traceability rules between them.
  3. Choose up to five attributes and the statuses you will actually use.
  4. Decide when baselines are set and who approves them.
  5. Write the change process: request form, impact analysis, decision body, how decisions are communicated.
  6. Say where requirement problems are logged.
  7. Track effort on managing requirements separately from developing them, as Wiegers and Beatty suggest, to see whether you invest too little or too much.

Template#

Template
# Requirements Management Plan: <project>

## 1. Introduction — purpose, scope, terms, references
## 2. Roles — requirements owner, analyst(s), customer contacts, change board members
## 3. Tools and repository — where requirements live; who has access
## 4. Identification — artifact types, ID formats, naming rules
## 5. Traceability — artifact chain, link rules ("each feature traces to at least one use case")
## 6. Attributes — up to five to start: name, allowed values, who sets each
## 7. Statuses — chosen set and the transitions allowed between them
## 8. Baselines — when they are set, who approves, how they are labelled
## 9. Change control — request channel, impact analysis checklist, decision body, notification
## 10. Requirement problems — where questions, gaps, errors and duplicates are logged
## 11. Reporting — status counts, burndown, change statistics
## 12. Deviations and training — agreed exceptions; who needs to learn the process
## Revision history

Sources and further reading#

  • IBM Rational Unified Process (RUP) document templates: Requirements Management Plan.
  • K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013, ch. 27 (management activities, status set, versioning, agile tracking).
  • Yu. A. Maglinets. Analysis of Requirements for Information Systems, lecture notes (in Russian). Siberian Federal University, 2007, lecture 7 (attributes, impact analysis, scope creep).
  • D. Leffingwell, D. Widrig. Managing Software Requirements: A Unified Approach. Addison-Wesley, 2000, ch. 31 and 34 (explicit and implicit tracing, leaked requirements, change process).
  • IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3, 2015, tasks 3.3 and 3.4.
  • Business analysis training materials (practice examples and templates): a filled-in example plan.