The Community Blog for Business Analysts

Ken Young
Ken Young

5 Pitfalls to Avoid in the Requirements Development Phase

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 ken.young@blueprintsys.com.

This entry was published on Aug 07, 2013 / Ken Young. Posted in Requirements Analysis (BABOK KA) , Requirements Management and Communication (BABOK KA), Functional Specifications, Business Analysis. Bookmark the Permalink or E-mail it to a friend.
Like this article:
  3 members liked this article

Related Articles

COMMENTS

Only registered users may post comments.


Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.



Modern Analyst Blog Latests

Jarett Hailes
Jarett Hailes
As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
3 Responses
Howard Podeswa
Howard Podeswa
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
14 Responses
Adrian M.
Adrian M.
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN
1 Responses
Featured Digital Library Resources 
Copyright 2006-2019 by Modern Analyst Media LLC