One of the first steps in any projects is gathering and defining requirements.  These are needed to measure whether the features being built are useful.  Requirements also give us a way to map progress and eventual success.  Sometimes there are projects where we will have all the information we need to get started.  However, most projects will require us to gather, define, and refine these details from others.

Gathering Requirements

The process of gathering requirements from others can be complicated and time consuming.  Luckily, this is not always the case.  Gathering requirements can be straightforward when you follow the step below.  The order is not as important as performing each of these along the way.

Find The Focus

This is the primary reason for the project in the first place.  It is often a problem or group of problems to solve.  There should be a business reason for solving the problem.  Make sure this reason is understood.  Some requirements will be set directly from this focus, but it has a greater value.  That value is to lay a foundation for the requirements.  When a requirement is assessed, the focus of the project determines whether to include or exclude.

For example, assume the focus of a project is to provide a quick way to enter a shopping list on a mobile device.  A requirement to force the user to enter a login and password each time would be excluded.  That function goes against the focus.  Not every requirement will be that easy to assess.  However, knowing and sticking to the focus can avoid scope creep.

Define The Foundation

In this step, the goal is to define some of the base features of the solution.  Over time these sort of features become standard questions for a stake-holder.  These will vary depending on the project.  However, this list is a good start.

• What are the security considerations? Multiple Users?
• Will reporting be required?
• Is auditing or logging going to be required?
• Does this require an offline/online mode?
• Is mobile support needed?
• How will this be used? (Web, Desktop, Mobile, etc.)
• Do users need to be able to interact with each other? Be grouped?
• What features will be used often and which used rarely?
• Will data need to be kept forever? Briefly?

Create a Plan

Once the requirements are gathered it is time to create a plan.  USe the requirements to build a story of how the solution will be used and how it will work.  This process is important for verifying with stake-holders, but also helps find gaps.  When requirements are viewed as a whole then often gaps will appear.  Think of a story with loose ends.  When requirements are not complete there will be loose ends that need to be addressed.  Thus, more requirements need to be defined.

Verify Your Assumptions

Take the plan to the stake-holders.  The plan should provide a complete story that makes sense to them.  This not only provides validation for the requirements that have been gathered, it also ties them together.  This step is often one that sparks stake-holder discussions about process steps and outliers that were missed.  However, It is often not a reflection on the requirements gathering.  Instead, it is a way to prompt for outliers and rare occurrences.