Abstract
Poor requirements management processes (or lack of thereof) have been identified as a leading cause of project failure. As many organisations find that utilising project management processes helps improve the probability of project success, research studies continue to point to poor handling of product requirements as the major cause of project failure. This leads to the question: How about Requirements Management? How can Requirements Management processes address the causes for project delays and failures and contribute to project success?
Requirements
What are requirements?
Requirements are capabilities that a product must meet to satisfy a user's need to solve a problem. The user's needs can come from a number of sources including compliance to a standard or to legal regulations, a business need, a business problem, market need, competition, etc.
Requirements can be classified into functional and non-functional requirements (Robertson 1999). Functional requirements are capabilities that the product must do to satisfy specific user needs. They are the most fundamental requirements. Functional requirements are sometimes referred to as business requirements. They describe capabilities that the intended product can perform to enable business users to do some part of their work and carry on with their business (operational) work.
Non-functional requirements include usability, performance, reliability and security requirements. These are qualities that the product must have. Technical requirements also fall under the non-functional category. Nonfunctional requirements are no less vital than functional requirements. In some projects, completed products that satisfy all functional requirements but leave even one important non-functional requirement (e.g., performance requirements) unsatisfied are considered a project failure.
Requirements vs. Scope
Are product requirements synonymous to product scope? Not exactly. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) defines product scope as the features and functions that characterize a product, service or result. Completion of the product scope is measured against the product requirements. Requirements set the scope in any project. While including more than the stated requirements in the product scope is not recommended, providing anything less than the user-stated requirements does not meet user expectations.
Requirements Management
Why is Requirements Management important?
Ineffective requirements management processes (or more commonly, not employing any requirements processes) has been identified as a leading cause of project failure. Specifically, scope creeps or the inability to control them is a common cause of project cost overrun or project delay. An IBM Rational Project Manager Survey (Visitacion, 2003) indicated that IBM project managers consider controlling scope creep and requirements quality as the greatest predictor of success. Wiegers (2002) identified eight typical requirements problems that can sabotage a project. He wrote that successful [software] projects are highly dependent on well understood requirements and suggested ways to avoid traps to effectively collect, document, or manage requirements.
Requirement issues should be addressed very early in the project life cycle because design problems based on poor requirements lead to design issues that are more difficult and expensive to resolve after project development is well underway (e.g., into the project execution phase). Investment in requirement processes implemented from the start of the project life cycle pays off at the end.
Project cost statistics at the Cost & Economic Analysis Branch, National Aeronautics and Space Administration headquarters indicate that projects that spent less than 5% of total project or program costs on the requirements process experienced an 80% to 200% cost overrun, whereas those that invested 8% to 14% experienced less than a 60% overrun (Young, 2003). The NASA study concludes that an investment of 8% to 14% of total program costs on the requirements processes yields project results with considerably lower cost overruns.
With requirements of poor quality, project fail, are completed late or over-budget. Other projects successfully completed on time and on budget delivered features and functions are not used. Research studies have shown only 45% of features and functions of IT products are used.
Reasons for Project Failure
Research studies (Standish Group, 1995) on project failure have identified the following reasons for project failure:
- Incomplete requirements
- Didn't involve users
- Insufficient resources/schedule
- Unrealistic expectations
- Lack of managerial support
- Changing requirements
- Poor planning
- Didn't need it any longer
The most common reasons for project failure are not all associated with requirements issues. However, requirement issues and project issues need to be resolved as early as possible in the project life cycle. When raised in the middle of the project development life cycle, many project issues not associated with requirements (e.g., executive support, project management skills) can be remedied and project development can continue without considerable loss of project results. However, resolution to requirement issues usually requires the project team to start from the beginning in defining/clarifying requirements and most of the development effort already spent on the project is wasted.
In the current state of requirements management, especially in the IT industry, project managers raise and highlight requirements issues as they arise. They attempt to use requirements processes to address the issues. If all project managers apply lessons learned to prevent recurrence of requirements problems, many requirements issues can be found and resolved during the early stages of project development or eliminated during project development.
This is not all that simple, as many requirements processes require the customers' involvement and participation, as well as their cooperation and collaboration. Some requirement processes present implementation challenges.
However, as project management communities and organizations focus on tackling the major causes of project failure and take steps to address these requirements issues, project managers find that implementation of organizational requirement processes can and do contribute to project success.
Requirements Management Processes
Requirements Management consists of the following processes: Requirements Planning, Requirements Development, Requirements Verification, and Requirements Change Management. It includes processes in planning, gathering, defining, refining, organizing, documenting, testing requirements, verifying that requirements are being met, and tracking and controlling requirement changes.
Requirements Planning
Requirements Planning is the process that involves the development, review, and approval of a Requirements Management Plan. The Requirements Management Plan has to be reviewed by all appropriate stakeholders (Customers, Users, Development/Design Team Leads/Managers) and approved by project sponsors and key stakeholders.
Requirements Development
Requirements Development consists of requirements gathering and elicitation, requirements analysis, and requirements definition.
Gathering & Elicitation
Requirements can be either known or unknown. The purpose of requirements gathering is to collect as many known requirements as possible. The process of requirements gathering is both critical and difficult (Phillips 2000). Although it seems straight-forward to gather requirements from users, record and document the information, it is often difficult to get accurate and organized information. Information may be provided in different forms, (e.g., via email, on-one-one interviews, in a telephone message, meetings) and in different formats (e.g., in documents, in a database or spreadsheet format). Clarifying, organizing and prioritizing the information can be a very time-consuming and daunting task.
The purpose of elicitation is to identify the needs and constraints of various project stakeholders (Wiegers 1999). The results of this process are a common understanding among the project stakeholders of the users' expressed needs.
Requirements Definition
Requirements Definition is the process of organizing, documenting, defining and refining requirements. The Requirements Definition Documentation (RDD), sometimes referred to as Requirements Specifications, is a documentation of the product requirements. The approved RDD (also called the Requirements Baseline) is a documentation of the agreed-upon product scope. It is considered a contract of the product to be developed between the business users (sometimes represented by the Product Sponsor) and the product developers.
In cases where development of the product is outsourced to an external group or organization, Requirement Definition is an integral part of the Statement of Work (SOW) (Kerzner, 2003). As with any contract, the RDD must be documented in great detail and must be signed by proper stakeholders. Although expected to be very detailed and well-understood by all stakeholders, requirements must define users' needs – what is expected from the product and not how the users' needs will be addressed in the product. Developers need to understand the requirements fully (what the users' problem is) to be able to develop the solution (how to fix the problem). It is common practice to use an SOW template within an organization.
A standard template that defines functional and non-functional requirements, constraints and assumptions is useful tool for documenting and reporting requirements. A number of system/software tools (Visitacion 2003) are commercially available for organizing, prioritizing, reporting requirements. A Work Breakdown Structure (WBS) is a common tool in identifying all product deliverables. WBS defines the work deliverables in sufficient detail such that each deliverable component can be managed easily (in terms of cost, quality and schedule). The IEEE Standard 803-1998 Recommended Practice for Software Requirements Specifications, (IEEE 1998) is sometimes used as a template for Requirement Specification in software projects. Many organizations start with a template commonly used in the industry, and tailor the template to the needs of the organization.
Requirements Analysis
Closely tied to requirements gathering and elicitation is Requirements Analysis. The purpose of Requirements Analysis is to discover unknown requirements, i.e., to turn unknown requirements into known requirements. Users' needs that were not expressed during requirements gathering and elicitation can be uncovered through Requirements Analysis. It is beneficial for the project if unknown or missed requirements are discovered as early as possible in the project life cycle. This will minimize the cost impact of requirement changes.
Requirements Verification
Requirements Verification is the process of ensuring that all stated requirements are being satisfied. This process is performed throughout the Requirement Phase of the project life cycle. It includes an analysis of how the requirements are being addressed in the development plan, as well as user acceptance testing and validation.
Requirements Change Management
Requirements Change Management (RCM) involves the implementation of a (requirements) change control system consistent with an integrated project change control system, and managing the actual implementation of changes (approved change requests). RCM goes hand-in-hand with the Requirements Development and Requirements Verification. It is an essential component of Requirements Management. The Requirements Management Plan is an input to this process, and must define the critical components of the RCM, including the change control system, the Change Control Board as the controlling and deciding body for handling change requests, any exceptions/limitations of the process, and any permissible deviations.
Effective Requirements Management
An effective Requirements Management process must involve all four Requirements Processes defined above: Requirements Planning, Requirements Development, Requirements Verification, and Requirements Change Management. None of the four processes is optional, in ensuring that all requirements are well-understood, known early enough in the project life cycle, addressed in the development plan and satisfied in the final product.
There are many tools and techniques that can be used for these Requirements Processes, including system/software tools for organizing and documenting requirements, templates for defining and reporting requirements, gathering and elicitation techniques, testing and verification tools, and change control system tools. The most useful tools are those that encompass all the processes mentioned above, and those that are employed when the requirements processes are implemented as formal standardized processes with defined inputs, tools and techniques, and outputs.
Performing some of these processes as requirements activities, not as formal standard organizational processes, does help improve project development results but does not address all requirement issues in the project.
For example, requirements gathering is a very time-consuming activity. In some projects, requirements gathering can take up 25% of the project's life cycle. Yet this activity can be futile, if it doesn't result in delivering a complete and accurate set of customer requirements. Many organizations continue to treat requirements gathering as an activity, not as a standardized organizational process. To be effective, requirements gathering has to be structured and be conducted in collaboration with customers and in association with other requirements activities involving customers, such as requirements elicitation and requirements validation.
Project management practitioners are accustomed to following processes that have well-defined inputs and outputs. They tend to look for usable inputs before implementing the process and templates for the outputs and other tool/techniques to employ in producing the process deliverables. Process deliverables should be well-defined.
The deliverable of Requirements Planning is a Requirements Management Plan that is reviewed and approved by the project sponsor and key stakeholders.
The deliverable of Requirements Development is a common understanding of the requirements. A well-written RDD is effective only if it represents a common understanding of the requirements among the key project stakeholders (between the project sponsors/users and the development team). The role of a Requirements Analyst is a very critical one. To be effective in this role, the Requirements Analyst has to be skillful in gathering information, tactful in eliciting requirements, and analytical in prioritizing and organizing solicited information.
The deliverable of Requirements Verification is a formal acceptance by the users that all requirements have been met. User acceptance must be both documented and approved. The business users' participation in reviewing, testing, and verifying the product is the best assurance of the success of Requirements Verification. Key contributing factors include early and sufficient user involvement in the requirement processes.
The deliverable of Requirements Change Management is proper handling of all requirements change requests and implementation of (approved) changes. Very rarely are all requirements known at the very beginning of the project life cycle. There will be requirement change requests. The project team has to be prepared to handle them. An agreed-upon change control system and a pre-arranged Change Control Board with appropriate controlling and decision-making authority are a must for an effective Requirements Change Management process. All change requests -- big or small, regardless of who sponsored the request -- must go through the Change Control Board.
To summarize, an effective Requirements Management process must involve all four Requirements Management Processes defined above: Requirements Planning, Requirements Development, Requirements Verification, and Requirements Change Management, and an associated formal standard organizational implementation for each process.
