Five common errors in requirements analysis (and how to avoid them)

This article is also available as a TechRepublic download.

In the traditional
waterfall model of software development, the first phase of requirements
analysis is also the most important one. This is the phase which involves
gathering information about the customer’s needs and defining, in the clearest
possible terms, the problem that the product is expected to solve.

This analysis includes
understanding the customer’s business context and constraints, the functions
the product must perform, the performance levels it must adhere to, and the
external systems it must be compatible with. Techniques used to obtain this
understanding include customer interviews, use cases, and “shopping
lists” of software features. The results of the analysis are typically
captured in a formal requirements specification, which serves as input to the
next step.

Well, at least that’s
the way it’s supposed to work theoretically. In reality, there are a number of
problems with this theoretical model, and these can cause delays and knock-on
errors in the rest of the process. This article discusses some of the more
common problems that project managers experience during this phase, and suggests
possible solutions.

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

Possibly the most
common problem in the requirements analysis phase is that customers have only a
vague idea of what they need, and it’s up to you to ask the right questions and
perform the analysis necessary to turn this amorphous vision into a
formally-documented software requirements specification that can, in turn, be
used 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 common
problem with software projects is that the requirements defined in the first
phase change as the project progresses. This may occur because as development
progresses and prototypes are developed, customers are able to more clearly see
problems with the original plan and make necessary course corrections; it may
also occur because changes in the external environment require reshaping of the
original business problem and hence necessitates a different solution than the
one originally proposed. Good project managers are aware of these possibilities
and 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 to
hear a customer say something like “it’s an emergency job and we need this
project completed in X weeks”. A common mistake is to agree to such
timelines before actually performing a detailed analysis and understanding both
of the scope of the project and the resources necessary to execute it. In
accepting an unreasonable timeline without discussion, you are, in fact, doing
your customer a disservice: it’s quite likely that the project will either get
delayed (because it wasn’t possible to execute it in time) or suffer from
quality 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 and
project managers

Often, customers and
engineers fail to communicate clearly with each other because they come from
different worlds and do not understand technical terms in the same way. This can
lead to confusion and severe miscommunication, and an important task of a
project manager, especially during the requirements analysis phase, is to
ensure that both parties have a precise understanding of the deliverable and
the 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 the
customer’s organization

The scholars Bolman and Deal suggest that an
effective manager is one who views the organization as a “contested
arena” and understands the importance of power, conflict, negotiation and
coalitions. Such a manager is not only skilled at operational and functional
tasks, but he or she also understands the importance of framing agendas for
common purposes, building coalitions that are united in their perspective, and
persuading resistant managers of the validity of a particular position.

These skills are
critical when dealing with large projects in large organizations, as
information is often fragmented and requirements analysis is hence stymied by
problems of trust, internal conflicts of interest and information
inefficiencies.

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, this
discussion should have served to both make you aware of potential pitfalls in
the requirements analysis phase, and provided some guidance about how to avoid
them. Good luck!