Analytics and Details - What You Need to Know About Business Analytics

As the business analyst works his way from the initial scope of change to the details of the change, the requirements process is driven more by analysis than by definition, meaning we feel like we are refining ideas more than creating new ones. Wikipedia defines analytics as "the process of breaking down a complex topic or substance into smaller parts to better understand it. Business analysts analyze stakeholder input with the goal of creating a comprehensive understanding of "business processes, policies, and changes in information systems."

Analysis is a process of solving real problems, in terms of specifying requirements, creating a visual representation of a new process or software application, and developing work-flows and business processes. A requirement specification is the result of a detailed analysis of a set of requirements. Some deliverable templates strongly support the analysis process by encouraging thinking about flows, rules, exceptions, and boundaries. Often in problem solving, the business analyst encounters a discrepancy between what stakeholders want and what makes logical sense.

Throughout the analysis process, the business analyst brings together stakeholders from both the business and technical sides to help solve the problems at hand. Analysis often involves bringing together both approaches to solve problems or to find out how to solve a particular problem given the constraints of a given project or system. In any organization, an analyst may involve individual technical disciplines to help negotiate a suitable solution.

Scope statements / specifications list / business requirements

This type of document is often the result of initial stimulation activities, defining the scope and justification of change from a business perspective. They are usually not executable, but they are concrete and drive project activities. You can think of a scope statement as a roadmap for a project or initiative, clearly defining the boundaries around what is to be achieved, what business objectives will be met, and what is not in scope.

Functional requirements

A functional requirements document, or list, details the desired functions of a new software or system. Often, functional requirements begin with "the system will do" or "the system will be able to do" and are sometimes grouped logically by feature. For a multi-month project, the functional requirements document can easily exceed 50 pages. This type of documentation best supports projects using a variation of the waterfall method.

Functional requirements are given attributes to categorize them or combine them in meaningful ways.

Some common properties are :

Priority
Owner
Requestor
Effort
Risk
Use Cases

Use cases are typically textual descriptions of interactions between one or more actors and one or more systems. They can be accompanied by use case diagrams or system interaction diagrams, which visually represent the flow between actors and the system. Use cases can be written at different levels of granularity, from a high-level business process describing flows through multiple systems to low-level interactions between two systems, or steps to accomplish a specific business task within one system.

Product backlog

A product backlog is a list of features or requirements for delivery in an agile environment. I want to do (something) (to achieve some goal)'. Backlog items can be at different levels of detail and are distinguished between them epics and stories. Epics are high-level descriptions of functionality that can span weeks to months of development effort, similar to a feature or business requirement. Stories are short enough to be accomplished in a few days, depending on the functional requirements. Like functional requirements, product backlog items can also have attributes.

User Stories / User Acceptance Tests

User stories are the features and requirements behind items in the product backlog that are specifically defined by a set of user acceptance tests.

Work as a Requirement for Delivering Software in an Agile Environment Many teams document user stories on physical index cards that are torn up once they become obsolete or complete. Others use electronic databases to store this information.

Wireframes / Mock-ups / Prototypes

Almost everyone you ask has a different definition of wireframes, mock-ups and prototypes. This activity is not always part of a business analyst's role. In general, a wireframe or mock-up is a collection of documents or functional code used to express the appearance or page layout of an application or website. This can be accomplished on the infamous “napkin,” on a white board, or using a variety of wire-framing tools.

Prototypes are a more sophisticated representation of requirements and may involve working, but can be created using skeletal code, or a simulation tool that allows for business logic to be included.

Site Map

A site map will label, organize and define the pages of a website. A site map is especially useful for web-based applications. Interrelated deliverables for an installable software application can be screen diagrams. If you are creating new screens or pages, or modifying existing screens or pages, a map can help you quickly scope the application and identify gaps in your solution.

Data Models / Data Mapping Specifications

Data models or data mapping feature communicate key aspects of requirements in projects as data is pushed or pulled between systems. Data models are considered closer to "design" than "requirements" but often fall into the business analyst's area of responsibility. These deliverables represent the data model at the logical level. For example, if you are integrating two systems, you can map data fields at the screen name/label level. (i.e., here we want the data element that appears in System X to appear in System Y).

An essential feature of data models and mapping features is that they provide a detailed analysis of how data flows through the system. The format can be a spreadsheet or word document or diagram. They usually include rules for default values, translation rules, allowed values, and optional required values.

Diagrams and UML

Business analysts use diagrams to visually depict process flows, relationships between concepts, or model systems or project scope. There are a variety of diagramming techniques, and new business analysts should at least be able to create a work-flow diagram that visualizes process or system interactions.

There are many types of UML diagrams. Will be asked to complete domain diagrams, use case diagrams and sequence diagrams with occasional use cases. The required UML knowledge will depend on the specific business analyst position and is by no means a general job requirement, especially for an entry-level role. We should generally be aware of what it is and how it can be used.

If the job requires or prefers it, you can train yourself in a little more detail before the interview. UML diagrams, applied correctly, can help you guide the team through some of the more complex issues a project may face.

User interface specification

User interface specifications detail the rules for a particular screen or page in the system. They help you analyze the rules behind the screen and ensure that the new system has all the necessary functionality "homed". UI specification may or may not be another area of work, as it is often considered a design element, not a requirement, but has been found to be extremely useful in resolving potential requirements issues and communicating work-flow requirements. Application and look and feel are important to business stakeholders.

Traceability Matrix

Part of the analysis process is to ensure that each business requirement is met by functional requirements and that each functional requirement is linked to a business requirement. As you dive into the deeper details of a project, a traceability matrix helps organize requirements at different levels. Some organizations also develop requirements or test cases for design elements that validate the requirements were implemented correctly.

Traceability can occur by using a requirements management tool or by passing iterations through various documents in an informal way to ensure everything is covered.

Related Links

Finance - Complete information

Financial Analysis - Complete Information

Strategic Marketing - Behavioural variables

Money management skills

Introduction to marketing strategy

What is strategy?

Towards Strategic Management

Business Shaping Strategy

A balanced scorecard approach to marketing strategy

The role of marketing in marketing strategy

The Law of Success - An Introduction to the Master Mind