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

61–70 of 104 posts

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

#61

Post by beat »

It's not free, and it's not simple, but Aha (https://www.aha.io) can be very helpful in figuring out product.

Engaging end users is a problem from a couple of directions. First, the very idea of "end user" - you need to engage customers, not end users. (Take Facebook, for example... you're not the customer, you're the product. If you build something for Facebook, your customer is Facebook, not Facebook's users.) This situation isn't exactly unusual. In this case, it's the customer's responsibility to gather feedback from end users - and put you in the feedback loop, as needed.

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

#62

Post by tootie »

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…

This is well-known and is the entire reason that agile exists. A lot of teams will write stories and run sprints and think they're doing it right. The actual definition is the ability to flex on scope and timing to meet changing requirements and priorities. Long-term estimation is just never going to be accurate, so setting a date and fixed scope is just automatically doomed.

The strategy I use its to scope out as much as you can up front. A list of high-level user stories. Give these a rough prioritization (MoSCoW works) and some rough estimates on each. Now estimate your velocity with a few possible team configurations. Also, assume your backlog will grow about 10% as you go when new stuff is uncovered.

Now if you need to schedule a launch or set a budget, set it deep into the non-mandatory features. If everything goes off the rails, you have cushion to avert failure. If everything goes ok, you will deliver a richer product. You'll also be able to track very accurately as you go how close you are to the plan week by week.

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

#63

Post by beat »

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…

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 way to gather better requirements. It's not agile. Think about it. A key part of agile is to push everything to the left as much as possible - to catch problems as early as possible in the cycle. What's earlier than before you write the code at all? Writing code to find out what's wrong with it from a requirements perspective is really inefficient.

This isn't to say we shouldn't get working code out there as quickly as possible, or that feedback from working systems has no value. But this idea that it's the only way to get meaningful requirements, that's just BS.

Requirements aren't a document, or a process - they are a system.

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

#64

Post by agentultra »

I think it depends on the problem domain. In high-risk or regulated industries having requirements and specifications is a prerequisite to shipping. There are plenty of good sources for finding the standard expected formats out there. If you're an IEEE member you'll find the ISO requirements and specifications templates in the library.

Doing requirements gathering isn't an inherently bad process to adopt even in non-regulated settings. However I believe many developers will have a negative reaction due to prior experiences with, or having heard about, the waterfall method. The key to remember is that requirements don't, and shouldn't, have to come with an estimate. Great requirements demonstrate a thorough understanding of the problem. They're written from the perspective of the end-user.

Specifications are the dual of requirements and are what drive the implementation that solves the stated problem. Specifications is something I think we need to get better at. We some unit testing, some integration tests, and occasionally end-to-end user tests... some few to property tests; but rarely do we write formal, verifiable specifications in a modelling language that can be checked with a model checker. Rarer still do we write proofs as part of our specifications.

We often elide specifications or we do the minimum necessary to assure correctness. This is to the detriment of your team on a larger project. How do you know your designs don't contain flaws that could have been avoided? How much time are you spending before you realize that the locking mechanism you chose and shipped has a serious error in it that is causing your SLO's to slip?

For requirements I just use plain old Markdown with pandoc. For specifications I use a mixture of Markdown and TLA+. I use TLA+ for the hard parts of the system that we're unsure about and require correctness for. The rest of the specifications that aren't as interesting I simply use prose. It's a matter of taste but it does require an intuition for abstraction... when to do it and how to think about systems abstractly.

We could definitely use better tools for TLA+-style specifications, btw. Maye more libraries that can translate TLA+ state machines into the host language so that we can drive them from our integration tests, etc. Better IDE tooling. Better training.

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

#65

Post by subpixel »

ian0 wrote: post #4

Not a software tool but I was recently introduced to the design-sprint[1] methodology from google and found it helped a lot with the requirements gathering and speccing phases. It was also light and easily implementable - they have some resources there too. [1] https://designsprintkit.withgoogle.com/

Also 'directed discovery' from Pluralight: https://www.pluralsight.com/blog/career/product-development-...

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

#66

Post by thedancollins »

Tade0 wrote: post #44
hyperpallium wrote: post #10

This was the inspiration for "Extreme Programming": You make a minimal cost mockup ASAP, for the client to try out, to see if it's what they wanted. Clients can't appreciate requirements, so (like, actual) architects make a scale model first. The alternative, of doing requirements as a separate phase, was ridiculed as the "waterfall model". In reality, there's interactions between the so-called phases of req, spec, d…

I wonder how effective it would be to at first make the programmers realize all the business processes manually so that out of frustration they would start automating things? A so-called FDD - frustration driven development.

I like it! Some of my most effective code was written that way but the end result of such development tends to be users that feel "cut out" of the process, as if we did not value their input. And with the wrong users in that dynamic you could be turning water to wine and they will still find things to complain about.

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

#67

Post by thedancollins »

mariopt wrote: post #14
hyperpallium wrote: post #10

This was the inspiration for "Extreme Programming": You make a minimal cost mockup ASAP, for the client to try out, to see if it's what they wanted. Clients can't appreciate requirements, so (like, actual) architects make a scale model first. The alternative, of doing requirements as a separate phase, was ridiculed as the "waterfall model". In reality, there's interactions between the so-called phases of req, spec, d…

> What's the point of spending the time and money on beautiful engineering, if it's going to be scrapped tomorrow anyway (or even before it's finished)? Good luck maintaining that code. Don't forget about the team, a messy codebase and/or poor requirements, eventually, will break a team's morale until the day news devs come along and demand a refactor. I start to love the idea of a waterfall model for software. Peopl…

Users want plausible deniability. And some need it. With iteration-based development you have the potential to avoid the "yeah, it meets the spec, but it is not what we wanted" problem.

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

#68

Post by thedancollins »

edejong wrote: post #28
groestl wrote: post #17

Earlier quoted context omitted.

Software that is used, changes, because successful software influences the world around it, which in turn changes it's requirements. So typically, even if a team gets it right the first time (which by itself requires enormous effort), the once perfectly specified requirements will have changed shortly after release. Edit: sibling is right as well, it depends on what you're building. Sometimes there is nothing better…

> Software that is used, changes, Yes, but... A good model can support larger changes than a bad model. For example, a well designed relational model can support iterative change better than a slapped together system using CSV. So does a system that supports a consistent mental model for the end-user. This is the fundamental skill: abstraction. To find the right abstractions, sustaining simplicity while opening up ab…

Survivorship bias/fooled by randomness. If a system can be abstracted to a model that can account for the bizarre stuff that the business throws at it, then the domain you are operating in is either Simple or slightly Complicated (as defined by the Cynefin framework). The real problem lies in Complex/Chaotic.

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

#69

Post by adrianN »

beat wrote: post #63
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…

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.

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

#70

Post by gilbetron »

beat wrote: post #63
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…

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 investment that only makes sense for incredibly important systems, like launching a billion dollar rocket. And even then, you need iteration, just a more more careful, sandboxed type of iteration.

Post reply on HN