Eliciting and Documenting Requirements (BCS)

Key ideas#

Start from terms of reference: OSCAR#

Before eliciting anything, the BCS authors want clear terms of reference. Their mnemonic OSCAR covers Objectives, Scope, Constraints (budget, time, standards), Authority (who settles conflicts between requirements) and Resources. Without them, requirements drift away from what the business is trying to achieve.

Who is involved#

On the business side: the sponsor (agrees the terms of reference, provides resources, signs off the requirements, arbitrates conflicts), domain experts, and business users. An external domain expert brings industry practice but may not know the company’s culture or politics and may be seen as an outsider. On the project side: the project manager, the business analyst and a developer, who checks technical feasibility and can build prototypes.

Tacit knowledge#

The book draws on Michael Polanyi’s observation that people know more than they can tell. Forms of tacit knowledge to watch for:

• Skills so practised they are automatic and hard to describe.
• Taken-for-granted facts an expert never mentions because they seem obvious. These surface at acceptance testing or after go-live, when they are expensive.
• Front story versus back story: people describe the tidy version of their work. “Everything runs smoothly” is a cue to check the numbers.
• Imagining the new: hard without a prototype to react to.
• Different norms: the book tells of an explorer who pointed at a mountain to ask its name and recorded the local words for “your finger”.
• Expert intuition and organizational culture, including communities of practice with their own unwritten rules.

To surface it, BCS suggests four approaches: apprentice (shadowing, or protocol analysis, where the expert thinks aloud while working), observe, recount (stories and scenarios) and enact (prototypes and scenario role-play).

From list to catalogue#

Raw requirements first go into a simple requirements list: requirement, source, comment. The analyst then passes the list through filters:

• Categorize each requirement.
• Merge duplicates and separate overlaps.
• Split compound requirements so each states one thing.
• Check necessity: it must support the project objectives and address a problem, not a symptom.
• Check technical, business and financial feasibility.
• Resolve conflicts by negotiation, escalating to the sponsor if needed.
• Remove disguised solutions: a requirement states what the business needs, not how to deliver it.

Each surviving requirement should be clear, concise, consistent, relevant, unambiguous, correct, testable and traceable. BCS recommends the form actor + verb phrase + object and a final SMART check.

Four categories#

• General: business constraints, policies, legal, branding, cultural, language and business continuity requirements.
• Technical: hardware, software, interoperability.
• Functional: data entry, data maintenance, procedures, retrieval (reports and queries).
• Non-functional: speed, security, access, backup and recovery, archiving, maintainability, availability, usability and capacity. The authors warn that these are often postponed or treated superficially, and that this causes many real failures.

General requirements often break down into the others: a data protection law becomes security levels (non-functional) and access rules (functional).

Document, validate, manage#

The BCS requirements document has six parts: introduction and background, business process models, function models (context and use case diagrams), a data model, the requirements catalogue, and a glossary.

Validation brings together the sponsor, requirement owners, a domain expert, developers, testers and the project office. Each requirement ends up accepted as is, accepted after minor changes, or sent back for rework and another review.

Priorities use MoSCoW from DSDM Atern: Must have (in the first increment), Should have (may slip briefly), Could have (dropped first if time runs short) and Won’t have this time.

Management means tracing each requirement backwards to its origin and forwards to what became of it, plus configuration management: versions 0.1, 0.2 for drafts, 1.0 at the validated baseline, 2.0 and later after approved changes.