The Community Blog for Business Analysts

Developing requirements is a process with many moving parts. It involves aligning multiple stakeholders from different areas within an organization to determine what must be developed to fulfill a business need.  Because it is a process, there are a number of factors that can cause the process to break down and lead to the development of faulty requirements:

• Lack of Clear Objectives: Every application is built to play a role in some larger business context.  When the business client is unclear in communicating the purpose of the application, or stakeholders lose sight of the application’s business context, the requirements in all likelihood will “miss the mark”, lacking essential functions and including unnecessary features.
• Lack of Stakeholder Involvement: One of the biggest challenges in the requirements process is getting stakeholders to invest their time, over multiple elicitation sessions and then multiple review cycles, to carefully examine the requirements and provide feedback. When stakeholders are inaccessible, or are not invested in the project during the early phases, requirements flaws can remain undetected until after development begins.
• Inconsistent Information Gathering: When developing complex applications, a team of business analysts will often be involved in gathering information. When inconsistent elicitation approaches are used to gather and record information, it becomes difficult to categorize, prioritize, and ultimately reconcile the often conflicting needs of different stakeholders.
• Information Overload:The traditional reliance on recording requirements in long, unwieldy text-based documents not only leads to misunderstanding, but also contributes to stakeholders’ lack of involvement in the requirements development process. Using long text-based documents makes it hard for end-users and business clients to picture how the application will behave, and what may be missing.
• Poor Expression: To review requirements, and ultimately build applications, all stakeholders, from the business client and end-user to the application developer and tester must be provided information in formats and using language that each can understand. Delivering information in forms that don’t take into account the different types of stakeholders inevitably leads to flawed requirements and the development of applications that don’t fulfill the objectives of the business. 

When developing requirements, check to ensure that you have avoided the pitfalls above and your requirements are much more likely to be complete and effective.

Ken Young works for Blueprint, The Requirements Company. He can be reached at [email protected].