Requirements gathering: a practitioner's reference

01 — Why it matters

What a requirements phase is actually for

Requirements gathering is not documentation for its own sake. It exists to produce agreement — between people who describe a problem in business language and people who have to implement it in configuration.

• Creates a shared understanding of the problem and the desired outcome
• Defines scope, priorities, constraints, dependencies and success criteria
• Converts stakeholder expectations into clear, testable requirements
• Provides the foundation for design, implementation, testing, acceptance and governance
• Reduces the expensive downstream changes caused by incomplete or misunderstood requirements

02 — Why identity is harder than most

IAM implements business rules, not software configuration

Most technology projects gather requirements about what a system should do. Identity and access management gathers requirements about what people are allowed to do — which is a policy question wearing a technical costume. The answers live with HR, with application owners, with compliance and with the business, and they frequently disagree with one another.

Identity requirements span people, applications, entitlements, approvals, policies, workflows, integrations and compliance obligations simultaneously. A single requirement about contractor access can touch the HR system of record, three applications, an approval chain, a certification cadence and a regulatory control.

When identity requirements are poorly defined, the failure modes are specific and familiar:

• Excessive access — people accumulate entitlements nobody intended to grant
• Provisioning failures — automation built on rules that do not match reality
• Audit findings — controls that cannot be evidenced because nobody defined the evidence
• Manual work that never goes away — the exceptions become the process
• User frustration — access requests that take days because the workflow was designed around an assumption

03 — The framework

The seven questions every access requirement must answer

Whatever platform is being implemented, an identity requirement is incomplete until all seven of these have a documented answer. Most late-discovered problems trace back to one of them being assumed rather than asked.

04 — The process

Eight steps, in order

The sequence matters. Skipping ahead to eliciting requirements before the current state is documented is the most common way a requirements phase produces a document that describes a system nobody has.

1. Identify stakeholders and business objectives Who has a stake in the outcome, who can decide, and what is the programme actually for.
2. Document the current state and pain points What exists today, what breaks, and what people work around. The workarounds are requirements in disguise.
3. Define the desired future state and use cases Concrete scenarios, not aspirations. "A contractor joins for a six-month project" beats "improve onboarding".
4. Elicit functional, technical, security, data and compliance requirements All five categories. Compliance and data requirements are the ones most often deferred and most expensive to retrofit.
5. Clarify business rules, exceptions, dependencies and constraints The exceptions are where identity programmes go wrong. Every "except when…" is a branch somebody has to build.
6. Prioritise and validate requirements with stakeholders Validation means the stakeholder confirms it, not that you wrote it down accurately.
7. Establish measurable acceptance criteria A requirement nobody can test is a preference. Acceptance criteria are what turn it into a requirement.
8. Maintain traceability through design, implementation, testing and acceptance Every requirement should be traceable to who asked for it and to the test that proves it was met.

05 — Who this applies to

A horizontal capability, not a specialist one

Requirements gathering is usually filed under business analysis, but it is performed by far more roles than carry the title. Anyone who translates business needs into systems, products, processes, controls or deliverables is doing it, whether or not it appears in their job description.

06 — What each role is gathering

Security, GRC and cloud roles

The same discipline produces very different requirement sets depending on who is running it. These five roles sit closest to identity work and are the ones most often brought into a programme late.

07 — What good looks like

What a sound requirements process returns

The benefits of doing this well are mostly the absence of things — the rework that did not happen, the change order nobody had to write, the audit finding that never came up.

• Faster requirements development — less elapsed time between kickoff and a usable baseline
• Lower consulting and project costs — fewer senior hours spent on elicitation and compilation
• Less dependence on scarce senior experts — the method carries the expertise, not one person's memory
• More consistent and complete documentation — the same standard on every engagement
• Reduced rework and implementation risk — fewer assumptions carried into build
• Improved stakeholder alignment — disagreements surfaced while they are still cheap
• Better solution design and configuration — decisions made from evidence rather than inference
• A repeatable foundation that improves with every engagement instead of resetting