A plan for requirements gathering

A plan for requirements gathering

When creating software program how do you get from an idea to a detailed list of things that need to be accomplished? This question is not easily answered. There is a road to get there, others have traveled this road and mapped the pitfalls. The following is a brief description of the basic parts of the process.

Understand the problem you’re tasked with solving:

This may be the hardest part. If you’re successful here chances for successful delivery of a working and useful program increase greatly. The first step is to create an honest and thorough description of the problem.

This looks like:

  1. Build a list of stakeholders – these are the people who’s input, if left out, would likely result in a program that fails to launch. Obvious members of this group are users and management, but there are likely others who have valuable input. Seek them out and include their opinions. Divide the stakeholders into groups. Each group of stakeholders will need to elect a representative leader who can speak for the group in periods where consensus cannot be achieved by the group itself.
  2. Meet with each group of stakeholders individually. Record what must be accomplished and what would be nice if accomplished. Build a definitive list of needs and desires.  Next, call a meeting with the group leaders to go over the needs and desires. The leaders have final say in what’s in or out of the product. You’ll gain much clarity at this point in the process.
  3. Meet with your team (if you have one) to discuss the product must-haves and the technical requirements necessary to make the product must-haves possible. If you don’t have a team you still need to work through this step. The user functionality requirements will drive the technical requirements and you need to map out the technical requirements.
  4. Set a schedule based on your estimates of fulfilling the required features, both functional and technical. Notify everyone who sees the schedule that it’s not set in stone, that’s it’s likely to change over time. Having a schedule, and honestly attempting to meet it, will force accountability to create positive progress. But you get to modify the schedule if something gets added to the product or if the stakeholders decide to make a significant change to the requirements.
  5. Using your schedule begin with phase 1 by building a rough prototype of the first part of your project. This can be on paper or using a mock-up tool. Show it to the stakeholder group that will be using this when it’s finished. Tell them that it’s just a mock-up, it’s not supposed to be perfect, but it should be functionally complete with representative buttons, text fields, display areas, lists, etc… Pencil in any additional features until everyone agrees it’s functionally complete.
  6. Build and maintain a list of risks that the project faces as it evolves. Show this list to the group leaders so they understand what might cause the project to fail. Risk can include anything from “not enough testing” to “the developer environment is too noisy”. If the stakeholders are serious about you finishing the project they will help you address the challenges you’re facing.

At this point you have something tangible that describes with great detail the challenge you must overcome.

Happy building!

Leave a Reply

Your email address will not be published. Required fields are marked *