Hacker News Reader

Comment by dalbasal | Hacker News Reader

Imo, the trouble starts with the term "requirements."

There's an old joke about posting requirements to a job site: "(1) awesome webapp (2) really useful (3) must make me a billion dollars.

The requirements problem is like that.

Requirements are "gathered." Reality doesn't work like that. They aren't gathered. They're invented. a collection of requirements adds up to a design. Thinking of it as a bunch of requirements leads to designed by committee problems.

Designers need to know the problem space, the materials, etc. The requirements part can't be separated from those, which is exactly what the concept promotes.

View on HN

Part of this is a separation of concerns between people in different roles. The person designing the thing may be different than the person engineering particular parts or getting parts in the supply chain.

Take something like a radio. The person building the electronics to meet the design and sourcing the parts may need to know the requirements around the temperature it needs to operate in. The person handling the internal electronics is very likely different from the person designing the product. The person designing the product will need to know where, when, and how it's used by whom.

With software we often mash the roles into one or a few people. A developer may do all or many of the parts. If we look at other engineering disciplines, aside from software engineering, requirements often make sense.

I was just reminded of someone who had to test PVC piping. It had to meet certain standards for handling pressure. The people do engineered the materials, the thickness of the pipe, and so forth had to know the requirements it needed to meet. They also needed to know the requirements for the size of the pipe so that it would mate with other things. They weren't designing the system the pipes would be used in.

Requirements are often a way to take the design, break it up, and communicate it to others who aren't part of the design. They are also a way to create common interfaces. Both of these are things software designs are often bad at. Sometimes intentionally so (non-standard interfaces create lock-in).

This problem comes from the absolutist implication of the word. A better word is "Objectives". Objectives aren't created equal like calling them "requirements" implies. Requirements must all be completely fulfilled for the request to be satisfied, while Objectives are ranked by importance and can tug against each other. Having contradictory requirements is a semantics error, but having contradictory objectives is normal: that's why they're prioritized.

"Make me a billion dollars" may be your objective, and while it may not be an actionable one, it is in fact important to distinguish in your design whether your primary objective is to make money, rather than being a passion project for example. The cost-benefit analysis of various design decisions changes depending on how big a priority profit is.

You may be willing to make decisions that are less profitable, but lead to a better product, when profit isn't your primary objective.

Whatever you call them, attempting to formalise them as a discrete object is flawed.

These aren't discrete objects. They're key parts of a formal, or semi formal decision making process, administration systems, management methods and suchlike.

Look... there are outlining methodologies that playwrights or novelists sometimes use. It's fine to use such constructs. What's not fine is trying to build institutions based on them.

It's just not reducible neatly into profit objectives and such. Those are fine tools, but they're not good models of the world.

So what you're against is having a corporate-mandated policy for how customer feedback is to be turned into a product design?

No.

I'm against framing design as "requirement gathering."

If you're designing, deciding or otherwise doing subjective, creative work don't wrap it up in a fake-discrete process.

Customer feedback is valuable information. It's isn't ore that you refine into cutlery.

At my organization we call it "requirements mining" -- because getting good requirements from which you can build useful software is f*cking hard work.

I really like "mining" here. At least for me the connotations fit really well. I think it's better than "inventing", because it's not like requirements come from thin air. They exist in a raw form buried in the stakeholder's minds / domain knowledge and they are extracted to a useable form through hard labor.

Inventions don't come out of thin air either. They interact with context, needs. They arise within limitations. Etc.

I totally disagree. The spec dies not exist. It isn't buried in your customers' brain or your CEO's. It isn't mined. It is invented, one way or another, by those making the damned thing.

The "requirement" for a spaceship is "must travel to the moon." What software requirement mining tries to do is mine Kennedy's mind for the design of the bathroom.

The requirements and the spec are very different things. The requirements are exactly the thing that comes from the stakeholders. The spec is a way longer document that must match the requirements, but it is not the requirements.

Also, the requirements for a spaceship are only "must travel to the moon" if your customer is a 5 year old child. The real list of requirements is way longer and includes things like "must be compatible with our existing launch infrastructure".

While it's true that requirements come from the stakeholders, often the stakeholders don't really have them, they don't know them, and when they think they know them, often those are not the "real requirements" but some proxies which may even need to be violated to get a good product - i.e. I may think that a significant requirement is to ensure that some thingamajig very reliable and has many redundant duplicates/backups, but a better solution is a design that removes that thingamajig at all.

The key problem in obtaining the requirements is not a problem of communication (as the original article states) but in the work that needs to be done by (or with) the stakeholders to figure out the actual requirements. And I'm not talking about making the detailed spec, I'm talking about the big conceptual requirements which often after some proper analysis get a fundamental change of perspective. This is the main issue in making good products. If you simply make a spec for the requirements the stakeholders initially think they have, your success will depend on how much thought and work they have given to choosing these requirements, and often that will be lacking.

I agree that the verb gathering is misleading. It makes the requirements sound obvious and salient, like you're picking up fallen apples under a tree.

To me requirements aren't gathered, they are 'elicited'.

There is a Wikipedia article for that:

https://en.m.wikipedia.org/wiki/Requirements_elicitation

"The term elicitation is used in books and research to raise the fact that good requirements cannot just be collected from the customer, as would be indicated by the name requirements gathering. Requirements elicitation is non-trivial because you can never be sure you get all requirements from the user and customer by just asking them what the system should do or not do."

> Imo, the trouble starts with the term "requirements."

> There's an old joke about posting requirements to a job site: "(1) awesome webapp (2) really useful (3) must make me a billion dollars.

> The requirements problem is like that.

Yeah. Someone, in the history of SW had a great idea: requirements must be atomic.

That's why a lot of products break when they are put together.

> Requirements are "gathered." Reality doesn't work like that. They aren't gathered. They're invented. a collection of requirements adds up to a design. Thinking of it as a bunch of requirements leads to designed by committee problems.

They are gathered. They are however, not a collection. They depend on each other. And when this depenfence is missing or left over the engineer will invent it to compensate for the lack of it. Every engineer. In its own way.

> Designers need to know the problem space, the materials, etc. The requirements part can't be separated from those, which is exactly what the concept promotes.

True. But "requirements must be atomic" :(

This may be true in an abstract sense, but not in the RW context that this post is dwelling in.

Requirements in the sense that a customer or higher up might negotiate with a PM aren't atomic like that.

Imo, this is a lot like an engineer blaming the spec and/or demanding a better spec. They're asking to be given a perfect task.

If everyone has slosh in their expectations budget, its ok, but if people want some undefinable thing and they know it when they see it and they get mad when they don't get it, you're going to get engineers asking for the "perfect spec" - because that's what they are effectively held accountable to.

Not so much perfect spec. But hidden assumptions

> a collection of requirements adds up to a design.

No it can't A collection of requirements implies many, many possible designs.

Change the team, you get a different design.

A good-quality requirement is _testable_, amongst other things. After the design and construction are complete(-ish), the team should have to show that each requirement is in fact met by comprehensive testing.

Along the way, each requirement should be mapped to elements of the design. So you can (on paper) verify the design meets requirements. And the designer(s) can be confident they are meeting the full set of requirements.

And for the nay-sayers that complain you can't ever adequately elicit the requirements out of the users (or customers), then your engineering process needs to address this risk. See many comments that refer to ways and means to achieve this mitigation.

I think the word missing from this is 'market'.

Good leadership identifies issues or opportunities in markets, builds something useful, and most importantly, markets and sells into the domain.

Having worked on both sides, I would say that understanding markets and being able to sell into them makes almost Engineering seem pedantic.

This 'gathering requirements for Engineers' is an 'engineering centric' way of viewing things. I mean you have to take some perspective on it, but I think that the issues is going to revolve around 'the hard part'.

If you're building new Nuclear tech, the Eng. is going to be a 'hard part'.

Otherwise, it's the money, markets and selling that is 'the hard par' and the Devs. are bit more like Construction workers but with more thought in the process.

Requirements from a "committee" of stakeholders are indeed gathered to turn design by committee into reality.

Software requirements encompasses a vast spectrum of best practices and creative problem solving, mediation and imposition, linguistics and invention, details and principles, according to the people and domains involved.

We spend an inordinate amount of time learning about deep technical issues and there are many training courses along those lines--many of them very good. Does anyone know of boutique training services who train devs how to mine requirements and run dual duty as a dev and emergency PM?

Reply on news.ycombinator.com