The purpose of root-cause analysis is to determine the underlying source of a problem under study. Doing this will help ensure the requirements attack the real problem and not just the symptoms.

A critical element is to challenge the current business thinking and processes.You want to overcome the “we’ve always done it that way” answer to the question “Why do you do this?”. I recently managed a project where it took interviews with dozens of people to finally get the answer to the question of why the pay week started on a Saturday instead of Sunday where the sales week started.

The steps to root cause analysis are:

• Define the problem under study and understand the impact
• Analyze the problem to determine the root cause
• Agree on solutions to prevent the problem from occurring

One technique to analyze the root cause is the “five whys” to explore the nature and true cause of a problem. This means repeatedly asking “why” after a question is answered until you uncover the real root cause. It may be more or fewer than five, but five is a good rule of thumb.

You can create a visual of your “five whys” analysis using a “Cause Map”. A Cause Map is simply a block on the left that identifies the problem, an arrow labeled “why” going left to right to another block that answers the question, then an arrow labeled “why” going left to right to the next answer and so on until the root cause is identified.

Root Cause Analysis is a good addition to your requirements analysis repertoire. If your project is not addressing the true root causes of the problem definition then you are unlikely to achieve the defined business objectives.

Prototypes are the shell of an actual production application and are used to provide insight into the look, feel and flow of an application. The main purpose is to gather requirements related to the user interface. A “throw away” prototype seeks to quickly uncover and clarify system interface requirements. It is especially useful in cases where the most efficient workflow can only be discovered with hands-on experience.

Some have made the mistake of thinking prototyping is all you need to do to gather requirements. This will almost always be a costly mistake! Other requirements techniques will need to be used to get a complete set.

When you obtain the user interface requirements using prototyping, the next step is to integrate these requirements with your use cases, scenarios, data model and business rules. Your new discoveries will usually result in changes to previously gathered requirements.

There are two categories of prototypes used to uncover functional scope:

1. Horizontal Prototype – models a shallow and wide view of the system’s functionality. It typically does not have any business logic running behind the visualization.
2. Vertical Prototype – models a deep and narrow slice of the system’s functionality. There usually will be some business logic built to uncover complex requirements.

It is a judgment call as to whether or not to use prototyping on a particular project. You must weigh factors such as the importance of the user interface, the clarity of the requirements gathered via other methods, the difficulty in building the prototype, and time constraints.

In many cases of gathering requirements, there is no substitution for actually observing the process as it happens. You will find that often the way things are done contradict what is written in process manuals. These deviations are important as they usually reveal an inefficiency in the process that the user felt the need to employ a different method. This is valuable information for process improvement!

You should be aware that at times just the fact that a process is being observed can make the user change how they usually do things. It is important to make the people being observed comfortable with why they are being observed and the objectives of the observation. Openness and honesty are important. Solicit their input and suggestions.

As with anything project related, there needs to be a plan. You can make a simple form with elements such as:

• Process Name
• Observation date(s) and times
• Observers
• Location
• Purpose/Objective
• Notes
• Key Findings

The dates and times are important as you need to know if this is considered peak/normal/low volume time. This is a key consideration regarding the observation objectives.

After the observations are complete, you should meet with key project staff and stakeholders to discuss findings and their impact on the requirements.

In this series so far I have addressed “functional” requirements. These are the requirements that address features, functions and processes for the new system. There are also many requirements that are not related to the features, functions and processes. These are called “Nonfunctional Requirements” and mostly address the quality of the delivered product.

Here are some examples of Nonfunctional Requirements:

• Performance – Response time, transaction rates, throughput.
• Operating constraints – System resources, people.
• Platform constraints – The target platform may have been predetermined.
• Accuracy – Some applications (e.g. Consumer Data Base) can tolerate some level of inaccuracy, while others (e.g. Taxes) have to be very accurate. This should be agreed upon in advance. Accuracy has a cost so it should be in line with the value.
• Maintainability – The effort required to make changes. Sometimes this will be sacrificed in order to meet a target date. Your business sponsor should be well aware of this decision.
• Portability – The effort needed to move to a different platform
• Availability – System up-time. Should specify the maintenance windows.
• Security – Requirements of the protection of the system and it’s data.
• Usability – How difficult will it be to learn the system? How much training time is needed?
• Legal – Consult your company’s legal team for these. Your project could involve labor laws, privacy laws, etc.

Your organization may have standard templates for these types of requirements. If not, you should create the templates as part of your project. There should be lots of useful information from previous projects for you to use as source material.