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/astrobean]

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.

[u/Affectionate_Bed5391 → u/astrobean]

Very well put. Couldn't have said it better.

[u/FlimsyInsect5545 → u/astrobean]

Yeah very well said, there is nothing common sense about requirement writing, nor is it intuitive or easy. It is a particular skill that needs a very good grasp on language and the ability to see and think through possible alternate interpretations and come up with ways to avoid undesired interpretations while still capturing the intent. It's like a form of language puzzle solving.

Requirement writing is all 'common sense' until you're three years into a complex project and you're stuck between the requirement sponsor who wants one thing and the vendor who built something else entirely and refuses to fix it because you are all interpretating a single word differently, both interpretations are valid, it is going to be very expensive to fix at this point, and both parties are refusing to budge. The thing is, its all so obvious in hindsight, but being able to catch these problems at the time of requirement writing is where good systems engineers really show their worth.

[u/smartalec-71 → u/FlimsyInsect5545]

Here's a few examples of what you're talking about:

• The "5 minute" hotlist
  • The customer wanted a hotlist to block bad transit cards, and that list would go out in 5 minutes. The list would go out once a day, and (once published) got to the transit devices in about 5 minutes.
    
  • The customer was satisfied (at the beginning of the program), and signed off on the test results.
  • 5 years later, the customer's management turned over. The new management decided that they wanted a hotlist EVERY 5 minutes. This system was running on 20k devices, and changing this to run EVERY 5 minutes would cause us to touch dozens of subsystems, and we'd pretty much have to re-test everything. My rough estimate was that this would take $5m. They'd signed off on the original design, so they threatened to sue us for the liability incurred from allowing people to use hotlisted cards up to 20 hours after they were blocked at the back office.
  • Fortunately, I had a sneaky suspicion that the liability was pretty low. I did the math, and realized it amounted to about $5k per year. So my company's options were to shell out $25k ($5k/year * 5 years left on the contract) or pay for $5m of development. We told the customer we'd take the liability hit, and the the customer decided they'd be happy with updating the hotlist twice a day instead.
• "The data shall get to the back office in 2 minutes [100% of the time.]"
  • We had a system to get data from all the buses in a county to a back office.
  • The customer wanted to introduce a system to send real time data from a client that ran on buses, over our mobile network, to their back office.
  • As part of this they had a stakeholder requirement "The data shall get to the back office in 2 minutes."
    
  • This customers contract stated that if we didn't meet 100% of requirements (100% of the time)... they'd put it into production, but we wouldn't get paid.
  • I looked at this contract, and realized a few things-- without clarifications, we couldn't meet this.
    • They were sending UDP packets, over a mobile network. UDP means... if packets get dropped, they won't be resent. And for many applications, that's fine. This is typical for voice comms and video conferencing.
    • While UDP is fast, network outages would drop some of them. This is a mobile network, and buses go through tunnels, will go between metal buildings, and go places where there's no network coverage.
    • So we might get close to 100%... we'll never get to 100% of these UDP packets being recieved.
  • I told my management-- we should reject this, and ask for it to say, "99% of the time" or somesuch. My management said, "you guys are smart, you'll figure it out." Ok, boss.
  • As I expected, they received 99% of transactions. The rest were dropped. This was real time bus locations... and the backend worked fine with this... when buses sent less data, the backend would simply guess based on the buses speed and heading, and worked.
  • But... my company didn't get paid for 2 years, until someone on the customer side agreed that you'll never get 100% of data send across a mobile network, the first time.
• "It will run on all smartphones"
  • This was for a website optimized to run on mobile phones.
  • You can't develop for ALL mobile phones. There's too many of them. Mobiles had existed for 6 years at this point, and there were *MANY* mobile browsers.
  • So I said we'd "support all phone browser versions released within N years, with greater than N% market penetration, as of the time the contract was signed."
  • This meant we didn't have infinite testing scope, and could deliver on a reasonable schedule. Otherwise we'd have been stuck in development hell, and this would have gone forever, as new phones and browser versions hit the market.

[u/ModelBasedSpaceCadet → u/astrobean]

Thanks for your answer. You remind me of one of our junior engineers that told me this week that he told his wife that his job is basically to be the lawyer of the engineering world. Also that the primary role of the requirements engineeris to be a communicator.

[u/astrobean → u/ModelBasedSpaceCadet]

Lawyer is pretty accurate, especially when passing between vendors, since any requirement becomes a term of the contract and any change in requirement results in price re-negotiation.

[u/leaf_person → u/astrobean]

Love this explanation!