Requirements Management

Requirements management is the process of eliciting, documenting, analysing, tracking, and controlling requirements throughout the system lifecycle. Good requirements management ensures that every stakeholder need is captured, every requirement is testable, and every design decision can be traced to a requirement.

Why companies use it

·Unmanaged requirements are the leading cause of project overruns and product failures — projects drift when no one owns requirement changes
·Required by standards like ISO 26262 (automotive), IEC 62304 (medical software), and DO-178C (aviation) as part of design control
·Enables impact analysis — when a requirement changes, requirements management tools show everything affected downstream
·Traceability from requirement to design to test is the foundation for demonstrating compliance to customers and regulators

What hiring managers look for

·Poor requirements management is the root cause of most expensive engineering rework — engineers who can manage requirements reduce project risk
·Experience with requirements management tools (DOORS, Jama, Polarion, Codebeamer) is directly practical in large engineering programmes
·Writing well-formed, testable requirements is a skill that distinguishes experienced systems engineers from juniors
·Understanding the difference between stakeholder needs, system requirements, and subsystem requirements shows systems engineering depth

Typical interview questions

What makes a good requirement? What are the properties of a well-written requirement?

How do you handle a situation where two stakeholders have contradictory requirements?

What is the difference between a stakeholder requirement, a system requirement, and a subsystem requirement?

How do you manage requirement changes during a project without destabilising the design?

Which requirements management tools have you used? What did you do in them?

Common mistakes

·Writing requirements that are not testable — "the system shall be reliable" cannot be verified; "the system shall operate for 10,000 hours MTBF" can
·Mixing solution statements into requirements — requirements should state what is needed, not how it will be achieved
·Not assigning ownership to requirements — requirements without an owner are never challenged, resolved, or maintained
·Allowing requirements to be changed verbally without updating the baseline — change control must apply to requirements
·Writing at the wrong level of abstraction — system-level requirements should not specify component details

Real engineering example

A defence electronics company reduced their requirements change rate from 42 per month to 7 per month by introducing a requirements review board that challenged all new requirements against three criteria: testable, unambiguous, and traceable to a stakeholder need. Requirements that failed any criterion were returned to the author for clarification. The discipline of review prevented 60% of changes from entering the baseline at all — they were resolved before becoming formal requirements.

Topics covered

requirementsDOORSJamatraceabilitysystems engineeringdesign controltestable

Related interview guides

Systems Engineer →Embedded Software Engineer →Functional Safety Engineer →Technical Product Manager →