Researching and documenting requirements is a difficult task. A good requirement must be SMART: Specific, Measurable, Actionable, Referenced, and Traceable:

• Specific = the point of requirements is to let all participants know exactly what is needed in order for the product to meet the expectations of the stakeholders. Make sure everyone on the team understands what a requirement means. They may start as rough ideas sketched on a whiteboard but must end up as structured “shall” statements. They may be structured in a hierarchy with the broad requirements at the top and supporting detailed requirements within. Where necessary, requirements can be extremely detailed specifications that establish the required behaviour of any component or aspect of the desired product or service.
• Measurable = requirements vary in complexity, but all stakeholders must understand what these requirements are about and how the benefit can be realized. Sometimes the measure is of a legal or statutory nature, sometimes it is a specific benefit to a client that otherwise might not want to purchase a product or service. There must be accountability for the investment in a solution.
• Actionable = the requirement must be feasible to implement given the context in which we want to implement a solution. This eliminates “wish list” items that are unrealistic given what we have to work with, or they may simply be too costly or too risky to implement. There has to be a clear, identified need that establishes the potential benefits of implementing that requirement so that it becomes clear what must be done to come up with a solution.
• Referenced = a critical part of the requirements elicitation is to establish a reference table that is used to confirm the implementation of the requirement through different gates, until the decision is made to drop a requirement. When work in progress for a bundle of work reaches a gate there is a need for QA to confirm that the product at that stage has, in fact, implemented support for the requirement – you don’t want to reach the end of the development only to discover that the requirements are not fully satisfied.
• Traceable = there must be a way to confirm that the requirement has been implemented, so we need to confirm that there are test cases established to establish that to be the case. The reason we look at this during the elicitation stage is so that we can define that ability – a requirement that cannot be tested is not a realistic input to the process. Early in the process QA needs to take a look at the requirements to see if, and how, they can verify that the work was done properly.

Requirements management consists of an inventory of what is expected at each stage of the project, and a reference to when the implementation of the requirement is confirmed. A management plan does not have dates, it has definitions of requirements, with a separate reference for each bundle of work in which a requirement is featured. At established checkpoints QA confirms that each requirement is accounted for in the delivered results before further work is done:

• For practical reasons we recommend a “gated methodology” that may drive some people nuts, but that is the only way to confirm that what is delivered is good to move on to the next stage of the project. For example, even with Agile, a requirement should not be added to backlog unless it is actionable, and a product is not deliverable until the requirement is demonstrably satisfied.

The team needs to understand what they are building and how that relates to the requirements we have in our management process. They will be able to understand “why” a requirement is important because it documents context to the goals and objectives for the project, feedback from the elicitation process, and confirmation of decisions about the requirements. Understanding increases predictability of future results and lessens the potential for issues or changes during work in progress, assuming that we start with a well thought-out set of requirements.

• Like the project plan itself requirements may define a precedence structure, suggesting that some requirement makes sense to implement only if the prerequisite requirement is implemented. If that is not the case the requirements management process must be able to show impact on the dependent work activities.
• Changes to the requirements once work gets underway must be vetted against the prerequisites to make sure that approving these changes does not put the project in jeopardy. The work might be completed on time and within schedule, but if it does not satisfy the stakeholders that doesn’t do much good and the project would still be deemed a failure.

A requirement is usually described as a document (physical artifact) that details aspects of the final result of a project. We often look for details about what the final product or service must do and how it will be used. We need to understand the required functionality, and the value it brings to the project initiative. Whether the actual collateral is pure text, a drawing, a model, a mock-up, or a simulation, the key is that we must have an audit record for each instance of that requirement in the project so that we can trace its implementation. Analysts, developers, testers, and other resources, must confirm that they understand the requirements before the work is initiated – there is no sense arguing after the fact that the needs did not get expressed in a manner that allowed the work to be performed.

REVEAL provides an Excel™-based tracking repository that mirrors to the development process except for a unique tracking record for each detailed implementation responsibility. It allows us to track the work, and to monitor when a specific milestone is expected to be reached so that the requirements contribution can be confirmed. This management process is independent of the manner in which “needs” or “goals” are defined as “use cases”, “features” or “functional requirements”, or as agile development “epics” and “stories”: if it looks like, sounds like, acts like a requirement, then it is a requirement. Requirements are essential to product development: without clear requirements results could be incomplete or defective.

Through the life of a project many participants contribute to defining requirements. A business analyst may initially work with stakeholders to understand what the business needs are. A stakeholder might request a feature by describing how the product will provide value in solving a problem or delivering a service. A designer might define a non-functional requirement based on how the final product should look or perform from a standards, usability, or end-user interface viewpoint. A systems engineer might create a system requirement that adheres to specific technical or organizational constraints like security or access restrictions. Starting with high-level requirements the details are fleshed out as sub-sets within the higher level, and this can be done iteratively until finally we list entries in each work package within a project plan to make sure we know how that work package will address the overarching need.

For sophisticated products or software applications we may collect hundreds to thousands of detailed requirements in order to have a clearly defined scope of work. A structured management repository is a necessity for projects of any size, and the information must be accessible to team members involved in a collaborative development effort. They must be alerted to changes (if any) that impact the work pending to make sure they do the right things at the right time. The tie-in between the requirements repository and the project plan should help to control work in progress, prevent work packages from being released when they are canceled or being changed, or alert the stakeholders what work has been completed that by then have become sunk costs.

Team collaboration can improve the final result based on receiving support on decisions and in planning good requirements: often the choices change when the team uncovers details that were unknown before. Everyone has a stake in projects and provides feedback: not only the client sponsors and stakeholders who are paying for the work. In some projects participants are just told what to do, and so there is none of the desired shared sense of commitment and understanding of what the project should accomplish. If the developers and testers are unclear about expectations issues lead to frustration that can cause delays on the projects. With a shared repository everyone can confirm expectations when they are ready to get going with the work, and the innate filtering selections in Excel™ make it a snap to focus on relevant items.

Requirements traceability describes a structured repository to organize and track the documents that are requirements artifacts, and to monitor how the requirements are being satisfied through the different stages (or gates) of the development process. This is not as complex as it might seem: it is just that there can be an awful lot of detail to manage, a good reason for having a repository on hand. We can have just one repository, or more likely several repositories, depending on how much control you want:

• Global = all the requirements by type and by system and data store may be referred to as the data dictionary. This incorporates the edit rules for each component or data element, so that there is a need for multiple tables that reflect different dimensions. It is much easier to ensure that we work in a matrix structure with multiple tables than to implement a multi-dimensional table that is difficult to represent in any other way.
• Local = all the requirements by project, broken down by work-packages and progress gates, that is a “to do” list supported by the global details (we only highlight the changes that will later end up in the global repository). The global repository will flag the requirement as undergoing change so that other projects are on notice that they might need to conform to the new rules.

The data dictionary should be able to trace each requirement back to an original business objective and product “owner”, which allows us to identify the impact changes have, and whether that requirement was implemented and tested, and above all to make sure we do not break something that is working.

Managing change is an important project management responsibility to prevent “scope creep” within approved work in progress. Scope refers to the project charter that approves what work may be done to deliver a product, services, or result within a given budget and time-frame. Scope creep is when projects drift away from what is authorized to implement new (sometimes not asked-for) functionality that may be at the expense of requested functionality that may not be delivered. Similarly, the data dictionary has change management to make sure that a project does not alter functionality in a way that is at odds with what are approved corporate standards. The project may only change established functionality of that is formally approved by the product management, then the change implementation is managed by project management processes until the final product is delivered and the new definitions become formalized.

REVEAL maintains a history of changes to requirements that show what was, what is, and what may be if proposed changes are approved. This provides visibility that supports communication and impact analysis and we can establish the domino effect of successive changes. Some features are “nice to have” but can only be implemented if bundled with another scope of work (that way the project overhead costs can be shared across objectives). Bundling work to optimize the value of the project work is not scope creep, but if that pick-up work causes time or cost budgets to be exceeded then it must be delayed to a later project. It is important to understand that requirements should never be determined within the project even if we propose to use Agile development methods. When the change management process is compromised it can put the entire development organization in jeopardy, which in turn puts the company at risk.

Quality is something that goes into a project, you cannot test it into the project at the end. Therefore, if we can get requirements sorted out properly at the beginning of the project, and we can establish testing rules to confirm that the implementation is correct, we can have more confidence in the results from the system development life cycle process. Generally there will be fewer errors, which means less re-work or fewer compromises, which then delivers the end-results to greater customer satisfaction. Getting it right the first time saves money and reduces conflict within the larger development organization. Testers that find problems at the end of the SDLC often get pushback for all the wrong reasons, not the least of which is that (by then) the development budget has largely been spent while there is little to show for it.

We noted earlier that testers can help during the requirements definition stage to establish appropriate SMART requirements to prevent, or to detect and fix, problems at the earliest stage in the SDLC, rather than later in the process when it’s much more expensive to fix. With proper requirements (as well as with the analysis and evaluation that goes into the definition) we can reduce development defects by 50-80% while we make sure that the implementation is tracked and testing is performed at optimal times before problems get buried. The cost escalation of finding bugs later in the process can be scary: it can cost up to 100 times more to correct a defect later in the development process. To understand that more clearly think of finding a foundation defect in the parking garage of a condominium building that is almost ready for occupancy – how much more complex do you think that will be to fix as compared to checking shortly after the concrete is poured that the mix meets the required specifications?

The REVEAL repository ensures that developers on any team can have access to current requirements to make sure they do not develop results based on expired requirements or ones that are not yet approved. An ounce of prevention is worth a pound of cure in development as well, which is why REVEAL will be one of the cornerstones of implementation projects of all kinds, not just for Information Technology projects.

Learning Formats       PMAP_REV

This course is currently available in a classroom setting (public or company private) with approximately 30 contact hours (5 days).

PDF – Certificate Of Completion

Each course offers a certificate of completion that identifies the course, the student, and a brief description of the course. To receive a certificate the student must have attended at least 80% of the course sessions. This personalized certificate is forwarded to the student by Email.

PDF – Course Notebook

Each course includes a notebook in PDF format that provides the minimum knowledge the student must master in order to obtain the certificate. In the notebook you will find references to other study materials. Students receive the notebook by Email when their registration is confirmed.

PDF – Program Overview

An overview of this study program can be downloaded from the website by right-clicking on the program link on the enquiry page.

PDF – Current Training Schedule

A list of upcoming training sessions can be downloaded from the website by right-clicking on the schedule link on the enquiry page.

Registration – Service Providers

To register for any training course please look on the enquiry link page of your service provider (from where you accessed this website). On the page you will find a registration request form where you can order the course that you are interested in. The availability dates will be provided to you, along with payment instructions if you decide to go ahead.