Requirements: Engineering vs. Management

Which is a subset of the other, is the process of requirements management a subset of requirements engineering or the other way around?

To best answer this question lets get back to the basics. What is "engineering" and what is "management".

The term engineering is used to indicate an activity whereby an engineer utilizes findings of sciences to realize solutions which solve problems. To provide an example, a society which has a problem crossing a river asks a civil engineer to realize a solution to this problem. The engineer based on his readings and input from scientists in the fields of chemistry, physics and materials suggests using a steel structure which can withstand corrosion from the environment, and hot summer temperatures as well as extremely low winter temperatures. The engineer performs calculations to detemine bridge loads and how the structure will behave to cross winds and othe environmental elements.

So back to requirements engineering, it is the process used to determine how to best engineer (recognize, analyze and synthesis) a requirement.

Generally speaking management is defined as the activity of controlling, organizing, planning, and directing. It can be argued that planning and analysis do overlap and hence both requirements engineering and management overlap to some degree, and I would agree with this. However requirements management has a much broader scope than engineering, requirements management plans, organizes, controls and directs the processes related to requirements "handling", this handling includes engineering, development, maintenance and obsolecence. Changes to requirements are considered part of requirements maintenance which is part of reqs mgmt.

Requirements management involves developing a database to store requirements, a report from this database could be the RTVM, a list of configurable items (CIs), requirements management could also include tracing requirements to business requirements upward and to test and verification results downwards, it also ensures that the synthesis process in requirements engineering is sound and consistent and traceable to project work packages in the work breakdown structure (WBS) and eventually the statement of work (SOW). It involves establishing requirements baselines, negotiation with stake-holders and prioritization of requirements and changes.

We should not assume requirements management to be a phase in the system life-cycle, but rather a continuous process overseeing all the phases of the system, nor is it a subset of requirements engineering but rather a superset of the various system phases. This is illustrated in the chart below.

A few papers related to requirements management are listed,

[1] Ian Somerville and Pete Sawyer, "Viewpoints: Principles, Problems and a Practical Approach to Requirements Engineering", Lancaster University, 1997.

[2] James Martin, "A Process for Requirements Definition and Architecture Definition", Texas Instruments.

[3] James Martin, "Systems Engineering Guidebook: A Process for Developing Systems and Products", CRC Press, 1997.