What is Business Analysis?
The practice of enabling change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders.
Business analysts identify and define the solutions that will maximize the value delivered by an organization to its stakeholders
Business analysts work across all levels of an organization and may be involved in everything from defining strategy, to creating the enterprise architecture, to taking a leadership role by defining the goals and requirements for programs and projects or supporting continuous improvement in its technology and processes.
Business Analysis is the set of tasks, knowledge, tools and techniques required to identify business needs and determine solutions to business problems [BABOK]
BA Solutions may include:
Development of software systems
Development of software components
Extensions of existing software
Improvements to the business process
Changes to the organization
Role of BA in project phases
Supporting implementation work in order to ensure developers understand and implement the requirements properly
Business Analyst supports the project from the beginning through the system deployment (and sometimes to the system retirement).
Supporting testing, for example by validating test cases in order to ensure that testing will adequately cover all the requirements
Analyzing and documenting change requests for the requirements
Processing new requirements (new regulations, standards, etc.)
Processing the requests to fulfill new needs requested by the customer or user
What is an artefact?
Final or intermediate work products that are produced and used during a project
Might describe the function, architecture, and design of software
Might be concerned with the process of development itself, such as project plans, business cases and risk assessments
Should use version control
Should be correctly traced to their origin
What is a Business Goal?
A Business Goal is a short- or long-term objective of an organization. Business Goals should be characterized by the following qualities
Both short- and long-term scope
Setting Business Goals is important because:
The organization needs to have a vision of what it wants to accomplish. This is facilitated by having clearly stated goals, along with establishing time periods in which they need to be achieved
It keeps a clear picture of what the organization is trying to do with the business, and helps focus motivation
It allows the organization to understand and maintain a commitment to the business’ main objectives
It provides a metric against which to measure the organization’s progress
SMART is a system and a tool that is used to establish goals and define their quality objectives. SMART requires that all goals have the following characteristics
What is a requirement?
A condition or capability needed by a stakeholder to solve a problem, or achieve an objective.
A condition or capability that must be met or possessed by a system or system component, to satisfy a contract, standard, specification, or other formally imposed documents
A documented representation of a condition or capability
Requirements are the foundation of systems, or system components. They can be obligatory (required functions, constraints, etc.), essential for the software to perform its functions, and meet the expectations and needs of the intended stakeholders
Requirements should be placed into one of the following categories
Purpose of requirements:
Provide a foundation for assessment, planning, execution and monitoring of the project activities
Define customer expectations (expressed as real requirements and stakeholder’s value of those requirements)
Serve as a component of agreements, orders, project plans
Establish system boundaries, scope of delivery, and the services classification of the requirements
describe needs and limitations of the business processes
Sales and distribution
functional and non-functional product requirements
POV of customer and team
Types of requirement
Solution or system requirements
Product or component requirements
Elaborate the solution definition in order to enable the project team to design and build a solution that will meet the needs of the business and stakeholders
Task: Organize Requirements
Structure and organize a set of requirements into logical sets. The organization may be based on defining multiple “levels” of requirements, packaging related functions together, and so forth.
Inputs: Business Case, Solution Scope, Requirements
Outputs: Structured requirements
Task: Prioritize Requirements
Determine the business priority of requirements (including voting, ranking, benefit analysis and so forth). Identify logical dependencies between requirements and requirements packages.
Inputs: Requirements, Business Case
Outputs: Prioritized requirements
Task: Specify and Model Requirements
Describes standard practices for writing textual requirements and creating models or diagrams. Specific models are addressed as techniques. Includes capturing the requirements attributes
Outputs: Specified or modeled Requirements
Task: Determine Assumptions and Constraints
Identify stakeholder requests that are not properly requirements but based on assumptions regarding what the solution team is capable of delivering
Capture and assess these requests
Outputs: Assumptions and Constraints
Task: Verify Requirements
Outputs: Verified requirements
Task: Validate Requirements
Validate that a requirement will satisfy a business need.
Outputs: Validated requirements
Business Requirements Elicitation is defined as a set of approaches, techniques, activities, and tasks used to capture the business requirements of a planned solution from the stakeholders and other available sources [
Purpose: Explore, identify and document stakeholder needs. Orienting the requirements toward the project vision. Excluding features that the customer does not want and need
Describes how we work with stakeholders to find out what their needs are and ensure that we have correctly and completely understood their needs.
Task: Prepare for Elicitation
Purpose: Prepare for elicitation by ensuring all needed resources are organised and scheduled for conducting the elicitation activities
Task: Conduct Elicitation
Meet with stakeholder(s) to elicit information regarding their needs
Elicitation activity results
Assumptions, constraints, risks, issues
Documentation based on technique (e.g., interview notes, workshop results, survey responses, etc.)
Task: Document Elicitation Results
Purpose: Record stakeholder info for use in analysis.
Outputs: Stated requirements
Task: Confirm Elicitation Results
Purpose: Play back the requirements to validate that the stakeholder’s intentions have been correctly captured and understood.
Outputs: Validated stated requirements
Reviewing existing documents
Reusing a specification from a previous project
Conducting workshops to refine the requirements after each iteration
Requirements Elicitation should apply to enterprise requirements as well as user or customer requirements.
What is a stakeholder
Any person involved in, or with an interest in, a project
Stakeholders on the vendor side
Business and System Analysts
Developers and Architects
Testers and Quality Assurance staff
Installation and Operations personnel
Stakeholders on the customer side
Customer representatives (i.e., “Business”)
End users (from the customer company)
Installation and Operations personnel
External stakeholders may be:
End users who are not a part of the customer’s organization
Other organizations (e.g., regulatory entities)
Stakeholder Identification Problems
A lack of understanding of the real operators of the business processes in the organization
Unclear definition of responsibilities within the customer’s organization
Excluding stakeholders who are not clearly and directly related to the process
Incomplete analysis resulting in missing processes and activities, and the related stakeholders
Business Analysis Communication Planning
The main purpose of planning the Business Analysis communication is to define how to receive, distribute, access, update and escalate information to and from the project stakeholders, as well as how to organize the schedule and structure of the communication within a project.
Business Analysis is the starting point for designing and implementing a software solution. Its deliverables are inputs to many other project phases and processes, such as establishing the system architecture that will allow meeting the business goals, creating detailed functional and non-functional system specifications, and planning and executing QA activities.
Outputs from the Business Analysis are also inputs to system acceptance testing, which is the final check before the production release.
System acceptance testing is conducted to verify that the software is working as expected, and is needed in order to realize its goals (i.e., improving efficiency of performing the business process
BA provides info to the following
Project management (scope planning, scheduling, and estimating development and testing)
Design (system specification and architecture)
Common methods of communication include:
Factors to be Considered
Type of project
Common BA techniques
CATWOE (Clients, Actors, Transformation, Worldview, Owner, Environmental constraints)
Data Flow Diagrams
PESTLE (P for Political, E for Economic, S for Social, T for Technological, L for Legal and E for Environmental)
MOST (Mission, Objectives, Strategies, Tactics)
Scenarios and Use Cases
Principles for Successful Requirements
Understand the top level critical objectives
Think stakeholders, not just users and customers
Focus on the required system quality, not just its functionality
Quantify quality requirements as a basis for software engineering.
Don’t mix ends and means
Capture explicit information about value.
Ensure there is “rich specification”; requirement specifications need much more information than just the requirement itself.
Carry out specification quality control (SQC).
Consider the total lifecycle and apply systems-thinking, not just a focus on software
Recognize that requirements change; use feedback and update requirements as necessary.
Acceptance and Evaluation Criteria
Acceptance criteria are used to define the requirements, outcomes, or conditions that must be met in order for a solution to be considered acceptable to key stakeholders. Evaluation criteria are the measures used to assess a set of requirements in order to choose between multiple solutions
Define measures of value attributes to be used for assessing and comparing solutions and alternative designs
Measurable and testable criteria allow for the objective and consistent assessment of solutions and designs
Acceptance criteria describe the minimum set of requirements that must be met in order for a particular solution to be worth implementing. They may be used to determine if a solution or solution component can meet a requirement.
Acceptance criteria are typically used when only one possible solution is being evaluated, and are generally expressed as a pass or fail
Valuation criteria define a set of measurements which allow for ranking of solutions and alternative designs according to their value for stakeholders.
Attributes that cannot be measured directly are evaluated using expert judgment or various scoring technique
~ Value attributes ~
are the characteristics of a solution that determine or substantially influence its value for stakeholders
represent a meaningful and agreed-upon decomposition of the value proposition into its constituent parts, which can be described as qualities that the solution should either possess or avoid
ability to provide specific information
ability to perform or support specific operations
performance and responsiveness characteristics
applicability of the solution in specific situations and contexts
availability of specific features and capabilities
usability, security, scalability, and reliability
~ Assessment ~
In order to assess a solution against acceptance or evaluation criteria, it must be constructed in a measurable format
Evaluation criteria provide a way to determine if features provide the value necessary to satisfy stakeholder needs.
The criteria are presented as parameters that can be measured against a continuous or discrete scale.
Acceptance criteria are expressed in a testable form
Acceptance criteria are presented in the form of statements which can be verified as true or false. This is often achieved through user acceptance testing (UAT)
Agile methodologies may require that all requirements be expressed in the form of testable acceptance criteria
Acceptance criteria are necessary when the requirements express contractual obligations
Acceptance criteria provide the ability to assess requirements based on agreed-upon criteria
Evaluation criteria provide the ability to assess diverse needs based on agreed-upon criteria, such as features, common indicators, local or global benchmarks, and agreed ratios
Evaluation criteria assist in the delivery of expected return on investment (ROI) or otherwise specified potential value
Evaluation criteria helps in defining priorities
Acceptance criteria may express contractual obligations and as such may be difficult to change for legal or political reasons
Achieving agreement on evaluation criteria for different needs among diverse stakeholders can be challenging.
What is a business analyst?
A person responsible for:
identifying the business needs of the customer (external or internal) and other stakeholders
determining solutions to business problems
BA activities include identifying, analyzing, developing and managing the requirements.
Business Analyst is not responsible for determining the solution implementation (creating the product’s design)
The Business Analyst acts as a bridge between the customer and other stakeholders (e.g., the project team), identifying, negotiating and achieving a consensus between the needs of the various representative individuals and groups.
Why is Business Analysis Necessary?
Problems with requirements can cause projects to fail. In most cases those problems are caused by poor or incorrectly conducted Business Analysis (especially Requirements Engineering, a part of the Business Analysis knowledge area).
Ambiguous, under-specified, unclear, impossible, contradictory business requirements
Instability of the requirements (frequent and uncontrolled changes in requirements)
Poor translation of the business needs to requirements (incomplete, inconsistent, or not measurable requirements)
Unclear objectives of the initiative
Overly formal wording
Gold plating (adding unnecessary scope)
Insufficient user involvement
Overlooked user classes
Consequences of low quality BA
Problems during during scope definition
Unclear requirements, or low quality business design of the solution, can lead to confusion and questions regarding the intended software product or process solution
risk of the project’s failure increases
Requirements are imprecise
Requirements are ambiguous
Requirements are contradictory
Requirements do not fulfill the agreed criteria
Requirements are missing
Business processes and artifacts are not covered by requirements or are described incompletely
All stakeholders are not identified
Business goals or needs are not identified causing the designed solution to fail to meet the organization’s needs and not achieve the business goals
Common reasons for neglecting BA
Exclusive focus on fast results
Exclusive fixation on costs
Perceiving documentation or the analysis and understanding of the business processes within an organization as a cost, not an added value
Requirements Elicitation is the collection of activities, approaches, tools and techniques for capturing the requirements for a planned software system (or other business solution) from the stakeholders\
Traceability is an association that exists between different types of requirements and the following items:
Requirements (mapping the higher level requirements that defined the needs and features to the more detailed requirements)
Detailed requirements to design models
Detailed requirements to test cases
High level requirements to test cases
Requirements to release/code branch/version
Allows BA to ensure all business requirements have been met.
Important from the change management perspective, to determine the impact of a change on the system or process
For the testers and developers, traceability ensures that the requirements coverage has been achieved
What is Enterprise Analysis?
Purpose: Identify and propose projects that meet strategic needs and goals.
Task: Identifying business processes performed in the organization
Purpose: Evaluate the internal and external environment
Conducting feasibility studies to determine the optimum business solution
Define/refine current/future business architecture
Assess the current state of technology (infrastructure and applications)
Fully define business problem/opportunity
Output: Defined Problem/Opportunity
Task: Determine Solution Approach
Identify potential solutions
Analyze feasibility of options
Recommend viable business solution
Validate with decision makers
Output: Solution Approach
Task: Define Solution Scope
Projects inevitably struggle at some point or the other if the scope is not defined properly
Solution scope may be determined using the following techniques
Work Breakdown Structure (WBS) - a decomposition of the work that is required to complete a project, and accomplish the business objectives
Product Breakdown Structure (PBS) - a decomposition of the components of the product
System Interface Analysis - a definition of the work required to integrate the new solution into the existing business and technical environments
Product Breakdown Structure
Output: Solution Scope
Task: Develop the Business Case
Define project objectives and expected business benefits
Develop project scope
Estimate time, cost, resources
Analyze cost vs. benefit
Inputs: Business Architecture, Business Goal(s), Defined Business Problem/Opportunity Solution Scope
Outputs: Business Case
Solution Assessment and Validation
How to assess proposed solutions to determine which solution best fits the business need, identify gaps and shortcomings in solutions, and determine necessary workarounds or changes to the solution
How we assess deployed solutions to see how well they met the original need in order to enable businesses to assess the performance and effectiveness of projects.
Purpose: Assess solutions to ensure that strategic goals are met and requirements are satisfied.
Task: Assess Requirements Coverage
Purpose: Determine how well possible options for solution designs will meet the requirements. The assessment may include a recommendation of a particular solution, rejection of all solutions, or an assessment of possible trade-offs.
Examples: RFI/RFP responses, Internal designs, Manual procedures
Inputs: Solution Design Option(s)
Outputs: Solution Design Assessment
Task: Allocate Requirements
Purpose: Allocate requirements among releases and/or solutions components. Ensures that the possible release options are designed in a way to maximize the possible business value given the options and alternatives generated by the design team.
Allocate requirements to hardware, software, manual procedures, etc.
Recommend the release/delivery strategy
Understand trade-offs between different implementation approaches
Inputs: Solution Design, Validated Requirements
Outputs: Allocated Requirements
Task: Determine Organizational Readiness
Determine organizational readiness to effectively operate the new solution
Conduct organizational readiness assessment
Recommend ways to optimize the organizational deployment
Outputs: Organizational Readiness Assessment, Organizational Change Recommendations
Task: Validate Solution
Validate the verified and deployed solution meets the business need
Define acceptance criteria (including what level of conformance to requirements is acceptable)
Identify defects/shortcomings (this should be distinguished from functional testing)
Define corrective actions
Validate corrective actions
When a problem is identified with the deployed solution determine what is the most appropriate response
Outputs: Validated Solution, Defect Impact Analysis, Validated Corrective, Actions
Task: Evaluate Solution
Assess the value of the solution as deployed to the business (to determine if the original goals are met).
Compare actual vs. expected costs and benefits.
Outputs: Cost/Benefit Analysis
Stakeholder Identification Techniques
Investigating the business domain
Identifying owners of the business processes
Analyzing the structure of the customer’s organization
Exploring the target market of the customer’s organization
Analyzing relationships with external organizations (suppliers, etc.)
Stakeholder Needs and Expectations
Different stakeholders may have different needs and expectations regarding the planned solution. It is very important to identify all the stakeholders and their needs, and to find a common understanding of the purpose of a solution, in order to avoid the situation where the final product may meet the requirements of only a selected group of stakeholders.
Ensure that the features to be implemented will not conflict with the requirement of other stakeholders
One of the responsibilities of a Business Analyst is to identify all the stakeholders and define their requirements and expectations
Determines the initial scope and requirements of the system
Business Case Definition
Provides the reasoning for initiating a project
Describes a justification for the project in terms of the value added to the business as a result of the project outcomes, in comparison to the cost of developing the new solution
May be in form of
Topics may include
Information about the opportunity (market trends, competitors)
Qualitative and quantitative benefits
Estimates of cost and time to breakeven
Cash flow consequences of the action, over time, and the methods used for quantifying benefits and costs
The impact of the proposed project on the business operations or business process
The impact of the proposed project on the technology infrastructure
Constraints associated with the proposed project
Alignment with priorities established by the business
Procedure of Building the Business Case
Identify and quantify the benefits
Identify and quantify the costs
Prepare the Business Case
Define the procedures that will be used to measure the costs and benefits
Follow common standards and guidelines
Each requirement must be unambiguous, precise, and understandable
Superfluous information should be avoided
Templates should be used as an aid
Models and diagrams should be used to make the specification document clear and more understandable for readers.
Formal graphical notation should be used as a method for presenting complex requirements, dependencies, and relationships
A requirements document may include
Purpose of the product
Limitations and assumptions
When creating a requirements document, the Business Analyst should remember that requirements specifications must be complete, consistent, modifiable, and traceable [Wiegers].
Trivialities - Lengthy descriptions of commonly known issues should not be included
Information out of scope
Thinking in solutions - The requirements specification should discuss the problem to be solved not the technical design of the solution
Modeling is a way of expressing requirements by representing parts, or the whole, of the proposed solutions
Way of presenting complex requirements and relationships in the form of a model, especially some graphical form such as diagrams, helps ensure the solution is understood by other stakeholders
Easier to read and comprehend than written text
Not mandatory but very helpful in big projects
Can skip modeling in the following situations
The solution is fully understood by the stakeholders and is easy to implement.
The requirements are mostly non-functional and difficult to express in the form of a model
The problem domain is well known
The solution is dedicated to use by very few people
The scope is declared as constant and there is a low probability of changes in the scope resulting from future requirements or needs.
model representation would be less understandable by the key stakeholders than written text
Benefits of modeling
simplified expression of real processes
describe a complex system in the most clear and unambiguous way.
Models present the whole system and its context in a single diagram and therefore help to look at the problem from the overall perspective.
UML notation to express requirements as use case diagrams, activity diagrams, component diagrams, state machine diagrams, etc.
Using prototyping as a technique of GUI modeling
Using SysML notation to develop specifications, analysis, design, verification and validation documentation for systems and systems-of-systems. The specifications may include hardware, software, information, processes, personnel and facilities.
Quality criteria for business process models
Correctness (syntactic and semantic correctness)
Relevance (no irrelevant details)
Economic efficiency (designed for a particular purpose)
Clarity (understandable by the audience)
Comparability (based on the same modeling conventions within and between models)
Systematic design (contains well-defined interfaces to other types of models)
The goal of a Business Analyst is to provide business solutions to business issues by assessing business problems, and identifying and analyzing root causes.
The success of Business Analysis is determined by the benefit that the solution provides to the business either in terms of savings in costs, improvement in productivity, and/or increase in customer satisfaction.
To be able to provide a business solution that provides a measurable benefit to the organization, the Business Analyst must have knowledge of the business domain.
Domain knowledge makes it easier for the Business Analyst to connect and communicate with Business Users.
Domain knowledge makes understanding and analyzing business issues easier
Lack of domain knowledge may lead to delays in providing the solution, since the business process and business rules must first be understood
Tools and Techniques of Facilitation
Applying engagement strategies
Generating and organizing data
Applying SWOT analysis
Root cause analysis
Managing conflicts tips sheet
Focus group framework
Process Improvement supports the introduction of change into the current process in order to improve quality, reduce costs and/or accelerate schedules
Supporting Process Improvement is one of the tasks of a Business Analyst.
The Business Analyst models and analyzes business processes used within an organization in order to discover any ineffective elements.
Manually re-design processes on the basis of experience and domain knowledge with the goal of eliminating bottlenecks and making the execution times shorter and more efficient
Introduce tools, including software, to optimize the business processes in the organization (e.g., SAP, ERP, CRM software)
Simulate and optimize processes
Adopt a selected methodology or strategy
Business process improvement
Business process reengineering
Capability Maturity Model Integration/Capability Maturity Model (CMMI/CMM)
Just In Time manufacturing
Process Improvement and Management (PI&M)
Total Quality Management (TQM)
BA Knowledge Areas
Business Analysis Planning and Monitoring (Orange)
Enterprise Analysis (Dark Green)
Elicitation (Light blue)
Requirement Analysis (light pink)
Solution Assessment and Validation
Requirements Management and Communication
Common Objectives of Business Analysis
Collect and document the requirements
Design business solutions to resolve the business problems
Assist in the timely completion of the project by providing accurate requirements identification and analysis
Improve efficiency by increasing the quality of requirements identification and analysis and therefore reducing the need for rework and fixes in the later stages of the project
Business Analysis influences other project areas
Significant impact on project management (especially scope and time management)
Design – Business Analysis determines the required business architecture and scope of the solution
Development – The Systems Analyst (who determines detailed requirement specifications) uses the Business Analysis to determine what has to be implemented.
Testing and other Quality Assurance activities – Products of Business and Systems Analysis are a basis for testing
A Business Need describes the business problem or opportunity which the Business Analyst must understand and analyze in order to recommend appropriate solutions
before a project starts, the Business Need (understood as a problem or an opportunity) and Business Case (understood as costs vs. benefits) are defined, either formally or informally.
for the projects that help the organization reach its vision, strategic goals, and business objectives.
Business Analysts are often supported by Project Managers and Product Managers in defining Business Needs
One of the responsibilities of a Business Analyst is to cooperate with the person or group requesting the project, including users or proxy users, and to help them articulate the real need.
What is a business process?
set of activities aimed at producing a specific output for a particular customer or market.
focuses on how the work is done within an organization, the way of organizing work, activities, relationships and the dependencies between them. A process can be considered as the ordering of work activities across time and place, with a beginning, an end, and clearly defined inputs and outputs [
A business process must have the following characteristics
Has a goal
Has specific inputs
Has specific outputs
Has a number of activities that are performed in some order
Affects at least one organisational unit
Creates value for the customer (both internal and external)
Identification of processes allows the Business Analyst to understand the organization’s goals,
Helps determine the activities and the flow required to achieve future planned business and strategic goals
Identification of business processes helps find possible gaps and ineffective parts of the process, which may then be improved via process optimisation
If business processes are not established and understood, then the organization may have a low maturity level, which makes measuring and controlling processes very difficult. In addition, there are likely to be significant problems with the definition of the business goals and needs.
BA in Phases of the Software Life Cycle
Identifying and evaluating the current business processes in an organization (“as is” analysis)
Gathering initial requirements for the needed business solution (“to be” analysis)
Creating and analyzing the business case
Conducting a feasibility study
Preparing ideas for the business solution
Identifying and documenting business requirements on a more detailed level
Supporting the Systems Analyst in preparing the detailed system specifications (e.g., covering such items as data, mapping, integration issues, user interfaces)
Validating the proposed software design with the customer and other stakeholders
Managing any requirements changes
Supporting the development team during implementation (e.g., clarifying issues related to the requirements, validating business rules to be applied in the code)
Validating the evolving solution according to the intended requirements and needs (when possible)
Supporting testers in preparing test cases and test scripts at the business level and validating the resulting work products
Managing any required changes to the requirements (resulting from detected defects, regulatory or legal changes, needs for new or extended functionality, etc.)
BA role varies
verifying test results
resolving issues related to defects or gaps in the requirements
Participating in the preparation of test cases for User Acceptance Testing
Supporting the acceptance testers by answering questions during test execution
BA Planning and Monitoring
The parameters which are defined and set during the planning phase should retain their validity throughout the project phases and it becomes the responsibility of the business analyst to perform the activities classified under this knowledge area precisely.
Identify the stakeholders
Identify stakeholders who may be impacted by a proposed initiative or who share a common business need.
determining appropriate stakeholders for the project or project phase, and analyzing stakeholder influence, authority (approve, sign off, veto), and project attitude.
Outputs: Stakeholder list, Stakeholder roles and responsibility designation
RACI matrix (also known as RASCI matrix) plays very important role in this process.
Scope of the tasks and the dependency can be defined easily
estimates related to cost, timings and resources
Determine what information the various stakeholders need to be provided about the results of business analysis and the forms it should take (verbal, written, etc). It includes considerations for, as well as constraints, impacts, durability and trade-offs of different communications media
Communication plays very important role in any stage of project life-cycle and in order to avoid ambiguity or conflicts in the requirements and end results, the communication should be precise and controlled.
Each stakeholder should understand the details of the requirements
WHAT, WHO and WHEN are the important questions related to communication
Monitoring BA work
metrics that can be used for monitoring business analysis work are determined.
helps in improving future business analysis plans
performance measures, reporting and corrective actions
Plan Business Analysis Activities
Determine which activities are required to define the solution to a business problem, how those activities will be carried out, the work effort involved, and an estimate of how long the activities will take.
Determine tasks in the Knowledge Areas:
Identifies task dependencies
Develop estimates for BA work (time, skill level, complexity of tasks, etc.)
Inputs: Stakeholder list, Stakeholder roles and responsibility designation, Organizational Standards
Outputs: Business Analysis Plans for each KA
Plan Requirements Management Process
Describes how to determine the appropriate requirements process for a particular initiative
Consider whether and how requirements are changed
Which stakeholders need to approve
Who will be consulted on, or informed of changes,
includes the approach to requirements traceability and determining which requirements attributes we will capture
Output: Requirements Management Plan
RASCI: R- Responsible (does the work), A- Accountable (decision maker, only one), S- Support (provides support during any phase of lifecycle), C- Consulted (consulted prior to the work and provides input), I- Informed (informed about the work progress).
Requirements Management and Communication
How we manage conflicts, issues and changes and ensure that stakeholders and the project team remain in agreement on the solution scope
Recognise that communication takes places throughout all knowledge areas and is important for managing requirements
Manage the approved solution and requirements scope
Ensure stakeholders have access to business analysis work products
Prepare and communicate requirements to stakeholders
Task: Manage Solution and Requirements Scope
Baseline and manage changes to business case, solution and requirements
Approve requirements (according to the approval authority stated in the Requirements Management Plan)
Control multiple versions of requirements work products
Manage requirements conflicts and issues
Inputs: Stakeholder roles and responsibility designation, Requirements, Requirements management plan
Outputs: Approved Requirements, Decision Record
Task: Manage Requirements Traceability
Trace requirements (update and maintaining relationships between requirements components)
Perform impact analysis when changes are requested and supply this information to the change control process
Support the allocation of requirements to the solution in Solution Assessment and Validation.
Outputs: Traced Requirements
Tasks: Maintain Requirements for re-use
Select which implemented requirements will be maintained after solution implementation
Name the responsible party who will maintain the requirements
Facilitate ongoing use of requirements for impact analysis and solution maintenance
Facilitate re-use of requirements on related projects to encourage enterprise consistency of business models
Inputs: Implemented requirements
Outputs: Maintained/re-used requirements
Task: Prepare Requirements Package
Determine appropriate format for requirements, Create a requirements package
Outputs: Requirements package (e.g., executive summary, formal documentation, RFI, RFP, etc.)
Task: Communicate requirements
Interaction with all stakeholders before, during and after projects.
Interaction with solution team to assure that requirements are correctly understood and implemented
Change Management process
Identifying a potential change
Requesting new functionality
Analyzing the change request
Evaluating the change
Planning the change
Implementing the change
Reviewing and closing the change request
Potential changes might be a result of:
A defect found in the code, documentation or requirements
System improvement efforts
External changes (regulatory, legal, etc.)
New or changing requirements (resulting from new regulations, changes within the business domain, new features requested by the users, etc.)
Business process improvement initiatives
When the need for a change appears, there should be a Change Request raised by a stakeholder requesting new or modified functionality. Important elements of a change request are a unique identifier, the author, the deadline (if applicable), an indication whether the change is required or optional, the change type, and an abstract, or description, of the proposed change
All changes should be tracked in a Change Log or Change List
Changes should be managed by the Change Control Board (CCB). The CCB is not allowed to submit, approve, reject, or implement changes without discussion with the other stakeholders.
may have significant impact on other elements of the system, such as components, interfaces, functionality, etc.
Impact analysis should be performed
Impact analysis includes analysis of the changes needed in the project schedule or budget that would be necessitated if the change were to be implemented
The planning of change implementation includes:
Updating plans as needed depending on the phase of the project (e.g., Project Plan, Development Plan, and Test Plan)
Updating business and system documentation (e.g., specifications, architecture design, user manuals)
Updating test cases and test scripts
Implementing the change (coding)
Testing by vendor or/and customer test team
Deploying the change to the production environment
Requirements can be organized (structured) into packages. This packaging conforms to the boundaries (limitations) and solution scope established during Enterprise Analysis and helps to further define those boundaries
BA decomposes the problem model to make each requirement more detailed
Ensure that the model correctly reflects the boundaries for the business problem
Ensure proper level of detail is achieved
Types of decomposition
Goals are business requirements
Goal decomposition helps to ensure the solution will satisfy stakeholder’s needs
Feature list decomposition
A feature is a service that the solution provides to fulfill one or more stakeholder need
an abstraction of the solution of the problem expressed at a high-level
A feature is developed into completely described functional and supplemental requirements
breakdown of a list of items into classifications or groups based on the function each item performs or the use it provides
identifies the high-level functions of the proposed solution, or the organization itself, and then breaks them down into sub-processes and activities.
usually performed by a Systems Analyst
Quality Assurance is a process of systematic monitoring and evaluation of the various aspects of a project or solution. The goal is to maximize the probability that the solution has achieved a desired standard of quality
Quality Criteria for Requirements
Does not determine solution
One of the most common techniques for requirements’ quality control is the use of checklists.
Acceptance and Evaluation Criteria
BA necessary skills
Working knowledge of technology
Understanding of engineering principles
Ability to apply financial principles to feasibility studies
Project management capabilities
Understanding of organizational behavior
Ability to negotiate to obtain data
Ability to negotiate with stakeholders to implement projects
Communication and writing skills
Ability to communicate with all levels of management
Ability to communicate with stakeholders of various knowledge levels
Precision in articulating ideas and thoughts
Ability to relate with line workers
Good technical writing skills
Strong communication skills in all forms (verbal, non-verbal, written, etc.)
Public speaking skills
Facilitation can be defined as a process of enabling groups to work cooperatively and effectively. Facilitation provides leadership
Facilitation serves to improve the following skills
Building team and community
Evoking wise democracy
Building personal effectiveness
facilitator is a person who contributes structure and process to interactions so that groups are able to function effectively and make high-quality decisions. The facilitator’s goal is to support others and enable them to achieve high performance
Tasks and activities
Helping the group to define its goals and objectives
Providing processes to support members of the group to help them use their time effectively and to make high-quality decisions
Guiding group discussions to ensure objectives are met, and noting any ideas and concepts raised by members during the discussion
Supporting members of the group in assessing their current skills and building new skills
Using consensus to enable the group to make decisions
Managing conflicts using a collaborative approach
Helping the group to communicate effectively and to access resources needed to make decisions
The facilitator must always stay neutral, listen actively and ask questions that allow the group to identify and collect ideas and concepts. One of the facilitator’s tasks is to note and summarize all ideas raised by the members of the group.
Processes ideas from people
Shows a natural interest
Empowers the group
Connects with the group quickly
Focuses on the business not on personal solutions
Negotiates between parties
Understands group dynamics
Helps the group to listen and draw logical conclusions
Manages people’s expectations
Understands and explains the process