What is a requirement?
At its core, a requirement is identifying what you’re supposed to be building, and why you’re building it.
Without clearly stated goals and objectives, you are lacking a framework to guide future decision-making.
Successful requirements gathering is both an art and a science.
Requirements dictate the functions, behaviors, inputs, and outputs of the system; just to list a few. Several types of requirements exist Business, Functional, Non-Functional, UI, etc.
If not well defined, communicated and understood, the output of the development cycle could be completely different than initially anticipated. A classic example.
Again in the spirit of simplifying and making abstract concepts easier to understand lets define in simple terminology what software requirements are.
Make it a recipe
When baking a cake, you are provided with a clear set of instructions; 1 cup of flour, 2 eggs, 1 tsp of vanilla extract, etc. Instructions on how long to bake and at what degrees are also provided; cook for 20 – 25 mins at 350 F.
This is simple. You know exactly what goes in and what the expected output is.
Defining requirements for a software application is exactly the same, it’s building a recipe to build something.
The functions and steps required for the application to meet certain needs have to be defined, documented and shared.
They have to be specific and relevant to the task. Reviewing them and adjusting are also key. Who says you will get the recipe ingredients and measurements correct the first time.
Requirements Gathering Methods
Requirements will be gathered and refined throughout the project lifecycle. It includes a set of activities; gathering, documenting and understanding.
To gather and document different techniques can be used: brainstorming, document analysis, focus group, prototyping, workshops and more.
Someone involved in software development regularly will be able to provide better requirements than someone who is not. Understanding the level of comfort with software development will help define what techniques will be used.
At this stage, we are building the ingredients list.
Documenting Requirements
Once the ingredients have been identified, we have to write the steps, in a logical order, which will lead the developers into building the expected application, with the proper features.
They have to be clear, concise and to the point. A requirement, like a step in a recipe, should only contain one set of instructions. If there is more than one set of instructions in a requirement, it is too long or too complicated. It has to be refined.
A written requirement must clearly state the function and steps to achieve it. Images, graphs, charts, and diagrams are also good to include visual aids.
If a requirement cannot be straight and to the point, it is not well understood. Further discussions must happen at this particular point.
Keep track
Once the ingredients and steps have been clearly defined, keep track of what has been completed, what’s changed and what will come next.
It is expected things will change or be refined as the project progresses. It is important to keep track of these changes. Not keeping track of the changes will contribute to a situation similar to the image here above, where what was asked is not what was delivered.
There are plenty of resources to help gather, document and track requirements. They can be as simple as Excel spreadsheets. Find what works best with your style.
The important thing to remember is to not begin on a project until you have a clear understanding of what is needed, and even more critical, that you can articulate it to others. If this is not achieved, the success of the project and outcome are at risk.
Comments