The basics of requirement gathering

April 12, 2016 | by Alejandro Hernandez

In App development, developers

Requirements are the definition of the dream product or solution to be developed. I like to use this Christmas analogy: requirements are like a Christmas wish list, and you are Santa Claus.

Be SMART, really SMART

A requirement is a characteristic that a product should have or should add in order to provide value. It is a condition that should be accomplished for a product or service in order for it to be adequate.  It is a capability needed by a user to solve a problem and accomplish an objective.

Nevertheless, a requirement is not an informal request from somebody in a meeting, in the hallway, in an email or in the elevator. Nor are the comments during marketing or sales events. Everything should be formally requested, documented, analyzed thoroughly, and officially approved.

Gathering requirements is not an easy task, and we have to be very careful. Our requirements should be SMART, too.  Let’s see what I mean by that.

Focus on the main goal

S

S is for Specific. Each requirement should completely describe the functionality that will be implemented. Remember to never assume anything.  Use words like should, must, or allow.  Avoid using words like could, maybe or would be good. Don’t use vague or ambiguous phrases like “it should be fast”, “do it well” or “not so important”, instead I recommend to use phrases like “It should respond in less than 30 minutes” or “insert 100% of the records”.

M

M is for measurable. Each requirement should be able to be tested or verified and tracked to determine if it is properly implemented. This is important because measuring requirements will essentially define how your project will flow.

A

A is for achievable. The requirements should be tasks that the company and working team will be able to implement. You also have to consider the capabilities and limitations of the system and operation environment you are working with.

R

R is for relevant. Each requirement should have an implementation priority to indicate how relevant each task is. There should be functional and technical specifications relevant to systems within the business.

T

T is for time-based. You should define your timeline from start to finish.  Do this based on needs and goals. A commitment to a deadline helps a team to completely focus their efforts on completion of the goal.

Everything should be formally requested

Remember that all requirements should be specified as clear as possible because a third party will be the one designing and developing the final product. Be concise and your project results will be on point.

 

SOURCES

Gilberto Grajales (2012). Conference on Requirements Engineering. Mexico.