CHAPTER 8

Working the Project

Requirement Defined

I want to take a moment to provide a bit more definition and discussion about what a requirement is before we proceed. The BABOK® Guide v. 3 defines requirement as:

Note that the “need” is not where the requirement ends. The definition goes on to focus on understanding the value. Often, a stakeholder will cite a requirement that once you dig deeper, you find doesn’t truly solve the business need. Recall the discussion of the 5 Why’s in Chapter 2—The History of Business Analysis. There we talked about the customer that thought they needed a field in order to distribute workload. Through prodding and analysis we discovered the “requirement” could be met with the current data structure. Not convinced yet? Let me give you another scenario.

I was project manager on a software development project to create a travel and expense reimbursement system. This solution was to replace a paper-based voucher submittal and review process. The paper travel voucher required that travelers sign to certify “all information on the voucher was complete and correct and appropriate to the organization’s travel reimbursement process.” The scope of the solution did not include the ability of fiscal staff to “correct” in the travel voucher what appeared to have errors. They could reject the entire voucher, sending it back to the traveler for correction, but not make adjustments. This meant that this would delay reimbursement for many travelers and that approvers and financial staff would have to handle vouchers multiple times—a huge inefficiency. The barrier was the certification language. The thought was that fiscal cannot make changes to the voucher without the traveler recertifying results.

In this case, I put on my business analyst hat and asked the question “what does the certification language need to say?” I made a proposal that we adjust the language to say that the dates, purpose, and items listed were correct. This allowed for technical corrections to the voucher when allowable reimbursement amounts were in error. I drafted some proposed language and sent it to the appropriate stakeholders including the organization’s attorney and accounting director. The certification was modified and adopted. Now the change to the system was a change in text without any changes in functionality, a much cheaper and easier resolution.

Requirements based on process or system constraints should be evaluated to determine if there is a continued requirement for the constraint or if there may be an opportunity to remove or loosen the constraint. I call this out because it is rarely that I see those in the business analysis role doing this level of prodding. The thought is that if someone says it is required, especially someone up the chain of command, then it is a requirement. Using seasoned, trained business analysis professionals will help identify opportunities to save money and time in the implementation of your solutions. This is one area where using outside business analyst consultants may have a greater effect.

The third point of the BABOK® Guide v. 3 definition is the “usable representation” of the requirement. It relates to the idea that a requirement is not a requirement until it is documented. An undocumented requirement is simply a wish.

Elicit Requirements

This is one area where the BABOK® Guide and PMBOK® seemingly do not agree. The PMBOK® Guide task in relation to requirements is “Collect Requirements”, whereas the BABOK® Guide states that the business analyst needs to “Elicit Requirements”. I point out this discrepancy only to show the apparent difference of philosophy between business analysis and project management, at least historically.

This goes back to the earlier sidebar on requirements as Easter eggs. It is not good enough to just collect requirements, as there’s a strong need for analysis of those requirements in order to make sure that we get them right.

It is interesting that the PMI has gone beyond collecting requirements with their PMI-PBAM^SM certification. The examination content outline points to 35 percent of the activities taking place in requirements analysis. This is a huge step for the PMI and is much more reflective of true business analysis work.

The reality is that we need to elicit requirements before we can analyze them. Eliciting requirements takes a lot of effort in talking with stakeholders with interviews and group meetings, but also reviewing processes, policies, and documentation to see what requirements we can find. We need to rely upon stakeholder analysis to make sure that we capture the requirements of all of the stakeholders that have an influence on our project’s success. We need to have a complete picture of the solution and the people and systems that it impacts.

Liz wanted to be sure that she got a full set of requirements that covered a variety of perspectives. She recognized that she would have to take a variety of approaches to get the broad coverage needed. First, she wanted to hold a focus group with the other business analysts in the company so that they could discuss what they need from a requirements management tool. She also identified a couple of business analysts that she wanted to observe working so that she could try to capture some of the nuances of their job that wouldn’t be apparent in the focus group session. She also wanted to interview some of the project stakeholders to get an understanding of what they need in order to review and approve requirements. Finally, she decided that she should take a look through the organization’s business analysis standards and processes to see what additional requirements she could find.

After completing all these activities, she had what she felt was a good starting point to develop a full requirement for the project.

Traceability Matrix

The Traceability Matrix is the heart and soul of the business analysis work. Both IIBA and PMI recognize this as the means of documenting and tracking requirements. In fact, when PMI did pilot testing for the PMI-PBA exam, feedback from the pilot indicated that there was a high instance of traceability questions. The instance of questions appeared to exceed the PMI-PBA Examination Content Outline’s published 15 percent for the Traceability and Monitoring domain. This is likely due to the fact that traceability happens across each of the five domains. The idea of the Traceability Matrix is that it provides easy reference to how each requirement traces back to the original project objectives. A requirement that does not link back to a project objective is a requirement that will not add value and should be deemed out of scope. That is the “traceability” part.

The matrix is also used to capture additional information about requirements that make it easier to track and communicate each requirement as well as the overall status of requirements for the project. Considerations in designing a Traceability Matrix include:

      •     What information does the project team and stakeholders need to know about each requirement?

      •     What categories of requirements will be needed to filter, sort, and communicate requirements in a meaningful way?

      •     Who should have access to the master Traceability Matrix?

Traceability Matrixes may take on many different forms, from Word tables, to Excel spreadsheets, to relational databases. Our case study project for a Requirements Management Tool represents the most sophisticated version of a Traceability Matrix. These tools are developed as relational databases specifically designed to capture, further analyze, document, and communicate solution requirements. They are often very configurable to allow the greatest flexibility in capturing requirement information and also in how requirements and related information are communicated. But you’re probably getting a good idea of how these tools work from the case study, so let’s move on. We will view the Traceability Matrix as a table so that you can get a holistic picture of how it works. The columns of our Traceability Matrix include:

      •     Unique ID

      •     Requirement Statement

      •     Type of Requirement

      •     Status

      •     Priority

      •     Planned Project Phase

      •     Project Objectives Related To

      •     Business Owner

      •     Author/BA

      •     Design References

      •     Test References

      •     Comments

      •     Test Notes

Keep in mind that there is not one and only one way to build the Traceability Matrix. This is just an example to help show how it can be put together.

Take a look at this example of a completed Traceability Matrix on the following page. Wait! You don’t need to see all the columns that we previously identified? That is okay. The idea is that we can pick and choose what information to provide to whom. The example hides many of the columns mentioned. For example, a business stakeholder will not have much interest in the design or test references, yet this is still important information to the business analyst and the core project team.

So we won’t go into all of the details of this Traceability Matrix, but hopefully, it gives you a basic understanding of how to capture, trace, and record requirements. One thing worth pointing out in this example is how easy it would be to filter the list to only show stakeholder requirements. This is something you would likely want to do for your project sponsors and executive-level stakeholders. A well-designed Requirements Traceability Matrix will make the job of communicating requirements so much easier.

Analyze Requirements

Analyzing the requirements means taking the requirements that were given to us by our stakeholders and turning them into requirements that will support bringing value to the project and provide the project team with what they need to develop that solution. There are many different aspects to analyzing the requirements, from ensuring that they are good quality requirements, which are written well, so that we have a full understanding of what the requirement means and what additional requirements result from it. Let us take a quick look at how both IIBA and the PMI define analyzing requirements.

There are quite a list of things to do before we can call our requirements complete. To call them complete at this point would be a gross error resulting in requirements that no one understands, as they do not make sense in the context of the project, and no one has any idea of how to satisfy. Also, here we are back to the 200-page list of requirements. We clearly need to do analysis after we have elicited requirements from our stakeholders, but before we can turn them over to our development team. In looking at the PMI-PBAM^SM exam, 35 percent of the exam is based on analysis tasks. This means that in looking at the overall business analysis activities, PMI has determined that 35 percent of the time should be spent eliciting and analyzing requirements before they are passed on to the project team. This is just one reason why providing an arbitrary deadline, “one month to complete requirements”, does not work. You will get requirements as stated by the stakeholders, but they will not be analyzed to ensure they are complete and correct and that they are suitable for use by the development team.

Let’s take a few moments to look at how we get from requirements that are stated by stakeholders to requirements that are suitable for use by our development team.

Now, as a result of this analysis, you have requirements that are …

      •     Confirmed to add value to the solution as defined in the business case

      •     Sufficiently detailed that the project team can fulfill the requirements as intended without ambiguity or confusion

Having good quality requirements upfront saves time and money in enabling the project team to develop the right solution the first time, without delays due to confusion. A list of quality characteristics has been provided in previous page. Consider the following two examples:

     1.   The system must be easy to use.

     2.   The system must provide one-click access to information for each data entry field on the definition of the field and allowable values.

The first one sounds like a good requirement. The person that said it had a clear vision of what they meant, but the developers and testers downstream may interpret it to mean any number of things. Verifying the requirement is necessary to ensure that the requirement is understood well enough to be satisfied by the technical team.

I would like to add here that when I say “requirements upfront” I do not mean that requirements should always be completed for an entire project at the beginning. What I do mean is that prior to the developer designing and coding, the requirements are crystal clear and complete. For an Agile project, this means requirements analysis happens at the start of the iteration for that user story. Refer to the “project approach” discussion in Chapter 5 to determine where “upfront” fits.

Liz’ preferred method to analyze requirements is to develop use cases. She finds this to be a great way to document the expected interaction between the user and the system and other systems. Often, in detailing these interactions she gets to a deeper level of requirements that will better support the project team down the road. Also, use cases are great to serve as a starting point for future testing. In addition to the use cases, she wanted to create a data dictionary to support all of the data fields that would be needed and to provide some information on the attributes and rules regarding that data. This would be something she could work with the database administrator on in order to verify that the solution was configured to meet the stated needs. Finally, she identified a few critical screens that she wanted to create prototypes for. By creating prototypes and comparing these to the use cases, she could walk the future user of the system through how the system would look and feel prior to development. This would allow her to capture additional requirements to support how they would use the system. This is also a great way to get buyin and acceptance of the project early on.

Liz knew that another critical piece of the analysis was to make sure that the requirements were quality requirements. She wanted to make sure that the development team could use the requirements without questions, ambiguities, or risk of system defects. She developed a quality checklist for the development team to use in reviewing the draft requirements. She further set up a peer review meeting where they could walk through the requirements and identify questions and uncertainty of the requirements. She knows that doing this in a peer review setting with most of the project team would help identify most of the unanswered questions so that she could address them before requirements were finalized.

Communicate Requirements

Requirements have undergone many changes since we first elicited them from the stakeholders. And that is okay. If stakeholders could state a requirement and have it clear, correct, complete, and usable by the project team, they wouldn’t need a business analyst. But we know that they very much do need our help.

Now we have two points of communication that we need to focus on for these changes. The first is to ensure that the stakeholders understand the requirements, all of the requirements, as they stand now after analysis and through verification. The trick here is how to communicate requirements. Remember our 200-page document? Yeah, that won’t work. The document will likely end up in the round file. Even worse, stakeholders may sign off on the requirements without reading them, which will surely mean issues down the road when those requirements turn out to be incomplete or wrong. Stakeholders must understand and approve requirements as written before the requirements are handed off to the development team to act upon. If not, there is a risk of defects and rework in order to bring value to the project and the business. We have to look back to the requirements management plan, our stakeholder analysis, and communication plan in order to understand which requirements need to be communicated for approval and to whom. It may vary from project to project. For instance, one strategy may be that stakeholders approve only the stakeholder requirements and that functional requirements supporting the stakeholder requirement are considered to be a subset. On other projects we may be looking for more control over the requirements and require stakeholders to approve functional requirements related to the stakeholder requirements. Either approach is fine and will be outlined in the requirements management or communication plans.

The other aspect that we need to keep in mind is communicating the requirements to the development team so that they can act upon them. To do this, we need to think about how to organize and present requirements so that they can review and respond to the overall picture. For the best results we will want to include project team members as we elicit, analyze, and document the requirements so that they can play a role in verifying requirements throughout the requirements life cycle.

This will ensure that they do not just get slammed with a long list of requirements that they now need to understand in the context of the solution. We need to communicate the requirements from the perspective of handing them off so that the solution can be developed.

In looking at these two separate needs for communicating requirements, we can see where we will need to take very different approaches in what we present. Our communication plan and stakeholder analysis will go a long way in helping us understand what we need to do to communicate. Personal communication preferences along with how the information will be used will be a significant factor in the way we communicate requirements to project stakeholders.

Liz has completed the analysis phase of the requirements and is ready to begin communicating these to the stakeholders and to get approval and sign off. She recalls having considered many factors in communicating requirements and developing a communication plan. She looks back to the plan, verifies that the plan still makes sense, and then begins to put together her communications for stakeholders. She notes that there are two separate communication activities noted: one is to walk through the requirements with subject matter experts, and the other is to do a peer review of requirements with the project team. She prepares two outlines for the plan of how she is going to communicate the requirements for each of the audiences.

Baseline Requirements

Now that requirements have been communicated, we need to get sign-off and approval so that we can baseline them. Baseline is a fancy project word for “approve”. Once the requirements have been baselined, a change request is required to make any further changes. This helps prevent scope creep on the project, and also helps to ensure that only requirements that have been deemed to add value (as documented in our Traceability Matrix) will be included in the final product. It is not that requirements cannot be changed, but rather that we’re going to do a thorough analysis of each requested change to ensure that it adds value to the project. We will discuss change control in more detail in the next chapter. We need two things in order to baseline the requirements. One, we need explicit approval of the stakeholders authorized to approve the requirements, and two, we need a means to document the final approved set of requirements. Documenting the final approved set of requirements can be managed with the Requirements Traceability Matrix.

Your Assessment

For the selected project …

       1.   Were there frequent changes to requirements after they were initially considered approved? If yes, why?

       2.   Of the defects found in the solution throughout test and implementation, what percentage of these could be attributed to poor or missing requirements?

       3.   Could delays in design, development, and testing of requirements have been avoided with better analyzed, more complete, and better quality requirements?

       4.   What was the overall impact of missed or poorly written requirements to on the project schedule and budget?