Requirements Development

This post is part of a series of writings about my point of view on some chapters of the book Software Project Survival Guide by Steve McConnell.
15851915765_55be93afdc_z
«Cake» flickr photo by Blondinrikard Froberg https://www.flickr.com/photos/blondinrikard/15851915765

For cooking a cake you only need: a list of ingredients, some basic cooking skills, cooking utensils, time and, of course, passion. You can make the cake all by yourself, but is way better to cook with some company. You may be wondering, what the heck does baking a cake have to do with making software? Well to some extend, is basically the same. To make software you need a list of requirements, some coding skills, tools to make the software, time and, as I mention earlier, passion (most of the times). Each of this activities have their our complexity, it’s not so simple to bake an excellent cake as it is to make a perfect software. Both of this activities could not be achieve, if one simple thing is missing and that is a: list. You can’t make a cake if you don’t know the ingredients, and you can’t start developing software if the list of requirements is missing. Requirements are of vital importance when starting a software project.

A key phase, when developing software is requirements development. The main focus of this phase is to have a clear idea of what the final product is going to do and to whom it is target. There are three main activities, in this phase, which are: 

  • Gathering candidates requirements.
  • Specifying requirements.
  • Analyzing requirements.

The first activity is mostly about identifying key users and seeing what they want. It is very important to know, who is going to be your main users. When you have identify them, you need to ask them what they think of the idea, if they would use it, and so on. With all the data you gathered from the possible users, you need to start building simple prototypes to some how visualize your idea. You can make a prototype as simple as you what, it can even be a paper one. You have to take in mind that is ONLY a prototype, so don’t get marry to it. A first draft, is not always the last. 

In the second activity, you are putting the requirements on paper. The idea is starting to take a better shape, so by this step you need to start documenting all. You can even start by making a more useful prototype. In this step, is important to start building a User Interface Style Guide, that establishes how the app is going to look. With this the application starts to gets a vision of how it would be. As I mention earlier, you can start making a prototype that can help you as guideline for your final product.

The third activity is about making a filter of the requirements that you have. You need to see what are the things that you can leave behind, or even not put them in the first version of your app, but in a future one. Requirements are a essential in any software project, so before you start one check that you have done all the correct things to have the requirements you truly need.

Stay Safe

A.C.

References

McConnell, S. (1998). Software Project Survival Guide. Redmond: Microsoft Press.