Requirements Management Pitfalls

How to recognize and correct requirements related problems during software development projects

Author: Guy Neill, IT Consultant, PMP

Introduction

There is plenty of literature concerning software requirements practices available to IT professionals through books, proprietary methodologies (RUP, Microsoft Solution Framework, etc.) and other sources.  These sources provide extensive information about the best ways to gather requirements, format requirements, and store/manage requirements.

This article will hopefully augment these resources by providing a list of pitfalls related to requirements that software project teams may encounter.  This list has been assembled from real world projects ranging in scope from multi-year banking system implementations to small website development projects.

Since there are many excellent sources of requirements and project management information this article will not go into the details of software projects or how requirements are turned into working software.

How to Think About Requirements

Before diving into the list of pitfalls it will be useful to review some terminology and define what requirements are and what they are not. Stakeholders are anyone or anything impacted by the system under development, most notably the end users and project sponsor.  Stakeholders have goals they expect to achieve with the system and make their best effort to communicate these needs to the project team building the system. The requirements are part of an informal or formal contract between the stakeholders and the project team describing what the team will build for the stakeholders.

These stakeholder needs, once communicated to the project team, are the basic requirements for the software.  They should describe what the system must do, not how the system does it.  The how is the job of the project team.  Figuring out how to build the system to meet the requirements is the design activity on a project – leading to the actual construction/development of the software.  Requirements lead to design which then leads to development.  A project team member often needs to organize, refine, and clarify the stakeholder requirements before they are used by the software designers.

Different types of software projects need different types of requirements management – complex, critical systems need very detailed and complex requirements.  Simpler systems, such as a marketing website where time to market is critical, may need less detailed requirements in an informal format.

Requirements Pitfalls

he pitfalls listed below have cropped up in one form or another during software development projects I have been involved with over the past 12 years.  It is a key task of the project manager and project leads to identify these hazards and ensure the team does not fall into any of them.

Note that I refer to the project team member that manages requirements as a requirements analyst.  Typically this role is performed by a systems analyst, business analyst, technical lead, or anyone else with experience and expertise at gathering and structuring software requirements.

The common requirements management pitfalls are:
 

• Not defining and communicating terminology to the project team.  This pitfall can lead to heated debate and misunderstanding among team members.  Defining all the terminology that will be used by the team, and making it available in a project glossary, will help prevent this problem.  Examples of words and phrases that are commonly used but ambiguous include: requirements, spec, design, plan, iteration, and phase.  If you are using a development methodology like RUP or Microsoft Solutions Framework a glossary of terms may already be available for you to reuse and tailor for your project.
• Not building what the project stakeholders want. While charging ahead with the requirements gathering and documentation work on a project it can be easy, especially over a long project, to lose sight of the original vision and goals of the project sponsors.  The sponsor’s goals may also change over the course of a project, or the sponsor themselves may change due to organizational change.  Because of this it is imperative that the requirements analyst get continuous review and feedback from all stakeholders at regular intervals throughout the project.  This can be as simple as review meetings or walkthroughs – but do not simply email a copy of the requirements to a busy sponsor and expect them to read it…actively engage them during the review to make sure they really understand what is being built by the team.
• Not planning the requirements roles, activities and approach. This pitfall occurs often on projects under time pressure or with less experienced team members. The key stakeholders, requirements analyst and other project leads should agree on the requirements document format and activities early in the project lifecycle.  To reach agreement early the requirements analyst can assemble and propose the following based on experience, expert opinion, or a prescribed development methodology the team is using (RUP, Agile, etc.)
  • Requirements gathering method (interviews, vendor reviews, etc.)
  • Format of the requirements documentation
  • Hierarchy of requirements – starting with a project vision/charter down through the business requirements, system requirements, and technical/UI design
  • Change control approach – how will requirements changes be communicated to the project team

  The requirements format must also be OK’d by key technical staff to ensure there is no resistance to the structure or contents later in the project. Make sure team roles related to requirements are clearly defined and documented in the project plan, and the staff are experienced in their role(s).

• Neglecting to tailor the structure, detail, and format of requirements to match the type of system under development.  Avoiding this pitfall is critical to project success.  A requirements management approach that worked well on one type of software project (a medical imaging system, for example) will not be suited to a different type of software project (such as an online store). Some project traits that will determine the best requirements format are:
  • The system domain (business ERP, banking system, embedded control system, etc.)
  • The complexity, number of users
  • The key features (web based UI, mechanical control, precision guidance, etc.)
  • The criticality of the system
  • Regulations and standards may dictate the requirements format
  • The development methodology employed by the team may provide guidance on the best format, but expert judgment may override the methodology’s approach

  The experience level of the project team must also be considered when tailoring the requirements structure.  A systems analyst with extensive UML modeling experience would make a terrible mistake if they documented all the requirements for a complex system in UML…and the project team had no experience with UML.

• Documenting software requirements too early or too late in the project lifecycle.  Software systems, especially consumer software, must adapt to changing markets and business environments.  Documenting software requirements in  too much detail too early in the project makes it difficult for the project team to adapt to the changing environment. This is especially true of long projects of 1+ year where sometimes the requirements are written months before development begins.  A better approach is to wait until the requirements are needed by other team members before committing them into a rigid, formal structure. Requirements become more stable over time so documenting them as late as possible ensures they change as little as possible before placing them under change control.
• Not clarifying ambiguities.  The chief duty of a requirements analyst is turning ambiguous and conflicting requests from assorted stakeholders into unambiguous requirements.  The project team depends on this removal of ambiguity for success.

  To achieve clarity the following techniques should be employed (the details of each technique is beyond the scope of this article):

  • Always maintain a thorough glossary of terminology that includes only words, acronyms, calculations and phrases unique to the system under development.
  • Structure the requirements in a manner meaningful to the stakeholders/users (use cases are good for this)
  • Avoid writing wordy, repetitive, or ambiguous statements
  • Help stakeholders articulate requests clearly
  • Review conflicting requests with stakeholders and negotiate resolutions
• Waiting until the requirements are ‘finished’ before starting development work. This pitfall is a problem particularly when building new software.  The project team should start the design and construction of software as soon as there is a candidate architecture and a draft of the requirements.  The reasons why development should start early are as follows:
  • Requirements are abstract, and it often takes a real working system for stakeholders to see and experience before they can confirm the requirements are correct
  • Developers can start work earlier in the project lifecycle and get experience with the technology, architecture and software domain
  • Project management will get early feedback on the feasibility and quality of requirements from the development team

  There will be some wasted effort and rework if development starts before requirements are finalized – but this cost should be outweighed by the reduced risk resulting from the benefits listed above. Most modern methodologies prescribe some form of early, iterative development.

• Ignoring the importance of requirement attributes. Each key requirement should have a documented set of attributes in addition to the usual ID, name, description.  The requirements analyst can decide what attributes to manage but the following are often useful: stability (how likely is the requirement to change), importance, complexity to implement, feasibility, cost, and whether the requirement impacts the system architecture. Attributes will be used throughout project lifecycle to prioritize work (do risky things first…) and aid in de-scoping work.
• Focusing on requirements tools and templates rather than the requirement quality. Some large project teams may need to use third party tools to manage complex, interdependent requirements. These tools, such as DOORS or IBM’s RequisitePro, may help (or hinder) the ability of team members to get quick access to the current requirements and should be carefully evaluated before use on a project.  Most average size projects do not need such complex requirements management tools and requirements may be stored in a simple format on a website available to the team along with change notifications (emails).
  Using template documents drawn from past projects may help provide ideas for a project team looking for best practices. However, as mentioned earlier each project is unique and an experienced requirements analyst will need to tailor the template and apply their skills to gather and document requirements properly.
• Mixing user interface details with the requirements. A key indicator of trouble down the road is when screenshots, wireframes layouts, or descriptions of how the user interface will work are mixed in with software requirements. The user interface is an important part of any software system, but its design should be kept separate from the requirements for several reasons:
  • The UI design changes much more frequently than the features/requirements during a software project.  For example, a drop down list could be changed to a pop up dialogue; or a single UI screen could be split into two after a usability review…these frequent changes should be kept separate from the requirements change control
  • Including UI design make the requirements document much larger than it needs to be, and obscures the important information (i.e. what the system must do)
  • Users and stakeholders care about the UI details less than they care about the features the software provides, but they do want a UI that is intuitive and easy to use. These general usability guidelines should be requirements, but the details of the UI layout, UI elements functionality are not user requirements
  • UI design is a separate and unique skill, different from the skill of capturing and documenting requirements

  UI details often get mixed in with requirements because they are the easiest and most intuitive way that users imagine software…they experience an application through the UI forgetting that is really the underlying features (requirements) that they use the software for.

• No quality assurance of requirements. Most decent sized software project teams make use of quality control techniques to find software defects or discrepancies between the software and requirements. What many teams do not do, however, is engage in quality assurance techniques to verify the requirement correctness and catch problems earlier in the project lifecycle before development is underway. Quality assurance is beyond the scope of this article but can include activities such as requirement walkthroughs with user focus groups, review of requirements by a third party, and making use of checklists/guidance from a standard development methodology to audit requirements.

In Summary

Careful planning along with the right techniques help the project team identify and avoid the pitfalls detailed in this article. An experienced requirements analyst can help a project team define the best approach to manage and document requirements on a software project, collect and organize the requirements, and finally manage changes to those requirements throughout the project lifecycle.

About the author

Guy Neill is an IT consultant working within Vancouver area software development firms. In this capacity he assists organizations with software requirements planning, documentation and management. Since 1994 he has spent his career designing, project managing, and implementing enterprise and consumer software systems.