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:
Possible forms for requirements packages may include:
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
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:
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.
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:
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.
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:
The supplier may be asked to submit specific information. Examples include:
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: 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.
Business Analyst Related Interview Questions
|Business Analyst Interview Questions||Business Letter Format Interview Questions|
|Business Communications Interview Questions||Business Environment Interview Questions|
|Business Management for Financial Advisers Interview Questions||Business Development Interview Questions|
|Business Management Interview Questions||Executive Business Analyst Interview Questions|
|Business Objectives Interview Questions||Business Development Manager Interview Questions|
Business Analyst Tutorial
Business Analysis Planning & Monitoring
Requirements Management & Communication
Solution Assessment & Validation
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.