Addendum H: Requirements Analysis

Introduction

Generally, requirements must be actionable, measurable, testable, related to a business need or desire, and defined at a level of detail that is sufficient for design criteria. They are commonly driven by some type of business need or desire where organizations are looking to improve a specific set of functions or processes.

Requirements analysis is a critical process toward achieving success in a project. Also referred to as requirements gathering or requirements specifications, it involves a series of steps and activities that allow organizations to determine what conditions must be met during the system design.

The Importance of Requirements

Organizations must ensure that the process of requirements analysis is not confused or mistaken for the system design process. Essentially, analysis is concerned with what needs to be done, such as studying the current state of a process and determining how it works. On the other hand, design is focused on how it needs to be done, such as implementing a technology to improve the process.

Knowing the scope of what requirements analysis is, the process is essential in translating business need or desires into an architectural view than can be used as the basis for systems design. Within the context of the system development life cycle (SDLC), requirements analysis focuses on identifying gaps within an area within the organization and is performed:

•  After the organization’s strategies are thoroughly understood; and

•  Before developing architectural design specifications.

The process of defining requirements involves considering how they are built. When organizations do not allow sufficient time to ensure that requirements are accurate and complete, the resulting consequence will be a finalized set of requirements that are ambiguous, untestable, and not capable of satisfying business needs or desires. Ultimately, the effects of these downfalls will lead to an unsuccessful project due to collateral damage such as:

•  Higher development costs

•  Schedule slippage

•  Scope creep

•  System defects

•  Customer dissatisfaction

It is important that organizations define their requirements to be clear, meaningful, effective, and aligned with business needs and desires.

Defining Requirements

Requirements analysis is centered on addressing the needs and desires of business strategies. From this, the requirements analysis process is performed to translate these business needs and desires into a comprehensive architectural model that can be used throughout the organization.

As described in the sections to follow, requirements analysis encompasses several phases to interpret business language and ultimately arrive at a deliverable solution. Understanding that the methodology used is subjective to the needs of each organization, the approach illustrated below is intended to provide a simplified workflow to performing requirements analysis.

Phase #1: Defining Scope

Similar to how any business project is initiated, boundaries must be set around what business strategy will be assessed. Without determining the scope for which requirements will be identified, the architecture model that will be delivered will not address the business needs and desires, resulting in an unsuccessful project as explained previously in this chapter.

Contributing to the scope definition, the following elements must be captured in terms of the specifics that will play a factor in the architectural model:

•  Data: What facts of significance are used to describe the organization and what they mean?

•  Activities: What processes, functions, etc. need to be included in this assessment?

•  Locations: Where in the organization will the activities be addressed?

•  People and organizations: What resources are involved in the activities that need to be included in this assessment?

•  Timing: Which business events are drivers that are included in this assessment?

•  Motivation: What objectives, goals, policies, etc. affect the activities included in this assessment?

There are no predefined rules or guidelines that dictate how to define scope; it is subject to every organization’s interpretation. Organizations must rely on their experience and common sense when determining the width and depth of where to set the scope boundaries. At the completion of this phase, a detailed scope statement is produced and will be used as the basis for executing the remaining phases.

Phase #2: Preparing Assessments

Although the scope has already been defined, there has yet to be a plan put together to outline the activities, people, and schedule that will be needed to complete this assessment. In establishing these components, it is important to keep in mind that there is traditionally a trade-off where only two out of three can be maximized.

To avoid unexpected surprises later in the process, it is important that organizations decide what the priorities for this assessment are. Figure H.1 illustrates the three scenarios that will occur based on deciding which components are priorities:

•  If the goal is to have a shorter schedule and maintain higher quality through increased activities, then there will be increased cost.

•  If the goal is to have a shorter schedule and reduce cost, there will be fewer activities, resulting in lower quality.

•  If the goal is to reduce cost and maintain higher quality through increased activities, then there will be a longer schedule.

Figure H.1 Priority triad.

Phase #3: Gathering Requirements

Identifying and capturing a baseline set of requirements must be done in a clear and concise business language. To arrive at a model that encompasses a complete set of business needs and desires, this baseline set of requirements needs to be drawn from various sources throughout the organization, including:

•  Operational support documentation

•  Stakeholder interviews

•  Formal proposals

•  Industry best practices

•  Strategic roadmaps

•  Security and regulatory requirements (international, federal, local)

As the baseline set of requirements is being gathered from multiple sources, it is important to recognize that while they are all related, each requirement is separate and distinct. Generally, requirements can be grouped into one of the following categories:

•  Functional requirements define features of the deliverable(s) that will specifically meet a business need or desire.

•  Operational requirements describe the “behind the scene” functions needed to keep the deliverable(s) working over time.

•  Technical requirements identify conditions under which the deliverable(s) must function.

•  Transitional requirements outline aspects of the deliverable(s) that must be met to hand over support responsibilities.

As requirements are identified, each item should be documented in a centralized register that will be used throughout the analysis process, such as a database or spreadsheet.

A requirement analysis report template has been provided as a reference in the Templates section of this book which includes a matrix that can be used to capture requirements.

Phase #4: Interpret Requirements

Using the aggregated set of baseline requirements, stakeholders now need to review what was documented to ensure that proper business language used in the requirements was captured correctly. Depending on the availability and location of stakeholders, performing these reviews in person might not be possible and alternative methods of meeting can be used, such as conducting interviews, distributing surveys, or holding workshops and focus groups.

Having stakeholders validate and verify the baseline set of requirements at this stage in the process is critical. Not only will stakeholder review ensure that requirements are as clear and concise as possible, but it also helps to eliminate any confusion related to having to translate business requirements into technical specifications by:

•  Not combining separate requirements

•  Removing subjective wording, ambiguities, or opinions

•  Avoiding scope creep

•  Preventing scheduling delays

Following the stakeholder review, it is important that the baseline set of requirements is signed off by all stakeholders as part of the requirements analysis report, which is discussed further in this appendix. Documenting stakeholder agreement is important because these individuals may not be present throughout the remaining phases of the analysis or afterward during the system design process.

Phase #5: Finalize Requirements

By now the baseline set of requirements has been agreed to by all stakeholders and can be finalized as the foundation for upcoming planning and architectural design activities. For each requirement that has been accepted, the following additional contexts are needed to determine how it will be actioned and turned into a deliverable:

•  Aligning the requirement to the scope of the project

•  Categorizing the requirements based on how they relate to business needs and desires

•  Prioritizing the requirements according to criticality to the business needs and desires by determining if they are:

•  Core requirements: those which the deliverable will not be able to function without

•  Essential requirements: those which a short-term work-around could be implemented; but in the long term must be addressed

•  Desirable requirements: those viewed as the “bells and whistles” that are not critical to deliverable(s) functionality

As part of the requirement analysis report template provided as a reference in the Templates section of this book, the requirements matrix can be used to further expand on the context of each requirement as discussed above.

Phase #6: Prepare Specification Documents

The specification document, also viewed as the final report, essentially outlines the organization’s understanding of its business needs and desires as related to a specific business strategy. It provides a level of assurance that all stakeholders within the organization understand and agree to the requirements that were captured at that point in time.

This document is created in clear and concise business language that will be used as the basis for subsequent project activities such as design and architectural specifications, statements of work (SOW), and testing and validation plans. Because it will be used as a governing document, it is important that it remains objective by not providing suggestions, solutions, or information other than that related to the requirements analysis activities. When completed, the specification document will contain enough information that it:

•  Provides assurance that all needs and desires have been well understood and translated into clear and concise requirements

•  Structures the requirements in a way that helps organizations to maintain appropriate control over scope and schedule

•  Contains sufficient details to serve as input into subsequent design specification activities

•  Acts as a governing document for the testing and validation activities that will be used to verify the requirements

A requirement analysis report template has been provided as a reference in the Templates section of this book.

Summary

Requirements analysis is an essential part of the SDLC process to ensure that the needs and desires of an organization’s business strategy are identified and documented as clearly and concisely as possible. Once completed, the specification document is used as a governing document to direct the subsequent activities of system design.