condensing business requirements into technical specs [closed]

Question

I work in the IT function at a large retailer and we have just started a project with the business to redesign a key system for our Website.

The business users know they want to update the system and improve it. They have some very very high level principles around how it should work but that's about it.

Management want the dev team to start "doing stuff" because there is resource available.

I'm struggling to think about the best way to spend our time as a dev team. Sitting down with the business users hasn't yielded much more than a few more very high level principles or things they don't want it to do but certainly nothing I would consider approaching requirements.

How can you link concrete implementation of features to vague business requirements and ensure that the business will be happy with the results, given a lack of technical expertise and buy in from a business?

Answer 1

From my experience, I would not spend a single minute developing. Not even a little piece of code. At this stage, where the customer doesn't know what he wants, it's really important to do a good job of consulting. It's as important for them as it's for you.

Behind each project, there's a need (sometimes isn't obvious) related to the customer's business. So, in order to clarify the need, you first have to learn the business as much as possible. Then you will be able to lead the customer to a functional solution.

During the learning, be careful at the time of differentiating needs and whishes. What customer need might or might not to be the same than the customer wants?

While the analysis, if the customer doesn't take decisions, take them yourself. As consultant your job is to give advice and to lead the process.

As @Ewan pointed out, it's easier for the customers to make decisions if there's any choice to do. Offering several alternatives (exposing their pros/cons), makes easier the decision-making. Mocking up prototypes is a good way to give an overview of what you have in mind for them. Customer will have the first contact (and feelings) about how things are going to be. Doing this exercise of "creativity" you will see quickly the lights and shadows of the project before they become a problem.

Try to get as many feedback as possible from the end user. So many times the person who we call "the customer", it isn't who is going to use the system. In such situation, you will get better feedback from the real end user. They will provide you with valuable tips about what they need. Identifying well who can provide the right answers to your questions will help you to meet customer's expectations.

Once you have collected a good set of requirements, put them into the prototype. Agile methodologies like SCRUM works fine at this stage. Doing sprints over the prototype.

Prototypes are going to be discarded/modified along the sprints. You can also "guide" the customer to the one that suits you best. ;-). Looking for a win-win deal.

I try to prevent Managers from starting the development before any well defined and measurable requirement has been signed off. Otherwise, starting with undefined requirements is fated to fail badly. A lot of money and time is going to be wasted (with no guarantee to recover it) because someone has decided to implement "the Chaos". The Chaos and the uncertainty where our so beloved and confused customer lives right now.

It's shocking to see companies whose employees do their job but they are not capable of explaining (reasonably) to you how. It's shocking also to see how many Project Managers doesn't care about this problem, they just say "yes to all" or "let's start and we will see what happens".

Finally, @Ewan again pointed to the most important point.

Get the customer to sign off on the ones they want and implement.

Don't forget to define clearly, which requirements and conditions need to be met in order to say the project is done. The acceptance conditions

No need to say why.

Answer 2

Write a document proposing 2 or 3 solutions along the lines of :

"To achieve 'high level principal x' we propose 'Technical solution y' which will 'thing techincal solution does'"

Get the customer to sign off on the ones they want and implement.

Answer 3

It is difficult to advise without being able to judge the mood music accurately.

Either:

The business users and management aren't doing their jobs and are just kicking the can down the road for the devs to deal with (and so they can kick the devs when things go wrong).

Or:

They're really not sure what they want and need to be guided by the dev team.

---

Naturally, the 2nd scenario is more preferable. You can wire frame some designs and roll in the dirt with it until you have a plan of sorts.

If you're dealt the first scenario be absolutely clear that the things that kill projects time and time and time again are woolly requirements and not having a concept of "done". Sure the project will get done eventually but how much money will have been torched before then?

Answer 4

At some point, the developers need a set of requirements where they can develop an application and later check whether it meets the requirements or not. And then they go and build an application that meets the requirements.

And it is a really, really good idea to have requirements where an application meeting the requirements benefits the business :-)

Someone needs to create these requirements. The owners of the business can't. The developers don't want to. The developers tried to make the owners of the business create requirements but didn't succeed. Still, someone needs to create these requirements.

You can try to find someone in the company and make it his job. Not like the developers did at first, trying to ask for requirements but failing, but pick a person and make it their full time job. If the development team feel they can create the requirements, then suggest it to the company, and be assigned the job, and the authority to do so.

Either way, it will be someone's job to create the requirements. And it needs to be made clear that if the development team creates the requirements, the requirements are what the company will get, and if they don't like it, then they need to make sure that the requirements are changed. Best to do this before the development work starts.

And you don't need to give people choices. You can tell them that what is in the requirements is what will happen, and they can either sign off on it, or complain and the requirements can be changed.

Answer 5

If you feel a prototype is too polished and will confuse the client, just sketch it out. You can have multiple versions if you think that will help prompt the client.

This will fulfill management's need for you to do stuff without creating a bunch of code that you will throw away (If you know what's good for you.).

The client also needs to know that they have to pay for this type of thing. Otherwise, there's little incentive to get them moving on the project. It may benefit the meetings if you can narrow down those that are really involved in the project and the decision making without a lot of people throwing in their useless suggestions that will only slow things down.

Answer 6

Let's do a thought experiment: imagine you want to build a house from the ground up, and you know nothing about construction. How do you describe the requirements to the builder? Even if you could, they would likely be vague statements like "I want to make sure I have plenty of closet space" and "I want a modern kitchen". Obviously you can't be expected to know all the ins and outs: the architect drawing the plans will ask you a ton of questions, and make some decisions on their own according to industry best practices.

This is where you are: someone has decided they want something, but they're having a tough time explaining exactly what they want to you. It's your job to work together with them to figure it out.

If there's a resource available, and you have high level principles, start decomposing those principles into user stories. From there you can come up with a list of tasks to do. Make suggestions along the way, but make sure that you fully understand the business need for the update first. Is performance poor? Is it insecure? Is the design outdated? It's up to you to handle a lot of the details that your end users aren't aware of. Document the choices you made and why, and have the business users (or the applicable person) sign off on them. Now you've got requirements!

Remember, a developer doesn't need to be coding all the time: they should be planning a significant part of the time as well. Some of the most important soft skills that a developer can have come from this process of taking vague "business ideas" and turning them into a working project, which outputs a product that fits the business need.

Building a prototype is a great idea to get specific feedback which will lead to better requirements. Keep it light and simple: there are tools out there (here's one) that allow you to build working mock-ups without writing a single line of code.

Also a basic prototype can often be misinterpreted by business users ...

Sure it can: that's why communication is so essential. Explain that it's a prototype over and over. Slap a watermark that says 'DRAFT' on it, whatever. Business users, especially ones that aren't tech savvy, are going to have an incredibly hard time simply giving you requirements, especially if there's nothing to see. If you can quickly work up a prototype they can play with, it will be easier for them to say "I prefer this over that" when you see it.