Why is requirements gathering difficult




















The factors driving the people category are typically the most volatile and seemingly least controllable of all of the variables within the requirements process. People have a major impact on the vagaries of requirements. All of the strengths and weaknesses that individuals and groups bring to the table will influence the final requirements product.

A few of the more intractable contributors to requirements variance are:. Two types of experience are the most germane to this discussion. The first is whether participants have knowledge of the problem space from a business perspective.

Without that, the requirements may not practically address the project needs. Knowledge of and experience in the problem space is critical for effectiveness. One technique that has been developed to mitigate this risk is to ensure access to business knowledge through co-location with a business partner. This kind of access is a central tenet of the most of the Agile methods. The second category is experience with the requirements process itself.

Without experience gathering, recording and managing the requirements process, it will be difficult to ensure information gathered is correct and that the results developed will be apt to be more costly than necessary and less valuable than needed. Agile methods use coaching to reinforce this knowledge and experience, while other methods use training and processes. The goal is the same in both cases: efficiency and effectiveness. This article focuses on some common problems when gathering requirements and suggestions on how to overcome them.

In many organisations there is often no or very poor documentation available about existing processes. In this situation, requirements gathering becomes a two-step process. Firstly, back-engineering of existing process, and then identifying areas for improvement and optimisation.

This helps eliminate any assumptions and provides a full picture. Drawing business process maps and visualising workflows are effective techniques that can be used in this situation.

Uncertainty about exiting process or different priorities for different stakeholders, often leads to conflicting requirements.

If this is the case, the role of a business analyst is to document all requirements, identify contradictory requests and let stakeholders decide on priorities. Setting up a poll can be one of the ways to get clarity about what is important to the majority of stakeholders.

Unavailability of end users may occur due to a few reasons and requires appropriate resolution. Sometimes end users are too busy with their day-to-day work and unwilling to participate in requirements gathering activities.

In such situations the best a business analyst can do is to minimise the number and length of engagements. Undocumented Processes - This is the reality in most organizations. The business runs with "word of mouth" or poorly documented processes and procedures. The business analyst is often forced to reverse engineer the business processes every time a new projects is started. What the BA can do : Document existing business processes and the differences among the various users. Lack of access to end-users - On many projects the stakeholders and IT management "think" they understand the requirements and what happens in the business and do not enable or allow the business analyst to have direct access to the end-users.

What the BA can do : Present your case to the project sponsor as to why it is key to observe the users at work and find out how each activity is actually performed and the types of problems faced by the user in their day-to-day work. Instability of UI Preferences - Stakeholders and end-users who are new to the requirement elicitation process or who are faced with new or unprecedented concepts or processes tend to have a hard time identifying and feeling good about their preferences and, therefore, they tend to keep changing their minds.

What the BA can do : use prototypes and other visual tools such as diagrams to gather, document, and verify requirements. Abundance of Choice - When stakeholders or end-users are presented with too many choices they generally have a harder time deciding the option to select.

When they do make a decision they are less satisfied than if those who have to pick from a much smaller list of options. If you can buy requirements, do so, because that is the fastest and most economical way to develop a list of requirements. This is the process of taking features from potential software products and reverse engineering them back into requirements.

Essentially, you are running the software development process backward. It is a very robust process because it finds requirements the organization does not know they need. It also ensures the latest innovations on the market are considered. Typically, this information comes from software product user documentation and software demo videos. Business-critical enterprise software is usually used by multiple departments in an organization, and this means requirements can number in the thousands.

Reverse engineering requirements is slow, for example, it can take between to hours of work per thousand requirements generated. Once a comprehensive list of requirements has been gathered, they must be rated for importance to the organization.

This essential step documents who wants each requirement, why they want it and how important it is to them. Asking users to rate requirements for importance and capturing their names on those requirements builds tremendous buy-in to the project.

Rating them also allows requirements that are less than important to be eliminated, e. This gap analysis is the key to identifying the best-fit software that will maximize ROI. When you think that the TCO of enterprise software often runs into the tens of millions or more, maximizing that ROI will make a significant difference to the bottom line. Chris Doig is CEO of Wayferry , a consulting company that helps organizations select enterprise software.

Chris is also the author of Rethinking Enterprise Software Selection: Stop buying square pegs for round holes. You can contact him to discuss this article or join the Wayferry mailing list.



0コメント

  • 1000 / 1000