Common misconceptions about Requirement elicitation

Requirement gathering is generally a part of a much larger concept, namely Requirement Management. As mentioned in our previous article, there are multiple methodologies for collecting requirements and any of them or a mix of them, depending on the scenario and your personal preferences, help us in understanding, collecting, documenting and conveying requirements to developers and QA team. At the end of the day, all said and done, it is important to understand that requirement elicitation is an art and, just as with any other art form, we get better in this area with practice.

Technical people or people with development backgrounds are best at requirement management:

Requirement elicitation needs perspectives from multiple stakeholders, persons, and even documents. This could include business leaders, marketing, legal teams, IT (development, security, analytics teams), end users, end customers, human resources, operations team, etc. This list would vary depending on your specific project. It is important to balance inputs from all stakeholders and ensure that stakeholders are involved right from the get-go.

Sometimes varying people can come up with a multitude of requirements, problems and solutions that might spill over the scope of current project. It is good to add these to the backlog for future considerations as some of these might impact the functionality of the end product and help in preventing conflicts at later stages.

To conclude, technical people might have more experience but they need inputs from all concerned stakeholders to get complete requirements.

Requirements are technical specifications:

Requirements are a solution to a problem and not just a technical specification. They are generally a collection of features. One needs to understand the problem at hand to device an appropriate solution.

Generally, the requirements can be broken down into functional requirements, basically what the application must do to meet its end goal, and non functional requirements which includes what the application must have, say security, global availability, browser specificity, performance, etc. As BAs, we need to pay special consideration to non functional requirements as they often become a source of concern towards the end of the project and lead to scope creep. Some of the non functional requirements are as mentioned below. The below list is not comprehensive and might not be required for a single project. However, considering all such non functional requirements helps in ensuring that there are no last minute grievances.

• Usability Requirements
• Performance requirements
• Storage requirements
• Portability requirements
• Reliability requirements
• Implementation requirements
• Compliance requirements
• Legal requirements
• Marketing requirements
• Safety requirements
• Privacy requirements

Requirements come from only product stakeholders involved in the business:

As mentioned in the first point, various viewpoints can be collected from various sources, some of which might not be a part of business. Try to focus on the various unconventional sources that might provide you requirements. The requirements can be collected from these various sources using some methodologies mentioned as a part of previous article.

BAs can throw requirements off the fence onto the development team:

Once the requirements are transferred to the development team, BAs need to continue to remain a part of the development team, making sure that all requirements follow the SMART criteria. BAs need to be engaged throughout the development of the project and might have to don the hat of QA, whitebox tester, destructive tester, etc.. It has been seen that teams in which additional members are involved from the get-go tend to prevent single point of failure.

Large organizations tend to separate BAs from the development team but for a successful project, BAs would need to merge as a part of the development team.

Requirement gathering needs to be perfect and complete on the first go:

This is quite often expected by both large and small organizations. Almost always this is impractical. Flushing out complete set of functional and non-functional requirements tends to lead to loss of time. In some cases, businesses might not even know the complete set of requirements. Continuous collection and review of requirements amplifies the team's ability to be successful. Of course, features need to be prioritized based on there need. However, irrespective of this, it is important to continuously identify and collect requirements.

In short, the development cycle is still the same but multiple small short iterations will need to be made through the above cycle. As can be seen, the requirement gathering feeds into the development of project and the requirements have to be continuously honed.

Requirements need to be prioritized one time:

Requirements need to be prioritized regularly and endlessly. No one understands their whole project, marketplace, requirements, etc. at the get go. When the requirements are validated with say technical architects, marketing/legal teams, product owners, and even analyzed by the business analyst, changes will need to be made to the requirement. Re-prioritizing this is important to ensure that loss of effort and cost is minimized. This re-prioritization can be done by using multiple methdods such as MoSCoW method, etc.

Requirements and software architecture go hand in hand.

Actually, they do not. This often stems from the method of working of Business Analysts who come from a technical background. However, to be clear, requirements define the solution to a business problem. However, software architecture defines the actual design of the software/application being designed. However, this is not to say that if the business solution is "technical", then in all probability the requirements will also be "technical".

Requirements are prioritized based on everyone's consensus:

This is actually one of the least productive way of prioritizing requirements. In such group settings, sometimes only some voices which tend to be larger tend to prevail. Some people tend to be quieter or shy and thus, their inputs might not be heard. Hence, everyone's inputs need to be heard either through one on one interviews, observation, surveys, etc. Having a product owner or champion definitely helps in sailing through this issue.

Above are some of the most common myths concerning requirement elicitation.