Business Analysis Guidebook/Documenting and Managing Requirements

Organizations spend a lot of money on key projects to ensure continued viability in a rapidly changing world. They invest in projects to solve a business problem, take advantage of an opportunity or implement a strategic solution that furthers business goals. Capturing and managing the right requirements ensures avoidance of costly missteps and is key to delivering successful projects with measureable value.

In this Section of the Guidebook, readers should gain an understanding of the activities that are associated with the documentation and management of project and application requirements. These activities support an organized methodology for performing Business Analysis throughout a project life cycle and enable an analyst to position an organization to manage application projects and downstream maintenance in support of organizational strategies and work processes efficiently and effectively. Whether an analyst is involved in a project or initiative from the ground level or ‘Initiation’ through enhancement changes or only involved in a part of the development life cycle, information contained in this section should provide guidance for the activities involved in the requirements management process.

Requirements Development

Requirements development includes activities related to gathering and analyzing the requirements.

Gather/Elicit Requirements

When gathering requirements, Business Analysts need to capture information within the context of the organization and in support of operational needs to satisfying stakeholder goals.

Learn How the Organization Operates

The process of gathering and eliciting requirements begins with an understanding of how an organization operates. Most projects involve a small subset of the overall organization. Understanding the high-level process flow of a business highlights the ‘big picture’ and serves as a foundation for planning the requirements gathering and management efforts. In public sector operations, the primary mission is to serve the public. Whether that involves ensuring the health and safety of the public, enforcement of laws and regulations, providing support services, or some other mission, identifying the high-level purposes that drive the project environment ensures that the project outcomes are aligned with the organization’s goals.
The construction of a context to identify the project’s organizational impact involves several iterations. Each iteration explores different organizational aspects until those operations directly affected by the scope of the project are isolated and there is a clear understanding of the scope of the expected deliverable(s). Communicating with business users and eliciting the sources of this information is a key step in building your plan for requirements management.

Learn How to Speak the Organization’s Language

Terminology: The study of terms and their use

Semantics: The study of meaning

Familiarizing yourself with the business terminology is a fundamental component of establishing an informed understanding of a project domain. The semantics and terminology of the business ‘language’ bridges gaps between the business, technical and external stakeholders. Using a common terminology/semantics to communicate information about requirements ensures that the deliverable will fulfill the expectations of all stakeholders.

Your role as a successful liaison depends in part upon expanding your vocabulary to meet the project needs. The internet and an organization’s intranet can be resources for gaining the additional vocabulary needed to assist in communicating clearly with all project stakeholders.
It is always useful to capture important terms and acronyms used within the requirements in a requirements glossary, especially where resources are shared and/or outsourced. Such a glossary may be held at the organizational level – if so, it can be a valuable resource for you to help in understanding the language of the business and as an aid to writing clear and concise requirements.

Plan to Capture Requirements

Requirements are useful throughout the SDLC and into the future. During the execution of a project, your requirements will provide a source for analysis in performing the impact analysis for change requests, design changes and other typical project experiences. Capturing requirements in an organized way enables you to perform fully informed analysis throughout the project life cycle and beyond, into the application maintenance phase.

When you have an existing application and need to incorporate an enhancement to that application’s functionality, your requirements can be re-used to determine every functional area of the application where proposed changes may impact the existing application. Planning for current project and ongoing maintenance deliverables requires the BA to form a plan for organizing the requirements.

Choosing appropriate attributes for your stored requirements will facilitate your analysis downstream during project execution. Attributes, like Source, Status, Functional Area, etc., are pieces of information about your requirements and can be used to filter requirements so that analysis is focused on only relevant information. Is the project complex enough to warrant this effort? To what level? Make decisions concerning how you will organize and manage requirements before the project is in full ‘Requirements Gathering’ mode.
A document repository for project documentation can be used to ensure that a project team has one source of authority for project artifacts like process models, use cases, key presentations, base-lined requirements, project and work plans, defects and change logs, or other documents used in the project execution. This type of tool enables project team members and business stakeholders to reference source material for requirements on demand, promoting a diversified review of the resulting project work.

Requirements Sources

There are many sources of requirements. BAs examine the business operational information and communicate with stakeholders and other interested parties to gather requirements. Many will be uncovered during the organizational analysis phase of gathering requirements. Even project documentation includes additional requirements, stated at a high level.

Business Rules

There is a common misconception that business rules are requirements. While there may be a one-to-one correspondence between the two, there is a distinction between them. Requirements describe what is needed to implement the business rules. Business rules themselves describe how the business must operate. The following table provides a comparison.

Business Rule	Requirement
Customers may reserve an appointment by scheduling a date and time to meet with a representative of the department.	• The public facing web site will display a phone number customers may call to reserve an appointment. • The public facing web site will allow customers to navigate to an appointment reservation request form. • The reservation request form will include the customer name, address, phone and e-mail contact information and requested appointment date and time. • The customer must not be able to choose an appointment date and time on the reservation request form that is already booked. • Customers may submit their request directly from the form interface. • Submitted reservation request forms will be scheduled on the department calendar.
Failure to pay the fee by the due date will result in a .02% penalty charge to the customer.	• The application will automatically determine when a customer fee is overdue based on the current date and the receivable due date. • When a customer fee is overdue, the application will calculate and update the penalty amount on the customer receivable record. • The penalty calculated for overdue fees will be equal to .0002 * the overdue customer receivable balance + previously accrued fees.

Business Rules (BABOK v2.0)
• Define or constrain some aspect of the business
• Apply across processes and procedures (system agnostic)
• Intended to assert business structure or control/influence the behavior of the business
• Rules are atomic – that is, they cannot be broken down

Many organizations actively manage their business rules. There are also many organizations where the rules are embedded in the policies and procedures used to guide operations. Many procedures are not captured in any document, but reside within the staff knowledge-base. Regardless of which environment you are working in, the business rules affecting your project should be identified to ensure that your project deliverables support overall operations.

For those organizations that effectively manage their business rules, understanding them is fairly straightforward. Where an organization does not formally manage the rules, you will need to perform analysis to identify the rules. Understanding applicable policies and procedures, and accepted IT and Security standards, prepares you to ensure that the requirements expressed by your users comply with business operations that must be supported by the project deliverable.

Business Case/ITIR

The Business Case, Project Charter, Information Technology Investment Request (ITIR) or other documentation created during project initiation clearly outlines the project deliverable expectations and justification. This document will generally provide high-level business requirements that you will use to guide the development of functional and non-functional requirements. It may even include some of the functional and non-functional requirements themselves. This is the starting point for user requirement discovery, providing a context for discussions and communications.

Constraints

Identifying constraints that are applicable to the project ensures that the deliverables are feasible. No software application can be constructed or implemented without an understanding of the technical environment where it will reside. No business application can be constructed or implemented without an understanding of the legal environment where it will reside. The solution must support the technical IT policies and security standards, and the law and regulations applicable to the business and/or business process. Constraints affecting the solution are important to identify non-functional requirements and to use when communicating with project stakeholders during the development of the functional requirements.

Existing Applications

When a project goal is to replace or enhance an existing application, that application can provide many of the requirements that will be applicable to the solution. This ‘As-Is’ scenario is a gold mine for determining necessary functionality and project requirements. If requirements were managed for the old application, they can be re-used, with the appropriate suitable modifications, for the current project. Maybe the project deliverable addresses a brand new need that no existing application supports. If this is the case, the project solution may need to incorporate business rules and functional requirements for multiple existing applications and business processes. This type of ‘As-Is’ scenario analysis is typically applicable to system integration projects.

Business Users/Stakeholders

While investigations into the Organizational structure, business processes, rules and project artifacts provide a foundational understanding of the business problem or opportunity that the project was created to address, it is an analysis that is constrained to a single perspective – that of the analyst. Business users and other project stakeholders provide verification that the requirements are correct and they also provide previously unidentified requirements that are not necessarily found in organizational documents, process analysis or other method. Gathering these types of requirements requires communications, involving interviews, surveys and Requirements Gathering sessions.
Reconciling and incorporating the multiple perspectives of users and stakeholders is an important BA activity.

Analyze Requirements

As requirements are gathered they should be analyzed within the context of the other requirements, the overall project and the organization. This activity will identify requirements that are not valid, highlight missing or incomplete requirements and provide the necessary information to complete requirement definitions.

Categorization

As requirements are captured, category information should be recorded as requirements attributes. Categories assigned to requirements assist in filtering requirements for analysis purposes. The context of the project will determine how and to what extent requirements are organized into categories. A primary goal of categorizing requirements is to facilitate analysis. Some organizations may have standard requirements categories to use while other use project-specific categorization. Categorization supports quick assessment of the impact of proposed changes and supports traceability for downstream work efforts, such as design and testing, helping to guide activities.

Use categories that make sense to the project where possible. For example, a development effort that involves multiple, integrated applications may want to include a category for the individual application the requirement applies to. Then, you can easily examine only those requirements associated with the single application when analyzing work efforts, costs, etc. For a small, self-contained application project, this category would not add any value. Regardless of what categories are used, they should provide an organized way to facilitate analysis, minimize development rework and ensure that the objectives for the project are delivered.

Dependencies

Dependencies that exist between individual requirements help to guide prioritization and highlight possible risks to the project’s success. For example, if you have one requirement that the customer address will be captured and another requirement stating that the system will assign work to staff based on where the customer lives, then the ‘work assignment’ requirement depends on the customer address requirement. From this dependency analysis, you now know that the customer address MUST/SHALL be captured before the work assignment requirement will be met. It also provides incentive to refine the address requirement to include all relevant address elements.

Requirements may also have dependencies on other projects or the existing infrastructure. For example, if your project will interface with the deliverable for another project, you may have requirements that are dependent on the output of the other project. If that project fails, your requirement may need to be modified or invalidated.

Impact and Feasibility Analysis

Organizational Impact
Extends beyond project focus and may include:
• infrastructure and technology strategies
• other applications
• work process changes

Implemented requirements generate changes to the organization, technical architecture, security, business processes and/or groups of people (both internal and external). The project team will be able to mitigate risks, set expectations and prevent unexpected consequences by understanding how the project will affect these organizational variables. Impact analysis includes identifying the impact if a requirement is not implemented, as well as the impact if it is included in the project deliverables. Use this information to set priorities and provide change management guidance.

During the requirements elicitation and facilitation process, you may identify requirements that certainly are possible, but they are not practical. A simple checklist can be used to focus attention on those requirements that affect areas of concern. The level of impact (None, Low, Medium, High) can be estimated and decisions regarding the feasibility of accepting a requirement can be guided by this analysis.

Where the project plan incorporates a staggered implementation of the deliverable or the project will be executed using an Agile development methodology, impact analysis may be needed to determine which requirements should be implemented for development cycle. Factors to consider when performing impact and/or feasibility analysis include:

• Associated costs,
• Complexity of implementing the requirement,
• Skill levels of the technical development team and the users who will use the application and
• The organization’s operational ability to support the completed project deliverables.
  

These factors can provide requirement attribute definitions (i.e., Is the cost associated with implementing the requirement ‘High’, ‘Medium’ or ‘Low’?), contributing to categorization of requirements.
The project manager and business sponsors should carefully review ‘High’ impact changes to verify their validity, cost, feasibility, effect on operations and any other factors discovered during the impact analysis. This assessment should prevent unexpected results during and following the execution of a project.

Requirements Management

Managing requirements provides the foundation for project analysis, design, development, quality assurance and ongoing maintenance activities. The primary tasks associated with requirements management involve capturing requirements for re-use, validating requirements, managing the change associated with requirements and ensuring traceability of the deliverable to the organizational goals and needs.

Capture Requirements

List of commonly used Requirements Attributes

Capture the requirements to manage them throughout the project lifecycle and for re-use into the future. The level of a requirement may identify the appropriate attributes that should be captured. For example, associated costs may not be a realistic attribute for a detailed system requirements, but support prioritization for a high-level Business requirement. For each requirement, identify and record information (attributes) about the requirement that is relevant to the project. The List of Commonly Used Requirements Attributes at right lists some common attributes that are often included in a requirements repository and include the appropriate requirement level where it makes sense to capture the attribute. Please note that these attributes represent general guidelines and should be adjusted for the project scope.


Word processing documents are often good vehicles for communicating requirements across the project’s stakeholder groups. But using a document-based approach to managing requirements introduces issues that can be avoided by storing requirements, and requirement attributes, in a spreadsheet, simple database or other requirements management tool. These issues include:

• Documents are difficult to keep current
• Changes to requirements become hard to communicate
• Information needed to manage requirements is difficult to store and use
• It is difficult to trace the requirements to other project artifacts
  

What should be the extent and level of requirements captured? This is generally determined on a case-by-case basis. It depends on various factors, including the nature of the business, the stakeholders who are involved, the complexity/scope of the deliverables and the project management methodology. A project that involves implementing an off-the-shelf application, for example, would generally not document all requirements as extensively as a project that is charged with integrating the information from multiple databases. Each project must determine the appropriate level of requirements definition based on the project deliverables.

The level at which requirements are captured should be driven by the project complexity and environment. At a minimum, the high-level business requirements must be captured. These requirements clearly and concisely state the needs and goals of the solution, providing a common understanding across stakeholder groups. They represent the foundation for validation of the solution during the quality assurance activities performed before release. They provide the source for ‘backward traceability’ of the detailed requirements that are implemented.

During the requirements definition phase of a project, the Functional and Non-Functional, or Business and Technical, requirements are identified and refined. These types of requirements may be captured at a very detailed level (e.g., UI, User, Stakeholder, etc.) or at a higher level which only encapsulates the ‘why’ and ‘what’ of the solution. Each lower-level requirement should be directly associated with the high-level business requirement that it supports. This ensures complete validation of the solution.

Transitional requirements may also be needed to cover the cut-over from the existing processes/applications to the new solution that the project will deliver.

Functional/Business	define the behavior and capabilities of an application, the information that the application will manage and the required inputs/outputs. These requirements must take into account how a business operates, the improvements and changes necessary to support the project goals and needs, and incorporate any existing constraints that must be supported.
Non-Functional/Technical	must support, and be supported by the environmental conditions under which the application must remain effective. They include the qualities that the application must have. They encompass criteria related to performance, scalability, security, usability, system availability and the underlying information architecture.
Transitional	exist only during the transition from the ‘As-Is’ state to the ‘To-Be’ state of the project deliverables and are not identified until the system is designed. They include data transformation, user training and other transition needs that must be supported during the implementation of the solution.

Verify Requirements

After the initial discovery, there is generally time involved to gather associated information and finalize the requirements. Each requirement should have a complete set of attributes captured and express the business need, or ‘what?’, that will be supported. The actual requirement text should be written clearly and concisely so that all project reviewers and approvers will share a common understanding of each requirement.

The process that results in requirements approval involves all project team members, business experts and technical oversight. Requirements are distributed to those designated as responsible for review. Reviewers will accept requirements as written, dispute requirement information, elaborate on the rationale or dependencies, and generally provide feedback to correct or complete requirements. It is important for requirement reviewers to understand their role in this process. Clear direction for reviewers should be provided, including criteria for evaluation and sign-off procedures for validation.

Once the requirements are reviewed and adjusted for any corrections or missing information, they must be approved by designated operational and/or technical authorities. The approval process involves a review of the operational and technical accuracy of the requirements and considers the feasibility to implement. An approved requirement will provide a ‘baseline’ for purposes of the requirements management process, setting user and other stakeholder expectations for the project deliverable. For IT projects where the deliverable will be accomplished in phases or sprints, approval for the requirements that will be supported in later phases of a project does not have to be completed before initial development work can begin.

During the period of review and approval, a process should be used to resolve conflicts and/or issues. This process will provide a framework to support forward movement on the project. Each project may have a unique process for resolving problems, depending on the business, culture and team members involved. Regardless of the process that is established, it should be clearly communicated to all project team members. And then, it should be followed. Consistency in the resolution of problems will enhance the ability to execute the project and meet objectives.

Manage Change

As the project progresses, there will be further changes and/or refinements that affect the approved requirements and/or create new requirements. Changes may be generated by the identification of new required functionalities, errors or defects in the current implementation and high priority requests to enhance existing functionalities. Each potential change should be analyzed to determine associated feasibility, costs and benefits. An analysis of the impact of making the change should identify any associated changes to project schedules, costs or other existing requirements.

Description of Attributes Collected For Managing Changes

Change requests are often captured separately from the project requirements. Identifying the requirements that will be affected by the change is critical to maintaining correct and current requirements for the project. Change requests should include details to justify enhancements or identify the necessity for the associated work. In effect, each request must include a mini-business case to justify the change. The Description of Attributes Collected for Managing Changes table at right lists some suggested change request attributes. As with the captured requirements attributes, change attributes should be determined to incorporate applicable project scope and needs.

Managing the change involves capturing the change, gaining stakeholder approval, modifying existing project plans, process or other diagrams/models, and requirements to include the change, executing the change, performing QA on the change and, finally, implementing it. This process will impact existing requirements and create new project (or application) requirements. The changes to your baseline requirements should be identified using the unique change request ID number as the requirement (or modified requirement) ‘Source’.

When a requirement is ‘Approved’, it becomes a baseline requirement. This ‘Approved’ status remains in effect until and unless it is changed. For example, a change request is approved for implementation that will modify our existing ‘Approved’ requirement. Now the existing baseline requirement will be replaced using an updated version of the requirement that incorporates the approved change. This updated version of the requirement is the new baseline, the currently ‘Approved’ requirement. The previously approved requirement is retired. Other project deliverables that are dependent on the requirement, including quality assurance tests and user documentation, will also need to be updated for the approved revision.

Change Management Process

A simplified process that might be used for managing changes is illustrated in the Change Management Process diagram at right. Information about the change, including scope, feasibility, costs, benefits and impacts to existing requirements and technical architecture, will be needed for the approver review. Specific designees will be responsible for approving changes.

Once a change request has been approved, the change will be incorporated into the current project work schedule, budget and requirements repository. For new requirements, attributes will be captured in the requirements repository. For changes to existing approved requirements, the original requirement(s) should be replaced with the altered requirement(s). The original requirement(s) should be marked with an inactive status and retained for historical analysis purposes.

Trace Requirements

Requirements are the foundation for ensuring that a project deliverable supports the needs that justified the project. Each captured requirement should include an attribute that provides ‘backward’ traceability to the source of the requirement.
Once requirements are approved, other project artifacts will be generated. There is a correspondence between the requirements and project work. For IT projects, the requirements will be allocated to different areas of the designed deliverable. For non-IT projects, the requirements also must be satisfied by project deliverables. Quality testing and user documentation and training also are derived from the requirements. Traceability, from the original project documents through the project life cycle to the implemented solution, should be supported in the captured requirements and other project artifacts.

Forward Traceability Diagram

The diagram at right shows the ‘forward’ traceability from requirement sources, through the design of the deliverable, test scripts for the project’s QA process and end user documentation. The flow can be reversed to review the ‘backward’ traceability path. Using a methodology that supports this tracing capability provides the means to ensure that the project deliverables support all the identified project needs and goals.

Matrix showing tasks against functional requirements in order to facilitate traceability

Traceability is usually presented using a matrix that correlates any two base-lined project artifacts. It is especially useful when determining the impact a change may generate. The Matrix at right provides an example of a Requirements Traceability matrix that might be used when assessing the impact of a requirement change to the quality testing for new development work.

In this example, a change to the functionality related to the third ‘Form’-related functional requirement has the potential to affect the 23 existing functional validation tests for the Creation, Editing and Editing/Copying form tasks.
As with the capturing of requirements, the degree to which requirements are traced should be determined by the circumstances of the project. Maintaining a very high level of traceability may be overkill when the associated effort delivers a low business value. But failure to maintain adequate traceability can easily impact the ability to remain within the cost and schedule constraints of the project.

Communications

The communications necessary during the requirements gathering and management activities will be determined by the project purpose, stakeholders and environment. For smaller projects, a requirements communication plan may be deemed as not necessary; for larger projects, a formal plan may be an essential ingredient to ensure that all team and management staff are coordinated in their efforts and that all project objectives are being met.
Regardless of the level of formality of the project, the goals associated with requirements communications center around the concept that all stakeholders should share a common understanding of the requirements.

Appropriate to the Recipient

Communications should always be presented at a level that is appropriate to the recipient of the information. The level of communication required for individual stakeholders should be matched to the role the person plays in the execution of the project.
For example, the Executives may receive an Executive Summary Requirements Document that presents the requirements at a very high level. SMEs and other stakeholders may review the mid-level functional requirements that describe what inputs, outputs, behavior and capabilities are needed. Detailed functional and system requirements are needed by the development and quality assurance staff.
Using these various levels when communicating about requirements will prevent recipients from receiving too much information, or not enough, for their purposes.

Requirements Artifacts

Requirements Artifacts

Where formal requirements artifacts are produced, these should follow standard formatting and include consistent content to accomplish the work task that they support. Standards regarding format and content may be adopted from a number of Standards-setting bodies or they may be developed internally within an organization. Consistency in the presentation of requirements information will facilitate the shared understanding across all stakeholder groups.
The image at right lists some common artifacts that are used for requirements management. The actual requirements artifacts that are used during the execution of a project may include these artifacts, and/or others, as appropriate for the project.

Requirement Information Delivery

Communications that occur during the Requirements Gathering phase of a project often take the form of informal conversations and e-mail messages between the project team and the business customers. Some projects may have a shared repository where documents can be reviewed simultaneously by multiple people, and may include electronic approvals; other projects may depend on stakeholders receiving e-mailed documents to be printed and filed in project binders. Regardless of the delivery method, it is a primary Business Analyst function to ensure that all project stakeholders have the appropriate requirements information to perform their roles within the project.

Communicate Requirement Changes

Changes to base-lined requirements must be communicated to the project stakeholders. Much of this communication is done during the course of the approval process, but for those not involved in that process, notifications, presentations or other methods of communication should be used so that all are aware of the change and its impact on the project work. Changes may need to be applied to upstream and/or downstream project deliverables. For example, a change to a law may require modifications to high-level project documents, requirements document, design plan, testing plan and/or other formal artifacts. When a change that includes such revisions is made, the people that use or rely on the artifact should be notified that the artifact has changed and why the change happened. The notification should include the updated revision of the affected artifact documents.

Application of material provided in this Section:

The scope of analysis work may include BA participation for the entire performance of a project or be limited to only a piece of the total project work. Documenting and managing requirements provides a framework to accomplish the necessary activities throughout the project lifecycle. The benefits of documenting requirements in an organized fashion include the ability to perform such tasks as impact analysis for changes, providing complete scope information for creating user guidance, determining quality assurance tests to validate the business goals and support for an organized approach to managing project team communications. Investing the effort to capture requirements at the time project requirements are being defined pays off even for future development projects involving the project deliverables.