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?
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.
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:
-
Human-machine interface, also known as user interface,
-
Hardware interface,
-
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 |
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 |
Document analysis, Interview and Workshop |
Business rules template |
|
Reporting requirements |
Delivery managers |
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: Brainstorming, Interviews, 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:
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:
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. |
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
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.
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 |
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.
Write Comment