As long as I’ve been an engineer, people have spoken about requirements management. I agree that requirements management is important to keep a program in compliance with stakeholder objectives. By stakeholder, I mean our own internal organization, the customer, the manufacturing team, the test team, the installation team, the lifecycle support team—and the list goes on. As a point of reference, I’ve worked in both the requirements management side of things and the requirements engineering side of things over my career. The difference between requirements management and requirements engineering isn’t simply semantics. The ideas cannot be used interchangeably.
Let’s look at the differences for a moment. Requirements management focuses on tracking requirements. Requirements management details the source of the requirement, and asks: What document did it come from? What was the document revision? It also focuses on changes to the requirement throughout its history. Who changed it? What was the authorizing document? When was the full implementation of the change? This thinking is procedural in nature.
During audits, requirements managers march out the paper trail of the requirements, and can provide very useful metrics pertaining to the maturity of the requirements base. In my experience, requirements managers are not requirements authors; they don’t originate the requirements, but they are responsible for institutionalizing the project’s requirements base. We often ask to see the requirements when a project experiences difficulty, to try to understand how we got to our current condition. It is the requirements manager who has the historical artifacts.
OK, so what’s a requirements engineer, you ask? Requirements engineers are responsible for the generation of the body of requirements. The requirements engineer will generally have a mastery of a topic, the justification for a requirement’s existence, and often engineering data pertaining to the requirement. The requirements engineer is the person who is asked the all-too-frequent question, “What does this requirement mean, and do we need it?”
The requirements engineer takes into account the impact a requirement has on the architecture that may ultimately impact the number and type of subsystems incorporated into the design. The incorporation of requirements also has an effect on cost, so the requirements engineer has to “right size” the requirements. With too few requirements, the resulting systems may not be useful; too many requirements and the system may be unaffordable.
The challenge the requirements engineer has is to determine the proper balance between too many and too few requirements. To get the right balance, the requirements engineer has to apply a combination of art and science. The requirements engineer focuses on the validity of requirements. Are they single, testable, clear, concise, and unambiguous? The requirements engineer also focuses on defining what a system has to do, purposefully avoiding how that system will accomplish the project objectives. Focusing on the how enables the design engineers maximum flexibility in their design efforts.
Additionally, the requirements engineer develops the overall testing strategy to plan where, by whom, on what test equipment or range, and what organizations will participate in the testing. The requirements engineer identifies validation and verification methods, testing, demonstrations, analysis, inspection, and simulation for each requirement, and confirms the approach with the stakeholders.
The requirements engineer is also often the person who evaluates the impact of a potential change, and supports the architect and program office in developing engineering change proposals. The requirements engineer will often identify the emergent effects the change may cause on downstream requirements or design constructs.
In a model-based systems engineering environment, a requirements manager is most likely the person assembling the data packages as well as the one who supports requirements engineering and the program office. The requirements manager is often the person who executes consistency checks on the requirements base, identifying gaps in completeness and preparing the metrics dashboard for status reviews. In my opinion, the requirements engineer is a systems engineer focusing on the foundation of the design. The requirements engineer often morphs into other systems engineering capacities over the lifecycle of a project.
To conclude, both the requirements manager and requirements engineer are critical roles. They are both key to a project’s success. The fundamental difference is that the requirements manager’s tasks tend to be procedural, and the requirements engineer’s tasks are technical and more senior in nature.
Happy Engineering!
