What Is Requirements Gathering? Process, Techniques and Best Practices

Requirements gathering is the work of finding out what a product or system must do, and under what conditions, from the people who will use, build, test, certify and pay for it. It turns what those people need into written requirements a team can design to and verify against.

If your team misreads a need at this step, you can write the mistake into the design, the test plan and the supplier’s statement of work before anyone checks it with the person who had the need. Jama Connect® is a web-based requirements management and traceability platform for complex, regulated product development. Because Jama Connect links each need to the requirement written from it, a team can check the built product against that need during validation.

This chapter covers the eight steps, the techniques, what changes when medical device, airborne or automotive rules apply to your product, the mistakes that cause rework and two worked examples (a portable medical device and a component noise limit).

What Is Requirements Gathering?

Requirements gathering is also called requirements elicitation, capture, discovery or acquisition, and the IEEE Computer Society’s Guide to the Software Engineering Body of Knowledge (SWEBOK) V4 calls it elicitation. The Business Analysis Body of Knowledge (BABOK) Guide from the International Institute of Business Analysis (IIBA) defines elicitation as drawing out information from the people a planned change affects, and from other sources, to understand business needs, requirements and constraints.

Gathering is the first activity of requirements development, which SWEBOK V4 describes as “reaching an agreement on what software is to be constructed.” Analysis, specification and validation follow it, and requirements management then keeps “that agreement over time.” The 2011 edition of ISO/IEC/IEEE 29148, since revised, describes these activities as applied iteratively and recursively.

Karl Wiegers, principal consultant at Process Impact, argues that gathering is too narrow a word. On SE Radio episode 604 he said, “The term requirements elicitation is broader and more accurate,” and “You can’t just ask people what their requirements are and expect to get a useful or very complete answer.” For more on drawing needs out of people, read the sibling chapter on requirements elicitation for product teams.

Why Does Requirements Gathering Matter?

The cost to correct a requirements error rises steeply with the phase in which it is found. A NASA study estimated that rise phase by phase, from design through build and integration to operations. The study modeled systems comparable to a large spacecraft, a military aircraft or a small communications satellite.

Late fixes are one cost, and rework is another. Boehm and Basili estimated in 2001 that software projects spent about 40 to 50 percent of their effort on avoidable rework.

Reviewers have difficulty finding the errors that cause that rework, because many of them are requirements nobody wrote down. SWEBOK V4 attributes incompleteness in a requirements set to inadequate elicitation. Wiegers said missing requirements “are perhaps the hardest kind of errors to find because they’re not there.” A reviewer can only check what’s on the page, so identify an absent requirement while you’re still talking to the people who would have voiced it.

What Are the Steps of the Requirements Gathering Process?

You can run requirements gathering in eight steps, from agreeing on scope to handing off a traced baseline, and steps 2 to 5 repeat. The steps are:

1. Scope and sources: Agree on what’s in scope, and list who must be heard and which documents, regulations and existing systems hold requirements. Expect more contributing teams and reviewers than your first list shows, and find the decision makers before their first major decision.
2. Elicit needs: Ask what people need to do before asking what they want built. An order-entry clerk should describe taking a phone order before proposing the screen she wants. In Wiegers’ words, “In almost every case, a focus on usage is more likely to yield accurate and valuable understanding of requirements than a focus on products and their features.”
3. Analyze and resolve conflicts: Consolidate what you heard, find contradictions between groups and check that each need is feasible.
4. Write the requirements: Follow the NASA Systems Engineering Handbook’s conventions of one “shall” per sentence, a rationale beside each requirement and as few to be determined (TBD) values as possible.
5. Confirm the results: Take the written set back to the people the needs came from. Check it for accuracy, consistency, errors, omissions, conflicts and ambiguity.
6. Prioritize: Rank by value, risk and cost so the team knows what to drop first when the schedule or budget changes.
7. Approve and baseline: A baseline is a reviewed, agreed snapshot committed to a specific release, and the requirements baseline chapter recommends agreeing on the change process before you set one. Once you set one, formal change control starts.
8. Hand off with traces: Pass the baseline to design and test with each requirement linked to the need it came from and the verification that will show it was met.

Plan to repeat steps 2 to 5, because SWEBOK V4 calls a complete single pass through them “highly unlikely.” Change requests after baselining can signal that the repeat passes stopped too soon.

What Techniques Do Teams Use to Gather Requirements?

A single technique rarely covers every source, so match each technique to what each group of people knows. The Systems Engineering Body of Knowledge (SEBoK) advises considering several techniques to accommodate diverse sources.

Comparison	Interviews	Workshops	Observation and job shadowing	Document and standards analysis	Prototyping	Use cases and user stories
Use it when	You need depth from one domain expert at a time.	Time is short, the business need is unclear, or several groups must agree in one session.	What people do differs from what they say.	Regulations, procedures, supplier specifications and legacy systems hold requirements.	Usability is uncertain. Storyboards, paper sketches and mock-ups all count.	You want elicitation centered on what users need to do.
Watch for	Interviews alone can miss the constraints and failure points that watching the work reveals.	A workshop needs an agenda and a facilitator, and a joint session can run for days.	Pair it with interviews to learn why people do what you saw.	A document records what was specified for an earlier product, which may differ from this one.	Participants can become attached to early designs.	Use cases alone rarely capture every requirement.

You need more than one technique whenever your sources disagree or hold different kinds of requirements. Pair interviews with observation when what people say differs from what they do, and add document and standards analysis when a regulation or legacy system holds requirements nobody raises in a conversation.

Learn About Requirements Gathering Workshops

How Is Requirements Gathering Different From Requirements Analysis?

Gathering produces candidate requirements by working with the people who have the needs. Analysis works on the written requirements and turns those candidates into a consistent set the team can build from.

Wiegers said he used to think analysis just happens if you stare at the requirements long enough. Done deliberately, requirements analysis looks for omissions, conflicts, inconsistencies, duplications, dependencies and priorities, and each of those is a check you can schedule and assign.

The two activities overlap in practice. SEBoK describes system requirements definition as determining what the system must do through detailed requirement analysis. So when analysis turns up a conflict, you go back to gathering and ask the people who gave you the conflicting needs.

How Does Requirements Gathering Work on a Regulated Product?

On a regulated product, regulations, company procedures, legacy systems and process documents are requirement sources alongside the people. Medical device, airborne and automotive programs each have their own rules for where those requirements come from and how they’re structured.

Medical Devices

US medical device makers now work under the Quality Management System Regulation (QMSR), which took effect on February 2, 2026. FDA’s final rule incorporated ISO 13485:2016 by reference.

Under the QMSR, design and development requirements are now in 21 CFR 820.10(c). The QMSR incorporates ISO 13485’s design and development clause at that section and adds its own changes. A procedure that still cites 21 CFR 820.30 cites a reserved section.

Design inputs under 820.10(c) cover functional, performance, usability and safety requirements, applicable regulatory and standard requirements and risk management outputs. All of them also have to be complete, unambiguous, verifiable and free of conflict. The QMSR chapter describes the rest of what Part 820 requires.

Airborne Software

Airborne software begins with requirements allocated at the system level. DO-178C assumes that system requirements have already been allocated to software. System requirements are developed outside DO-178C, and its guidance is there to make sure the software implements them correctly.

For the return path, DO-178C added a rule on what goes back to the system level. Derived high-level requirements address functionality beyond what the higher-level requirements specify. They go to the system processes, including the system safety assessment, with the reason each exists. On an airborne program, much software-level gathering is receiving requirements allocated from the system level and sending derived requirements back. DO-254 is the corresponding guidance for airborne electronic hardware.

Road Vehicles

The concept phase of ISO 26262, the functional safety standard, covers item definition, hazard analysis and risk assessment, and the functional safety concept. Safety goals are the top-level safety requirements derived from that hazard analysis. Teams derive functional safety requirements from those goals, then requirements at the system, hardware and software levels. So part of what you gather is the output of an analysis, and the team keeps the trace from each safety goal down to the software requirements that implement it.

What Goes Wrong, and How Do You Avoid It?

Gathering failures are usually found later, as rework. The following failures recur on product programs, each paired with a practice that reduces the risk:

• Features instead of needs: People describe what they want built, so ask why until they explain the need. As Wiegers puts it, “The customer’s not always right, but the customer always has a point.”
• Ambiguous or untestable wording: NASA’s systems engineering guidance rewrites “minimize noise” as a measurable decibel limit. When you author requirements against the International Council on Systems Engineering (INCOSE) requirements writing rules, you can catch vague terms, escape clauses and pronouns before review.
• Incorrect requirements: A requirement can be well-formed yet not correct or feasible, and step 5 is where you catch it, by confirming it with the people the needs came from.
• Unwritten assumptions and constraints: Write down the budget ceiling, the connector the customer already stocks and the regulation nobody mentioned, with the requirement each affects and its source.
• Scope creep and gold plating: Scope creep tends to follow a project scope that wasn’t clearly defined, and gold plating is extra work nobody asked for, added inside the scope. NASA’s handbook treats a requirement with no parent as gold plating to eliminate, so trace each one to the need or parent requirement it satisfies.
• Suppliers building to an old version: A supplier working from an emailed export may not see that the baseline changed unless someone tells them, so give every party one versioned baseline.

Several of those fixes depend on every requirement keeping a link to the need it came from. A Product Manager at Rimac Automobili described that link in Rimac’s customer story. “It’s awesome, because I can open up a comment that our CEO made, that I then recreated as a requirement, and from there, I can trace it all the way down to, say, a specific lightbulb.” With that trace in place, you can start from the CEO’s comment, the requirement or the lightbulb and find the other two.

Get the Writing Requirements Guide

What Does a Requirements Gathering Template or Example Look Like?

A usable template records the need, the requirement written from it, the criterion that shows it was met and the link between them. NASA’s Systems Engineering Handbook lists requirement ID, rationale, traced from, owner and verification method among the attributes to record. The example requirement for a portable device comes from FDA’s QMSR design and development training. The example requirement for a component noise limit comes from NASA’s expanded systems engineering guidance. The needs, acceptance criteria and verification methods paired with them are illustrative.

Field	Portable device (FDA QMSR training example)	Component noise (NASA SP-2016-6105-SUPPL)
Need	A clinician has to carry the device between rooms, so it must be portable.	The component must not disturb the crew or the instruments around it.
Requirement	The device “weighs three pounds plus or minus one pound.”	“The noise level of the component X shall remain under Y decibels.”
Acceptance criterion	Weigh the built unit and compare against the input, which confirms, in FDA’s words, “I made the product correctly.”	Measure sound pressure at the defined distance and operating condition and compare with Y.
Traced from	The portability need, confirmed by intended users in the actual use environment during validation.	The parent need and the rationale for Y, recorded with the requirement.
Verification method	Test (measurement).	Test (measurement).

In the FDA example, the need and the requirement get separate acceptance criteria. Verification confirms the weight. During validation, intended users try the device in the real environment to confirm it’s portable, and a device can pass verification and still fail validation. In the noise example, X and Y are unknown at the first interview, so record who will supply them alongside the rationale.

How Jama Connect Supports Requirements Gathering

Jama Connect keeps needs and requirements as separate, traced items, with acceptance criteria and test cases linked to them, ready for you to confirm in step 5, baseline in step 7 and hand off in step 8. A Traceability Information Model (TIM) defines expected need-to-requirement-to-test relationships, and its coverage checks flag missing links while the work is under way, before an audit. Review Center gives outside reviewers structured access to confirm requirements, and Baselines capture the approved snapshot. To exchange requirements with a supplier using another tool, Jama Connect Interchange™, an add-on, uses the Requirements Interchange Format (ReqIF).

Jama Intelligence, an add-on for Jama Connect Cloud, imports customer, request for proposal (RFP) and regulatory inputs that arrive as Portable Document Format (PDF) files and turns them into structured items for review. At step 4, it evaluates each requirement against 30 of the 40 INCOSE rules and the six Easy Approach to Requirements Syntax (EARS) patterns. Jama Intelligence then suggests a rewrite that refines vague requirements without inventing values, and the engineer accepts, edits or rejects each suggestion. Scoping, elicitation, conflict resolution and prioritization still depend on conversations and team judgment.

Keeping Requirements Gathering Tied to the Need Behind It

The requirements you gather on one program are also the starting set for the next one. A requirement that still has its need, its rationale and its verification method can be reviewed and reused on a derivative product. One pasted into a spreadsheet without those attributes often has to be re-elicited from people who may have moved on.

Jama Connect supports this workflow by keeping each need, requirement and acceptance criterion linked, so you can trace a few of your own requirements back to their needs and forward to their acceptance criteria. You can try it on one program with a free 30-day trial.

Frequently Asked Questions About Requirements Gathering

Who is responsible for requirements gathering?

On a software project, a business analyst or product manager usually leads requirements gathering. The systems engineer or requirements lead handles gathering on a hardware or systems program, and the program manager owns the initial scope decision. Wiegers described the lead as “really a guide.” Participants who do not author requirements can still review and approve them, for example in Jama Connect Review Center.

How long should requirements gathering take?

There’s no fixed duration, because risk decides how much detail you need to document and so how long gathering takes. A distributed team usually needs more written down than a co-located one. Plan for more than one pass. For effort and iteration, read the chapter on how long requirements take.

What is requirements gathering in agile?

Agile teams gather requirements in increments. Scott Ambler argues that big requirements up front leads to significant wastage and recommends exploring the details just in time, so you gather deeply for what’s next and broadly for the rest. In a regulated environment the increments still need documentation, review, change control and traceability, with requirements linked to tests and an item version history showing who changed what, when and why.

If I want to learn more about requirements gathering, what else should I read?

Requirements engineering shows where gathering fits in the wider discipline, from elicitation through validation and management. Managing project scope deals with the scope-creep failure mode. For the writing step, the characteristics of excellent requirements lists what each requirement needs.

This article was authored by Mario Maldari and published on October 30, 2026.