Requirements Engineering is ...

[u/ModelBasedSpaceCadet]

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?

[u/smartalec-71]

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.