Skip to content
Share this post

Business Analysis

Definition, Perspectives, Process, Tools, and Techniques

Become a Business Analyst

Speak to a Learning Advisor to learn more about how our bootcamps and courses can help you become a Business Analyst.

Business analysis is among the fastest growing fields as per LinkedIn 2020 survey. Business analysis is a key skill which every professional should acquire to enable his/her organization to scale newer heights.

Let's learn about:

What is business analysis?

Business analysis perspectives

Business analysis process

Business analysis tools

Business analysis techniques

What is business analysis?

As per Business Analysis Body of Knowledge® (BABOK® Guide) Version 3.0 from IIBA®,

“Business Analysis is the practice of enabling change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders. It is a disciplined approach for introducing and managing change to organizations, whether they are for-profit businesses, governments, or non-profits. Business analysis is used to identify and articulate the need for change in how organizations work, and to facilitate that change.”

Business Analysis Perspectives

Business analysis is a vast topic. It can be conducted from multiple perspectives. Following is a list of perspectives which by no means is exhaustive.

1. Enterprise strategy analysis
2. Product portfolio analysis
3. Cyber Security Analysis
4. Enterprise Needs Analysis
5. Enterprise analysis
6. Project needs analysis
7. Business Data analysis
8. Product ownership analysis
9. Business Process Analysis
10. Software needs analysis
11. Cyber security analysis

Business Analysis Process

The set of tasks and techniques that are used to perform business analysis are defined in the Guide to the Business Analysis Body of Knowledge® (BABOK® Guide). We have listed all the tasks in BABoK in a subsequent section. Unfortunately, BABoK does not give a definite business analysis process definition. It is rightly so because the situations are different, organizations are different, needs are different. Trying to propose a business analysis process in such varied conditions can really be a nightmarish approach.

At the same time, applying Pareto’s principle, it will be prudent to say that in about 80% of the situations, we can propose a solid business analysis process. For remaining 20% cases, of course, we need expert guidance and need to design custom process. We are proposing a 10-step approach to business analysis. We propose following 7 steps business analysis process.

Business analysis process - Adaptive US

 

1. Plan, Engage, and Monitor

There are certain activities which run across the business analysis life cycle. This is numbered as 0 as it is the foundation for the remaining phases. Phase 0 will involve continuous planning, monitoring, engaging stakeholders, managing issues, risks, requirements, traceability. For every phase, we should perform an appropriate level of planning and monitoring.

2. Understand Project Context, Objectives, and Scope

Often business analysts are expected contribute as soon as possible towards project delivery. Often, the project may have started already, or a phase may be completed. As business analysts, it’s our job to clarify the business and project objectives as quickly as possible. Investing some time, whether that’s a few hours or few days, to get oriented will ensure we are not only moving quickly but also competent, effective, and confident contributor for the project.

3. Elicit Requirements

Plan to understand the process and expectations in detail from various stakeholders to understand their expectations from the solution. Identify stakeholders who are in best position to provide the requirements. Choose appropriate techniques to conduct elicitation activities.

4. Manage Requirements

Not all stakeholder expectations can be met given the organizational constraints. We need to understand which requirements are critical and feasible.

6. Document Requirements

Detailed requirements provide the implementation team with the information they need to implement the solution.

7. Define solution options

Define suitable solution options to meet business and stakeholder needs.

8. Evaluate and Improve Solution Performance

A track record of successful projects creates significant positive momentum within an organization. So, if we need to assess the value created by the solution.

 

Business Analysis Tools

Commonly used business analysis tools are:

1. Microsoft Visio
2. Atlassian Jira
3. Balsamiq
4. Lucid Chart
5. BizAgi BPM

Business Analysis Techniques

There are hundreds of techniques which business analysis professionals use. The most common ones are:

Functional decomposition

Functional decomposition breaks down a large aspect (processes, functional areas, deliverables, scope, or problems) into smaller aspects, as independent as possible, so that work can be assigned to different groups. This reduces complexity of analysis.

Estimation

Estimation techniques are used for better understanding of possible range of costs and efforts associated with any change.

Interface analysis

An interface is a connection between 2 components or solutions. Identify interfaces and interactions between solutions and/or solution components.

Organizational modelling

Org. modelling describes roles, responsibilities, and reporting structures that exist within an organization, and aligns those structures with organization’s goals. Visual representations of organizational units.

Stakeholder list, map, or personas

Identify stakeholders affected by a proposed initiative or share a common business need, level of decision-making authority, authority within domain and organization, attitude/ interest towards change, and business analysis work.

Scope modelling

Describe scope of analysis or scope of a solution. They serve as a basis for defining and limiting scope of business analysis and project work

Brainstorming

One or group of stakeholders deliberate on an idea to produce numerous new ideas in a non-judgmental environment, and to derive themes for further analysis.

Workshops

Requirements workshop, also known as JAD (Joint application design) session, is a highly productive focused event attended by carefully selected key stakeholders, and Subject Matter Experts for a short, intensive period (typically 1 or a few days).

Focus groups

Elicit ideas, impressions, preferences, and needs and attitudes from pre-qualified individuals about a specific product, service, or opportunity in an interactive group environment. Guided by a moderator. Typically 1 to 2 hours with 6-12 attendees.

Collaborative games

Uses game playing techniques to collaborate in developing common understanding of a problem or a solution. Involves strong visual or tactile (activities) elements such as moving sticky notes, writing on whiteboards, or drawing pictures.

Interviews

Most common form of elicitation technique where interviewers ask questions to stakeholders. Effective interviewers control discussions understand needs from ALL stakeholders, probe deeper when needed and ensure completeness of answers.

Observation

Elicit information by observing activities and their contexts.

Survey or questionnaire

Administers a set of written questions to stakeholders and Subject Matter Experts. Survey can elicit information from many people, sometimes anonymously, in a relatively short period of time. Can collect information about customers, products, work practices and attitudes. Alternatively, respondents are provided with a series of statements and asked for their level of agreement.

 

 

Document analysis

Elicit Business Analysis information, by examining materials describing business environment or organizational assets. Document analysis helps in understanding context of a business need or understanding how existing solutions are implemented. Based on Business Analysis information being explored, purpose, scope, and topics to be researched are determined.

Benchmarking and market analysis

Benchmarking compares org. practices against best-in-class practices from competitors, government, industry associations or standards. Market analysis understands customers’ needs, factors influencing purchase decisions, and studies competitors.

Prototyping

Provides an early model of final result, widely used for product design. Details UI requirements and integrates them with other requirements such as use cases, scenarios, data, and business rules. Stakeholders often find prototyping to be a concrete means of identifying, describing, and validating their interface needs. Prototypes can discover desired process flow and business rules.

Glossary

Comprises of key terms relevant to a business domain to provide a common understanding of terms. Contains definitions and synonyms. Needs to be organized and be accessible to all stakeholders.

Mind Map

Articulates and captures ideas in a non-linear (tree) structure. Ideas are grouped as topics, sub-topics, further sub-sub-topics. Mind maps use words, images, color, and connections to structure thoughts, ideas, and information.

Backlog management

Backlogs record, track and prioritize remaining work items. Backlog management is a planned approach to manage remaining work for project. In managed backlogs, items at top have highest business value and priority. Backlog items can be user stories, use cases, defects, CRs, risks etc.

Business rules analysis

Business policies dictate actions of an enterprise and people in it by broadly controlling, influencing, or regulating them. Business rules serves as a criterion for guiding behavior and making decisions in a specific, testable manner.

Lessons learned

Discusses and documents successes, failures and improvement recommendations for future phases or projects. Can include any format or venue that is acceptable to key stakeholders. Can be formal facilitated meetings or informal.

Prioritization

Provides a framework for stakeholder decisions to understand relative importance of requirements. Importance may be based on value, risk, difficulty of implementation etc.

Reviews

Communicate, verify, and validate content of work products, formally or informally. Communicate review objectives in advance to participants.

 

Item tracking

Captures and assigns responsibility for issues and stakeholder concerns. Items can refer to actions, assumptions, constraints, dependencies, defects, enhancements, and issues.

Balanced scorecard

A strategic planning and management tool to measure org. performance beyond traditional financial measures aligned to organization's vision and strategy.

Business capability analysis

Capability maps provide a graphical view of capabilities. Capabilities describes ability of an enterprise to act on or transform something that helps achieve a business goal or objective. Capabilities describe outcome of performance or transformation, not how it is performed.

Business cases

Formally or informally, justify investments based on estimated value compared to cost. Spend time and resources on business case proportional to the size and importance of its potential value. Business cases do not provide intricate details.

Business model canvas

Comprises 9 building blocks describing how an organization intends to deliver value. As a diagnostic tool, use elements of the canvas as a lens into current process or system of business, especially wrt relative amounts of energy, time, and resources currently invested in various areas.

Decision analysis

Supports decision-making in complex, difficult, or uncertain situations. Examines and models possible consequences of different decisions.

Decision modeling

Shows how repeatable business decisions are made using data and knowledge.

Financial analysis

Explore financial aspects (benefits and costs) of an investment.

Risk analysis and management

Identify, analyze, and evaluate uncertainties that could negatively affect value, develop and manage way of dealing with risks.

SWOT analysis

SWOT is an acronym for Strengths, Weaknesses, Opportunities, and Threats. A framework for strategic planning, opportunity analysis, competitive analysis, business, and product development.

Concept modelling

Organizes business vocabulary, usually starting with glossary.

Data dictionary

Standard definitions of primitive data elements, their meanings, allowable values, how those elements combine into composite data elements. Used to manage data within a solution’s context, often used along with ER diagrams.

Data modelling

Data models describe entities, classes or data objects relevant to a domain, their attributes and relationships among them.

Data flow diagrams

Show transformation of data from (data source such as external sources, activities and destination). Data used in DFDs should be described in a data dictionary. Highest level diagram (Level 0) is context diagram represents the entire system.

Process modelling

Graphical model to describe sequential flow of activities. A system process model defines sequential flow of control among programs or units within a computer system. A program process flow shows sequential execution of program statements within a software program.

Sequence diagrams

Sequence diagrams (also known as event diagrams) model logic of usage scenarios, by showing information (also known as stimuli, or message) passed between objects during execution of a scenario.

State modelling

State models (also sometimes called a process or system transition model) describe and analyze different possible states (formal representation of a status) of an entity within a system, how that entity changes from one process or system to another and what can happen to entity when it is in each state.

User stories

User stories are a brief textual description, typically 1 or 2 sentences, of functionality that users need from a solution to meet a business objective. User story describes actor (who uses story), goal they are trying to accomplish, and any additional information to be critical to understanding scope of story.

Use cases and scenarios

Scenarios, and use cases describe how actors (a person or a system) interacts with a solution to accomplish one or more of that person or systems goals.

Non-functional requirements analysis

Examines requirements for a solution that define how well functional requirements must perform. Also known as quality attributes or quality of service requirements. Expressed in textual formats as declarative statements or in matrices.

Roles and permissions matrix

Ensure coverage of activities by denoting responsibility, to identified roles, and to discover missing roles.

Acceptance and evaluation criteria

Acceptance criteria describe minimal set of requirements to be met for a solution to be worth implementing, also known as Must Have requirements. Typically used when evaluation only one possible solution and is expressed as pass or fail. Must be testable.

Metrics and key performance indicators (KPIs)

Measure performance of solutions, solution components and other matters of interest to stakeholders. A metric is a quantifiable level of an indicator to measure progress. A target metric is objective to be reached within a specified period.

Process analysis

Analyzes processes for their effectiveness, efficiency, and identifies improvement opportunities.

Root cause analysis

Identify and evaluate underlying causes of a problem, looking into causes occurring due to people, physical or organizational effects.

Vendor assessment

Assess ability of a potential vendor to meet commitments wrt delivery and consistent provision of a product or service.

Data mining

Finds useful patterns and insights from large amounts of data, usually resulting in mathematical models. Utilized in either supervised (user poses a question) or unsupervised (pure pattern discovery) investigations.

MOST

Most is a short form of Mission, Objectives, Strategies. It allows business analysts to perform thorough internal analysis of what is the aim of an organization to achieve and how to tackles such issues.

PESTLE

Pestle stands for (Political, Economic, Sociological, Technological, Legal, and Environmental). This model helps business analysts to evaluate all the external factors which can possibly impact their organization and determine how to address them.

SWOT

SWOT is a full form of Strengths, Weaknesses, Opportunities, and Threats. This technique helps we to find areas of both strength and weakness. It also allows for the proper allocation of resources.

MoSCoW

Must or Should, Could or Would process is a long-form of MosCoW. This technique allows prioritization of requirements by presenting a framework in which every individual requirement should be evaluated relative to the others.

CATWOE - Customers, Actors, Transformation Process, World View, Owner, and Environmental

 

This technique helps us to recognize processes that may be affected by any action the business undertakes.

The 5 Whys

This technique is a backbone of both Six Sigma and business analysis techniques. It consists of leading questions that allow business analysts to single out the root cause of an issue by asking why such a situation arises.

Six Thinking Hats

This process helps us to consider alternate perspectives and ideas.

Business analysis training

Business analysis learning can be expedited by undergoing a formal training.

Many colleges, universities, professional training institutes provide structured training on business analysis.

Adaptive US provides both theory training through it's Entry Certificate in Business Analysis training and skill training through it's Inner Circle program.

Business Analysis Vocabulary

A

Absolute reference

Unique identifier of a requirement to be maintained even if requirement is moved, changed or deleted.

Acceptance criteria

Minimal set of requirements to be met for a particular solution to be acceptable to stakeholders.

Active/visible observation

Observer observes the current process and takes notes, interacts with the user while work is being performed.

Activity

A unit of work performed.

Activity diagram

Diagram showing sequence of activities.

Actor(s)

Any person, system, or event that interacts with the system.

Additional potential capabilities

Capabilities offered by solution beyond those specified.

Agile

One type of software development life cycle.

Allocation

See requirements allocation.

Analyst

Stakeholder responsible for analysis.

Approach

High level plan to execute any task.

Architecture

Manner in which components of system are organized.

Association

Relationship between two elements or objects in a diagram, such as between classes and use cases.

Atomic level

At lowest level

Attribute

Defines information associated with a concept.

Auditory learners

Stakeholders who learn best through oral communication.

B

BA

Business analyst / Business analysis

Baseline

A point-in-time view of requirements which have been reviewed and agreed upon. Serves as the basis for further development.

Benchmarking

Comparing a process or application's cost, time, quality, or other metrics to those of best in class process or applications to identify opportunities for improvement.

BI

Business intelligence - Analyzing business data to draw inferences.

Black box tests

Tests conducted using expected inputs and outputs.

BPR

Business process re-engineering - To modify business processes from scratch.

Brainstorming

Process for generating creative ideas and solutions through intensive and freewheeling group discussion.

Business constraints

Business limitations placed on the solution design such as schedule, budget etc.

D

Data dictionaries or glossaries

Identify and define critical terms used by the organization or organizational unit.

Data entity

Group of related information to be stored in the system.

Data flow

Describes how data movement between a data process and an external entity, a data store or another data process.

Data flow diagram (DFD)

Diagrams data processes. See data flow.

Data model

Diagram depicting logical structure of data, independent of the data design or storage mechanisms.

Data process

A process that transforms the data in some way, either combining, reordering, converting, filtering etc.

Decision analysis

Decision-making approach modeling possible consequences of different decisions under conditions of uncertainty.

Decision tables

Tables expressing complex business rules or logic concisely in an easy-to-read tabular format, specifying all of the possible conditions and decisions.

Decision tree

A graphical representation illustrating conditions and outcomes.

Deep structure

Actual needs of the stakeholder.

Defect

Deficiency in a product or service reducing quality.

Deliverable

Any work product or service that stakeholder has agreed to deliver.

Dependencies

Activities that have to be completed before subsequent tasks can begin.

Design constraints

Constraints placed on solution design.

Detailed logical data models

Describe complete descriptions of all entities, attributes and relationships.

Developer

Stakeholders responsible for the construction of software applications.

DFD

See Data flow diagram.

Dialog hierarchy

Diagram showing user interface dialogs arranged as hierarchies.

Dialog map

Diagram showing architecture of the system’s UIs.

Discovery session

See requirements workshop.

Dispersed stakeholders

Stakeholders located in different geographic regions or countries.

Document analysis

Analysis of existing documentation and documentation of competing products.

E

Elicitation

Elicitation involves understanding underlying needs from stated requirements of stakeholders. It also involves eliciting all necessary information for successful development of a system from all identified sources.

Elicitation workshop

See requirements workshop.

End user

A person or system that interacts with the solution.

Entity-relationship diagram

Graphical representation of entities relevant to a chosen problem domain, their attributes and relationships between them.

Event

Something that occurs to which an organizational unit, system, or process must respond.

Event-based elicitation

Techniques that require in person interactions, such as brainstorming, focus group, interview, observation, prototyping, requirements workshop.

Event response table

A table defining events and their responses.

Evolutionary / functional prototype

A prototype that becomes the product.

Exploratory prototype

Prototype developed to explore requirements.

Extend use case

Extends additional behavior into a use case.

External interfaces

Interfaces with other systems (hardware, software and human) that a proposed system will interact with.

F

Facilitation

Skill of moderating discussions among a group.

Flow chart

A diagrammatic representation of activity or logic.

Focus group

Means to elicit ideas, attitudes and improvements about a specific product, service or opportunity in an interactive group environment.

Force field analysis

A diagram depicting forces supporting and opposing a change.

FP

Function point – A method to compute software size based on the functionality provided by the software.

FS

Functional specifications.

Functional requirements

Product capabilities or features.

H

Heterogeneous

A group with diverse participants.

High-level logical data models

Focusing on describing important entities, attributes and relationships.

Horizontal prototype

A prototype that shows a shallow and wide view of the system’s functionality. Does not support any actual interaction.

I

Impact analysis

Assessing effects of a proposed change on stakeholders, project, or system.

Implementation subject matter expert (SME)

Stakeholders responsible for designing, developing and implementing requirements.

Incremental delivery

Creating working software in multiple releases.

Industry

Various categories of businesses in economy, for example, retail, telecom, aviation etc.

Initiative

Effort undertaken with a defined goal or objective.

Inspection

Formal peer review utilizing a predefined and documented process, specific participant roles, captures defects and process metrics. Also see Structured walkthrough.

Interface

A shared boundary between any two entities (persons and/or systems).

Interview

Elicit information from stakeholders by asking relevant questions.

Iteration

A set period of time in which a solution is progressively built.

Iterative

One methodology for software development life cycle where working software is created in multiple releases.

JAD (Joint application design)

A session where client and solution team discuss requirements together. See requirements workshops.

J

JAD (Joint application design)

A session where client and solution team discuss requirements together. See requirements workshops.

K

 

Key Performance Indicators (KPI)

KPIs measure progress towards a strategic goal or objective.

L

Lessons learned process

Learn about and improve a process or project. Also called Sprint retrospective in agile process.

Logical order

Order of priority/significance, for example, general questions to specific questions, start to finish, summary to, etc.

M

Matrix documentation (model)

Captures a set of requirements having a complex but uniform structure in tabular form.

Metadata

Data about data.

Methodology

Proven approach.

Metric

Quantifiable level of an indicator at a specific point in time.

Milestones

Represent significant events in the progress of a project.

Mock-up

Synonym for proto-type.

Monitoring

Continuous process of collecting data to determine if the solution is performing in real world scenario. See also metric and indicator.

MoSCoW

MoSCoW categorizes requirements into, Must Have, Should Have, Could Have and Wont Have.

Multiplicity

See Cardinality.

N

Natural language

Expressed in spoken language

Nominalization

Converting a long-lasting activity or group of nouns into a single event or noun.

Non-Functional requirements (NFR) aka Quality or Supplementary requirements

Conditions under which the solution must remain effective.

O

Object oriented modeling

A software engineering approach where software is comprised of objects.

Observation

Eliciting requirements by observing stakeholder’s work environment.

On-going requirements

Requirements required to be maintained on an ongoing basis.

OO

Object oriented - An approach to design systems with real-world concepts.

OOAD

Object oriented analysis and design.

Open-ended question

Respondent is free to answer questions as he/she wishes.

Operational support

Stakeholders who provide support, such as trainers, help desk, network and other technical support personnel.

Operative rules

Rules intended to guide actions of stakeholders.

Optionality

Defines whether there is a mandatory relationship between entities in a data model.

Oral communication skills

Verbally express ideas, and information.

Organizational change management professionals

Stakeholders responsible for facilitating adoption of new solutions and overcoming resistance to change.

Organizational process assets

Methods, policies and processes and artifacts created by the organization from past experiences and best practices.

P

Passive/invisible observation

Observer observes users working but does not interact with them.

PDCA

Plan-Do-Check-Act, four phase approach to complete any activity. Also known as Deming cycle or Shewhart's cycle.

Peer review

Stakeholders evaluate a work product to discover errors in order to improve its quality.

Personal organization

Ability to quickly find information, timeliness, management of outstanding tasks and appropriate handling of priorities.

Physical data models

Description of how data is stored and managed in a system.

Plan-driven

Approaches focusing on up-front minimizing uncertainty and fully defining solution before implementation begins.

Plan-driven methodology

Methodologies emphasizing planning and formal documentation.

POC

Proof of concept - Activities carried out to check technical feasibility of an initiative.

POLDAT

Process, Organization, Location (Business architecture), Data, Applications, Technology (Systems Architecture)

Post-conditions

Aspect to be true when the use case is complete.

Preconditions

Aspect to be true before the use case begins.

Preventive and corrective action

See CAPA.

Primary actor

Actor who initiates the use case.

Primary or basic flow

Simplest way to accomplish the goal of the use case.

Prioritization

Determining relative importance among a set of items.

Process map

Model that shows a process.

Product

A solution or its component.

Product backlog

A set of user stories, features or requirements identified for potential implementation, prioritized and estimated.

Product scope

Features and functions that characterize a product.

Project

A temporary endeavor undertaken to create a unique product or service.

Project charter

A document that formally authorizes the existence of a project.

Project manager

Stakeholder to manage work required to achieve the project objectives.

Project scope

Work to be performed to deliver a project. See also scope.

Q

QA

Quality assurance – Activities carried out to ensure that the designed process will deliver quality products and services.

QC

Quality control - Activities carried out to ensure the defective products are not delivered to customers.

QMS

Quality Management System.

Quality

Degree to which a set of inherent characteristics fulfils requirements.

Quality assurance

See QA.

Quality attributes

See Non-functional requirements.

Questionnaire

See survey.

R

RACI (Responsibility-Accountability-Consulted-Informed) matrix

Describes stakeholders / roles for a given task or deliverable.

Recorder

Alias scribe

Regression testing

Checking if the existing functionalities are affected due to introduction of new functionalities.

Regulator

Stakeholder with legal or governance authority.

Release planning

Deciding requirements to be included in different releases.

Repository

A real or virtual facility where information is stored.

Request for information (RFI)

Document issued to obtain supplier input on a proposed process or product.

Request for proposal (RFP)

Requirements document issued when seeking a formal proposal from suppliers.

Request for quote (RFQ)

RFQs are used when the organization understands solution options available and is seeking suppliers to implement an option.

Requirement attributes

Metadata related to requirements used for requirements management.

Requirement defects

Errors in requirements caused by incorrect, incomplete, missing, or conflicting requirements.

Requirements allocation

Apportioning requirements to subsystems and components (i.e., stakeholders, hardware and software).

Requirements coverage

Tracing business objectives to detailed requirements such as business rules, data elements and use cases.

Requirements discovery session

See requirements workshop.

Requirements document

See requirements package.

Business Analyst, aka requirements analyst

A practitioner of IT Business Analysis.

IT Business Analysis

Systematic and disciplined approach to identify, specify and manage requirements.

Business Analysis approach

Overall process to be followed to perform IT Business Analysis work.

IT Business Analysis communication plan

Types of communication that Business Analysts perform.

IT Business Analysis performance assessment

Using prior experiences to determine effort involved in performing IT Business Analysis work.

IT Business Analysis plan

Includes information such as scope, work breakdown structure, activity list and estimates for each activity and task.

Requirements iteration

An iteration defining requirements for a subset of the solution scope.

Requirements management

Activities that control requirements development, including requirements change control, attributes definition and traceability.

Requirements management plan

Describes approach to be taken to structure traceability, definition of requirements attributes, requirements prioritization and change process.

Requirements management tool

Software tool that stores requirements information in a database, captures attributes and associations and facilitates reporting.

Requirements model

Representation of requirements using text and diagrams.

Requirements package

Requirements documents created for sharing with specific audience.

Requirements quality

See requirements verification.

Requirements repository

See repository.

Requirements risk mitigation strategy

Identify, prioritize and mitigate requirements-related risks.

Requirements signoff

Formal approval of a set of requirements.

Requirements trace matrix

A matrix tracking requirements’ relationships to other requirements and other deliverables.

Requirements traceability

Linking requirements to business objectives, other solution components and other requirements.

Requirements validation

Ensuring requirements are aligned to the goals and objectives of the business.

Requirements verification

Ensuring requirements are at an acceptable level of quality.

Requirements workshop

A structured meeting in which selected stakeholders define requirements.

Retrospective

See lessons learned process.

Return on investment

A measure of the profitability of a project or investment.

S

Scenario

Series of actions to achieve a goal.

Scope

Area covered by a particular activity or topic of interest. See also project scope and solution scope.

Scope model

A model that defines scope boundaries.

SDLC

Software Development Life Cycle.

Secondary actor

An actor who participates in a use case but does not initiate the same.

Service

Work carried out or on behalf of others.

Signoff

See requirements signoff.

Software engineers

Stakeholders responsible for construction of software applications.

Software/systems requirements specification

Requirements document describing detailed functional and non-functional requirements.

Solution requirement

Requirements described to develop a solution that meets the business and stakeholder requirements.

Solution scope

Set of capabilities a solution must deliver to meet business need.

Span of control

Number of employees a manger is responsible for.

Sponsor

Stakeholder who pays for the project.

Stability

Indicates how mature the requirement is.

Stakeholder

A group or person who may be affected by an initiative or has influence over it.

Stakeholder analysis

To identify, prioritize, assess interests and likely participation of stakeholders for an initiative.

Stakeholder list, roles and responsibilities

List of stakeholders affected by a business need or proposed solution and their participation.

Stakeholder maps

Visual diagrams that depict relationship of stakeholders to the solution, their authorities and interests.

Stakeholder requirements

Statements of needs of a particular stakeholder or class of stakeholders.

State machine diagram, State transition diagram

See state diagram.

Stated requirements

Requirement described by stakeholders.

Status attribute

Indicates requirement status.

Structured walkthrough

A session where invited participants review a set of requirements/deliverables.

Subject matter expert (SME)

Stakeholder with specific expertise in any aspect of problem domain or potential solutions.

Surface structure

Requirement stated by the stakeholder

Survey

Administering a set of written questions to stakeholders to collect responses.

Swim lane

Horizontal or vertical section of a process model showing activities are performed by a particular role.

T

Technical constraint

Limitations on design of a solution based on technology used.

Throw-away prototype

A prototype used to quickly uncover and clarify interface requirements using simple tools and which is not used in final product.

Time box

A fixed period of time assigned for a purpose.

Tracing

Act of linking requirements among them and also to other deliverables.

U

UCP

Use case point – A method to compute software size using use cases.

Unified modeling language (UML)

A non-proprietary modeling language used to specify, visualize and document requirements and designs for object-oriented software systems.

Universal quantifiers

Universal quantifiers group set of objects and generalize behavior or property for the group such as All, None etc..

Urgency

Indicates how soon the requirement is needed necessary.

Use case diagram

A diagram showing actors and use cases for a system.

Use case (UC) specifications

Describes the tasks that the actors and system will perform for achieving a goal.

User

See end user.

User acceptance test

Testing carried out users to judge whether the delivered system is acceptable.

User requirement

See stakeholder requirements.

User requirements document

A requirements document prepared for a user audience.

User story

A short description of a solution capability described from a stakeholder perspective.

V

Validated requirements

Requirements that demonstrate delivery of business value.

Validation

Ensuring product or service satisfies its intended use.

Variance analysis

Analysis of differences between planned and actual performance parameters.

Verification

Ensuring deliverables produced at a given stage of development satisfies the conditions or specifications of the previous stage.

Verified requirements

Requirements that demonstrate characteristics of requirements quality.

Vertical prototype

A prototype that dives into the details of the interface, functionality, or both.

W

Walkthrough

A review where participants present, discuss and go through a work product to find errors and verify correctness of requirements

Waterfall

Software development methodology where activities move from one phase to another.

Wire-frame

Synonym for proto-type.

Work breakdown structure (WBS) A deliverable-oriented hierarchical decomposition of the work to be executed to accomplish the project objectives.

Work packages

Include at least one and usually many activities, which can be further broken into smaller tasks.

Work product

Document or collection of notes or diagrams created during the IT Business Analysis process.

Detailed Description of BA Processes

Plan IT Business Analysis

4.1 Key Concepts

Plan IT Business Analysis knowledge area focuses on having right planning for IT Business Analysis. It describes following tasks:

  • Plan for understanding requirements context

  • Understand and document requirements context

  • Define system boundary and solution scope

  • Identify requirement sources

  • Identify and prioritize stakeholders

  • Determine Business Analysis approach

  • Plan for requirements communication

  • Identify IT Business Analysis risks and assumptions

  • Estimate schedule, effort and cost

  • Develop IT BA plan

A good planning ensures that Business Analyst has identified all requirements sources and resources needed for IT Business Analysis. This goes a long way in ensuring quality of requirements gathered.

4.1.1 Understanding context

Dictionary definitions of word “Context”.

Webster-Mariam dictionary

  • The words that are used with a certain word or phrase and that help to explain its meaning.

  • The situation in which something happens: the group of conditions that exist where and when something happens.

Cambridge dictionary

  • The influences and events related to a particular event or situation.

Oxford dictionary

  • The circumstances that form the setting for an event, statement, or idea, and in terms of which it can be fully understood.

So, we can conclude context is the prevailing situation that affects or helps to understand requirements.

Typical elements of the context are:

  • People (stakeholders),

  • Systems in operation (interfacing systems),

  • Processes,

  • Events,

  • Documents (e.g., laws, standards, system documentation).

Requirements originate within a certain context. Stakeholders, relevant standards, and legal authorities demand specific functionalities from the system to be developed. Requirements can ONLY be interpreted correctly in regard to the specific context. Better understanding of the context lowers the likelihood of incorrect interpretations. Business Analysts MUST document the context correctly and completely.

Very first thing Business Analysts should do is to plan for understanding the context. As part of the plan, plan for studying existing documentation and meet key stakeholders. Use case diagrams and data flow diagrams are often used to document system context.

System boundary

System boundary demarcates aspects to be developed from its environment. It separates the aspects of the environment that can be modified from aspects of the environment that cannot be modified by the development process. Aspects within the system boundary can be business processes, technical processes, people and roles, organizational structures and components of the IT infrastructure.

Sources and sinks

Sources and sinks can be used to identify system’s interfaces with its environment. Sources provide inputs for the system. Sinks receive outputs from the system. Possible sources and sinks of a system are:

  • Stakeholders of existing systems,

  • Other systems (applications and hardware).

Sources and sinks interact with the system via system interfaces. Using system interfaces, the system provides functionalities to the environment, monitors the environment, and influences parameters of the environment. Depending on the type of source or sink, system needs different interface types:

  1. Human-machine interface, also known as user interface,

  2. Hardware interface,

  3. Software or application interface.

[Rupp, Klaus Pohl and Chris 2015]

4.1.2 Requirements sources

Significance of requirements sources

Requirements are the foundation of solution development, hence it is essential to identify all requirements sources.

Identifying relevant stakeholders, interfacing systems and relevant documents is a key task for Business Analysts. Gather, document and consolidate goals and requirements from different sources.

Consequences of unconsidered sources

Not identifying or not considering stakeholders, documents and interfacing results in significant re-work, possibly leading to failure of the project. Unconsidered sources will create large number of change requests during system acceptance and operation. As we learnt earlier, not implementing requirements at appropriate time leads to significant re-work and hence high additional costs.

Types of requirements sources

Key requirements sources are:

Stakeholders

Stakeholders are those people or organizations who affect requirements. They may provide or implement requirements. Stakeholders are the most important sources of requirements, hence not considering is bound to result in incomplete requirements.

Typical IT Business Analysis stakeholders are: Sponsor, Project managers, Domain SMEs, Implementation SMEs, Testers, End users, Administrators, Management, Application owners, and Legal entities, and institutions etc. There could be undesired stakeholders as well, such as hackers and users with fraudulent intents.

Documents

Documents are also another significant source for requirements. Documents may be:

  • Provided by statutory and regulatory bodies.

  • Standards prescribed by industry bodies and standard setting organizations such as ISO.

  • Requirements documents of existing systems.

  • Feature documents of competing systems.

  • Error reports of existing systems.

  • Complaints and feedbacks on existing systems.

Systems

Since most applications need to interact with other applications, interface requirements are needed for most applications. Similarly, Business Analysts can get insights into requirements from competing systems available in the market.

  • Existing or predecessor systems

  • Other interfacing systems.

  • Competing solutions.

Important information of the stakeholder documentation
Stakeholders can be classified as internal or external.

Internal stakeholders are within the organization: e.g. employees and management. External stakeholders are outside the organization: e.g. government and trade associations etc.

Stakeholders can also be classified as Primary, Secondary and key stakeholders

Primary stakeholders are directly affected by the system such as end-users, management etc. Secondary stakeholders are indirectly affected, e.g. government and media. Key stakeholders are the ones who are most significantly affected or those with maximum influence.

4.1.3 Stakeholder management

Identifying relevant stakeholders is a key task of Business Analysts. Identify stakeholders and determine the impact of proposed changes on them to determine the needs, wants, and expectations to be satisfied by a solution. Some individuals may play a variety of roles in the same project, and different roles in different projects. Early identification of stakeholders helps in timely delivery of requirements deliverables. Stakeholders are the MOST important source of requirements. Business Analysts gather, document, and consolidate conflicting goals and requirements of different stakeholders.

Not considering stakeholders (could be due to non-identification) will result in significant negative impact for the project progress. Significant change requests can result during system operation as critical requirements may remain undetected. Modifying the system late causes high additional costs. Hence it is critical to identify all stakeholders in the beginning itself. Change-driven approaches better accommodate this risk, but cannot eliminate it.

Another technique for stakeholder identification is maintaining stakeholders’ checklist. This allows planned elicitation from relevant stakeholders. If the stakeholder list is not updated at right time or incomplete, the result may be that some stakeholders are missed from elicitation.

Stakeholder elicitation often begins with suggestions of relevant stakeholders made by management or by domain experts.

Enterprise architecture describes organizational units in the enterprise, their interactions with each other, customers, and suppliers, responsibilities within the organization, and roles, and relationships within each organizational unit.

Project manager, and Business Analyst share the responsibilities of stakeholder identification and management. Project manager is accountable for project team meeting commitments made to stakeholders, assignment of stakeholders to project tasks, their involvement in project execution, ensuring project scope is managed.

Business Analysts assist Project managers in defining which project team members and stakeholders should be involved in developing, reviewing or approving IT Business Analysis deliverables.

Stakeholder management process

Advantages
  • Ensures no stakeholders have been left out.

  • Involving stakeholders can build trust.

Disadvantages
  • May add non-critical stakeholders to the project leading to additional requirements, cost and schedule.

Ensuring agreement with stakeholders

It is essential that all stakeholders agree to a common requirement for the system to be developed. Hence Business Analysts along with stakeholders should define a protocol to work. A stakeholder charter is a great tool to do so. The agreement process can be verbal or written. A sample stakeholder charter can be:

  • All stakeholders will deal with all stakeholders in a dignified professional manner, treat each other with civility and respect

  • To carry out activities as per project scope

  • All stakeholders agree to listen and be open to the diverse points of view expressed by other participants

  • Needs beyond project scope can be discussed and agreed by Steering committee

  • Respect time of each stakeholder

  • All stakeholders agree to provide other stakeholders the level of commitment and support expected in terms of time and effort minimum 2 weeks in advance

  • As an effective team, all stakeholders agree that the issues will be judged on the merit of the issues only

  • All stakeholders will co-operate and support each other to make the project a success

  • All stakeholders shall raise any concerns about the project or the process with an open and timely manner

  • All stakeholders agree to attend all review meetings,

  • In case they are unable to attend, nominate a representative

  • All stakeholders agree to provide approval / objection to the requests within 1 week

  • Meeting if need to be re-scheduled, should be done at least 3 days in advance

  • To save time on travel, stakeholders can participate calls through tele-conferencing means

Usually many stakeholders are involved in large projects. Due to limited resources, Business Analysts MUST carefully select stakeholders MOST suitable for IT Business Analysis. Principles in dealing with stakeholders are:

Comprehensive identification

Comprehensive identification ensures no stakeholders are left out from the IT Business Analysis process.

Constant prioritization

Since stakeholders are not static, it is essential for Business Analysts to keep the stakeholder register updated and prioritized.

Continuous involvement and constant communication

Continuous involvement and periodic communication with stakeholders help in better collaboration. Address stakeholder grievances.

Collaborative (Win-win) mindset

Business Analysts and project managers need to convince stakeholders regarding project benefits.

Defined protocol for engagement

To avoid misunderstandings and disputes, Business Analysts should develop formal communication and approval mechanism. This should include deliverables, tasks, roles, responsibilities and approval authorities. Also determine communication paths and feedback loops for stakeholders. Organizations differ greatly on formality on approvals, which could be ranging from being verbal to ink signature sign-off.

[Rupp, Klaus Pohl and Chris 2015]

 

4.1.4 Principles in dealing with stakeholders Stakeholder’s rights & duties

Stakeholders play vital role in IT Business Analysis process. They have deep understanding of the domain and its processes. Stakeholders’ responsibilities include:

  • Provide requirements,

  • Prioritize and rank requirements,

  • Review documented requirements,

  • Accept requirements trade-offs,

  • Approve requirements,

  • Assist Business Analysts in understanding domains and application,

  • Communicate requirements promptly,

  • Adhere to defined requirements development and change processes.

4.1.5 Business Analysis approaches

In software development, Business Analysis approaches range from Waterfall (plan-driven) to Agile (change-driven) approach, proprietary in- house methodologies, customs, and practices.

 

Attribute

Plan driven

Change driven

Focus

To detail as much as possible in the beginning to maximize control, and reduce risk.

To discover on the go.

Authority to approve

Sponsor.

Designated person.

Applicable situation

Complex, high cost of failure, well drafted requirements possible, challenging stakeholder interactions.

Low cost of failure, requirements amorphous.

Model

Water-fall.

Agile / Iterative.

Level of detail

High.

Low.

Change management

Formal process through standardized template. Accept change only when justified.

Through prioritized product backlog, time box driven.

Communication

Formal. Documented. Periodic.

Informal. Verbal. Frequent.

Documentation

Prior to implementation.

Post implementation.

Emphasis on requirements priotization

Low

High

Source: BABoK

Business Analysts can combine elements from different approaches. Organizational process assets are typically known as Quality Management System in many organizations. Organizational process needs, and objectives include:

  • Compatibility with other organizational processes.

  • Constraints on time-to-market.

  • Compliance with regulatory, and governance frameworks.

  • Desire to evaluate new approaches to solution development.

  • Other business objectives.

Organizations usually have formal or informal standards regarding how to conduct IT Business Analysis, and how it fits into project, and other activities. Review existing organizational standards, guidelines, and processes relating to the initiative. These may suggest or mandate Business Analysis approach. Even if a standard approach exists, tailor it to the needs of a specific initiative. Organizational standards govern tailoring of IT Business Analysis processes, specifying permitted approaches, elements that can be tailored, and guidelines for selecting an approach.

If no standards exist, work with appropriate stakeholders to determine the Business Analysis approach. Business Analysis approach often follows project approach but can also be independent. For example, project may follow an iterative approach but Business Analysis approach can be waterfall.

Especially, collect non-functional requirements in water-fall approach as changing non-functional requirements will be very difficult once the product is designed and built.

4.1.6 Plan for requirements communication

Determine how best to receive, distribute, access, update and escalate information from project stakeholders and how best to communicate with them. Requirements can be presented in any format, as long they as are understandable for the reviewer. This task decides formats appropriate for a particular initiative, and its stakeholders. Requirements must be clear, concise, accurate, and at appropriate level of detail.

Typically, IT Business Analysis communication plan is integrated into overall project communications plan. On small projects, it may be very brief, and may not be formally documented. On projects with many stakeholders, it may be a separate document or at least an essential part of the overall project communications plan.

4.2 Activities

4.2.1 Plan for understanding requirements context

Purpose: To plan for understanding requirements context from the sponsor and key stakeholders.

Stakeholders: Sponsor*, Domain SME*, Project Manager*.

Inputs

Elements

Outputs

1.Enterprise architecture

2.Business needs

1.Plan for understanding requirements context.

2.Get system and application landscape.

3.Estimate effort needed for understanding requirements context.

1.Plan to understand requirements context

2.System and application landscape

Tools and Techniques: IT Business Analysis plan.

 

Example:

Stakeholder Name

Desig.

Key Topics for Discussion

Target Date

Est. effort

Technique

Status

Dave Richards

CEO

KPIs and Dashboards.

10-Feb

8

Interview

Completed

Mike Dent

CDO

Non-functional business requirements

10-Feb

8

Interview

Completed

 

 

Project monitoring business requirements

10-Feb

 

Interview

Completed

 

 

Operational Dashboards.

10-Feb

 

Interview

Completed

Dinesh Pandey

Head-PMO

Process compliance business requirements.

12-Feb

4

Interview

Completed

Lee Fung

Head-IT

IT standards

12-Feb

4

Interview

Completed

 

 

Expectations from GRC system

12-Feb

 

Interview

Completed

Adi Gururaj

Head-HR

Expectations from GRC system

14-Feb

4

Interview

Completed

Iqbal Mohammed

Head-Administration

Expectations from GRC system

14-Feb

4

Interview

Completed

 

4.2.2  Understand and document requirements context

Purpose: To understand and document requirements context for guiding the IT Business Analysis activities.

Stakeholders: Sponsor*, Domain SME*, End users*, Customers*.

Inputs

Elements

Outputs

1.Plan to understand requirements context

2.System and application landscape

1.Discuss project vision with sponsor, domain SME and Project manager.

2.  Understand the rationale behind the new / improved system.

3. Understand current and likely future needs of the organization.

4. Define requirements context.

1.Business objectives / opportunities

2.Current system challenges

3.Requirements context

4. Objectives of new / improved system

5.Interfacing requirements

Tools and Techniques: Interviews, Document analysis, Context diagram

 

Example:

 

4.2.3 Define system boundary and solution scope

Purpose: To define system boundary and solution scope.

Stakeholders: Sponsor*, Domain SME*, End users*, Customers*.

Inputs

Elements

Outputs

1. Plan to understand requirements context

2. System and application landscape

3. Requirements context

4. Objectives of new / improved system

1. Define requirements context

2. Define system boundary

3. Define solution scope

 

1. System boundary

2. Solution scope

Tools and Techniques: Interviews, Document analysis, Context diagram, Requirements management plan.

 

Example

In Scope

Req ID

Requirement

Req Type

Criticality

User Contact

10000

Project and program dashboard

Functional

Must Have

Dinesh Pandey

20000

Manage schedule

Functional

Must Have

Lily Vasantini

30000

Manage defect

Functional

Must Have

Shalini Paul

40000

Manage risk

Functional

Must Have

Sara Lee

50000

Manage requirements

Functional

Must Have

Nori Masa

60000

Track effort

Functional

Must Have

Gajendra Battalla

70000

Manage audit and compliance

Functional

Must Have

Rebecca Randad

 

 

Out of Scope

Req ID

Requirement

Short Description

Reason for exclusion

Req Type

90001

Financial accounting

Invoicing, collection

Not aligned to product vision

Functional

90002

Recruitment management

Plan and track recruitment activities

Not aligned to product vision

Functional

90003

Task dependency management

Similar to MS Project features

Extremely complex feature

Functional

90004

Critical path

Similar to MS Project features

Extremely complex feature

Functional

 

 

Purpose: Identify requirements sources and suitable elicitation techniques for the initiative which may be regulatory, contractual and implicit requirements.

Stakeholders: Sponsor, Domain SMEs, Project manager, Regulator.

Inputs

Elements

Outputs

1. Business and system context

2. Objectives of new / improved system.

1. Identify sources of government regulations.

2. Identify pertinent standards published by industry associations.

3. Identify requirements fulfilled by current systems.

4. Identify requirements fulfilled by competitors’ products.

1. Identified requirements sources

Tools and Techniques: Interviews, System context diagram, Organization chart, Process models, Brainstorming.

 

4.2.4 Identify requirements sources & suitable elicitation techniques

Purpose: Identify requirements sources and suitable elicitation techniques for the initiative which may be regulatory, contractual and implicit requirements.

Stakeholders: Sponsor, Domain SMEs, Project manager, Regulator.

Inputs

Elements

Outputs

3. Business and system context

4. Objectives of new / improved system.

5. Identify sources of government regulations.

6. Identify pertinent standards published by industry associations.

7. Identify requirements fulfilled by current systems.

8. Identify requirements fulfilled by competitors’ products.

2. Identified requirements sources

Tools and Techniques: Interviews, System context diagram, Organization chart, Process models, Brainstorming.

 

Example:

Type of requirements

Sources

Elicitation techniques

Modeling techniques

Non-functional requirements

Sponsor, Delivery managers

Interview

Non-functional requirements

Process, data and UI requirements

Delivery managers
Project managers
PMO Office

Workshops

Prototype, Activity diagram, State chart diagram

Interfacing requirements

System owners for Oracle Apps and Attendance System

Interview

Interface mapping template

Legal requirements

Finance

Interview

Business rules template

Business rules

Delivery managers
Project managers
PMO Office

Document analysis, Interview and Workshop

Business rules template

Reporting requirements

Delivery managers
Project managers
PMO Office

Interview

Reporting requirements template

Implicit requirements

Competitor systems

Benchmarking

Benchmarking template

 

4.2.5 Identify and prioritize stakeholders

Purpose: Identify stakeholders affected by a proposed initiative, determine their influences, and approval authority for project deliverables.

Stakeholders: Sponsor*, Regulator*, Domain SME*, Project Manager*, and End Users*.

Inputs

Elements

Outputs

1. Business need

2. Enterprise architecture

3. Requirements context

4. Stakeholder checklist

1. Identify stakeholders.

2. Determine their influences and interests.

3. Prioritize stakeholders.

1. Stakeholder list, roles, and responsibilities

[Note: Describes which stakeholder is responsible, accountable, consulted, and informed for IT Business Analysis deliverables ]

Tools and Techniques: BrainstormingInterviews, Organization model, Process model, Scope models.

 

Example:

Name of Stakeholder or Group

Desig.

Authority Level

Inf.

Int.

Cri.

Key Expectations / Special Needs

Dave Richards

CEO

High

5

4

High

Project to be delivered within accepted budget and time.

Mike Dent

CDO

High

5

5

High

Have a unified view/process implemented across the business divisions of ABCT.

Dinesh Pandey

Head-Quality and PMO

High

2

5

Medium

Carefully gather business requirements and evaluate work pending vs. work done.

Jan Lesher

Project Manager

High

3

5

Medium

Plan and track GRC project working closely with key stakeholders.

Lee Fung

Head-IT

High

4

4

High

New project must fit into organizational IT policies and strategies.

 

4.2.6 Determine Business Analysis approach

Purpose: To select correct Business Analysis approach based on project context and stakeholder needs.

Stakeholders: Sponsor*, Customer*, Domain SME*, Project manager*, End user, Supplier, Implementation SME, Tester, and Regulator.

Inputs

Elements

Outputs

1. Business need

2. Requirements context

3. Organizational process needs, and objectives

4. Organizational process assets.

1. Consult key stakeholders on selecting the Business Analysis approach.

2. Decide Business Analysis approach based on timing of IT Business Analysis work, formality, and level of detail required for IT Business Analysis deliverables.

 

1. Business Analysis approach

Tools and Techniques: Brainstorming, Expert judgment.

 

 

 

Example:

Since the project approach is agile, Business Analysis approach will also be agile. This will allow the project team to deliver maximum possible value to stakeholders in shortest possible time.

 

4.2.7 Plan for requirements communication

Purpose: To plan for requirements communication based on stakeholder needs

Stakeholders: Sponsor*, Domain SME*, Project Manager*, Customer*, Supplier, End user, Implementation SME, Operational support, Tester, Regulator.

Inputs

Elements

Outputs

1. Stakeholder list and expectations

2. Organizational policies and processes

3. Business Analysis approach

1. Understand stakeholder needs.

2. Consider geographic locations.

3. Consider cultural diversity.

4. Consider type of project.

5. Determine communication frequency.

6. Consider communication formality.

7. Plan for requirements communication.

1. Requirements communication plan

Tools and Techniques: Brainstorming, Requirements management plan, Guidelines for requirements communications.

 

Example:

Frequency / Event

Aspects to be reported

Stakeholders to be communicated

Template to be used

Weekly

RE progress

Entire team

WSR

Monthly

RE progress, Issues, Risks

Steering committee

MSR

 

 

4.2.8 Identify IT Business Analysis risks, assumptions & mitigation actions

Purpose: Ensure IT Business Analysis risks and assumptions are identified and suitable mitigation actions are designed.

Stakeholders: Sponsor, Customer, Domain SME*, Project manager*.

Inputs

Elements

Outputs

1. Business Analysis approach

2. RE activity plan

3. Organizational risk database

4. Past project experiences

1. Identify sources of business IT Business Analysis risks.

2. Identify business IT Business Analysis risks.

3. Prioritize risks.

4. Identify mitigation measures for critical risks.

1. IT Business Analysis risks and mitigation plans

Tools and Techniques: Risk management, Requirements management plan.

 

Example:

Risk description

Probability

Severity

RPN

Impact

Mitigation Plan

Domain SME availability

Medium

Critical

9.00

High

Identify back-ups for all critical Domain SMEs.

Increase in scope

High

Critical

12.00

High

Discuss during steering committee meetings

Stakeholders agreement on scope

Very High

Critical

15.00

High

Sponsor to review efforts needed beyond 0.5 person-month to implement

Completeness of requirements

Medium

Critical

9.00

High

Prototypes to be approved by Domain SMEs

 

4.2.9 Define constraints

Purpose: To identify factors other than requirements affecting the viability of solutions.

Stakeholders: All stakeholders, Implementation SME, and Project manager.

Inputs

Elements

Outputs

1. Business constraints

2. Technical constraints

1. Document business constraints.

2. Document technical constraints.

1. Constraints

Tools and Techniques: Requirements templates.

 

Example:

No

Category

Constraint

Remarks

1

Business

Follow agile approach to development.

 

2

Business

Budget limited to 2000K USD.

 

3

Business

First go live within 6 months and subsequently every quarter.

 

4

Business

Must adhere to ISMS policies.

 

5

Technical

Must adhere to approved IT architecture.

Documenting Requirements

1.3 Requirements documentation

Good requirements are foundations for successful projects. A good document design improves communication between stakeholders and increases quality of requirements. Requirement engineers MUST design appropriate documentation standard and adhere to the same. A requirements specification are collection of requirements, typically for a system or component.

Reasons for documentation

Requirements are basis of system development. Requirements influence all succeeding phases of project: analysis, design, implementation, test, acceptance and maintenance. Quality of requirements documentation has a strong impact on progress of the project and on its success.

Key reasons for requirements documentation are:

Communication vehicle among all stakeholders

Requirements documents serve as the primary communication medium among stakeholders.

Legal relevance

Non-fulfilment of requirements can become a legal issue for the organization. Documenting requirements helps the organization during legal conflicts.

Complexity

Large systems have large number of requirements with complex interdependencies. Without proper requirements documentation, managing requirements will be near impossible task.

Accessibility

In a large and complex project, many stakeholders participate at different points in project life cycle.

Requirements MUST be accessible to all stakeholders for the project and even after completion of the project.

Sharing of knowledge

Requirements documentation helps in sharing and maintaining organizational knowledge about processes and business rules.

For future re-use

Requirements documentation helps in requirements reuse. Requirements reuse saves significant effort and time for the organization. Requirements documents may also contain relevant information which are helpful for current and future projects.

Use of requirements documents

Over course of the project, requirements documents serve as basis for different tasks:

Planning

Requirements documents are used to develop concrete work packages and milestones for implementation of system requirements.

Architectural design

Requirements documents are used to develop detailed requirements (along with constraints) which serve as basis for design of system architecture.

Implementation

System is implemented by making use of architectural design and detailed requirements.

Test

Test cases can be developed from requirements to be used for system validation.

Traceability management

Requirements documents are also used for managing traceability between requirements and other associated documents.

Change management

When requirements change, requirements document can serve as basis to analyze extent to which other parts of system are impacted, thus helping in estimation of change effort.

System usage and system maintenance

Requirements document can be used to analyze defects and shortcomings those are discovered during system use. For example, one can decide if a defect is a result of incorrect usage, a defective requirement, or an implementation error.

Contract management

Requirements document is prime aspect of a contract between a client and a supplier in most cases. During any dispute, requirements documents serve as the basis for dispute resolution.

1.4 Documentation types

Requirements can be documented in 3 different ways: natural languages, conceptual models and hybrid approach.

       Requirements documentation using natural language

Advantages of using natural language

Most requirements originate as natural language text when stakeholders describe their needs. Text is natural to all stakeholders and no one needs to learn a new notation. Text can be used to express any kind of requirement and all 3 perspectives (Data – Logic – Behavior).

Disadvantages of using natural language

Natural language texts are prone to be ambiguous, leading to multiple interpretations. Requirements understandings can vary greatly depending on the stakeholder’s knowledge on the subject, their ability to express and understand. In natural language, it is also difficult to isolate information pertaining to a particular perspective, say data or behavior.

Requirements documentation using conceptual models

Advantages of conceptual models

Conceptual models decrease ambiguity (i.e., fewer ways to interpret requirements) than natural language due to their notation formalities. They depict requirements in a concise manner. It is easier for a trained reader to understand conceptual model than natural language.

Disadvantages of conceptual models

Conceptual models require specific knowledge of modeling symbols and texts appropriate to the perspective (Data – Logic – Behavior).

Hybrid requirements documents

Hybrid requirements documents use both natural language and conceptual models, hence overcome dis-advantages of both text and conceptual models.

Example of requirements structure:

Requirement Type

Description

Attributes

Stakeholder Request (STRQ)

A request of any type—for example, Change Request, enhancement request, request for a requirement change, defect—from a stakeholder.

Priority, Status, Cost, Difficulty, Stability, Assigned to

Feature (FEAT)

An externally observable service provided by the system which directly fulfills a stakeholder need.

Priority, Status, Planned Iteration, Actual Iteration, Difficulty, Stability, Assigned to, Origin, Rationale, Cost, Enhancement Request, Defect

Use Case (UC)

A description of system behavior, in terms of sequences of actions. A use case should yield an observable result of value to an actor.

Property, Affects Architecture, Planned Iteration, Actual Iteration, Assigned to, Rank, Test, Priority, Status, Difficulty, Stability, Cost, Enhancement Request, Defect

Glossary Item (TERM)

A term used in the project’s common vocabulary.

 

Supplementary Requirement (SUPL)

A description of a requirement not readily described by a Use Case.

Priority, Status, Difficulty, Stability, assigned to, Cost, Enhancement Request, Defect, Test

Basic rules to enhance readability of requirements

1. Short sentences: Limiting requirements to 10 words per sentence is a good practice to follow.

2. Short paragraphs: As human memory is limited, use 7 or less sentences in a paragraph.

3. Formulate only one requirement per sentence: Avoid long, complicated interlaced sentences.

4. Use business terminology: Use terminology used in business than using technical terms.

5. Define and mandate glossary: Stakeholders interpret same terms differently which is a frequent cause for conflicts in IT Business Analysis. To avoid these conflicts, everyone involved in development process MUST share same understanding of terminologies used. Glossary MUST contain all relevant terms.

6. Use active voice: Active voice is always better than passive voice.

7. Use models and matrices where ever possible: Using models and matrices improves requirements clarity.

  • Quality criteria for requirements

Quality criteria defined in IEEE standard can be used for individual requirements and requirements documents. In addition, few more quality criteria for individual requirements can be:

Necessary

Must be needed by stakeholders and MUST fulfill their needs.

Feasible

Requirements MUST be feasible given organizational, legal, technical, or financial constraints.

Agreed

All stakeholders agree to the requirement.

Unambiguous (IEEE Std. 830)

It MUST not be possible to interpret a requirement in different ways. All readers of requirement MUST arrive at same understanding of requirement. One example of ambiguous requirement:

1. System shall calculate time taken to complete a service request as Date of completion of service request minus Date of arrival of service request. One stakeholder may interpret this as Calendar days (Elapsed days) where as another stakeholder may interpret as Number of working days elapsed between arrival and departure.

2. The system shall have ability to support multiple browsers. Which all browsers?

Consistent (IEEE Std. 830)

Requirements MUST be consistent with other requirements, i.e., requirements MUST not contradict one another, irrespective of their level of detail or documentation type. Requirements should not contradict themselves.

Verifiable (IEEE Std. 830)

Requirements MUST be testable. Example: System should be extremely user friendly. This cannot be tested as “User-friendliness” is undefined quantitatively.

Traceable (IEEE Std. 830)

Requirements must be traceable to their origin.

Complete (IEEE Std. 830)

Each individual requirement MUST completely describe functionality it specifies. Incomplete requirements MUST be marked, for example by adding "TBD” (“to be determined”) into description or using a corresponding status.

Each requirement MUST be documented completely. Describe all possible inputs, required responses, errors and exception cases and quality requirements for each desired system function.

Understandable

Requirements MUST be understandable to stakeholders. Type of requirements documentation can vary significantly, depending on development phase (and therefore, depending on involved staff). It is important to strictly define terms and use them.

Correct (IEEE Std. 830)

A requirement is correct if it adequately represents idea of stakeholder. This also means that requirement should not express more than what stakeholder communicates.

Example: For any service request, actual end date of is always greater than actual start date. It may seem to be a correct requirement, but it is not. Correct requirement is, actual end date of a service request is always equal to or greater than actual start date of service request.

Ranked (IEEE Std. 830)

It is important to rank requirements, according to their importance, legal obligation, or priority.

Valid and up-to-date

Documented requirements MUST represent facts and conditions valid for current actualities.

1.5 Assigning attributes to requirements

Important attribute types for requirements

Attribute Type

Meaning

Identifier

Unique identifier of a requirement / artefact.

Name

A short description.

Description

Long description of the requirement.

Rank

Order of the requirement in a set of requirements. Rank should be unique in a chosen set of requirements for implementation.

Version

Current version of requirement.

Author

Specifies author of requirement.

Source

Specifies source of requirement

Stability

Specifies approximate stability of requirement. Possible values can be “Fixed”, “Established” and “Volatile”.

Criticality

Specifies impact of requirement on business. Possible values can be “High”, “Medium” and “Low”.

Priority

Specifies priority of requirement. Priority determines order implementation.

Assigned to

Specifies person, group of stakeholders, organization, or organizational unit that is responsible for the requirement.

Requirement type

Specifies type requirement (e.g., “Functional requirement”, “Quality requirement”, or “Constraint”).

Status regarding content

Specifies current status of requirement content, e.g., “Idea”, “Concept”, “Detailed content”.

Status regarding validation

Specifies current status of validation, e.g., “Un-validated”, “Erroneous”, “In correction”.

Status regarding agreement

Specifies current status of negotiation, e.g., “Not negotiated”, “Negotiated”, “Conflicting”.

Estimated Effort

Estimated effort to implement requirement.

Release

Release in which requirement shall be implemented.

Legal obligation

Specifies degree of legal obligation of requirement.

Cross references

Specifies relations to other requirements, for example, if it is known that implementation of requirement requires prior implementation of another requirement.

Remarks

Any information which is of stakeholders’ interest.

 

1.6 Prioritizing requirements

To prioritize requirements, follow these steps:

1. Define goal (i.e., purpose) of prioritization.

2. Document constraints of prioritization, such as availability of different stakeholders or resources available.

3. Ensure requirements are at similar level of abstraction.

4. Choose requirements prioritization criteria. Typical examples of requirements prioritization criteria:

5. Choosing appropriate stakeholders to ensure required expert knowledge is available during prioritization.

6. Select of the artifacts to be prioritized.

1.7 Requirements traceability

Requirements traceability is ability to trace requirements to business needs, work products based on requirements and relationships among requirements.

Benefits of requirements traceability

Aid in verification: Allows verifying whether a requirement has been implemented in the system.

Identification of unneeded properties / requirements in solutions: Traceability allows identification of unneeded properties / requirements solutions of developed systems. Tracing properties / requirements back to their origin allows identifying requirements that do not contribute to business need and system goal. Unneeded requirements should not be implemented.

Impact analysis: Allows for analysis of effects during change management. Allows identifying requirements and artefacts that MUST be changed when their underlying requirements change.

Reuse: Allows for reuse of requirements artefacts in other the projects.

Accountability: Traceability assists in determining accountability.

Maintenance: Traceability of requirements allows for simplified system maintenance.

Caution:

It takes significant effort to establish and maintain traceabilities. Record information with clear purpose that it will serve.

Three types of traceability relationships

1. Pre-requirements traceability are traceability links between requirements and those artefacts that are basis for requirements (Prior artefacts).

2. Post-requirements traceability are traceability links between requirements and artefacts of subsequent development activities, such as components, implementation, or test cases (Posterior artefacts).

3. Traceability between requirements is about mapping dependencies between requirements. For example, a requirement refines another requirement, generalizes it, or replaces it.

Representing requirements traceability

Traceability can be represented using textual references, hyperlinks, trace matrices and trace graphs.

Text-based references

Mentioning source artefact name / description in the target document.

Hyperlinks

Establish a hyperlink between initial artefact and target artefact.

Trace matrices, aka Traceability matrix, Coverage matrix

Trace matrices are tables where rows contain source (initial artefacts, requirements) and columns contain target artefacts (development artefacts). If a relationship exists between artefact in row “p” and a artefact in column “f”, cell (p, f) is marked.

Trace matrices are difficult to maintain as number of requirements increases. For example, a trace matrix documenting relation between merely 100 requirements contains over 10000 cells.

1.8 Versioning of requirements

Versioning of requirements aims at providing access to specific contents of requirements over time. Versions are marked by unique version numbers. Versioning can be applied to single text-based requirements, to entire requirements documents, and to models.

Requirements versions

When versioning requirements, one should distinguish between version number and increment number. For example, version number 4.2 references a requirement with version 4 and increment 2. As shown in figure, with smaller changes regarding content, increment is increased by one. If large changes are performed, version number is incremented. “V” is added in front of version number to make it easier to identify. 

 1.9 Requirements validation

3 quality aspects of requirements

Defined requirements quality criteria (e.g., completeness, understandability, agreement etc.) help to check requirements systematically. Requirements validation is carried out for:

Content: Relevant requirements elicited and documented with appropriate level of detail.

Documentation: Requirements documented as per defined guidelines and templates.

Agreement: All stakeholders agree with documented requirements and known conflicts resolved.

Stakeholders should approve requirements for further development activities only when all three quality aspects are verified.

Using validation criteria for the quality aspects

Quality aspect “Content”

Validate requirements with respect to errors in content. The validation criteria are:

  • Completeness of individual requirements
  • Correctness and adequacy
  • Consistent – Necessary – Testable - Realizable
  • No premature design decisions.
  • Traceable to business needs

Quality aspect “Agreement”

Validate requirements for agreement between stakeholders. During the project, stakeholders may change already agreed requirements as they gain new knowledge. Requirements are agreed with all relevant stakeholders and all known requirements conflicts are resolved.

1.10   Importance of requirements changes

Requirements change over during life of a system due to errors or incomplete requirements, evolution of context, changes in stakeholders’ needs, legal changes, new technologies, or additional competition in market etc.

Requirements changes per se may not be an issue as it may indicate stakeholders working closely with system and learning more about it. However, frequent requirements changes make it extremely difficult to develop a stable system. A high change frequency may also indicate inadequately performed IT Business Analysis. Frequent changes take up a lot of resources in project development.

Change control board

Change control board (CCB) evaluates and approves changes to requirements. It has following tasks:

Ø Classification of incoming change requests.

Ø Estimate effort for performing change.

Ø Evaluate CRs for desirability (Benefit vs. cost).

Ø Define new requirements based on CRs.

Ø Approve or reject CRs.

Ø Prioritize approved CRs.

Ø Assign approved CRs to change projects.

[Source: CPRE FL syllabus].

Representatives in change control board

CCB usually consist of following stakeholders: Change manager (Chairperson for CCB), Sponsor, Suppliers, Architect, Configuration manager, Customer representative, Product manager, Project manager, Quality assurance representative and Business Analyst.

Change manager mediates between parties in case of conflicts, negotiate decisions with respective parties, documents and communicates decisions.

 

Change request (CR)

Change requests document desired change and associated information. In agile methodologies, CRs are called "Product backlog". CRs typically contain following information:

1. Identifier: Uniquely identify a CR.

2. Title: Summarizes CR in brief statement.

3. Description: Describes change, also information on effects of changes as well.

4. Justification: Reasons as to why change is necessary.

5. Date created: Date at which change request was filed.

6. Requestor: Person who raised CR.

7. Requested priority: Importance of CR as per requestor.

8. Impact analysis status: Indicates whether impact analysis has been performed on CR.

9. Acceptance status: Indicates CCB acceptance status.

10.   Accepted priority: CCB priority of CR.

11. Assigned to: Person responsible for CR.

12.   Release: Release for CR implementation.

Classification of incoming change requests

CRs can be classified as:

1. Corrective CR: CR raised for fixing a failure of system during its operation attributed to an error in requirements.

2. Adaptive CR: CR raised for modifying system behavior due to change in stakeholder needs or change in system context.

CRs also can be classified as:

1. Exceptional CR (hotfix): CR must be done immediately

2. Normal CR (hotfix): CR which can follow planned release schedule.

 

Basic method for implementing CRs

* Can be tailored depending on organizational and project-specific needs.

Analyze impacted components

Identify all components (requirements, design, code, test cases, user manuals etc.) affected by change. Traceability matrices are helpful in analyzing impact of a CR. In absence of traceability matrices, Business Analysts should consult domain experts and development team to identify impacted components.

Estimate effort and cost

For each affected component, determine effort for implementing each change. Sum up efforts for finding total effort and then subsequent costs.

Evaluate and approve / reject CR

CCB evaluates CR based on objective criteria such as cost and benefit, availability of resources and approves / rejects the CR.

Prioritize CRs

CCB prioritizes approved CRs and assigns to projects or system releases for implementation.

Implement approved changes

Development team implements approved and prioritized CRs.

Validate requirement changes

CCB or person responsible validates implemented CRs.

Elicit Requirements

1.1 Key concepts

  • What is elicitation?

Elicitation involves understanding underlying needs from stated requirements of stakeholders. It also involves eliciting all necessary information for successful development of a system from all identified sources.

  • Elicitation challenges

Some of the common challenges faced in elicitation are:

  • Users omitting to identify requirements.
  • Users and analysts taking certain knowledge for granted and failing to ensure a common understanding.
  • Lack of clarity in the wordings.
  • Ambiguity of written language.
  • Conflicts between requirements.
  • No way to test.
  • Providing a solution rather than stating requirements.
  • Lack of consensus among business users.
  • Getting into solution domain.
  • Role of communication in IT Business Analysis

Natural languages are the most important means to communicate requirements. However, stakeholders may understand natural language requirements differently due to their knowledge and background. Effectiveness of natural language communication depends on familiarity of stakeholders on the subject, their past experiences, cultural and educational backgrounds, etc. Hence, it is important to develop common terminology (glossary) and defined requirements constructs, i.e. describe requirements using a standard structure, while communicating in natural language. Expressing requirements using standard constructs helps in not forgetting essential information while using natural languages.

Business Analysts can take help of modeling languages such as Unified Modeling Language (UML) and Business Process Modeling Notation (BPMN) which reduces ambiguity in communication using natural language.

 

  • Impact of communication mediums in IT Business Analysis

    Communication mediums (written or spoken) have significant effect in requirements communication (or miscommunication). When communicating in natural languages, all stakeholders MUST consciously focus on direct and simple communication. In verbal communication, success of the communication relies on expressed language, gestures and feedbacks. But in written communication, these are absent. Many often, requirements may be communicated incorrectly due to natural transformations that occur during human perceptions

 

  • Language effects

    Natural languages are inherently ambiguous and often interpreted in multiple ways. Requirements are described and referred by people with different knowledge, different social backgrounds and different experiences. Due to gaps in communications, developers develop something different from actual needs of stakeholders. Business Analysts MUST try to minimize such transformations and try to make requirements unambiguous.

 

  • Transformational effects

As transformational effects adhere to specific rules, Business Analysts can exploit this to elicit deep structures (i.e., what requirement providers really meant) from its surface structures (i.e., stated requirements).

5 most common transformational processes for requirements are:

Nominalization (Compression of activities)

Users tend to convert a long-lasting activity or group of nouns into a single event or noun, this is nominalization. For example, users may say “Manage schedule” when what they actually mean is “Create, Retrieve, Update, Delete, Import and Export schedule”. The way to minimize nominalization is to identify all verbs used in requirements. These verbs MUST be explained clearly in glossary and agreed upon by all stakeholders.

Nouns without reference index

Users tend to omit adverbs or use generic nouns. Common nouns which are incompletely specified are: user, system, message, data, or function. For example, let us study a requirement “Users shall update data using their devices”. The following questions arise: Which user? What data? Which devices? We can write the above requirements as: Privileged users can update schedule data using their laptops or mobile phones.

Universal quantifiers

Universal quantifiers group set of objects and generalize behavior or property for the group. Typical universal quantifiers are: All, always, every, never, no, none, or nothing etc. Most likely the specified behavior or property may not apply to all the objects in the specified group. Business Analysts MUST verify whether specified behavior or property really applies to all objects grouped through quantifiers.

For example, let us consider a requirement “The system shall not allow anyone to delete projects”. In this case, following question must be asked: “Can no employee actually delete the name? What happens if someone created a project by mistake?”

Incompletely specified conditions

Conditions are usually associated with words such as if... then, in case, whether and depending on. Stakeholders sometimes specify behavior that MUST occur when condition is met, but forget to specify what should occur if condition is NOT met.

For example, let’s consider requirement, “Only post graduates are eligible to attend the program”. In this example, at least one aspect remains unspecified: “Which programs shall be offered to graduates or lower”?

Business Analysts should use decision tables and decision trees for complex conditional structures.

Incompletely specified process verbs

Some verbs need more than one noun to be completely specified. For example, verb “Communicate” requires at least three aspects for completeness: “What is being Communicated, who is communicating and to whom it is being Communicated”. Formulating requirements in active voice minimizes incompletely specified process words.

 

  • Elicitation using requirements models

If you would have visited any new housing complex or a large building being constructed, you would have observed that a tiny replica is made with defined proportions, such as 100 meters: 10 centimeters. Such physical models allow designers and architects to visualize the entire property before constructing the actual property. They can understand if the open spaces will be adequate, what would be ideal places for provisioning the common amenities such as club-house, swimming pool etc.

Obviously, the model is the real thing but it serves a great purpose: Be a guide for the architects and engineers. Same way, Business Analysts can model requirements which often provides requirements in a condensed manner and aids in completing the missing parts of the requirements.

We can define models as: "Models are abstractions of an existing or desired reality”. Requirements models are usually diagrams, tables or mathematical equations. Requirements models make it easier to document requirements, understand requirements from different perspectives and reduce ambiguity.

Elicitation and documentation of requirements in the form of conceptual models offers following advantages:

  • Information presented in pictures is quicker to understand,
  • Allow the targeted modeling of one or multiple perspectives on the requirements.

Combining natural language and requirements models provides the advantages of both documentation types.

 

  • Aspects to take care during elicitation

While conducting elicitation, Business Analysts should carry out concurrent activities for eliciting, documenting, validating, capturing attributes, modeling, verifying, and confirming requirements. However, it is not possible to complete all the work during elicitation. Still Business Analysts should keep an eye on above mentioned activities to get quality requirements at source.

 

  • Elicitation techniques

Various techniques used for requirements development are:

1. Survey techniques (e.g. interviews, workshops, questionnaires),
2. Creativity techniques (e.g. brainstorming, brainstorming paradox, change of perspective, analogy technique),
3.Document-centric techniques (e.g. system archaeology, perspective-based reading, requirements reuse),
4.Observation techniques (e.g. field observation, apprenticing),

 

  • Factors influencing choice of elicitation techniques

Factors influencing the choice of elicitation techniques are:

1. Type of requirement - Conscious, unconscious and subconscious requirements to be elicited,

2. Desired level of detail of the requirements, Time and budget constraints,

3. Availability of stakeholders, Risks of the project, Context, Organizational influences,

4. Human influences: Experience of Business Analysts and stakeholders with particular elicitation techniques.

Techniques based on level of detail required

Level of requirement

Techniques

Advantages

Disadvantages

Abstract requirements

Creativity techniques

(Interview, Brainstorming)

Capture subconscious requirements

Provide immediate feedback

Time and effort consuming

Medium

Inquisitive (survey) techniques or observational techniques

Questionnaire

Precise and unbiased.

Stakeholders unable to express their opinions can provide their inputs.

Cost effective.

Can be only employed to elicit requirements IT BA already knows.

Do not provide immediate feedback.

Creating right questionnaire is tricky, time-consuming and requires good knowledge of the domain.

Finely detailed requirements

Document-centric techniques

Captures extensive details.

Takes time.

Can produce lots of requirements.

 

 

Techniques based on availability of stakeholders

Stakeholder availability

# of stakeholders

Techniques

Co-located

Limited

Interviews, Workshops

Distributed, Large

Large

Survey

Techniques based on risks of project

Low

Medium

High

Survey

Prototyping

Interviews, Workshops

Observation and document-centric techniques

Techniques based on complexity of the project

Simple

Complex

Survey

Prototyping, Interviews, Workshops

Observation and document-centric techniques

 

1.2 Activities

  • Determine suitable elicitation techniques

Purpose: Determine suitable elicitation techniques to elicit requirements.

Stakeholders: Sponsor, Domain SMEs, Project manager, Regulator, Supplier.

Inputs

Elements

Outputs

1. Requirements context

2. System scope

 

1. Understand different types of requirements to be elicited.

2. Determine suitable requirements techniques to elicit requirements.

1. Identified elicitation techniques

Tools and Techniques: Brainstorming, Elicitation techniques chart.

Example:

Type of requirements

Elicitation techniques

Modeling techniques

Non-functional requirements

Interview

Non-functional requirements

Process, data and UI requirements

Workshops

Prototype, Activity diagram, State chart diagram

Interfacing requirements

Interview

Interface mapping template

Legal requirements

Interview 

NA 

Business rules

Document analysis, Interview and Workshop

Flow charts

Reporting requirements

Interview

 Report structure template

 

  • Prepare for elicitation

Purpose: To prepare for conducting elicitations.

Stakeholders: Business Analyst.

Inputs

Elements

Outputs

1. Identified Stakeholders

2. RE activity plan

1. Identify resources needed for conducting elicitations.

2. Organize needed resources.

1. Resources organized for elicitation

Tools and Techniques: Audio and video recordings.

 

 

 

Example:

Prepare for eliciting business requirements

Type of meeting

Focus of workshop

Participants

Date

Time

Status

Workshop

Stakeholder commitment

 

Dave Richards

Mike Dent

Dinesh Pandey

Lee Fung

17-Mar

10:00 AM to 12:00 Noon

 

Workshop

Delivery Management

Peter Lily

Shalini Paul

Gajendra Battalla

Nori Masa

19-Mar

10:00 AM to 12:00 Noon

 

Interview

Audit management

Rebecca Randad

21-Mar

10:00 AM to 12:00 Noon

 

Interview

Training manager

Susan Thomas

22-Mar

10:00 AM to 12:00 Noon

 

Interview

Risk manager

Sara Lee

23-Mar

10:00 AM to 12:00 Noon

 

Interview

Resourcing manager

Jane Macrae

26-Mar

10:00 AM to 12:00 Noon

 

Interview

IT Manager

Surya T

27-Mar

10:00 AM to 12:00 Noon

 

 

 

  • Elicit requirements

Purpose: To elicit requirements from stakeholders and other sources.

Stakeholders: Sponsor*, Customer*, Domain SME*, End user*, and Regulator*,

Project manager, Implementation SME, Operational support, Tester, Supplier.

Inputs

Elements

Outputs

1. Business need and solution scope

2. Scheduled resources

3. Supporting materials

1. Elicit non-functional, functional and implicit requirements.

2. Elicit regulatory, statutory, contractual requirements.

3. Elicit current and future requirements.

4. Elicit interface requirements.

5. Ensure requirements expressed are aligned to business need and solution scope.

6. Capture requirement attributes.

a. Elicited requirements

Tools and Techniques: Requirements workshop, Interview, Observation, Survey/Questionnaire, Document analysis, Requirements Template.

 

Example:

Abstract of a discussion between Head of Delivery and Business analyst

Michelle (BA): Good morning Mike. Thanks for taking time out to talk to me.

Mike (CDO): Good morning Michelle. Pleasure meeting you.

Michelle: I would like to congratulate you on our company receiving the prestigious Delloite Technology Fast 50 Award.

Mike: Thanks Michelle. Yes, indeed this is a very good news for our organization. I hope you are enjoying your work in our organization.

(Example of an ice-breaker and forming a rapport with the stakeholder).

Michelle: As I had intimated you earlier, I am performing the role of Lead BA for the Governance, Risk and Compliance (GRC) management business for our organization. In this regard, I would like to discuss and collect business requirements for the business.

Mike: Sure Michelle, go ahead.

Michelle: Can you pls. describe in few sentences the key objectives behind the proposed GRC business?

Mike: Let me describe why senior management would like to have a GRC business for the organization. We as a company have been growing at a rapid pace. We had 40 active projects 3 years back and now we have 120+ active projects. In next 3 years, we may have 200+ active projects. We could monitor and manage projects when the numbers were small. We should invest into a GRC business which allows us to grow further.

Michelle: Good to know about our growth story. I would like to know conditions for the GRC business before I discuss the features of the business. Is that ok with you?

Mike: That’s fine.

Michelle: Would we like the GRC business to be deployed to our main development center in Seattle or to all development centers world-wide?

Mike: This is a corporate initiative and all development centers will be part of the deployment. However, we plan to deploy it in phases starting with a small development center in New Jersy.

Michelle: That’s good to know. Can you let me know who would be primary users of the business?

Mike: Although senior management will be the primary stakeholders of the business, everyone in the organization will be using the business. Especially for attendance and effort tracking, all employees and contractors will be using the business.

Michelle: That means we are expecting about 20000 users for the business.

Mike: Yes. But this could grow up to 100000 users in next 5 to 10 years’ time frame.

Michelle: Thanks for this information Mike. Since we are deploying the business world-wide, do you expect the business to support multiple languages and currencies?

Mike: Multiple currencies is a must as this business needs to interface with our accounting business. In future, we would expect the business to enable us invoice our customers. We do not expect the business to support other languages other than English. However, we expect the architecture to be flexible to support other languages in future if needed.

Michelle: What are the platforms and browsers would you like this business to support?

Mike: On the end user front, we expect it to support 4 most popular browsers, IE, Chrome, Fire-fox and Opera.

Michelle: Now that we have discussed key conditions for the business, I would like to capture key features of the business. Can you pls. let me know key user groups for the business?

Mike: Sure Michelle. Although my group is championing the business, the business is envisioned to support GRC related requirements from other groups such as HR, IT, Compliance and Administration as well.

Michelle: What are your key requirements from the GRC business?

Mike: Let me explain my roles for the organization. The 2 key roles for me is to provide our management committee information about revenue projection from our current projects. I also need to monitor health of our client relations and projects.

Michelle: How do we do that currently?

Mike: Currently our PMO function shares an excel workbook which is filled by project managers and consolidated by PMO.

Michelle: What are the challenges that we face in the current process?

Mike: Challenges are many. We spend significant effort in collecting and consolidating the data. There is a high probability of data getting corrupted as it is a manual process. Due to manual process, there is problem with data not being up-to-date which means management is not able to take action when it should.

Michelle: I understand, manual processes do have their challenges. As the Head of Delivery, what Features are a must for you?

Mike: Senior management would like to have a visual dashboard about revenue projection and project health of all projects in the organization. We would like to have color coded indicators with ability to drill down. We would also like to track the actions being taken by project and account managers in rectifying any issue identified by senior management or client.

Michelle: Sure Mike. Would you be able to share the current revenue projection process and dashboards with me?

Mike: My colleague, Dinesh who heads our Quality and PMO function can help you with that.

Michelle: Will do that Mike. Let me make a note of that. Would you like to describe any other critical feature from your perspective?

Mike: I do not think so Michelle. For first iteration, let us focus on the revenue projection and dash board requirements. You can discuss other business requirements with Dinesh and other department heads.

Michelle: Thanks Mike for your time and hope we complete the project soon.

Mike: Thanks Michelle and see you again with the solution.

Example for detailed requirements:

Abstract of a discussion between Project Manager – Development Projects and Business Analyst for Schedule Management Feature

Michelle (BA): Good morning Dave. Thanks for taking time out to talk to me.

Dave (PM-Dev Projects): Good morning Michelle.

Michelle: I would like to congratulate you on our company receiving the prestigious Delloite Technology Fast 50 Award.

Dave: Thanks Michelle. Yes, indeed this is a very good news for our organization.

Michelle: As I had intimated you earlier, I am performing the role of Lead BA for the Governance, Risk and Compliance (GRC) management system for our organization. I met Mike last week to elicit high level business requirements for the GRC system. Mike wanted me to meet you to understand system requirements for the schedule management module.

Dave: Sure Michelle. Since I manage development projects, I can give you requirements for development projects. For other types of project, pls. do get in touch with Lily, Srini and Abdullah.

Michelle: Can you pls. describe how our schedule management is currently performed in our organization?

Dave: During proposal preparation phase, our Solutioning team provides a rough schedule with high level milestones to the client. Once the contract is awarded to us, the same details are passed on to the Project Managers. Project managers expand the schedule.

Michelle: Good to know about the process Dave. Can you show me the template that is used by the Solutioning team for the same?

Dave: The data captured is quite simple. The following table is filled-up by Engagement managers and Sales Managers.

Milestone name

Planned Start Week

Planned End Week

Responsible

Key deliverables

Billing %

 

 

 

 

 

 

 

Michelle: Are there any business rules that we follow while preparing this data?

Dave: Not very sure Michelle. This is prepared by Solutions team given our past data and reviewed by Senior Management for appropriateness.

Michelle: Thanks Dave. How do you expand the schedule?

Dave: This is highly non-standardized at this point in time and that’s what makes our projects vulnerable to failures. Each project manager expands the task list based on his or her prior experience.

Michelle: I have noted that Dave. Would you like our new GRC system to standardize the process?

Dave: That will be a great thing to happen. It will reduce our work as well reduce opportunities for failure. I know from my personal experiences that many projects have suffered heavily because the project manager forgot to include performance or security testing.

Michelle: In the expanded schedule, do you capture any other information?

Dave: Yes, Michelle. The expanded schedule has planned, re-planned and actual start and end dates, efforts and resource names.

Michelle: Ok Dave. Is there any current template that you use?

Dave: I have created an excel based template which I use for my projects. Being an excel based template, it is difficult to share with all team members. Especially collecting actual efforts become very hard as each week I am consolidating 40+ excel workbooks.

Michelle: Thanks for this information Dave. I will collect the requirements for the effort tracking system some other time. However, I am noting that our schedule module will require integration with effort capture system, even possibly with our attendance tracking system.

Dave: Sure, Michelle.

Michelle: Are there any specific rules that we need to follow for schedule management?

Dave: Of course, Michelle. Since tasks can have a hierarchy, the child elements must be contained with parent elements. End dates can never be prior to start dates.

Michelle: Are there any specific interfaces that you would like to have schedules?

Dave: Yes, Michelle. Since most of our planning may happen in MS-Project or MS-Excel, we would like the system to have feature for importing tasks from MS-Project and MS- Excel and exporting back as well.

Michelle: What are the reports that you expect the system to provide?

Dave: We need reports on task wise schedule variance and effort variance. This is a very key report for customer and for our senior management.

Michelle: Ok Dave. Let me make a note of that. Would you like to describe any other critical feature from your perspective?

Dave: We also would need alerts for task allocation and escalation for tasks delayed more than a week.

Michelle: Anything else Dave?

Dave: No Michelle. I am done from my side.

Michelle: Thanks Dave for your time and hope we complete the project soon.

Dave: Thanks Michelle and see you again with the solution.

 

  • Document elicitation results

Purpose: To document stakeholder and other inputs elicited during elicitation.

Stakeholders: Any stakeholder who has participated in elicitation tasks.

Inputs

Elements

Outputs

1. Requirements (Stated, Unconfirmed).

2. Stakeholder concerns (Unconfirmed).

1.   Document elicitation results with the stakeholders who provided the requirements.

1. Documented elicitation results

Tools and Techniques: Backlog, Enumerated list, Minutes of meeting, Audio and video recordings, Issue log.

Example:

#

Captured elicitation results

1

The business must assist senior management to monitor project performances.

2

The business must support world-wide deployment.

3

Capture effort and attendance.

4

Support up to 100000 users.

5

Must support multiple currencies.

6

Business shall be designed for English. Must have provision to support other languages in future.

7

Must support to support 4 most popular browsers, IE, Chrome, Fire-fox and Opera.

8

Provide revenue projection to senior management.

9

Assist in monitoring health of client relationships and project’s health.

10

Provide visual dashboard about revenue projection and project health of all projects in the organization. Dashboards shall have color coded indicators with ability to drill down.

11

Ability to track the actions being taken by project and account managers in rectifying any issue identified by senior management or client.

 

  • Confirm elicitation results

Purpose: To validate that stated requirements expressed by stakeholders match stakeholder’s understanding of the problem and their needs.

Stakeholders: Any stakeholder who has participated in elicitation tasks.

Inputs

Elements

Outputs

3. Approved scope.

4. Requirements (Stated, Unconfirmed).

5. Stakeholder concerns (Unconfirmed).

2.  Verify alignment of elicited elicitation results to approved scope.

3.  Confirm elicitation results with the stakeholders who provided the requirements.

4.  Confirm requirements elicited from document analysis with Domain SME and Sponsor.

5.  Update business requirements document based on stakeholders’ feedbacks.

2. Confirmed and prioritized requirements.

Tools and Techniques: Interviews, Observation.

Example:

#

Requirements

Aligned to scope

Stakeholder Priority

Stakeholder Rank

1

The business must assist senior management to monitor project performances.

Yes

High

1

2

The business must support world-wide deployment.

Yes

High

4

3

Capture effort and attendance.

Yes

High

3

4

Support up to 100000 users.

Yes

High

5

5

Must support multiple currencies.

Yes

Medium

7

6

System shall support English. Must have provision to support other languages in future.

Yes

Medium

8

7

Must support to support 4 most popular browsers, IE, Chrome, Fire-fox and Opera.

Yes

Medium

9

8

Provide revenue projection to senior management.

Yes

High

6

9

Assist in monitoring health of client relationships and project’s health.

Yes

Medium

10

12

Provide an option to evaluate developers’ performance every month.

No

NA

NA

 

 

Business Analytics Tools

1.   Analyze requirements


1.1     Key concepts

 

  • Models and their properties

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Models are abstract representations of existing realities or desired realities. 3 important properties of models:

Mapping of realities:

Models map certain aspects of realities onto their modeling elements. Models can map existing realities, known as “As is” or “Descriptive models” or can map desired realities, also known as “To be” or “Prescriptive models”.

Reduction of realities:

Models reduce mapped realities through selection (only selecting a particular aspect, say for example only process steps for a system) and compression (providing high level overview than actual activities).

High level requirements for GRCPerfect, an Enterprise Governance Risk and Compliance management system

 

 

 

Detailed process requirement for defect management of GRCPerfect

Mapping exact realities will result in highly complex and large outputs and would need considerably higher efforts. Hence, purposefully, during modeling, we reduce the complexities. One can consider a simple rule, models provide 80% values with 20% investment. For rest 20% value, one needs to invest 80% effort which does not make business sense.

1.      Pragmatic property: Models are always constructed for specific purposes through selection or reduction, containing only information necessary for the respective purposes. The perspective could be data, flow, behavior (state) or user interaction. For example, above model only describes “Activity flow” for defect management. It does not describe data, state, or user interaction perspectives for defect management.

 

  • Elements of a conceptual modelling language

 

Modeling languages are defined by their syntaxes and semantics.

Syntax: Defines modeling elements and their valid combinations.

Semantics: Defines individual modeling elements and helps in interpretation of models.

Conceptual modeling languages are classified as formal (e.g. UML, BPMN) and informal (Flow charts, Swim-lanes) depending on degree of formalization.

Requirements models

Conceptual models that document requirements of a system are called requirements models. UML (Unified Modeling Language) is frequently used to develop requirements models. Extensive examples of modeling using UML can be found at OMG.ORG.

1.2     Activities

 

  • Organize requirements

Purpose: To organize requirements into appropriate requirements levels and categories.

Stakeholders: Domain SME, End user, Implementation SME, and Project manager.

Inputs

Elements

Outputs

1.      Confirmed requirements

2.     Organization process assets

3.     Organize requirements according to type of requirement (Functional, non-functional, constraint), level of requirement (High level vs. detailed).

1.      Organized requirements.

Tools and Techniques: Functional decomposition, Requirements templates.

 

Example:

In this example, confirmed requirements are categorized as per their type and category.

Confirmed Requirements

Type

Category

The business must support world-wide deployment.

Non-functional

Business

Support up to 100000 users.

Non-functional

Business

Must support to support 4 most popular browsers, IE, Chrome, Fire-fox and Opera.

Non-functional

Business

The business must assist senior management to monitor project performances.

Functional

Business

Capture effort and attendance.

Functional

Business

Provide revenue projection to senior management.

Functional

Business

Provide visual dashboard about revenue projection and project health of all projects in the organization. Dashboards shall have color coded indicators with ability to drill down.

Functional

Business

 

  • Prioritize requirements

Purpose: To ensure project efforts focus on the most critical requirements.

Stakeholders: Sponsor*, Domain SME*, Implementation SME*, Regulator, and Project manager*.

Inputs

Elements

Outputs

1.      Business need

2.     Business case

3.     Organized requirements

4.     Requirement prioritization guidelines

5.     Stakeholder list, roles, and responsibilities

1.      Enhance requirements attributes.

2.     Prioritize requirements.

3.     Manage requirements prioritization challenges.

1.      Prioritized requirements

Tools and Techniques: Ranking, Decision analysis, Risk analysis, MoSCoW analysis, Time-boxing, Budgeting and Voting

 

 

 

Example:

Requirement

Type

Stk. Pri.

Stk.
Rank

Legal?

Value

Cost

Impl. pri

The business must support world-wide deployment.

NFR

H

4

NA

NA

NA

H

Support up to 100000 users.

NFR

H

5

NA

NA

NA

H

Must support to support 4 most popular browsers, IE, Chrome, Fire-fox and Opera.

NFR

M

9

NA

NA

NA

H

The business must assist senior management to monitor project performances.

FR

H

1

No

5

1

H

Provide revenue projection to senior management.

FR

H

6

No

5

1

H

Assist in monitoring health of client relationships and project’s health.

FR

M

10

No

5

1

H

 

 

 

 

  • Model and elaborate requirements

Purpose: To model and elaborate prioritized requirements using a combination of matrices, diagrams, and mathematical formulas.

Stakeholders: Domain SME.

Inputs

Elements

Outputs

1.      Prioritized requirements

1.      Elaborate requirements.

2.     Model requirements.

1.      Modeled requirements

Tools and Techniques: Data flow diagram, Functional decomposition, Interface analysis, Non-functional requirements analysis, Organization modelling, Process modelling, Prototyping, Scenarios and use cases, State diagrams, and User stories, Matrix model, Use case specifications, Flow charts, Decision tables, Activity diagram.

 

Models for schedule management

 

 

 

 

  • Prepare requirements package

Purpose: To package set of requirements in an appropriate manner for effective stakeholder communication.

Stakeholders: Primary responsibility of Business Analyst.

Inputs

Elements

Outputs

1.      Business analysis communication plan.

2.     Organizational process assets.

3.     Requirements.

4.     Requirements structure.

1.      Prepare work products, and deliverables.

1.      Requirements package.

Tools and Techniques: Requirements documentation, Requirements for vendor selection.

 

Example:

Since this is an excel workbook, this will be available on the book web-site.

 

  • Verify requirements

Purpose: To ensure requirements and packages meet necessary standards of quality. To identify defects in the requirements before presenting to other stakeholders.

Stakeholder: Primary responsibility of Business Analyst.

Inputs

Elements

Outputs

1.      Packaged requirements

2.     Requirements quality criteria.

1.      Review requirements.

2.     Update requirements based on review.

1.      Verified requirements

Tools and Techniques: Requirements review checklist, Commenting, Inspection, Prototyping, Peer review, Structured walkthrough.

Example:

Date of review

14-Jan-15

Reviewed by

LN Mishra

Overview

Yes/No/NA

Remarks

Check if prototyping requirements, if any, are documented

Yes

 

Check requirements for completeness

Yes

 

All stated requirements together, when implemented, will achieved the systems' stated objective

Yes

 

Check for consistency

Yes

 

Standards and methods are all consistent across all modules of the system

Yes

 

Check whether requirements are testable

Yes

 

 

 

 

 

  • Validate requirements

Purpose: To validate verified requirements before sharing the requirements for development or procurement.

Stakeholders: All key stakeholders.

Inputs

Elements

Outputs

1.      Business need and solution scope.

2.     Verified requirements.

1.      Communicate review schedule.

2.     Present requirements for review.

3.     Gather observations during the review.

4.     Seek information from documentation or stakeholders for the queries or clarifications raised by stakeholders.

5.     Update requirements document with stakeholder feedbacks.

6.     Obtain approval on requirements.

1.      Minutes of review meeting

2.     Approved requirements

Tools and Techniques: Group review, Structured walkthrough, Inspection, Prototyping, Perspective based reading.

 

 

 

Example:

Requirements Group

Requirements

Priority

Rank

Approved?

Dashboard

The system must assist senior management to monitor project performances.

High

1

Yes

Dashboard

Provide revenue projection to senior management.

High

2

Yes

Dashboard

Assist in monitoring health of client relationships and project’s health.

High

3

No

Dashboard

Provide visual dashboard about revenue projection and project health of all projects in the organization. Dashboards shall have color coded indicators with ability to drill down.

High

4

Yes

Project management

Ability to track the actions being taken by project and account managers in rectifying any issue identified by senior management or client.

High

5

Yes

Project management

Assist project managers in scheduling tasks

High

6

Yes

Project management

Provide skill projection for projects.

Medium

 

Yes

Project management

Project IT asset requirements for projects.

Medium

8

Yes

Project management

Assist Project Managers in tracking project risks.

High

9

Yes

 

 

Manage requirements

 

1.1     Key concepts

 

Requirements management knowledge area describes following tasks:

ü  Allocate requirements

ü  Communicate requirements

ü  Manage requirements changes

ü  Manage IT Business Analysis activities, risks and performance

ü  Manage requirements conflicts

ü  Define transition requirements

ü  Define interface requirements

ü  Validate new / improved solution

ü  Identify workarounds and future improvements

Assigning attributes to requirements

Defining views on requirements

Prioritizing requirements

Tracing requirements

Versioning requirements

Managing requirement changes

 

Requirements management manages individual requirements as well as complete requirements documents. It documents information about requirements throughout entire life cycle of a system. This includes, unique identifiers, name, author, person responsible and sources of requirement.

 

  • Significance of requirements conflicts

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Requirements conflicts occur when stakeholders disagree on requirements. For example, one stakeholder may like to include a feature which another stakeholder may prefer to keep out. Unresolved requirements conflicts have negative impacts on the project including:

1.      Stakeholder dissatisfaction.

2.     Poor return on investment.

3.     Some stakeholders’ requirements not implemented.

4.     Operational system not accepted.

5.     Operational system not sufficiently used.

Conflict identification

Conflict analysis

Conflict resolution

Documentation of conflict resolution

At the same time, conflicts provide opportunity for Business Analysts to discover potential new ideas and different options for development. Resolving conflicts increases acceptance of the system. Requirements negotiation aims to develop consensus on requirements among relevant stakeholders. Requirements negotiation MUST be performed throughout IT Business Analysis needing additional efforts and costs. However, advantages of requirements negotiation (reduction of overall cost, increase in acceptance, supporting creativity and innovations) is significantly higher than these additional costs.

 

 

Conflicts arise during throughout IT Business Analysis activities. Stakeholders provide contradicting requirements during elicitation. Business Analysts should identify potential conflicts early so that they can be analyzed and resolved early.

 

  • Workarounds

 

 

When a problem is identified with the solution (i.e. a failure to meet a stakeholder need, whether or not the requirement was correctly specified), Business Analysts help the team to determine the most appropriate action.

Some solution components, especially software applications, may require an Implementation SME to investigate the root cause of problems. Identify defects which MUST be rectified, which can be mitigated through workarounds or other approaches, and which can be accepted until resources are available to address them. If a defect cannot be resolved in an acceptable timeframe (due to complexity, or cause not identified, or not of high priority, etc.), and stakeholders cannot accept the defect, investigate options for mitigating the effects. Options can be additional quality control checks, new manual processes, removal of support for certain exception cases, etc.

In spite of project and implementation team’s best efforts, situation could arise that the solution is not able to handle certain requirement(s). In such a situation, Business Analyst should identify possible workarounds. Workarounds are useful that they may not be the most elegant solution but they are highly cost-effective and can be implemented in a short duration.

1.2     Activities

 

  • Allocate requirements

Purpose: To allocate solution requirements among releases, and solution components to maximize possible business value.

Stakeholders: Sponsor*, Domain SME*, Project manager*, Implementation SME*, Customers, Suppliers, End user, Operational support, Tester.

Inputs

Elements

Outputs

1.      Approved and prioritized requirements

2.     Release plan

3.     Solution components

1.      Compute capacity of the releases.

2.     Allocate requirements among releases and solution components.

1. Allocated Requirements

Tools and Techniques: Release plan.

 

Example:

Release name

Capacity (Person-hours)

Feature

Effort needed

Cumulative effort

1

900

Login

50

50

 

 

Basic Schedule

400

450

 

 

Basic defect

400

850

2

900

Basic issues

300

300

 

 

Basic risk

300

600

 

 

Basic estimation

300

900

3

900

Dashboard

400

400

 

 

Time tracking

300

700

 

 

Advanced schedule

200

900

 

 

  • Communicate requirements to stakeholders

Purpose: To communicate validated requirements to stakeholders.

Stakeholders: Sponsor*, Domain SMEs*, Implementation SMEs* / Procurement team*, Testers*, Support team.

Inputs

Elements

Outputs

1.      Requirements communication plan.

2.     Validated requirements.

1.       Share validated requirements with stakeholders.

2.      Send meeting invites if needed.

3.      Explain requirements.

4.      Clarify questions.

5.      Explain rationale behind selection / non-selection of requirements.

1.      Minutes of meeting.

Tools and Techniques: Structured walkthrough, Email.

 

Example:

Date of Review

1-Aug-14

Start Time

14:00

End Time

17:00

Sl #

Meeting Invitees

Department

Attended?

Prepared?

Role

1

Mike Dent

CDO

Yes

Yes

Reviewer

2

Dinesh Pandey

Head-PMO

Yes

Yes

Reviewer

3

Lee Fung

Head-IT

Yes

Yes

Reviewer

4

Peter Lily

Delivery Manager

Yes

Yes

Reviewer

5

Shalini Paul

Delivery Manager

Yes

Yes

Reviewer

Discussion Topics and Action Items

Sl #

Section No. of Document

Discussion point

Action Item

Responsible

Target Date of Completion

Status

1

NFR

Testing of NFRs

To describe testing approaches for NFRs

Michelle

30-Sep-14

Open

2

Out of scope

Out of scope elements

To clearly specify aspects not in scope

Michelle

30-Sep-14

Open

3

Application sizing

Transaction volume estimates

To estimate transaction volume estimates for critical features

Michelle

30-Sep-14

Open

Review Status

Conditionally Accepted

                     

 

 

  • Manage IT Business Analysis activities, risks and performance

Purpose: To manage performance of IT Business Analysis activities to ensure they are executed as effectively as possible. Monitor and report IT Business Analysis progress and take necessary corrective actions.

Stakeholders: Sponsor, Project manager.

Inputs

Elements

Outputs

1.      Defined IT Business Analysis metrics.

2.   IT Business Analysis performance

1.      Prepare IT Business Analysis performance reports.

2.     Review IT Business Analysis plan, risks and performance with key stakeholders.

3.     Identify corrective actions to meet desired performance level.

1.      Corrective actions.

2.   Updated IT Business Analysis activity plan.

Tools and Techniques: Status Reporting, Variance analysis, Problem tracking

Example:

IT Business Analysis status report for Week of 10-Feb-2014

Requirements activity

Target Date

Status

Re-planned End Date

Reason

Understand project vision

3-Feb

Completed

 

 

KPIs and Dashboards.

10-Feb

Completed

 

 

Non-functional business requirements

10-Feb

Completed

 

 

Project monitoring business requirements

10-Feb

Completed

 

 

Operational Dashboards.

10-Feb

Open

15-Feb

Stakeholder on leave for the week

Risks and mitigations

Risk description

Probability

Severity

Impact

Mitigation Plan

Domain SME availability

Medium

Critical

High

Identify back-ups for all critical Domain SMEs.

Increase in scope

High

Critical

High

Discuss during steering committee meetings

Completeness of requirements

Medium

Critical

High

Prototypes to be approved by Domain SMEs

 

 

  • Manage requirements changes

Purpose: To effectively manage requirements changes.

Stakeholders: PM*, Domain SME*, End user, Sponsor, CCB*.

Inputs

Elements

Outputs

1.      Suggested requirements changes.

1.      Record requirements changes.

2.     Determine if change is acceptable as per project change management policy.

3.     Propose change to change control board.

4.     Update requirements documents once change is accepted.

1.     Accepted requirements changes.

Tools and Techniques: Requirements Change management, Problem / Issue Tracker, Brain storming.

 

Example

Req ID

Requirement

Req Type

Requestor

Crit.

Benefit

Cost

Val.

Idx.

Accepted

80100

Support for task dependency

Functional

Gajendra Battalla

Should Have

3

6

50

No

80200

Export of reports to ppt

Functional

Dave Richards

Should Have

5

6

83

Yes

80300

Integration with BI tools

Functional

Sara Lee

Should Have

3

4

75

Yes

80400

Support for Known error database

Functional

Nori Masa

Should Have

5

6

83

No

 

 

  • Manage requirements conflicts

Purpose: To effectively manage requirements conflicts.

Stakeholders: PM*, Domain SME, Sponsor, End user*, Implementation SME.

Inputs

Elements

Outputs

1.      Requirements conflicts

1.      Record requirements conflicts.

2.     Explore options to manage conflicts.

3.     Decide on the action for the conflict.

1.      Resolved conflicts

Tools and Techniques: Conflict management, Problem / Issue Tracker, Brain storming.

 

 

Example:

Conflict

Cause

Involved stakeholders

Stakeholder Opinions

Alternatives for conflict resolution

Decision

Reason for decision

Incorporation of multiple currency

Future scope of the product

Domain SME, PM, Lead BA

Lead BA - Will involve significant effort in reporting

Domain SME - 90% of contracts are in one currency

Convert other currency contracts into USD manually

Convert other currency contracts into USD

To save project effort

 

 

  • Define transition requirements

Purpose: To define requirements for transitioning from an existing solution to a new solution.

Stakeholders: Sponsor*, Implementation SME*, Domain SME*, Project manager*, End user, Operational support.

Inputs

Elements

Outputs

1.      Existing solution data model

2.     New solution data model

3.     Stakeholder list

1.      Determine data migration requirements.

2.     Map data elements between existing application data model and New / Updated application data model.

3.     Develop transformation rules, if needed.

4.     Determine options to perform ongoing work, and new solution concurrently for defined duration.

5.     Plan for end user trainings, if needed.

6.     Manage organizational change.

7.     Manage on-going work along with new work.

1.    Transition requirements

2.   Training plans (Optional)

3.   Data migration approach

 

Tools and Techniques: Business rules analysis, Data flow diagrams, Data modeling, and Data mapping template.

 

Example:

Since the organization did not have a project management system earlier, there is no need to migrate data. Only a training plan is prepared to enable end-users use the new system effectively.

Stakeholder group

Workshops planned

Date

Status

Project managers

Project management features

21 to 28 Nov - 2 PM to 5 PM

Open

Administrators

Product administration

15 and 16 Oct - 10 AM to 4 PM

Open

End users

Time and defect tracking

5 to 22 Dec - 2 PM to 4PM

2 batches – 1 hour each

Open

 

 

 

 

  • Define interfacing requirements

Purpose: To define requirements for interfacing new application with existing applications.

Stakeholders: Sponsor*, Implementation SME*, Domain SME*, Project manager*, End user, Operational support.

Inputs

Elements

Outputs

1.      Existing solution data model

2.     New solution data model

4.     Stakeholder list

1.      Determine data interfacing requirements.

2.     Map data elements between existing application data model and New / Updated application data model.

3.     Decide interfacing frequency

1.      Interfacing requirements

Tools and Techniques: Data flow diagrams, Data modeling, Data mapping template, Interfacing template.

 

Example:

Since the organization has an existing ERP system (Oracle Apps), following interfaces are designed between Oracle Apps and GRCPerfect.

Source

Destination

Data

Frequency

Oracle Apps

GRCPerfect

Employees, Projects, Allocations

Once in 15 minutes

GRCPerfect

Oracle Apps

Effort data

Once a day - midnight 12 AM

GRCPerfect

Reporting DB

Schedule, Defect, Risk and Effort data

Once a day - midnight 12 AM

 Identify workarounds and future improvements

Purpose: To validate that a solution meets the business need, and determine the most appropriate response to identified defects.

Stakeholders: Domain SME, Implementation SME, End user, Sponsor, Project manager, Tester, Operational support, and Regulator.

Inputs

Elements

Outputs

1.      Solution (Constructed)

2.     Requirements (Prioritized, and Validated)

1.      Investigate defective solution outputs.

2.     Assess defects, and issues.

3.     Identify possible workarounds to defects where developing permanent solutions may not be gainful.

4.     Obtain feedback from stakeholders on the workarounds.

1.      Identified defects

2.     Mitigating actions

3.     Solution validation assessment

Tools and Techniques: Acceptance evaluation criteria definition, Problem tracking, and Root cause analysis, Workarounds.

 

Example:

In few of the projects, the stakeholders expected GRCPerfect data to be exported Microsoft Project. However, this was technically very difficult as the internal structure of MS Project is not available to development team. Hence, it was decided that GRCPerfect will export data to MS Excel which will be manually updated in MS Project.

  Previous Next  

Related Posts

Write Comment

Write Comment