Failed requirements are one of the most common reasons of failed projects. Who’s to blame? Who made them unclear or misunderstood, intentionally or accidentally? Nah, there is nothing interesting in figuring all that out. What’s much more interesting is how to prevent receiving not what you want. Here are some helpful tips to start gathering requirements for your project with. In fact, the more of these are missed, the more problems may arise later, with everyone having to sit late at night and solve them.

Step #1. Document Everything

When you are driven by passion for what you want to do and share with the world, you seem to remember everything perfectly. But writing things down has lots of pros. One, it’s a good start for the documentation, which is more useful and impressive than words – for both developers and investors. Two, you won’t lose details (which do tend to be lost). Three, when you write an idea down, you develop it right there, then come up with another one, and so on. New and useful ideas always come when you pay them due attention.

Step #2. The Sooner You Set The Goals, The Better

The universal rule for any project. The goals of your project must be written down, and you’ll have a basis for the upcoming decision-making. All of your requirements will help the project achieve its goals one way or another. If a requirement is of questionable importance for satisfying the objectives, most probably it can be left on the shelf until later.

Step #3. Set The Right Priorities

The main priority is user. Startups don’t have yearlong time to roll products on the market – they let their development walk the agile way, offer a minimum viable product to users, and improve upon each new update. This natural scheme of things works through prioritizing features. Research of the market and professional opinion in your subject area will help you determine what is ‘needed’ and what ‘would be nice’. Until the first user feedback, which will help you move on.

Step #4. Look For The Right People And Listen To Them

We already discussed before how and where you should look for the development team to do the job, so you may check these articles to learn more. Here we’ll mention that the right people may include investors; those who are able to help your product with marketing and media coverage; and those who can help you with testing your future product – the actual users. It goes without saying that professional feedback is valued for the sake of a great product.

Step #5. Think About Requirements, Your Team Will Find The Tools

Specifications, sketches, notes, diagrams, user stories, goals of the product – this is what matters to your team. The choice of the right tools comes after the scope of work is more or less clear to them. Determine what you need, not how it will be done. Don’t waste your time on what your project manager and developers will do for you and your users.

Step #6. Get Rid Of Ambiguities

Once you’ve found the right people to do the job, be clear and share your vision. Always make sure your team understands all the terms you use the way you see them. Illustrate everything whenever you can. When you systematize your requirements and use certain terms and abbreviations, make sure to structure them – it will be valuable for the team in the future. Not to mention it’ll save plenty of time.

Step #7. Never Neglect The Details

Many details pertaining to your product may seem generic and obvious – but never ever trick yourself into it. Write all of them down in a structured way. Don’t rely on vague assumptions. There’s no such requirement as ”users will need to create an account”. How many steps will it take? What fields do they need to enter? Do they need to confirm the activation via email? Will they be able to create it in one click through Facebook? Or Twitter? What data will be accessed then? Within the answers lies the feature.

Step #8. Keep In Mind: You’ll Miss Something Anyway

You won’t capture everything. Something changes (say, priorities or technologies), something gets forgotten (say, some detail about a feature), something needs to be altered because of that, and somewhere there may be a mistake. Planning ahead is essential, but the point is being ready to fill in the gaps quickly and effectively. Keep your hand on the pulse of your project.

Step #9. Try Writing User Stories

”As a <user type>, I want to <get the value from the product by using a feature, with the result described>.”

If you roughly know how your software is supposed to look like, you may try writing user stories with the help of sketches, proceeding from screen to screen. A great way of explaining your features to your team, and understanding your users. You won’t make it perfectly, but it’s not required either – everything will be worked out during the development.

Of course there is more to gathering requirements – but here is a nice way to start with. Moreover, your development team will definitely appreciate the approach described here. We have several other articles about requirements – you may find them below, and get acquainted with further insights.