Improving Your Requirements Process

Key ideas#

Requirements connect everything#

The authors show requirements as an input to: - project planning: estimates, scope cuts, the choice of incremental delivery; - project tracking: gaps between plan and actual trigger change control; - change control itself; - system and acceptance testing; - design, code and unit testing; - user documentation: technical writers sit at the end of the chain and suffer first from late changes.

In one case they describe, a tester needed far longer than planned for a test plan because related functions were scattered across someone else’s specification. The authors also map what each stakeholder group contributes to and needs from requirements work, a useful checklist when you redesign the process.

Resistance and real commitment#

Expect objections: “we’re too busy to learn new methods”, “change control is a barrier”, “writing requirements is bureaucracy”. Answer them with the cost of not changing, such as rework caused by misunderstood requirements. Frame benefits as “what’s in it for us”: the team, the organization, the customers.

Management commitment shows in actions, not statements. Signs include managers who: - expect documented, reviewed and approved requirements before building starts, and review them themselves; - work with the business analyst (BA) on business requirements; - budget time for requirements work in project plans; - set up a working change policy; - fund training, books and tools, and give people time for the improvement work.

Four principles#

1. Improve step by step, continuously. Start with a few templates and the “low-hanging fruit”: problems everyone agrees need fixing.
2. People change when they feel pain. Real pain from past projects motivates more than pressure from above: schedules blown by underestimated requirements, rework from ambiguity, wasted testing, high maintenance costs, lost changes, unavailable customers.
3. Every change needs a goal tied to a business objective.
4. Treat improvement as a project, with a plan, resources and progress tracking.

The authors’ practical advice: don’t bite off more than you can chew, celebrate small wins, push gently but steadily, run one to three improvement initiatives at a time, and grow a group of enthusiastic allies.

Find the root cause first#

Ask “why?” repeatedly before choosing a fix; otherwise you try new methods at random. Causes nest. The authors’ chain: requirements were missed ← the analyst did not ask the right questions ← the people in the analyst role were never trained to elicit. The last one is the root cause and calls for training, not just a longer checklist. A fishbone (Ishikawa) diagram helps: the problem is the spine, categories such as process, people and project are the main bones, and successive answers to “why?” branch off them. By the Pareto principle, a minority of causes usually explains most of the trouble, so you need not fix them all.

The improvement cycle#

1. Assess current practices with a questionnaire and interviews. You will often find that real practice differs from the documented process, and that people disagree about “how we do it here”.
2. Plan improvement actions: a tactical plan for two to three months, with no more than about ten items, each with an owner.
3. Create, pilot and roll out new practices.
4. Evaluate the results against the target measures, then plan the next round.

A roadmap#

Put business goals on the right, improvement actions on the left, and milestones between them, delivered from left to right. Each milestone has an owner who writes the action plan for reaching it.