Appendix J: 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 to 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 as being the same with the system design process. Essentially, analysis is concerned with what needs to be done, such as studying the current state of a process or function and determining how it works. On the other hand, design is focused on how it needs to be done, such as applying a particular technology to improve the current state of a process or function.
Knowing the scope of what requirements analysis is, the process is essential in translating business needs or desires into an architectural view than can be used as the basis for systems design. Within the context of the systems development life cycle (SDLC), requirements analysis focuses on identifying gaps within a particular area within the organization and is performed:
• after the organization strategies are thoroughly understood
• before developing architectural design specifications
The process of defining requirements involves giving careful consideration to how they are built. When organizations do not allow sufficient time to ensure that requirements are accurate and complete, the resulting consequences will be a finalized set of requirements that are ambiguous, untestable, and not capable of satisfying the business needs or desires. Ultimately, the effect from 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
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 needs and desires into a comprehensive architecture model that can be used throughout the organization.
As described in the following sections, requirements analysis encompasses several phases to interpret the business language and arrive at a deliverable solution. Understanding that the methodology used is subjective to the needs of each organizations, the approach illustrated below is intended to provide a simplified workflow to performing requirements analysis.
Phase #1: Defining Scope
Similar with 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 do 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 being activities 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 have to 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: Prepare Assessment
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 on in the process, it is important that the organizations decide what the priorities for this assessment are. Figure J.1 illustrates the three scenarios that will occur from 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 an 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
Phase #3: Gather Requirements
Identifying and capturing a baseline set of requirements must be done in a business language. In order 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; such as:
• operational support documentation
• stakeholder interviews
• formal proposals
• industry best practices
• strategic roadmaps
• (international, federal, local) legal and regulatory requirements
As the baseline set of requirements is being gathered from the 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
• Technical requirements identify conditions under which the deliverable(s) must function
• Transitional requirements outline aspects of the deliverable(s) that must be met to handover 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 which 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 and that they were 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, holding workshops, or conducting focus groups.
Having stakeholders validate and verify the baseline set of requirements at this stage in the process is a critical activity. Not only will stakeholder review ensure that requirements are as clear and concise as possible, but it also helps to eliminate any confusion of 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; discussed further on 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
• Prioritizing the requirements according to the criticality to the business needs and desires by determining if they are:
• “core” requirements which the deliverable will not be able to function without
• “essential” requirements which a short-term work-around could be implemented; but in the long-term must be addresses
• “desirable” requirements which are viewed as the “bells and whistles” that are not critical to the 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 Document
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.
It is important that this document is created in a clear and concise business language because it will be used as the basis for subsequent project activities such as design and architectural specifications, statements of work, and testing and validation plans. Because it will be used as a governing document, it is also important that it remains objective by not providing suggestions, solutions, or other 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 business 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 clear and concise as possible. Once completed, the specification document is used as a governing document to direct the subsequent activities of system design.