Pagal World
Before you dive into this section, get out pens or highlighters of at least two different colors. If you are reading online you can use the online editing functionality of your reader or simply have ready a sheet of paper with room for three lists.
As you read this section be aware of areas in which you believe you have a good understanding. Consider “good understanding” to mean if you needed to do it tomorrow you probably could pull it off, possibly with a brief refresher. Secondly be aware of things that confuse you or that you don’t understand much at all, i.e. you don’t feel like you could do them tomorrow.
ANALYSIS AND SPECIFICATION
As the business analyst makes his or her way from the initial scoping of the change to the details of the change, the requirements process becomes driven more by analysis than elicitation we are refining ideas more than we are generating new ones. Wikipedia defines analysis as the process of breaking a complex topic or substance into smaller parts to gain a better understanding of it business analyst analyzes the input of stakeholders with the goal of creating a comprehensive understanding of the changes to business processes, policies, and information systems.
Analysis is the process of solving the actual problem, in terms of specifying requirements, creating visuals that represent the new process or software application, and developing work-flows and business processes. Requirements specifications are the result of detailed analysis about a set of requirements. Some deliverable templates heavily support the analysis process by encouraging thinking about flows, rules, exceptions, and boundaries.
Often in breaking down the problem, the business analyst will find inconsistencies between what the stakeholders want and what makes logical sense.
Scope statements / Features List / Business Requirements
These types of documents are often the result of the initial elicitation activities and define the scope and the justification of a change from the business perspective. They are often not implementable but they are concrete and drive the activities of a project. You can think of scope statements as a roadmap for a project or initiative, clearly defining boundaries around what is to be achieved, what business objective will be fulfilled, and what’s not in of scope.
Functional Requirements
A functional requirements document or list details the intended functions of a new software or system. Most often, functional requirements start with “The system shall” or “The ability to” and are often grouped logically by feature. For a multi-month project, a functional requirements document might easily be in excess of 50 pages. These types of documents best support projects using a variation of the waterfall methodology.
Read more: What is Business Analysis
Product Backlog
The product backlog is the list of features or requirements for delivery in an agile environment. Backlog items are typically expressed in the following syntax ‘As a *user+, I want to *do something+ to *achieve some objective]’. Backlog items might be at varying levels of detail and a distinction is made between epics and stories. Epics are high-level descriptions of functionality that might encompass a few weeks to a few months of development effort, analogous to a feature or a business requirement. Stories tend to be small enough to be achieved in a few days, analogous to a functional requirement. Like functional requirements, product backlog items might also have attributes.
