5 Common Errors In Requirements Analysis - Online Article

Problem 1: Customers don't (really) know what they want

Possibly the mostcommon problem in the requirements analysis phase is that customers have only avague idea of what they need, and it's up to you to ask the right questions andperform the analysis necessary to turn this amorphous vision into aformally-documented software requirements specification that can, in turn, beused as the basis for both a project plan and an engineering architecture.

To solve this problem,you should:

  • Ensure that you spend sufficient time at the start of the project on understanding the objectives, deliverables and scope of the project.
  • Make visible any assumptions that the customer is using, and critically evaluate both the likely end-user benefits and risks of the project.
  • Attempt to write a concrete vision statement for the project, which encompasses both the specific functions or user benefits it provides and the overall business problem it is expected to solve.
  • Get your customer to read, think about and sign off on the completed software requirements specification, to align expectations and ensure that both parties have a clear understanding of the deliverable.

Problem 2: Requirements change during the course of the project

The second most commonproblem with software projects is that the requirements defined in the firstphase change as the project progresses. This may occur because as developmentprogresses and prototypes are developed, customers are able to more clearly seeproblems with the original plan and make necessary course corrections; it mayalso occur because changes in the external environment require reshaping of theoriginal business problem and hence necessitates a different solution than theone originally proposed. Good project managers are aware of these possibilitiesand typically already have backup plans in place to deal with these changes.

To solve this problem,you should:

  • Have a clearly defined process for receiving, analyzing and incorporating change requests, and make your customer aware of his/her entry point into this process.
  • Set milestones for each development phase beyond which certain changes are not permissible -- for example, disallowing major changes once a module reaches 75 percent completion.
  • Ensure that change requests (and approvals) are clearly communicated to all stakeholders, together with their rationale, and that the master project plan is updated accordingly.

Problem 3: Customers have unreasonable timelines

It's quite common tohear a customer say something like "it's an emergency job and we need thisproject completed in X weeks". A common mistake is to agree to suchtimelines before actually performing a detailed analysis and understanding bothof the scope of the project and the resources necessary to execute it. Inaccepting an unreasonable timeline without discussion, you are, in fact, doingyour customer a disservice: it's quite likely that the project will either getdelayed (because it wasn't possible to execute it in time) or suffer fromquality defects (because it was rushed through without proper inspection).

To solve this problem,you should:

  • Convert the software requirements specification into a project plan, detailing tasks and resources needed at each stage and modeling best-case, middle-case and worst-case scenarios.
  • Ensure that the project plan takes account of available resource constraints and keeps sufficient time for testing and quality inspection.
  • Enter into a conversation about deadlines with your customer, using the figures in your draft plan as supporting evidence for your statements. Assuming that your plan is reasonable, it's quite likely that the ensuing negotiation will be both productive and result in a favorable outcome for both parties.

Problem 4: Communication gaps exist between customers, engineers andproject managers

Often, customers andengineers fail to communicate clearly with each other because they come fromdifferent worlds and do not understand technical terms in the same way. This canlead to confusion and severe miscommunication, and an important task of aproject manager, especially during the requirements analysis phase, is toensure that both parties have a precise understanding of the deliverable andthe tasks needed to achieve it.

To solve this problem,you should:

  • Take notes at every meeting and disseminate these throughout the project team.
  • Be consistent in your use of words. Make yourself a glossary of the terms that you're going to use right at the start, ensure all stakeholders have a copy, and stick to them consistently.

Problem 5: The development team doesn't understand the politics of thecustomer's organization

Aneffective manager is one who views the organization as a "contestedarena" and understands the importance of power, conflict, negotiation andcoalitions. Such a manager is not only skilled at operational and functionaltasks, but he or she also understands the importance of framing agendas forcommon purposes, building coalitions that are united in their perspective, andpersuading resistant managers of the validity of a particular position.

These skills arecritical when dealing with large projects in large organizations, asinformation is often fragmented and requirements analysis is hence stymied byproblems of trust, internal conflicts of interest and informationinefficiencies.

To solve this problem,you should:

  • Review your existing network and identify both the information you need and who is likely to have it.
  • Cultivate allies, build relationships and think systematically about your social capital in the organization.
  • Persuade opponents within your customer's organization by framing issues in a way that is relevant to their own experience.
  • Use initial points of access/leverage to move your agenda forward.

Hopefully, thisdiscussion should have served to both make you aware of potential pitfalls inthe requirements analysis phase, and provided some guidance about how to avoidthem. Good luck!

About the Author:

No further information.


No comment yet. Be the first to post a comment.