Abstract
Missed and misunderstood scope and requirements, vague requirements, unclear definition of scope, and failure to align with constituents and stakeholders are common reasons multiple research studies show are associated with project failures (Gulla, 2011, slides 4, 8, 9, 11). Through my own experiences, facilitating Joint Application Design meetings for customers on hundreds of projects, it is evident that the tie between vague, missed and misunderstood requirements and project failure is not unique to Information Technology (IT) projects. These problems are observed on all types of projects (product creation, product enhancement, software development, manufacturing, process improvement, problem resolution, etc.) and in all types of industries (Banking, Education, Health, Manufacturing, Technology, etc.). The reason project failures can be attributable to problems with project requirements is that many project teams are willing to forgo defining their project's needs and are eager to jump prematurely into describing their project “How's” or solutions, before they have communicated and gained alignment on the project's scope (i.e., boundaries of the project and capabilities to be delivered).
This paper addresses a technique for expanding and analyzing the Business Requirement Document (BRD), which typically contains functional business requirement statements, and finding and closing gaps in these documented project needs before creating the project's scope baseline. It will discuss techniques for looking at the business needs from three additional perspectives, beyond functional capabilities, which encourage the project stakeholders to discuss and clarify their functional needs from the viewpoints of solution acceptance needs, ongoing reporting needs and user interface and solution interaction needs. I have found that the more perspectives the project stakeholders employ to think about their project needs, the more gaps they uncover and close, and the lower the risk of project failure due to missing or misunderstanding their project requirements.
Elaborating On Requirements to Uncover Requirement Gaps
The scope of a project establishes the boundaries around the project effort and clearly differentiates between what is in scope and what is out of scope to build or change for a product, service, or process. Scope elaboration results in the identification of all of the project needs or capabilities which fall within the project boundaries. If we were to dissect the scope of a project, it would become evident that every project contains two basic types of requirements. First, there are Business Requirements, or User Stories if you work on Agile Projects, which communicate the “What's” for the project effort or the needs to be satisfied by the project solution. A Business Requirement describes what someone wants to be able to do, in the future – the capabilities they want to have that they do not have today.
The second type of requirement is the Technical Requirement or the project “How's,” which become the solution that is designed, acquired or created, tested, and implemented to satisfy the business needs of the project. There is a direct relationship between business and technical requirements for every project. Technical requirements or solutions are only in scope, when they satisfy an approved business need (i.e., a need that is in scope for the project). Any component of the delivered project solution which does not satisfy an in-scope business need is either a result of gold plating the project solution, (i.e., delivering more than what was asked for or expected) or a result of misunderstanding the project need.
Project needs are typically captured in a Business Requirement Document (BRD) or in a Product Backlog on Agile projects. Failure to identify these needs and hold collaborative discussions about these needs will likely result in the solution provider delivering a solution that is missing capabilities or has delivered the wrong capability. A challenge that project stakeholders may encounter, when writing and elaborating the Business Requirements, is knowing when enough alignment of the Business Requirements has occurred or if all of the requirements are included in the BRD before they establish the scope baseline. An elaboration technique of expanding the core functional business requirements by describing the project needs from more than the one perspective of core functionality will help them recognize when their requirements are not only complete enough to move on to the design and construction phases of the project, but also moving on with minimal risk of overlooking or misunderstanding the project needs.
To better understand this concept of a multiple perspective views of the project requirements, think about the project as if it were a Rubik's Cube puzzle. A Rubik's Cube has 6 sides with 9 squares of 6 colors on each side. The puzzle starts with a mixture of colors on each of the six sides. To solve the puzzle, every side of the cube must have only one color (red, green, yellow, white, blue or orange). It can be simple to get all of the same color on one side of the cube, leaving the solver with the false impression that the puzzle is now fully solved. However; as the cube is turned and viewed from a different perspective, it becomes clear that the other sides still have mixed colors and the puzzle is not fully solved. As the solver continues to view the cube from every side they can determine how to rotate the cube layers until all sides have only one color – basically looking at the cube from multiple perspectives.
Figure 1 – Project Requirements Cube
The project's requirements can symbolically be viewed as the “project requirements cube” (as illustrated in Figure 1: Project Requirements Cube). Each color square represents a different type of project need which must be solved for by the project solution. The project requirements cube isn't fully defined until the stakeholders have turned their cube and viewed their project requirements from different perspectives, clarifying their needs beyond the functional requirements as they add the relevant User Acceptance Test Objectives, Reporting Requirements and User Interface Requirements for the project. Elaboration of the project requirements in this manner allows stakeholders to discover gaps in their BRD (missed and misunderstood requirements) which they can close with no impact to the project before baselining the project requirements, rather than with impact later in the project lifecycle.
The elaboration process begins by defining the functional requirements for the project. Stakeholders are encouraged to start here because these are the most obvious business requirements – new or changed capabilities to be delivered by the project. Once stakeholders believe they have a placeholder, in their BRD, for all of the project's functional requirements, they are ready to symbolically turn the project requirements cube - changing their view to the other types of project needs. Their next view of the project is from an acceptance test perspective. Stakeholders will expand their requirements to include User Acceptance Test Objectives as they consider the viewpoint of signing off on or accepting the solution after validating that the desired needs and capabilities have been provided in the solution. Continuing to expand their requirements, the stakeholders turn the project requirement cube again to focus on their needs from a reporting perspective. Not all projects have Reporting Requirements, but if there is an expectation to be able to evaluate the delivered solution on an ongoing basis from an operational perspective, Reporting Requirements should be defined and are stated in the form of Business Questions. Those question should, when answered, allow stakeholders to assess how well the project solution is performing and what future changes may be needed. Lastly, the stakeholders will turn the project requirements cube to focus on the user interface needs of the project. Not all projects or all business requirements require a solution that supports overt user interactions. If the solution will involve users interacting with it to provide or view information or to perform the functions made available by the solution, User Interface requirements need to be defined as an expanded part of the project's Business Requirements and project needs.
As each new requirement type is defined, it can be mapped or cross-referenced back to one or more of the functional Business Requirements. The cross referencing technique provides a means to uncover gaps in the Business Requirements. Gaps can exist for situations where the Business Requirement functionality is misunderstood, missing, out of scope, or too vague for stakeholders to be able to:
- Describe how they will prove a project need has been met (User Acceptance Test Objective);
- Clarify the types of reporting which needs to exist (Reporting Requirement Business Questions); and
- Agree on the intended user interactions necessary to utilize the solution (User Interface Requirements).
It is not likely that a project's BRD will ever be complete to the extent that no new or previously undetectable need will be discovered as the solution is being designed, constructed or tested. However; by looking at the Business Requirements from more than just one perspective prior to baselining the requirements, and expanding the project requirements to include these additional types of project needs, the quality of the BRD will improve. Improvement in the quality of the project's BRD can be measured by fewer Change Requests which are created to include overlooked or misunderstood capabilities. This technique minimizes the risk of project failure related to vague, missing or misunderstood project scope and requirements.
User Acceptance Test Objectives
Project teams often delay the creation of User Acceptance Test Objectives until they have completed the project design or even built components of the project solution. This delay can result in testing only what was designed or built versus conducting tests to ensure all of the approved business needs have been met. In order for the project stakeholders to reduce the likelihood of misunderstanding a business need for the project, they need to ensure that every Business Requirement is testable. If the requirement's capability is not testable, it is probably not clear enough to design and build. When stakeholders think about the project from the perspective of using the solution as they perform their business functions, they have shifted their focus from describing what capabilities need to be solved for to ensuring the solution can be used as expected.
User Acceptance Test Objectives are the highest level of test statement and describe provable outcomes which must exist, verifying that the new functionality is ready to be accepted. During scope elaboration, this is the only level of testing which can be created without the design of the solution being decided. As User Acceptance Test Objectives are defined they can be cross-referenced or traced to one or more Business Requirement statements (as illustrated in Exhibit 2: User Acceptance Test Cross-Referenced to Business Requirement). There is typically not a one-to-one relationship between test objectives and Business Requirements, because acceptance testing views the use of the project solution from a higher functional level perspective which encompasses many Business Requirement level capabilities. During the cross-referencing, the stakeholders look for these types of gap conditions:
- Business Requirements without an Acceptance Test Objective
- User Acceptance Test Objectives which are not able to be mapped to a Business Requirement
User Acceptance Test Objective / Business Requirement Gaps
When a gap exists between a Business Requirement without a User Acceptance Test Objective mapped to it, one of three situations are present: the Business Requirement is misunderstood by the stakeholders or not clear enough to identify how the capability will be tested; the capability described in the Business Requirement is out of scope for the project and should not be tested; or User Acceptance Test Objectives are missing an objective. The sooner the stakeholders discover and close these gaps related to misunderstood or missing capabilities, the less need there will be to redo work or have to leave out capabilities later in the project lifecycle.
Figure 2 – User Acceptance Test Cross-Referenced to Business Requirement
Stakeholders resolve the misunderstood requirement gap, by adding more description to clarify the Business Requirement or splitting a high level parent Business Requirement into multiple, more discernible child-level statements. This action improves the likelihood of defining a User Acceptance Test Objective to prove the Business Requirement capability has been met – in other words, the Business Requirement is now clear enough to be testable.
The other gap scenario which can uncover an out-of-scope Business Requirement comes to light when stakeholders never intended to change or add the capability described by a Business Requirement and there would be no acceptance criteria included in the list of User Acceptance Test Objectives for the out-of-scope capability. This scenario is illustrated in Figure 2, which shows Business Requirement BR-011 has a “?” in the cross reference column for the Test Objective. Assuming the list of User Acceptance Test Objectives is not missing any test objectives, it can be determined that the Business Requirement is out of scope. In this example, BR-011 would be deleted from the BRD or marked as Out Of Scope and deferred for a future project. If it is determined that the Business Requirement is clear and its capability really is in scope for the project, then the gap can only be closed by adding a missing User Acceptance Test Objective.
Reporting Requirements
Based on my experience, Reporting Requirements tend to be the most overlooked project need. Stakeholders often mistakenly assume that their reporting needs will automatically be met when the project solution is delivered even though they have not described what their reporting needs are. Reporting Requirements may not be applicable to every type of project, but when there is a need to be able to answer questions about the performance of the solution or answer questions to help assess how the solution may need to be enhanced in the future, then Reporting Requirements are applicable. Delaying the definition of Reporting Requirements until after the solution is designed or built only increases the risk of not being able to answer these questions without having to retrofit the designed or built project solution. The level of Reporting Requirements I find are most often missed is the level which includes Business Questions that need to be answered about the product, service or process provided by the project solution.
By understanding the business question needs of the project, the stakeholders gain clarity about the type of information entities which must be available to answer the question as part of the project solution. Answers to the operational Business Questions help stakeholders evaluate how well the solution is performing or how it is being used to support the related business functions. Answers to knowledge worker Business Questions will provide insight to stakeholders when they are making decisions for future uses or capabilities of the product or help pinpoint needed changes in the overall business model relevant to the use of the project solution. In either case, turning the project requirements cube to focus on Business Questions provides a perspective of project needs related to information that needs to be part of the solution which is different from the core Business Requirement functionality perspective.
As Business Questions are brainstormed and accepted into the Business Questions document, stakeholders must ensure that each question is in scope for the project. It should only be expected that the answer to each question will be available because the information associated with the answer is relevant to providing a capability described in the Business Requirements. Business Questions are mapped back to one or more of the Business Requirements, although not every Business Requirement must to have a corresponding Business Question. For some capabilities provided by the project, the stakeholders may not have any questions they intend to ask about these capabilities.
When Business Questions cannot be mapped to a Business Requirement, a gap exists in the project requirements which needs to be resolved. There are several reasons which cause this gap to exist:
- the Business Question is Out of Scope for the project and should not be able to be answered because of the project solution;
- the Business Question is not clear enough to understand which Business Requirement it relates to;
- a relevant Business Requirement is missing; or
- the Business Requirements are not written clearly enough to map a valid Business Question to them.
Business Questions / Business Requirement Gaps
In the example illustrated in Figure 3: Reporting Requirements Cross-Referenced To Business Requirements, Business Question BQ-001 is a question about the number and type of transactions requested at an ATM which could not be completed. The cross reference to the Business Requirements shows that this question pertains to Business Requirements BR-015 and BR-046 (not listed in the example). It is common for there to be a one-to-many relationship of Business Questions to Business Requirements, because questions typically cover a higher level of capability than is represented by a more discreet Business Requirement statement. The example also shows that BR-024 has no Business Question mapped to it, which is a gap. After the project stakeholders reviewed this gap, they were able to determine there is no need to be able to report on whether a customer has created an online profile; therefore, not having a Business Question mapped to BR-024 is an acceptable condition.
Continuing to review the gaps, Business Questions BQ-003 is question about whether each location has the appropriate number of ATMS installed and there is no requirement mapped to this question – this is also a gap. Looking at the list of Business Requirements, there does not appear to be any appropriate Business Requirement which would provide availability of the information needed to answer BQ-003. If the stakeholders determine that BQ-003 is in scope for the project, then either one or more Business Requirements are missing from the BRD or the existing Business Requirements are not clear enough to be able to map this question to any of them. If an attempt to clarify the Business Requirements still results with no Business Requirement to which one can map BQ-003, the stakeholders must close this gap by adding Business Requirements to the BRD. Alternatively, if the stakeholders decide that BQ-003 is a really good question, but it is not a question that should be able to be answered as a result of providing the solution for this project, BQ-003 is out of scope and would either be deleted from the Business Questions document or marked as deferred question which could be included in a future project's scope of work.
If the Business Question itself is not clear, stakeholders can clarify the intent of the Business Question by adding another column to the Business Question to document the type of information needed to answer the question Category (as illustrated by the Information Category column shown in Figure 4: Business Questions With Information Categories). Information Categories are high-level data entities or collections of similar types of information. To avoid moving into the activities of designing the solution, keep this information at a logical view (focusing only on the type of information needed to answer a question - not how the information will be structured and stored or all of the attributes associated with the entity). This serves solely to clarify the Business Question.
Figure 3 – Reporting Requirements Cross-Referenced to Business Requirements
Figure 4 – Business Questions with Information Categories
When stakeholders cannot agree on the contents of the Information Category column, this is an indication that they do not agree on the intent of the question itself and may in fact be trying to ask different questions. Rewording the Business Question or splitting it into two or more unique questions should result in achieving agreement on the purpose of the question and the content of the Information Category column. Clarifying the Business Question in this manner will also enable the stakeholders to then agree on the Business Requirement(s) to which the question maps.
By turning the project requirements cube so the focus of the project needs is now on Reporting Requirements, the stakeholders are able to help find missing, misunderstood or out-of-scope Business Requirements prior to creating the project's scope baseline. This outcome will save time and money associated with trying to retrofit the solution to include the reporting capability needs into the project much later in the project lifecycle, if at all.
User Interfaces
A final turn of the project requirements cube will occur when the project stakeholders are ready to discuss their project needs from a user interface viewpoint. User interfaces are the methods an end user (i.e., Actor, Use Case terminology) will use as they interact with the project solution's system represented by a delivered product, service or process. Not every Business Requirement will require a direct user interface between an Actor and the resulting system; therefore, it is acceptable to have Business Requirements without a corresponding User Interface cross reference. However; every User Interface that is in scope for the project must be able to map back to one or more Business Requirements in order for the interface to remain as part of the scope elaboration.
User Interface requirements are documented at the logical level and communicate only the conceptual interaction or “What's” to be satisfied by the project solution. Stakeholders are still at the point of elaborating on the project's scope and Business Requirements – not designing the solution details for how the needs will physically be met. The graphical Screen Mock-up is a type of User Interface Requirement used to conceptually visualize the user entering or retrieving information from the solution as they perform the capabilities described by the Business Requirements. It is not intended to be a finalized layout of the screen. The textual Use Case deliverable describes observable steps performed by a user, as they perform capabilities described in the Business Requirements along with the resulting response from the system. Reference to the system is a generic Use Case term depicting the mechanism the user is interacting with as they perform various capabilities to achieve specific goals.
During this elaboration activity, the stakeholders review each Business Requirement and indicate if the requirement will needs a direct User Interface for performing the capability described in the requirement. If yes, a “Y” is placed in a column of the Business Requirement document to indicate a User Interface is needed to perform a Business Requirement capability (as illustrated in Figure 5: Business Requirement With User Interface Indicator). As seen in this example, an interface is needed for the parent-level requirement BR-020 and three of its child-level requirements: BR020-001, BR020-002 and BR020-030, which will allow a user to reset their password for their online profile and account access. BR0--020.040 for sending an email notification for the account password reset is a non-observable background action, which is why it does not need a User Interface indicator of “Y.” A User Interface Scenario document is created and updated with interface information relevant to the Business Requirement capabilities (as illustrated in Figure 6: User Interface Scenarios) and this cross-reference information will be depicted on the Screen Mock-ups.
Figure 5 – Business Requirement with User Interface Indicator
Figure 6 – User Interface Scenarios
The User Interface Scenarios can be assigned to teams of stakeholders who will work together to create the conceptual Screen Mock-ups (as indicated in Figure 7: User Interface Screen Mock-up). Scenarios are also assigned to teams of stakeholders to create Use Cases (as indicated in Figure 8: User Interface Use Case). Although stakeholders have already agreed, prior to developing the User Interface requirements, that the BRD accurately describes their project needs, when they turn the project requirements cube to focus on User Interfaces, they will improve their ability to assess whether the Business Requirements really are clear and whether or not the BRD contains a complete list of requirements to convey all of the project needs.
Figure 7 – User Interface Screen Mock-Up
User Interfaces / Business Requirement Gaps
The Screen Mock-ups and the Use Case deliverables prepared by the teams of stakeholders are reviewed and validated by the entire stakeholder team. As stakeholders compare the concepts depicted on the Screen Mock-ups and steps outlined in the Use Cases to the Business Requirements, they are looking for gaps between what is depicted for the interface and what was the stated intention of the Business Requirement. Often, these perspectives are different. At this point in the elaboration process, gaps will exist because stakeholders have graphically depicted functionality on a Screen Mock-up or included a step in a Use Case, which cannot be mapped to a Business Requirement for one of several reasons:
- The Business Requirements are unclear;
- The user interface is in scope for the project but a Business Requirement is missing from the BRD;
- The functionality depicted on the Screen Mock-up is not in scope for the project; or
- The functionality associated with the Use Case Step is not in scope for the project.
Closing a gap when the Business Requirement is unclear is accomplished by rewording an existing Business Requirement so that the missing interface capability is now obvious in the requirement. Alternatively, stakeholders might create a child-level requirement to describe the interface capability which was not clear at the parent-level requirement. A gap may exist because stakeholders were able to see the need for new elements of information which they depicted on a Screen Mock-up or a new capability they clarified and included in a Use Case step. If the new element is determined to be in scope for the project, adding the missing Business Requirement(s) for the capability will allow the gap to be closed.
Figure 8: User Interface Use Case
When the User Interface functionality is determined to be out of scope for the project (i.e., it is intentionally not represented in the Business Requirements) then the functionality needs to be removed from the user interface deliverable it is included on. This type of gap is illustrated in Figure 7: User Interface Screen Mock-up, and represented by the button labeled Espanol, which is circled in red. When creating the Screen Mock-up, the stakeholders believed having an option to present screen information in Spanish was a good idea. However, after further discussion and consensus of all of the stakeholders, it was determined that the capability was not intended to be delivered by this iteration of the project solution. The button must be removed from the Screen Mock-up because the feature is out of scope for the project. Leaving the button on the Screen Mock-up which allows a developer to include this unapproved capability is gold-plating the solution and could potentially drive cost overruns or schedule delays to fully integrate this seemingly simple yet unplanned capability.
The capability for a Chat Feature, depicted in red on step 001.05 of the Use Case example (as illustrated in Figure 8: User Interface Use Case) also could not be traced back to a Business Requirement, when the Use Cases were reviewed; therefore, this is a gap. If the entire stakeholder team agreed that the capability was a nice feature but it was out of scope for the project, the reference to this capability would need to be removed from the Use Case. Alternatively, if it had been determined that the Chat Feature included when the Use Case was created was not out of scope, then a Business Requirement is missing from the BRD and would need to be added so that the Chat Feature capability would be further clarified and included in the project solution.
Summary – Closing Business Requirement Gaps
The requirements elaboration techniques and examples presented in this paper have explained the value to a project realized when project stakeholders delay the establishment of the scope baseline until they have communicated and gained alignment on the project needs beyond the single viewpoint of functional Business Requirement statements. When stakeholders view their project's needs from three additional perspectives described in this paper (rotate the “project requirements cube”), they are able to gain insight into requirement gaps resulting missing and misunderstood requirements. Early awareness of the requirement gaps will enable the stakeholders to adjust and correct their Business Requirements prior to establishing the baseline for the project scope and Business Requirements. Closing the gaps prior to baselining the scope will avoid costly impacts to the project when these gaps are not discovered until after a solution has been designed, acquired, or tested.
The perspective of User Acceptance Test Objectives looks at the project needs from the viewpoint of determining if the project solution is ready to accepted and released to the customer. The test objectives will clarify how stakeholders will verify the solution meets their expectations, even before the first solution component is designed or built, by ensuring every Business Requirement is testable. The Reporting Requirements viewpoint allows for Business Questions to be documented and mapped to Business Requirements. The included mapped Business Questions will ensure that information to support ongoing reporting needs will not be overlooked and will be able to be provided by the project solution. The final turn of the “project requirements cube” will focus on User Interfaces and clarify the user interaction needs of the project. Gaining alignment on the project needs from a user interaction perspective by graphical Screen Mock-ups and textual Use Cases will improve the quality of the Business Requirements and help ensure they are complete and not vague.
Expanding the Business Requirements using the requirements elaboration techniques described in this paper will ultimately contribute toward reducing the risk of project failure associated with vague, missing or misunderstood project scope and requirements.