Prepare Requirements Package - Business Analyst


To select and structure a set of requirements in an appropriate fashion to ensure that the requirements are effectively communicated to, understood by, and usable by a stakeholder group or groups.


Requirements should be presented in formats that are understandable by the stakeholder. This task describes the work required to decide which format(s) are appropriate for a particular project and its stakeholders. They must be clear, concise, accurate, and at the appropriate level of detail. Requirements documentation should be created only to the extent needed to assure clear understanding by the team.

Requirements packages may be prepared for a number of reasons, including but not limited to early assessment of quality and planning, evaluation of possible alternatives, formal reviews and approvals, inputs to solution design, conformance to contractual and regulatory obligations, and maintenance for re-use.

The primary goal of developing a requirements package is to convey information clearly and in an understandable fashion. To help decide how to present requirements, ask the following types of questions:

  • How detailed do the requirements need to be?
  • What information is important to communicate? What is the appropriate level of detail to include?
  • What will the particular stakeholder understand based on the type of audience they represent and on that stakeholder’s preferred style of communication or learning?
  • Are the requirements package presentation and format, and the requirements contained in the package, appropriate for the type of audience that needs to review it?
  • How does the requirements package support the previous and subsequent phases(i.e. testing, implementation) or project activities and deliverables?
  • Misunderstanding of requirements will adversely affect solution implementation. It leads to re-work and cost overruns, particularly if deficiencies are uncovered late in the process.

Possible forms for requirements packages may include:

  • Formal Documentation: Formal documentation is usually based on a template used by the organization , such as a Vision Document or Software Requirements Specification.
  • Presentation: Delivers a high-level overview of the functionality delivered by the solution.
  • Models: The requirements may be presented only in the form of a model, such as a process map, or captured on a whiteboard.


Business Analysis Communication Plan: This will typically describe the stakeholder groups, their communication needs, and define whether a single requirements package or multiple requirements packages are required. The business analysis communication plan will also define the level of formality that is appropriate for the requirements.

Organizational Process Assets: May include templates that can be used to package requirements.

Requirements: The business analyst must understand which requirements will be included in the package. Requirements may be packaged at any point in their lifecycle.

Requirements Structure: A package should contain a consistent, cohesive, and coherent set of requirements.


1. Work Products and Deliverables

Work Product

A work product is a document or collection of notes or diagrams used by the business analyst during the requirements development process. The work product may or may not become a deliverable, although during different phases of the requirements eliciting process, the business analyst may need to share this information with stakeholders in order to clarify requirements, elicit additional requirements, or assess the feasibility of the solution approach. Examples of work products might be:

  • Meeting agendas and minutes
  • Interview questions and notes
  • Facilitation session agendas and notes
  • Issues log
  • Work plan, status reports
  • Presentation slides used during the project
  • Traceability matrices


A deliverable is a specific output of the business analysis process that the business analyst has agreed to produce. A requirement deliverable is used as a basis for solution design and implementation. The business analyst must understand the difference between these two concepts and use the deliverables as communication mechanisms. The business analyst will assess the needs of the audience, determine the level of detail that needs to be communicated, and as certain which deliverables to include in each presentation package.

2. Format

Depending on the type of requirement, the presentation technique may vary and specific formats may have been selected during development of the business analysis communication plan. There will likely be a combination of many formats in one requirements package. Consider the best way to combine and present the materials, so that they convey a cohesive, effective message to one or more audiences who will participate in the requirements review process. This may result in more than one requirements package being created for the same project.

Give careful consideration to what types of information should be included in a requirements package, and that the content may vary between different projects. The best format choice is the one that best communicates the specific content of the requirement. Each organization may have standards that the business analyst will be required to follow, and the project team will utilize the techniques appropriate for their project. Usually, each organization also has an approved suite of tools that are used for documentation.

If the package is created with the intention of obtaining formal approval, the requirements documentation must be complete in order to prepare the requirements package.

Additional Considerations for Requirements Documentation

Each requirements package may have a Table of Contents outlining what is included in the package. Grouping of the requirements into categories should be clearly identified in the Table of Contents for ease of navigation. It may also include a revision log to document changes between versions and help stakeholders verify that they have the most recent version.


1. Requirements Documentation

Requirements are frequently captured in a formal document. Many templates for requirements document exist and are in common use. While the selection of templates and documents is dependent on the business analysis approach chosen, some of the most common types of requirements documents include:

  • Business Requirements Document (note: many “Business Requirements Document” templates also include stakeholder requirements)
  • Product Roadmap
  • Software/System Requirements Specification Supplementary Requirements Specification
  • Vision Document

2. Requirements for Vendor Selection

If the solution team thinks that a potential solution is available from an outside party, the business analyst may capture the requirements in the form of a Request for Information (RFI), Request for Quote (RFQ), or Request for Proposal (RFP).

While these terms are sometimes used interchangeably, they are intended to reflect differing levels of formality in the vendor selection process. The organization’s purchasing agent, legal department or procurement organization is usually the owner of this process.

  • An RFI is generally used when the issuing organization is open to a number of alternative solutions and is seeking information to evaluate possible options.
  • An RFQ or RFP is used when the issuing organization understands the nature of the solution options available to it and is seeking vendors who can implement an option. An RFQ generally follows a less formal review and selection process than an RFP.

The solution team should carefully consider how each vendor solution will be evaluated. Often stakeholders can be impressed by a product demo when the underlying product does not truly meet the business need.

Business analysts must develop evaluation criteria based on the business requirements before looking at available products. In particular, an RFP typically includes a description of the selection criteria and process. The evaluation criteria used may be based on cost of the implementation or total cost of ownership. An objective measurement (weighting criteria) of how well the proposed solution meets the requirements may also be included.

When developing RFP questions, avoid using closed ended questions (those requiring only short answers). The goal is to stimulate the vendors to provide extensive information regarding their product and service offerings.

Most RFPs include many sections or components. Examples include:

  • Business and stakeholder requirements for the particular problem / solution area
  • Business strategy or business architecture description
  • Technical environment constraints/limitations
  • Legal, regulatory, or government requirements

The supplier may be asked to submit specific information. Examples include:

  • Solution cost or total cost of ownership
  • Alignment with overall business strategy
  • Solution architecture, performance, quality, and support
  • Solution’s extensibility and ability to integrate with other applications
  • Supplier’s sustainability, and/or supplier’s profile and reputation


Domain SMEs and End Users: Need requirements that are written using familiar terminology and that are easy to understand and review. They must fully understand each requirement, since it is this group that will be most affected by the solution implemented. This group will be primarily concerned how operational processes are affected by the implementation of the project, and will be interested in ensuring that the requirements they provided to the business analyst during the requirements elicitation are achieved.

Implementation SMEs: Need to obtain an understanding of the overall requirements for the project, and will focus on requirements they will use to design the solution. External customers and suppliers will need detailed technical interface requirements to order to construct the proper network and security protocols in accordance with corporate policies.

Project Managers: Include deliverables (including specific requirements packages) in the project plan and typically track them as milestones to assess project progress. The deliverable acts as a “contract” for the project defining the agreed upon work. The deliverable becomes a project asset because it represents a project output.

Regulators: May have specific legal, contractual, or governance requirements regarding what is included in a requirements document.

Sponsors (and other managers at the executive level): Often want summaries and high-level requirements. Their primary goal is to understand that the solution will meet the return on investment expectations in accordance with their business plan, and to minimize the time required for them to make an effective decision. The project scope may suffice, including the ROI (Return on Investment) assessment, business benefits, project cost and target implementation date(s).

Testers: Focus on understanding the critical success factors of the project based on the needs of the business users. They must acquire a thorough understanding of the functional and non-functional requirements in order to build an effective testing strategy.


Requirements Package

Requirements Package: The result of this task is a requirements document, presentation, or package of requirements ready to be reviewed by stakeholders. A package may contain all of the project requirements or may be broken into several sub - packages.

All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd Protection Status

Business Analyst Topics