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

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 most efficiently bring people to where they discover and understand the requirements?

Experience tells me people are much better at giving concrete, specific feedback to a running system than to an abstract requirements document.

Hence iterative development.

In essence requirements are not a document by a process.

It really depends on what you do. If you have a well defined problem, that is complex enough to require quite some work, than I would say: Do as little as possible to be able to imagine as much of the workflow as possible, while also staying as flexible as possible.

If a problem is less complex or can be released iteratively, than that's the lean way to do it, where you also have good learning. But often to solve the problem just a bit you already need a load of stuff to be taken care of.

Key to me is to stay in text or cheap click-dummies for long enough. Depending on the complexity I go through several stages:

generally:

- Always probe for details if you can imagine some already, you are trying to know as much as possible as soon as possible. File it all in to a "to take care of later"-list at least, better yet sort in properly already.

- write down everything (maybe others can remember everything, fine too :) )

- change and refine whenever something new has to be taken care of. IN the following steps it will always be easier now, than in the next step.

1. gather high level requirements with the stakeholders

2. sketch a rough workflow. I usually do a nested list.

3. write down a complete workflow

4. now you might know what you need, so define a rough UI, technology, interfaces

5. still in text: write your concept so someone else understands it

6. talk everyone involved through the concept (first stakeholders, than devs)

7. double-check if you cant simplify or leave out anything, at least for a first version

8. if necessary: do mockups, designs, schemas

9. only now start to program (for difficult stuff a prototype)

- On top it might be helpful to have a small checklist depending on your needs with entries like "reporting?, testing?, support?"

Sad upvote... :(

> 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 ability to change is an extremely difficult and hard-fought skill.

Unfortunately, due to a constant influx of new developers, its value is underappreciated. Requirements for this skill are (non-exhaustive): excellent communicative abilities, combined with a predilection for logic reasoning, good technical understanding, some psychological understanding and perseverance for when a model proves unsuccesful.

From my experience, the best systems we have designed and implemented started with long sessions at the white-board, often followed by some tech 'spikes' [1].

[1] https://en.wikipedia.org/wiki/Spike_(software_development)

I recently took a model-based systems engineering course that opened my eyes to some helpful methods.

Use UML, SysML, etc to diagram out your requirements (starting at high level at first, more granular as the system matures). Now build a high-level model of your system design (software and hardware if required). Match parts of your system to the requirements. This lets you see gaps in two directions: requirements you haven't addressed (because they aren't connected as "satisfied by" anywhere on your model), and questions to ask for more detail on a given requirement that could drive the design.

As others have said, there will always be late requirements that change things, so it won't resolve those. It can, however, show stakeholders how much changing a requirement can cost in terms of rework/time by showing how the model has to change to accommodate.

The caveat with this is: the model needs to reflect your actual design, and you need to keep it up to date. The times I've used it so far it has been a useful exercise.