How to formally figure out the best design based on the informal user's description of their needs?

Question

I am to write a piece of software to a friend of my uncle's, but I don't exactly know all the elements that are needed to fulfil the user's needs, so I can't begin to formulate a design yet. Since the problem is kind of solvable (in a small, non practical scale) by spreadsheets, macros, forms and a database, I am doing exactly that, and in the process I am figuring out the elements that will have to somehow be present in my design.

I imagine there must be another way to do this, a formalized way to design your system based on the needs of the user without the middle step of emulating the user trying to solve their own problem via inferior means. If indeed there is such a thing, what is the name of such discipline/technique?

Answer 1

You actually aren't far off the mark. If your client cannot clearly say what he wants your best bet would be to 1. talk to him! 2. knock up a quick prototype 3. listen to what he says. Repeat until one of you has had enough,

This is actually known as Agile Software Development.

Answer 2

Your way of doing things is formally called Prototyping.

With several iterations and discussions the formal name is Agile.

Answer 3

Matching "customer" expectations is a multi-parametric unsolvable problem with no closed-form analytical solution, for many reasons, of which one should be enough (as it makes all the difference in the world). Customers (i.e. users) usually have no idea of what they want.

Joel Spolsky practically hits this nail on its head pretty hard:

If there’s one thing every junior consultant needs to have injected into their head with a heavy duty 2500 RPM DeWalt Drill, it’s this: Customers Don’t Know What They Want. Stop Expecting Customers to Know What They Want. It’s just never going to happen. Get over it.

As Joel carries on to explain, when you go to an expert designer (of anything, e.g. an architect, but just as much a software engineer), you go to them because they know better. So you have to work your way around this first of all.

The point is that you have to try to provide some alternatives, dig somewhat deep into the customer's problem and try to "understand" their needs, feel them and try to apply the best of your knowledge to meet their needs. Customers sometimes make an important mistake, they put their expectations over their needs. They don't do that mistake on purpose, but you need to keep that in mind. The reason for that is, somewhat obviously, that expectations are primarily shaped based on past experience and can be (and usually is) very subjective, but needs are usually objective and stem from real-world problems, the pragmatic difficulty of which is almost always hard to argue against.

You have to be your customer's "ally" down the interaction road. Unfortunately, this includes, more often than not, you explaining to your customer what they need. So you have to get into your customers' "world", understand their needs and actively shape their expectations into a result that helps them achieve what they want.

Beyond this "philosophical" chatter, the only useful advice you can get is that you have to spend quality time with your client. Ask, ask, and ask again. Gather all the details, prepare a few reasonably chosen alternatives, demonstrate the pros and cons of each and communicate them clearly to your client.

Answer 4

I believe you are looking for the term Requirements engineering. Do not confuse with a phase of the joke※ software methodology known as waterfall (1956).

Iterative and incremental development is just the Deming Cycle (1959) with some software specific considerations. See also Continual improvement process (1951). It is the way software engineering should have taken, as more mature engineering diciplines did.

And yes, Agile says you should do that (principles 1 through 3 of the Agile manifesto). And I agree that following the Agile principles is a good idea for your project. Do not confuse with Scrum (1986).

---

※: If you read the waterfall paper, it is all about how it goes wrong.

Answer 5

You have found the nicest way to do it: discuss with the customer, build something, discuss and change it until the solution is clear. Basically, whenever the problem can be solved solo, do it like you did.

When challenges get more complex and more people need to get involved, an agile variant is to discuss with the customer, write down some user stories, let the team perform a sprint for a first version, present it to the customer, take note of more user stories, and go on for the next sprint, until the product is finished.

When it gets really complicated, then you'd better go for user story mapping or use-case 2.0: you discuss in a workshop to get the big picture, and then cut in it into a couple of initial user-stories or use-case-slices and add new ones on the flow whenever needed. Stories or slices are processed in sprints as above; you simply need more sprints to do the work. Note that each iteration delivers, presents, discusses (early feed-back from user is the key, just as when you discuss with your uncle).

Sometimes it is really complicated, but you need to have a good product concept before you start. For example if you want venture capital to finance the team that you'll recruit. In this case, you could start with a design sprint. Read Jeff Knapp's book: you can apply it whether you want to build software, robots, AirBnB (spoiler alert on the book). Note that design sprints are about product design (main features, look & feel,...): once you have hired a team, just go back to one of the approach above.

Now, to complete de picture: If you are working for a huge organization, or if your software is only a small part of a much larger endeavour, you might have to start, drafting a software requirement specification and follow the V-model to design the system, the components, and all the corresponding tests. This works well in some very demanding domains like sending some satellite in the outer space or robot on mars. But in many other domains, this more traditional approach bears some risks. Requirements might take you an awful lot of time to write. Your users might approve it despite they do not grasp at all what you're meaning (or they understand something else). In the end, the delivered product might not be what the user expected, or might no longer fit the user requirements that evolved in the meantime.