Requirements Analysis & Specification

Analyzing & Structuring Raw Requirements

18 min Lesson 2 of 10

Analyzing & Structuring Raw Requirements

Requirements rarely arrive in a clean, organized form. A stakeholder interview produces a mix of wishes, complaints, workarounds, and assumptions — all bundled together in a stream of consciousness. Before you can write a single formal requirement, you must transform that raw material into something coherent. This lesson covers three tightly connected activities: deduplication, conflict resolution, and grouping. Together they turn noise into a structured requirement set that the whole project team can trust.

Step 1 — Collect and Surface Everything First

Before you can deduplicate or resolve conflicts, every requirement candidate must be visible. Gather the outputs of all your elicitation sessions — interview notes, workshop transcripts, survey responses, email threads, existing documentation — and list each distinct statement as a raw item. Do not filter yet; the goal is completeness. For a clinic booking system, your raw list might include forty or fifty items ranging from "the system must allow patients to book appointments online" to "I hate it when the system logs me out after two minutes".

Tip: Use a simple spreadsheet with columns: ID, Source, Raw Statement, Stakeholder, Priority (stated), Category (blank for now). Giving each raw item an ID from the start lets you trace it back to its origin even after heavy editing.

Step 2 — Deduplicate: Merge Without Losing Nuance

Duplication is the most common raw-requirement problem. In a logistics firm project, the warehouse manager says "the system should send an email when a shipment is delayed." The operations director says "drivers must receive automatic delay notifications." Are these the same requirement? Superficially yes, but on closer inspection they differ: warehouse manager → email vs. driver → possibly SMS or mobile push.

The deduplication rule is: merge only when the underlying need is truly identical. When two statements differ in audience, channel, or trigger — even slightly — keep them separate or create a generalised parent with two child requirements. Record the merge decision and the original source IDs so nothing is lost.

Common duplication patterns to watch for:

Same need, different vocabulary — "search orders" vs. "look up orders" vs. "find orders" (probably identical).
Same need, different scope — "export to CSV" vs. "export to Excel, CSV, and PDF" (the second is wider; do not silently discard the richer version).
Same feature, different trigger — "notify customer when order ships" vs. "notify customer when order arrives" (two distinct events, not duplicates).

Step 3 — Identify and Resolve Conflicts

Conflicts are inevitable when multiple stakeholders have competing interests. There are three kinds:

Direct contradictions — The finance team requires all transactions to be audited and immutable; the marketing team wants the ability to retroactively adjust promotional pricing. You cannot satisfy both as stated.
Implicit contradictions — The UX team specifies that the checkout flow must take no more than three clicks; the compliance team requires four mandatory consent screens. Neither team mentioned the other's constraint — the conflict only emerges during analysis.
Priority conflicts — Two requirements are logically compatible but cannot both be delivered in the current sprint or budget. This is a resourcing conflict, not a logical one, and is resolved through prioritisation (covered in Lesson 6), not through requirement editing.

Resolution process: (a) document the conflict explicitly — write both statements side by side; (b) identify the stakeholders who own each position; (c) schedule a short focused meeting with those stakeholders only; (d) record the agreed resolution and mark the conflicting raw items as Resolved — see REQ-047. Never resolve a conflict by silently deleting one side; the stakeholder who raised it will notice and trust will erode.

Warning: Do not try to resolve conflicts alone at your desk. An analyst who rewrites a requirement to eliminate a conflict without consulting stakeholders is making a business decision that is not theirs to make. Escalate, facilitate, and document.

The three-phase analysis pipeline: deduplicate, resolve conflicts, then group into a structured set.

Step 4 — Group Requirements by Theme or Capability

Once duplicates are removed and conflicts resolved, you have a cleaner but still flat list. Grouping organises that list so teams can reason about it, estimate it, and implement it in coherent chunks. There are three common grouping strategies:

By functional area — Patient Registration, Appointment Booking, Notification, Reporting. Natural for teams organised around modules.
By user goal (feature-centric) — everything a patient needs to book an appointment in one group, regardless of which technical module it touches. Natural for user-story mapping and backlog management.
By stakeholder — patient-facing requirements, clinician-facing requirements, admin requirements. Useful for validation: each stakeholder group reviews only their section.

For most projects a two-level hierarchy works well: a top-level theme (Appointment Management) containing a handful of sub-groups (Search Availability, Book Slot, Cancel/Reschedule, Waitlist). Avoid going deeper than three levels — the overhead of maintaining a deep hierarchy outweighs the benefit.

Worked Example: Online Store Checkout

Imagine you receive these six raw items from a checkout re-design project:

"Customers should be able to pay by card." (Marketing Director)
"We need Stripe for card payments." (CTO)
"The system must accept PayPal." (Customer Success Manager)
"Card payments must be PCI-DSS compliant." (Finance)
"The checkout page must load in under two seconds." (UX Lead)
"The payment page should be fast." (Marketing Director)

Analysis:

Items 1 and 2 — merge with nuance: the underlying need is card payment, but item 2 specifies an implementation detail (Stripe). Record both; flag item 2 as a design constraint to be validated, not a pure requirement.
Items 5 and 6 — true duplicate: merge into one performance requirement; keep item 5's specific metric (< 2 seconds) rather than the vague "fast".
Item 3 — no conflict with items 1/2; PayPal is additive. Keep as separate requirement.
Item 4 — non-functional requirement (compliance); group separately under Security & Compliance.

After analysis you have four requirements instead of six: Card Payment Support, PayPal Support, PCI-DSS Compliance, Checkout Page Performance — grouped into two themes: Payment Methods and Non-Functional.

Key idea: The goal of structuring is not to reduce the number of requirements at all costs. It is to eliminate redundancy and contradiction while preserving every distinct business need. A 30-item structured list is always better than a 50-item noisy one — but a 50-item structured list is better than a 30-item list that silently dropped something important.

Maintaining Traceability Through the Process

Every merge, split, and grouping decision must be traceable. When a formal requirement in your SRS says "REQ-012: The system shall send appointment reminders via email and SMS," the reader should be able to look up which raw items produced it (e.g., raw items R-04, R-17, R-23) and which stakeholders raised them. This trace is your audit trail and your insurance policy during scope disputes.

A simple traceability note in your spreadsheet — "REQ-012 derived from R-04 (Ward Manager), R-17 (Patient Rep), R-23 (IT Director) — merged because same notification event, channels combined" — takes thirty seconds and can save hours of argument months later.

Common Pitfalls

Over-merging — collapsing requirements that look similar but serve different users or contexts. Always check audience and trigger before merging.
Analysis paralysis — spending weeks on perfect grouping instead of making a reasonable decision and moving forward. Good enough and documented beats perfect and late.
Losing the original voice — rewriting raw statements so heavily during structuring that the original intent is obscured. Preserve the source verbatim in your traceability notes.