Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Better tools for the software requirements / scoping phase?

news.ycombinator.com

Post reply on HN
Print view View original

71–80 of 104 posts

Re: Ask HN: Better tools for the software requirements / scoping phase?

#71

Post by carlmr »

adrianN wrote: post #69
beat wrote: post #63

Earlier quoted context omitted.

This is largely wrong. No, people cannot know "everything in detail, in advance". That doesn't mean that they don't know anything . They know a lot. Nobody with any actual experience in requirements-gathering expects 100% perfection. So the underlying assumption about the underlying assumption is wrong. After 20+ years in this industry, I'm long past believing the conventional wisdom that running systems are the best…

I've found that writing (pseudo-)code is absolutely necessary to find problems in the requirements. Often enough the requirements are self contradictory or just contain too many unnecessary corner cases. I've seen requirements that sounded really simple in the requirement doc, but turned out to be extremely hard to test because they implicitly defined a state machine with dozens of transitions.

Especially because English is often a terrible language to express requirements.

Re: Ask HN: Better tools for the software requirements / scoping phase?

#72

Post by andymoe »

We do this thing we call Discovery & Framing at the kickoff of a new project. It usually lasts 3-6 weeks and involves design, product, engineering and someone with the power to make decisions on the spot. We call this role a product owner.

It’s a good way to get stuff out of folks heads, validate the problem and solution with users, and end up with some stuff for everyone to execute on by the end of the process. You can google the term for more detailed descriptions.

As for tools, we’ve been having success with real time board, and pivotal tracker (maybe gives away where I work) and of course a ton of sticky notes.

Re: Ask HN: Better tools for the software requirements / scoping phase?

#73

Post by zolthrowaway »

geezerjay wrote: post #47
namdnay wrote: post #16

Earlier quoted context omitted.

It really depends on what you're building. There's a reason civil engineering isn't "Agile" - this also applies to major IT systems. A tiny difference in requirements can have massive impacts. Honestly, in these cases, there's nothing better than waterfall, partly to save development time, but mostly for contractual protection: If a small change can cost millions more (and from experience, they can), you need to know…

> There's a reason civil engineering isn't "Agile" There are plenty of reasons why engineering isn't "agile" and it's only usable in software development, and one of the main reasons is that software development projects manage a single resource: man/hours. Building the wrong or inadequate solution has its cost, but rebuilding something from scratch does not require additional resources to be allocated to the project…

I 100% agree with you. Software is "soft". Making changes to a code base is very cheap. Iteration just makes sense in software even for critical systems. If you build a suboptimal bridge, you have to live with it. If you write suboptimal software, you can test the actual product and fix it before you even ship. You can't really test a bridge outside of simulations. GP's comparison is apples to oranges in a lot of ways.

Re: Ask HN: Better tools for the software requirements / scoping phase?

#76

Post by beat »

gilbetron wrote: post #70
beat wrote: post #63

Earlier quoted context omitted.

This is largely wrong. No, people cannot know "everything in detail, in advance". That doesn't mean that they don't know anything . They know a lot. Nobody with any actual experience in requirements-gathering expects 100% perfection. So the underlying assumption about the underlying assumption is wrong. After 20+ years in this industry, I'm long past believing the conventional wisdom that running systems are the best…

The OPs statement isn't wrong, or even largely wrong, it is largely right. There was no statement of skipping all requirements gather, but skipping the idea that you can do one requirements gathering and have everything you need to develop the entire system. Your push back to waterfall development is driving me crazy - we already tried that for decades and you can only get it to (kinda) work with a ridiculous investm…

So the OP was fighting a strawman. Like I said, nobody out in the real world believes in pure waterfall anymore. Everyone knows that, realistically, a completely up-front requirements process doesn't do enough.

But the quote agile unquote response is every bit as reactionary, and does happen out in the real world... "You guys start writing code, I'll go get the requirements". Writing code is expensive, even in agile process. Just because you're doing two week iterations or continuous delivery doesn't mean you no longer waste time and effort on dead ends. You're just dying by a thousand cuts.

Turning to user reactions to working code as the only requirements-gathering mechanism is stupid. Stupid. It ignores a ton of requirements issues that are not only complex, but dangerous to screw up - financial behavior, SOX and HIPAA compliance and other regulatory issues, and more. A mistake in initial implementation can cost millions of dollars, company reputation, and worse.

And again, what the OP is proposing here is not agile. Just because you're tossing code over the wall in short sprints doesn't mean you're agile. Agile means catching potential problems as early as possible in the process. Catching problems with requirements is almost always going to be cheaper than catching them by writing code and finding out that the code is wrong.

Agile requirements gathering is a thing, yo.

Re: Ask HN: Better tools for the software requirements / scoping phase?

#77

Post by mjdease »

mjul wrote: post #22

The underlying assumption with requirements is often not stated explicitly: that people _can know_ everything in detail, in advance. If that is the case, surely we can find better ways to uncover the requirements, and better tooling will help solve the problem. Experience tells me that people don’t know everything beforehand. Thus the key assumption is not valid. Then the question we should be asking is: how do we mo…

Agreed, I've been on many projects where a client only had vague requirements and useful clarification only came in response to seeing the app.

This is reasonable, it's human, but does anyone have a good approach to applying an iterative development approach on fixed price contracts?

I've been on many fixed price projects that are "agile" in name only, general issues I've observed:

- Iteration on requirements becomes confrontational (pay for change request) making it difficult to build a good product as we all learn what does/doesn't work for users throughout development.

- Upfront estimate is inaccurate causing time pressure on development resulting in rushed work which negatively impacts code quality and team learning.

The traditional answer is to have the client commit to specific requirements and hold them to it.

But what I'd really like to figure out is a way to acknowledge evolution of requirements will happen so we can work _with_ clients to build great products.

I struggle because this seems incompatible with fixed price and large companies seem to only want to do fixed price.

Re: Ask HN: Better tools for the software requirements / scoping phase?

#78

Post by beat »

adrianN wrote: post #69
beat wrote: post #63

Earlier quoted context omitted.

This is largely wrong. No, people cannot know "everything in detail, in advance". That doesn't mean that they don't know anything . They know a lot. Nobody with any actual experience in requirements-gathering expects 100% perfection. So the underlying assumption about the underlying assumption is wrong. After 20+ years in this industry, I'm long past believing the conventional wisdom that running systems are the best…

I've found that writing (pseudo-)code is absolutely necessary to find problems in the requirements. Often enough the requirements are self contradictory or just contain too many unnecessary corner cases. I've seen requirements that sounded really simple in the requirement doc, but turned out to be extremely hard to test because they implicitly defined a state machine with dozens of transitions.

Yes, definitely. This applies a lot to infrastructure issues, too. But pseudocode or extremely simple test case code can do this a lot better than tossing something into production to find out if it sucks.

I suspect a lot of the HN hostility to proper requirements analysis is coming from writing trivial systems.

Re: Ask HN: Better tools for the software requirements / scoping phase?

#79

Post by flarg »

Wireframes for UI design alongside UML for enterprise data models and process flows, and finally good old truth tables work best in my experience. They work to bridge the gap between business and development. You'll never get 100pc coverage but you'll get a lot of the way there.
Post reply on HN