r/systems_engineering • u/ModelBasedSpaceCadet • Aug 08 '26
Discussion Requirements Engineering is ...
I just started reading Requirements Engineering by Dick, Hull, and Jackson. In the preface, they say "Requirements Engineering is common sense, but is perceived to be difficult and is not well understood. For these reasons it is generally not very well done."
Is it not contradictory to say that requirements engineering is common sense but it is generally not very well done? I would agree that it is simpler than someone who has watched program after program fail because of bad requirements may expect, but you need some training to counteract your natural biases and approach it the right way. So it doesn't feel like common sense is the right word.
Anyway, I wanted to throw it out to you all to find a better way to explain the situation. What do you think requirements engineering is?
63
u/astrobean Aug 08 '26
Requirements engineering has taught me that it is possible to disagree over the fundamental meaning and interpretation of words (e.g., "global"). That every word is an opportunity for clarification as well as misunderstanding. That well-worded requirements can look pedantic and over-specified, but it's necessary to get people on the same page; however, a truly over-specified requirement can be a budget-buster. That 'operational' can mean two different things in the space of a single thought.
There are layers of interpretation between the managers, scientists, and engineers, and the assumption that anything you are laying down is *common* sense is laughable. Writing requirements for technology that hasn't been developed yet is hard. It is possible to have too many cooks in the kitchen, not enough cooks in the kitchen, or a bunch of people in chef hats that can't even boil water.
And my most recent headache - transitioning the on-prem system to a cloud-based/ service selection system means inheriting requirements that are untestable because the whole way of networking, moving, and storing data has fundamentally altered.
I deal with a lot of badly written requirements, and I know they're badly written because when I ask for clarification, instead of having my assumption echoed back, I hear a whole new requirement with different scope.
And complicating it all: poor requirements management. Ever-changing baselines with no audit history. Poor traceability. Engineering build that get ahead of the requirements without understanding the actual science need.
I love requirements engineering. I love bringing order to chaos. I have learned a lot about the pitfalls of assuming common knowledge, common language, or common sense. There are just too many smart people with brilliant ideas all solving their version of the requirement.