Requirements management for improved project performance
Poor requirements management processes (or lack thereof) have been identified as a leading cause of project failure. To address this problem, a number of approaches have been recommended to deal with requirements definition and requirement gathering. This paper deals with requirements management, including requirements change management and how it can lead to improved project performance. Major reasons for project failures and delays will be discussed, as well as ways how requirements management processes can address project failures/problems. Tools and techniques in requirements definition and requirements gathering will be explored. A general approach in handling requirements will be presented. Elements of an effective requirements management process will be discussed to allow participants to tailor a general approach and develop a practical methodology for their organization. Benefits and challenges in implementing a requirements management process will also be discussed, including many areas relevant to the various work situations. The paper presentation will conclude with discussion of how requirements management can (positively and negatively) impact customer satisfaction, project performance and organizational performance.
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.
What is Requirements Management?
Requirements Management consists of three processes: Requirements Development, Requirements Verification, and Requirements Change Management. It includes processes in gathering, defining, refining, organizing, documenting, testing requirements, verifying that requirements are being met, and tracking and controlling requirement changes. There are many tools and techniques 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.
A more detailed discussion of Requirements Management processes will follow.
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.
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.
Common techniques used in requirements gathering and elicitation are the use of workshops, brainstorming, conducting facilitated meetings, one-on-one interviews, customer focus groups, and Joint Application Development (JAD).
The Project Management Book of Knowledge (PMBOK®) (PMI, 2000) defines product scope as the features and functions that characterize the product. Completion of the product scope is measured against the product requirements (PMI, 2000). 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, 2000). 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.
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.
A number of situations can lead to having many unknown or missed requirements. Possible causes of unknown requirements include some user groups being overlooked, user information being misinterpreted, inaccurate or inadequate information gathered from the users.
This process is no easier than Requirements Gathering. Requirements Analysis is conducted throughout the Requirements Phase of the project life cycle, before and after requirements gathering and before and after Requirements Definition. Helpful techniques include stakeholder analysis, the RDD review/approval process, and the use of the Requirements Traceability Matrix.
Stakeholder Analysis involves identifying stakeholders and determining their stakes/roles in the intended use of the product. This technique helps determine if some user groups are overlooked and helps focus on specific groups for specific requirement areas. RDD review/approval process presents an opportunity for a thorough review of the RDD by expert business users, subject matter experts and stakeholders who are familiar with similar prior projects. The process also helps uncover unstated/missing (assumed) requirements. Requirements Traceability Matrix (RTM) provides another opportunity to review the RDD for completeness, helps find missing requirements and helps determine if the requirements are being addressed in the development plan. To create the RTM, all requirements are listed in matrix-format at the start of the Requirements Phase. During Design/Development phase, the RTM is expanded to include indicators that show if the requirements are being addressed in the product design/development. The RTM is further expanded upon in 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. The Requirements Traceability Matrix (RTM) can be a very useful tool in tracking requirements through the different phases of the project life cycle. Starting with identifying all requirements, the RTM is expanded during the Design/Development phase to include indicators that show if the requirements are being addressed in the product design/development. During the Test and Validation Phase, the RTM is further expanded to “trace” requirements through testing (i.e., to ensure that stated requirements are being tested). User acceptance testing is another technique employed in Requirements Verification. Business users are either directly or indirectly involved in testing, verifying and/or approving acceptance of the product.
Requirement 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 three Requirements Processes defined above: Requirements Development, Requirements Verification and Requirements Change Management. None of the three is optional, in ensuring that all requirements are well-understood, known early enough in the project life cycle, addressed in the development plan and met in the final product.
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.
Benefits and Challenges in Implementing a Requirements Management Process
The challenges in implementing Requirements Management are too numerous to list in one paragraph. Requirements Development is the most difficult of the processes discussed above. Requirements Gathering is the most error-prone. There may be many, many requirements. They may be many user groups. Some users may be more vocal than others. Some users may not be vocal at all. They may not be interested in talking about their business needs and business problems. Business process documentation is hard to find in many environments. The role of a Requirements Analysts is a very critical one, yet a skilled Requirements Analyst is difficult to find. How many users document their business processes, business rules and procedures, so that the requirements analyst and/or the development team can understand them? How many business users can explain their problems or articulate their business needs? How much time can business users afford to accommodate interviews, customer focus groups, meetings, JAD, or brainstorming to allow the development team to understand their problems and their needs? How many developers can understand or speak the business user's language?
Requirements Verification is most effective when it involves the business users or the customers. But how many business users enjoy participating in user acceptance testing or getting involved in checking if all requirements are being addressed or being tested?
Implementing a Requirements Change Management is probably the most challenging of the three Requirements Management processes. Establishing a Change Control System, getting stakeholders’ buy-in for the requirement change control system and enforcing the process can be a formidable task. In some organizations this will entail an organizational culture change. Introducing any type of change to individuals or to an organization presents a whole new set of challenges. How many Project Sponsors are pleased to follow the Requirement Change Management process, documenting every change request? Even customer satisfaction can be sacrificed (in a short-term) as customers are “forced” to document requirements/change requests and follow/participate in Requirements Processes that they are not used to. Utilizing a system/software tool for a change control system can help in the long term, but can be a lot of work in the initial stages.
Yet, the benefits of a Requirements Management Process, if implemented properly, can be tremendous. An effective Requirements Management process presents so many opportunities: in Requirements Gathering -- opportunities to cross-train business and development team staff, in Requirements Definition -- new requirements may be discovered that become the basis for new/follow-on projects. This in itself can present opportunities for alignment business and development goals. Another benefit is collaborative partnership between the business and development teams in delivering the right product within the project budget and schedule. Engaging users in elicitation and in requirements verification helps gain support and buy-in for the project from the users. Involving users in user acceptance testing helps prepare the users for the new functionalities of the product An effective Requirements Change Management process helps eliminate scope creeps, as all change requests are handled uniformly in the project. Eliminating scope creeps can offer tremendous savings in terms of reduced rework and unplanned work. Controlling requirement changes help minimize the ‘churn’ in the project life cycle. Improved project performance is the ultimate benefit of an effective Requirements Management Process.
IEEE Std. 830-1998 (1998) Recommended Practice for Software Requirements Specifications. Los Alamitos: IEEE Computer Society.
Kerzner, H. (2000) Project Management – A Systems Approach to Planning, Scheduling, and Controlling, New York: John Wiley.
McConnell, S. (1998) Software Project Survival Guide, Redmond, WA: Microsoft.
Phillips, D. (2000) The Software Manager's Handbook, Los Alamitos: IEEE Computer Society.
Project Management Institute. (2000) A guide to the project management body of knowledge (PMBOK®) (2000 ed.). Newtown Square, PA: Project Management Institute.
Robertson, S., & Robertson, J. (1999) Mastering the Requirements Process. Harlow: Addison-Wesley.
Visitacion, M. (2003, May) A Practical Guide to Requirements Management. IBM Rational Seminar.
Wiegers, K. (1999) Software Requirements. Redmond, WA: Microsoft.
Wiegers, K. (2002, June 20) Software Requirements: Eight Traps to Avoid. Project Management Institute Information Systems Special Interest Group. Webinar. Retrieved from http://www.pmi-issig.org/webinars/Webinars%202002/Wiegers.asp
Proceedings of PMI® Global Congress 2003 – North America
Baltimore, Maryland, USA ● 20-23 September 2003