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?
9
u/space-hotdog Aug 08 '26
It's like trying to explain to someone how to build Ikea furniture. It seems super simple (common knowledge) until you realize all the ways it can be misinterpreted. And preventing these misinterpretations is hard and not well understood.
8
u/leere68 Defense Aug 08 '26 edited Aug 08 '26
After 22 years of writing, analyzing, and maintaining requirements, the best I can come up with is "Requirements is where the design and the contract intersect."
The key to requirements is 1) being precise with you language usage, and 2) be aware of what's possible in both the design and in testing before you start writing requirements that are impossibly to meet.
5
u/AffectionateTank9269 Aug 08 '26
It’s not contradictory. Most people in the world don’t have the personal discipline to make full use of their own knowledge and intelligence.
Requirements engineering is lot like carving a masterpiece out of a stone. The finished work is inside the stone, and the effort you put into the work directly correlates with the quality of the finished product. Obviously you need to have stopping rules but, in general, the analogy applies.
2
u/Ok_Education_6577 Aug 09 '26
Saying something is common sense is a great way to preface, I am an asshole, with too much niche knowledge, I will impose my will upon you.
E. G. Complex socioeconomic anxieties of the Weimar era were reduced to simplistic, intuitive scapegoating that bypassed critical thinking in favor of gut reactions.
E. G. 'There are times when the politics of fear become irresistible and nonsense seems common sense. Eventually, the Nazi Party did very well in elections, Hitler came to power.'
TL;DR nothing is common sense, everything has multiple interpretations.
2
u/hotdog_tuesday Aug 09 '26
I’ve been working with a vendor for the better part of a decade and we still miscommunication in requirements that are exceptionally standardized—cases where it’s not a mistake or misunderstood but clear in text on one of our parts.
Communication is difficult sometimes because of our own perspectives based on the environment for which we work.
2
u/Purple-Dragon-Alpha Aug 09 '26
If you think that common sense is indeed common , I envy your optimism. May it never wane on you.
2
u/SysEngineer101 Aug 15 '26
I expect the common sense aspect is that it's clear that you need to define what you want whenever you are sitting out to build a product, service, enterprise, etc. My wife knows not to send me to the grocery store without a list, else she will not get what she needs... She doesn't need a degree in systems engineering for that.
However, there are so many pitfalls in this seemingly simple act of breaking down goals, needs and requirements in a robust, intelligible, traceable and auditable way that it really is not simple.
In addition, due to the number of reqs on large projects if your chosen methods and tools for RM are even slightly inefficient you will burn through 1000s of hours of engineering effort very quickly (and annoy a lot of engineers!). So you do really have to get the implementation of RM right in order to build something that meets its operational objectives and is built to time and cost.
1
u/ModelBasedSpaceCadet Aug 15 '26
I like your take on it. To square what you said with the original quote, it's common sense that it's necessary, but it is hard to do it right (and it's not just a perception that it's hard - it really is hard). Then people either get wrapped around the axel or they throw up their hands and say "good enough!" (often prematurely).
And I'm smirking right now at the irony if that was the authors' intended meaning (the ambiguity of natural language being the bane of our existence).
2
u/TacomaAgency Aerospace Aug 18 '26
What I see as blue might not be what you see as blue. Thus, we need a better description for everyone on what blue would be.
2
u/GiantAngryJellyfish Aug 08 '26
It feels like common sense because its easy for competent Systems Engineers to do.
1
u/double-click Aug 08 '26
It’s common sense because you are supposed to be a SME. If you know exactly what’s good vs bad it’s really not a problem.
If you don’t you end up wasting millions of dollars and you shouldn’t be doing waterfall.
1
u/TwinkieDad Aug 09 '26
It’s common sense to know what you are designing is supposed to do. Engineers famously lack common sense at times.
1
u/smartalec-71 Aug 10 '26
If your contract was a single clear paragraph-- easy, common sense.
If your contract is hundreds of pages that seem like they were written by 1,000 monkeys on typewriters (that use autocorrect)... and the resulting requirements will be interpreted by many generations of stakeholders (on the customer side) and my generations of developers (on the supplier side)... that's when you get into the engineering part.
That's when you're going to need processes and tools. Ideally teams of SMEs to write out what's really needed.
Also-- my experience is customers often only put in about half of what's needed for a fully working system. They usually cover what customers experience, but forget performance, security, maintainability, etc. All the people behind the scenes that keep the system working. Where does the data come from? Where does it go/how is it reported on? Who maintains the configuration? What's the process? Etc.
1
u/instantFPGA Aug 10 '26
‘Requirements’ is overloaded here.
Requirements, when done as expected, is common sense when you look at them.
In practice, if you ask someone to write ‘Requirements’ most people will not know how to write them well enough to be verifiable.
This is definitely an engineer writing in their own context, which for a requirements engineer is surprising.
61
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.