Create your own awesome maps

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account?
Log In

IQBBA® Certified Foundation Level Business Analyst (CFLBA) study guide mind map by Mind Map: IQBBA® Certified Foundation Level
Business Analyst (CFLBA) study guide mind
map
5.0 stars - 34 reviews range from 0 to 5

IQBBA® Certified Foundation Level Business Analyst (CFLBA) study guide mind map

IBAQB® is a registered trademark of the International Business Analysis Qualifications Board. Trademarks are properties of the holders, who are not affiliated with mind map author.

Process Improvement

Process Improvement

Process Improvement is a method to introduce process changes to improve quality, reduce costs or accelerate schedules

Improving the business process, Approaches, Manual re-designing of the process on the base of experience and domain knowledge, Introducing tools allowing to optimize the business processes in the organization, Process simulation and optimizing, Adopting selected methodology or strategy

Triggers of Process Improvement, Process Improvement may follow a specific methodology or strategy, Benchmarking, Business Process Improvement, Business process reengineering, Capability Maturity Model Integration / Capability Maturity Model, ISO 9000, IT Governance, Just In Time manufacturing, Lean manufacturing, Performance improvement, Process management, Process improvement and Management (PI&M), Six Sigma, Total Quality Management

Business Process Improvement, BPI is a systematic approach to help an organization optimizing its underlying processes to achieve more efficient results, The goal - radically change the performance of an organization, No improvement by a series of small incremental changes

Methodology of BPI, Define the organization's strategic goals and purposes together with the existing structure and processes (AS-IS), Determine the organization's stakeholders and identify, What outcomes adds value to the organization's objectives, What are the best ways to align its processes to achieve those outcomes (TO-BE), Re-organize the business processes to realize the goals and to meet the new objectives, Supported by the tools available within the BPI methodology

Roles in BPI, Business Leader, Responsible for developing business plans (including strategic plans), Responsible for developing resource plans, Process Owner, Designs processes, Necessary to achieve the objectives of the business plans created by the Business Leaders, Responsible for the creation, update and approval of documents to support the process., Procedures, Work instructions / protocols, Operational Manager, Organizes the resources and processes in order to achieve the objectives of the business plans created by the Business Leaders, Instructs the Process Operators how to perform the processes, Process Operator, Performs the processes necessary to achieve the objectives of the business plans created by Business Leaders, Ensures the realization of a process meets performance objectives, Ensures the products of the processes meet the specifications, The roles has different responsibilities but they work together!

Process simulation and redesigning

Business Process Simulation, Business Process Simulation (BPS) is a part of Business Process Management (BPM), BPS allows simulating, The execution of business processes, Parameters over time, Simulation is based on process models, The purpose, Understand, analyze and design (or re-design) business process models with respect to performance metrics, Evaluation and comparing the (re)designed processes and implementing the best choice

Process models, The process models must represent, The specific elements of the business process, The attributes of the business process, Execution time, Resource usage, Costs, Running the simulation allows checking how the process is realized, BPS Procedure, Mapping the business process onto a process model, Identification of the sub processes and activities, Creating the control flow definition, Identification of the resources and assigning them to the activities, Defining performance characteristics, Running the simulation, Simulation should be executed for several sub runs, A simulation is run in a specific tool, Tools show an animated picture of the process flow or real-time fluctuations in the key performance measures

Tools and Techniques

Modeling tools

Modeling tools allow to, Link requirements in models, Create graphical representation of requirements, Represent relations between requirements, and between requirements and other artifacts, Establish and maintain traceability, Design the overall structure of the system

Business Analysis techniques

Solution Validation

Assessment

Validation

Requirements Analysis

Requirements Organization

Requirements are organized (structured) into packages, The purpose of organizing requirements, To determine the solution boundary, To determine the solution scope, To define the structure of requirements, The problem model is decomposed to make each requirement more detailed and to ensure that the model correctly reflects the boundary for the business problem

Decomposition, Goal decomposition, Allows ensuring the solution will satisfy stakeholder's needs, Breaks down high-level stakeholder goals into lower-level goals, Lower-level goals have measurable objectives, Goals are business requirements, Feature list decomposition, Feature is a service that the solution provides to fulfill one or more stakeholder needs, Feature is an abstraction of the solution of the problem expressed on high-level, Feature is developed into completely described functional and supplemental requirements, Functional decomposition, Functional decomposition is a breakdown of a list of items into classifications or groups on the basis of the function each item performs or is used for, Identifies the high-level functions, Breaks them down into sub-processes and activities, To analyze the processes in detail, To ensure proper coverage of all major processes, Functional decomposition is used to, Hierarchically decompose a system into functional components, Hierarchically decompose a business process into sub-processes, Provide a definition of all the business functions and sub-functions identified as system requirements, Levels of detail for functional decomposition, Enterprise Level of Detail, The root of the decomposition diagram contains, The name of the organization, A major function within an organization, The second level represents major business functions, Planning, Execution, Control, Conceptual Level of Detail, Processes identified at this level typically reflect application systems or sub-systems, Marketing, Sales, Finance, The lowest level functions on the Enterprise Level Chart are decomposed into the next level of detail, This identifies the major business processes needed for each function, Logical Level of Detail, Processes are decomposed into the lowest level of detail., At this level all the processes within the scope of the project are identified., This level identifies particular functions

Modeling and Specification

Model, Model is a representation of an object, System model is a conceptual description and representation of the system, Model describes, The structure of the system, Dependencies and relationships between the system's objects system model is a, Textual elements, Matrixes, Diagrams, Reflects the relationships and dependencies between requirements realizing identified business needs

Modeling, Modeling is a way of expressing requirements representing parts or the whole of the proposed solutions, Modeling is helpful but not always necessary, The organization may skip modeling when:, The solution is fully understood by the stakeholders, The solution 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, The model representation would be less understandable by the key stakeholders than written text, Advantages of Modeling, Models allow to focus on the important aspects and areas of the solution, Models describes complex system in more clear and unambiguous way, Models are more readable and clear than written text, Looking at the problem from the overall perspective, Modeling Techniques, Archimate, BPMN, A graphical notation that depicts the steps in a business process, The end to end flow of a business process, The notation is designed to, Coordinate the sequence of processes, Coordinate the messages that flow between different process participants, BMPN diagrams provides a view on the various processes performed within an organization, Help in understanding the organization's performance, Allows effective requirements analyzing and modeling, Quality criteria for business process models, Systematic design, Correctness (syntactic and semantic), Relevance, Economic efficiency, Clarity, Comparability, DSL, GUI modelling, Allows to design the user interface, Allows stahekolders to verify the visual side of the solution and the way of meeting requirments, Supports development works - allows to avoid misinterpretation, Prototyping is the activity of creating prototypes of software application, its components or modules or single screens, Common techniques, Storyboarding, Card sorting, Protytyping, OBASHI, SysML, A general purpose modeling language for systems engineering applications, A dialect of UML, Supports, Specification, Analysis, Design, Verification and validation of a broad range of systems and systems-of-systems, Structure diagrams, The Block Definition Diagram (BDD), replacing the UML2 class diagram, The Internal Block Diagram (IBD), replacing the UML2 composite structure diagram, The Parametric Diagram, a SysML extension to analyze critical system parameters, The Package Diagram remains unchanged, Dynamic diagrams, The activity diagram has been slightly modified in SysML, The sequence, state chart, and use case diagrams remain unchanged, The requirements diagrams is a SysML extension, UML, UML combines techniques from, Data modeling (entity relationship diagrams), Business modeling (work flows), Object modeling, Component modeling, UML diagrams:, Static (or structural):, Class diagrams, Composite structure diagrams, ..., Dynamic (or behavioral):, Use case diagrams, Sequence diagrams, Activity diagrams, State machine diagrams, ...

Defining Assumptions and Constraints

Assumptions and constraints identify aspects of the problem domain that are not functional requirements of a solution, and will limit or impact the design of the solution

Constraint, A constraint is a requirement that explicitly and intentionally tries to directly restrict any system or process, Limitations on, Engineering process System's operation Lifecycle

Types of constraints, Business constraints, Financial or time restrictions, limits on the number of resources available, skills of the project team or any other organizational restriction, Limitations on the projects flexibility to implement requested solution, Technical constraints, Related to the architecture of the solution (hardware and software platforms, programming language or technology, supporting software), Technical constraints include also: database size, resource utilization, message size, software size, maximum number of and size of files

Example constraints, Hardware or software environment, End-user environment, Availability or volatility of resources, Standards compliance, Interoperability requirements, Interface / protocol requirements, Data repository requirements, Data distribution requirements, Security requirements, Memory limitations, Performance requirements, Network communications

Assumption, Assumptions are things that are believed to be true but have not been confirmed, Assumptions are unproven conditions, which if not true at some defined point in time, would affect the initiative / solution, Assumptions often become limitations!, Goal, Assumptions are used to document, Issues identified as true but impossible to verify, Issues identified as true in the current situation that, if they change, can have negative or even destructive impact on the project

Types of assumptions, Business assumptions, The purpose: to inform the project team of key stakeholder expectations, Requirements assumptions, The purpose: to transfer business domain knowledge to the project team

Example assumptions, The back-end system is available, There is no more than 1000 transactions per day, All transactions are processed in EURO

Verification and Validation

Validation, Validation is an activity of confirmation by examination and through provision of objective evidence that the requirements for a specific intended use or application have been fulfilled [ISO 9000], Goal, The goal of validation is to ensure that the stated requirements correctly implement the business requirements determined in Enterprise Analysis and Requirements Identification phases

Verification, Verification is a confirmation by examination and through provision of objective evidence that specified requirements have been fulfilled [ISO 9000], Verification ensures that requirements are defined clearly enough to allow solution design and implementation and test preparation to begin, Verification process requires to involve and cooperate closely with, Customer, Users, Project team, Requirements can be stated as verified if, Project stakeholders agreed that the requirements are correctly understood, The requirements were checked with the stakeholders and confirmed as complete description of what has to be implemented, The requirements were stated as of high quality

Quality Assurance

Quality Assurance, Quality Assurance is a process of monitoring the quality of the process or project in order to ensure that minimum level of quality standards is achieved

Quality criteria for requirements, Allocatable, Complete, Consistent, Correct, Does not determine solution, Feasible, Measurable, Necessary, Prioritized, Testable, Traceable, Unambiguous, Understandable

Examples of QA techniques, Checklists, A common technique for quality control, A standard or customized set of quality elements to validate the Requirements Specification (or other artefact), Reviews, A review is an evaluation of a product or project status to ascertain discrepancies from planned results and to recommend improvements [IEEE 1028], Examples, Management review, Informal review, Technical review, Group discussion focused on achieving consensus on the technical approach to be taken, Inspection, Visual examination of documents to detect defects, Walkthrough, Step-by-step presentation by the author of a document in order to gather information and to establish a common understanding of its content, Peer review, A review of a work product by colleagues of the author of the product for the purpose of identifying defects and improvements, Testing

Requirements Elicitation

The concept of Requirements Elicitation

Business Requirements Elicitation, Business Requirements Elicitation is a set of approaches, activities, tasks and techniques allowing to collect the business requirements of a planned solution, from the stakeholders and other available sources

The purpose of Business Requirements Elicitation, Identification of:, Desired functions, Attributes, Quality characteristics, Limitations and expectations, Requirements resulted from external regulations, norms etc., Orientation of the requirements toward the project vision, Establishing the finał scope, Establishing business design of the system, Excluding functions that the customer does not want and need

Techniques for Requirements Elicitation, Q.uestionnaires, What is it?, Eliciting information from many people, anonymously, in a relatively short time., Quastionnaire can collect information about:, Customers, Products, Work practices, Attitudes, 2 types:, Closed, The respondent is asked to select from available responses., Used if the issues are know., Open-ended, The respondent answes the questions in free way., Used if there is range of users responses is pretty well understood., Process:, 1. Prepare the questionnaire, 1. Define the purpose / target group, 2. Choose the questionnaire type, 3. Select the sample group, 4. Determine if individual interviews are needed, 5. Determine desired level of response, 6. Select the distribution and collection methods, 7. Write the survey questions, 2. Distributethe questionnaire, 3. Communicate the results, Questions, The questionnaire should be short., The questionnaire should be easy and fast to complete., Guestion wording must be elear and unambigous., No double questions in a single question., No questions involving negatives., No complex branching structures., No questions that make respondents feel uncomfortable., lnterviews, What is it?, An interview is a systematic approach to elicit information from a person or group of people in an informal or formal setting by asking relevant questions and documenting the responses., 2 types:, Structured interview, A pre-defined set of ąuestions., Unstructured interview, Without any pre-defined questions., Open-ended discussion about what the business expects from the target system., Process:, 1. Opening the interview, 2. Conducting the interview, 3. Closing the interview, 4. Post interview follow-up and review, Self-recording, The user records his own activities (AS-IS)., Documents all steps, inputs and resources needed to complete a task / procedure., The user describes also changes, desires and needs., Advantages:, Low time and work effort on software vendor side, Disadvantages, Highly dependent from the motivation and experience of the user performing self-recording, Customer's representative, A main idea in Agile methods. Allows close cooperation and direct communication with the customer. One of the most effective requirements identification (and validation) method., Assumption:, The representative has adequate knowledge and communication skills., The representative:, Systematically monitors the progress -Verifies correctness of the design, Provides quick feedback and additional information wherever necessary, Identification on the basis of existing documents, Allows to elicit requirements of an existing system by studying available documentation and identifying relevant information., Used to gather details of the AS IS environment for the solution:, Existing business rules, Entities, Attributes, Process:, Prepare the documents, Analyze the documents, Review and follow-up, Review and confirm the selected details with subject matter experts, Obtain answers to follow up questions, Reuse (Reusing the specification of a certain project), Reuse of documentation / solution from previous projects., Requirements specification prepared for previous project can be used in another, similar, project., Shorts the duration of Business Analysis., Important notice:, Only some parts of existing specifications can be used in new project., The documentation to be reused should be checked against the compliance with the current needs., Brainstorming, A way of eliciting many creative ideas for an area of interest., Produces numerous creative ideas about any given "central question" or topic., Promotes diversion type of thinking., Brainstorming to detail identified requirements and find new ones, Brainstorming helps answer specific questions:, What options are available to resolve the problem?, What factors are influencing or constraining the proposed solution?, How should we design the usability of the solution?, How can be the process improved?, Process:, 1. Prepare for Brainstorming, 2. Conduct Brainstorming session, 3. Wrap-up the brainstorming, 1. Discuss and evaluate the ideas., 2. Create a list and rate the ideas., 3. Communicate the results to the team., Field observation, Conducting an assessment of the user's work environment., Studying people performing their jobs-without any interventions!, Observation is usually used:, To document the current processes, When the purose of the project is to enhance or change a current process, 2 types:, Passive / invisible observation, Observing the user working without asking questions., The Business Analyst writes notes about what he/she sees., Waiting until the process has been completed before asking any questions., Active/visible observation, Dialog with the worker., In case of questions, the Business Analyst asks the worker - even if it breaks the routine., The Business Analyst may participate in the work., Apprenticing, Apprenticing is a process of learning from the user his job, The customer teaches the Business Analyst., Master and student approach., The "student" is watching the "master" working., The student is asking questions in case of problems., The masteris explaining the tasks being performed., Useful when the customer is not able to provide full time support of his employees., Overcomes the problem of abstract thinking and expressing the tasks in words, Users can always refer to the actual case and explain things on examples., Workshops (after each iteration), Workshop is a structured way to capture requirements., May be used to scope, discover, define, prioritize and reach closure on requirements for the solution., Its is not a traditional meeting., Focused event attended by key stakeholders and subject matter experts for a short period., Workshop roles, Facilitator, Enforces discipline, Introduces the goals and agenda for the workshop, Keeps the team on track, Facilitates a process of decision making and builds consensus, Scribe (Recorder), Documents the business, requirements elicited, Documents outstanding issues, Participants, Process:, Prepare for the workshop, Conduct the workshop, Post Requirements Workshop wrap-up (done by Facilitator), Prototyping, Helps uncover and visualize interface requirements before the solution is designed or developed, Prototyping to visualize implementation of identified requirements, Focus groups, Used to elicit ideas and attitudes about a specific problem in an interactive group environment, Interface Analysis, Helps to clarify the boundaries of the system, Important notice:, The best results are achieved when mixing some techniques.

Requirements quality characteristics, Functionality, Reliability, Usability, Efficiency, Maintainability, Portability

Requirements Scope Management

Managing requirements scope is considered as managing the list of the requirements of some or all of the following projects, System or component development, Process improvement, Organizational change

Requirements Scope Management, 1. Establishing requirements baseline, 2. Creating a requirements structure for traceability, 3. Identifying impact to external systems and other areas of the project, 4. Identifying changes in the scope resulting from requirements changes, 5. Maintaining scope approval

Establishing requirements baseline

All requirements identified and approved by stakeholders must be baselined

The baseline, Is a base for further system development, A point of reference for any changes in the content / scope of requirements

Creating a requirements structure for traceability, Requirements traceability is necessary for managing changes to the requirements done after the requirements are baselined

Impact to other systems / areas, Identification of all impacts to external systems and other areas of the project necessary to ensure that there is no work outside the baselined list of requirements

Changes in requirements scope affects, Project schedule, Project cost, Project and product risk, Project Resources, External interface to another systems or hardware

Identifying changes in the scope, Requirements are not constant throughout the project's lifecycle, Impact on the project, Minor change -> no impact on the project scope, time or cost, Major change -> may drastically change the project scope, time or cost, Major changes examples, Changing business logic, Changing process flow for critical functionality

Maintaining scope approval, The list of requirements must be approved and baselined, The approved list of requirements is a mutual understanding between the customer and the vendor team about the requirements, Changes in the approved list of requirements must be managed via Change Management procedures

Requirement Traceability

Goals, Scope management, Impact analysis, Coverage analysis, Proof of implementation, Use of the requirement, Defect reports

Traceability, Traceability is an association existing between requirements when more detailed requirements are associated with the higher level requirements (needs and features), Traceability may exist between detailed requirements and both design models and test cases, Traceability between requirements and other project artefacts aIlows to ensure all requirements are met, Representing traceability on UML diagrams

Tool support, Requirements Management software, Storing all requirements of all specifications of a technical system under development, Arranging requirements in structures (specification tree), Linking each one to the "parent" requirement in the higher specification, Requirements are realized into:, Design artefacts, Implementation, Test cases, Artefacts are traced back to the requirements.

Tools, Requirements Traceability Matrix, Track all requirements and check if they are being met by the current process, Assist in the creation of project's documentation, Supports verification process, RTM is created at the beginning of a project, Bi-directional Traceability Matrix, Bi-directional Traceability Matrix between Software Requirements Specification (SRS) and Software Design Document (SDD )

Software, i.e. Enterprise Analyst, i.e. Enterprise Architect, …

Requirements Documentation

Requirements document, A requirements document describes a set of related functional and non-functional requirements, No project deliverable information - constant time, Formalizes the project scope

Purpose of the requirements document, Structuring the requirements, Providing clear and unambiguous explanation of the requirements, A basis for implementation and testing, A basis for requirement management, Documentation is a baseline

Content of a requirements document, Assumptions, Business Process Description (BPD), An executive summary of an initiative, Describes the problem and the proposed solution in high-level terms, Business Requirements Document (BRD), Describes the behavior required of a software application, Primarily describes the business requirements, The target audience is the customer and users, Dependencies, Functional requirements, Introduction, Non-functional requirements, Overall description, Purpose of the product, Regulations, Request for Proposal / Request for Quotation (RFP / RFQ), Distributed to parties outside the organization, Basis for the contracting of solution development services, Risks, Safety requirements Document acceptance, Secrecy clause, Software Requirements Specification (SRS), Also known as a System Requirements Specification, Describes the behavior and implementation of a software application, The target audience is the development team, Stakeholders, Standards, ...

Common Document Formats, Software Requirements Specification (SRS), A description of the problem domain, Decomposition of the problem domain, Description of the functional requirements, Description of the non-functional requirements, Assumptions and constraints affecting the solution, Requirements attributes and traceability information

Construction of a requirement, Describe business justification for the requirement, Identify the business process, Identify the stakeholders, Identify the limitations and assumptions, Describe the context, Describe the requirement, Input, Output, Resources, Quality characteristics (if applicable), Provide the graphical model (if applicable), Describe risks, Provide references

Guidelines for the requirements document, The requirements must be unambiguous, precise and understandable, Superfluous information should be avoided, Templates as an aid to limit language, Models and diagrams makes the document clear and more understandable, Use formal graphical notation to express complex requirements, dependencies and relationships

Common Document Problems, Trivialities, Lengthy descriptions of commonly known issues, Information out of scope, Information without added value to the description of the solution, Thinking in solutions, Description of solutions, Requirement specification determining the technical design, Redundant details, Details unnecessarily complicating the implementation, Implementation details, Lacking rationale, No description of what shall be achieved with the solution (inc. concrete numbers and metrics)

Requirements Communication

Requirements Communication, Requirements Communication includes activities for expressing the output of the requirements analysis and documentation to the stakeholders

Communication, An ongoing and iterative activity, Presenting, Communicating, Verifying, Obtaining approval

The role of a Business Analyst

Communicate requirements in a way allowing all stakeholders to gain the same understanding of a particular requirement

Consider and choose communication approach appropriate for the project

Requirements Communication process

1. Preparing requirements communication Plan

2. Managing requirements conflicts

3. Establishing the most appropriate requirements format

4. Creating requirements package

5. Conducting requirements presentation

6. Performing formal requirements review

7. Obtaining requirements approval (Sign-off)

Requirement acceptance

Requirements should be agreed and accepted by all relevant stakeholders

All requirements must be formally approved

Formal agreement, Starting point for detailed system specification, designing the architecture and other works on the planned system

Stakeholders with the acceptance authority

Business Sponsor

Project Managers

Business Analysts

Architects

Test / QA Manager

Standards

ISO 25000 (ISO/IEC 9126), Defines a quality model with 6 categories:, Functionality, Reliability, Usability, Efficiency, Maintainability, Portability

IEEE 830, Recommended Practice for Software Requirements Specifications

IEEE 1233, Guide for Developing of System Requirements Specifications

IEEE 1362, Guide for Information Technology - System Definition

Major reasons of neglecting Business Analysis

Time praccure

Exclusive orientation towards fast results

Exclusive fixation on costs

Perceiving documentation or analyzing and understanding business processes as a cost, not added value

Business process within an organization not known / understood as a result:

Imprecise, ambiguous, contradictory or missing requirements

Requirements that change

Requirements that do not fulfill the agreed criteria (i.e. quality criteria)

Products of the business processes not known

Stakeholders not identified or identified only pertially

Business goals or needs not identified

The organization needs not satisfied

The business goals not achieved

Common pitfalls in Business Analysis

Bad quality of the requirements and / or business needs:

Incomplete

Inconsistent

Not measurable

Unclear objectives

Communication problems

Language barriers

Knowledge barriers

Vague formulation

Too formal formulations

Ambiguous, overly specified, unclear, impossible, contradictory requirements

Instability of the requirements (frequent changes)

Redundant description of requirements

Insufficient user invelvement

Overlooked user classes

Minimal specification

Business Analyst

"A Business Analyst is a person responsible for identifying the business needs of the customer / stakeholders and to determine solutions to business problems."

source BABOK

“A business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate, and validate requirements for changes to business processes, policies, and information systems.”

The Business Analyst, ensures that the PRODUCT of the project is well-defined (product scope) throughout the project and meets the targeted business needs through expert requirements management, systems analysis, business analysis, and requirements analysis.

Product Scope, "The features and functions that characterize a product, service, or result."

Project Scope, "The work that needs to be accomplished to deliver a product, service, or result with the specified features and functions."

A Business Analyst might start “bridging” further up the stream in terms of business needs and problems and stop “bridging” at the functional requirements level or at WHAT the system will do and leave it to a systems analyst or a senior developer to determine HOW to do it.

Business Analyst Role

A liaison among stakeholders

Identify, analyze, communicate and validate requirements for changes to:, Business processes, Policies, Information Systems

Business Analyst Major tasks

Requirements elicitation (identification)

Requirements analysis and modelling

Requirements realization planning

Requirements communication

Requirements documenting

Requirements validation

Requirements configuration management

Business solution proposal

Specific activities of Business Analyst

Identification

Developing

Managing the requirements

Business Bnalysts want to achieve the following outcomes

Reduce waste

Create solutions

Complete projects on time

Improve efficiency

Document the right requirements

Identify the root causes of problems

Activities of Business Analyst

Requirements Elicitation (identification)

Requirements Analysis

Requirements Specification

Requirements Management, Including Configuration Management

Requirements Communication, Communicate requirements in a way allowing all stakeholders to gain the same understanding of a particular requirement, Consider and choose communication approach appropriate for the project

Requirements Documentation

Requirements Modeling

Requirements Validation

Business Analysis in different phases of the Software Development Lifecycle (SDLC)

Analysis phase, Identification and evaluating of the current business processes (AS IS analysis), Gathering initial requirements for needed business solution (TO BE analysis), Creating and analyzing Business Case, Conducting feasibility study, Preparing ideas of business solution

Specification phase, Identifying and documenting business requirements on more detailed level, Supporting System Analyst in preparing detailed system specifications, Validating proposed software design with the customer and other stakeholders, Managing requirements changes

Development phase, Supporting development team during implementation, Validating increments of solution according to intended requirements and needs, Supporting testers in preparing test cases and test scripts at business level, Managing potential changes in requirements

Testing phase, Checking test results, Resolving issues related to defects or gaps in the requirements, Supporting preparing test cases for User Acceptance Testing, Supporting acceptance testers in executing test cases

When a Business Analyst is needed?

When a need for clarification of business issues appears (implementation, testing)

When a need for new functionalities appears

When the business changes

When the end users need support with working with the solution

A Business Analyst is involved during the whole software life cycle, including maintenance phase

Objectives of Business Analysis

Collect and document the business 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

System Analyst

A System Analyst writes technical requirements from the business requirements.

A Systems Analyst role requires a stronger programming skill set and often involves systems design responsibilities.

Requirements

Requirements descriptors / categories

Requirements should be preceded by descriptors like:, Business requirements, User requirements, Functional requirements (FRs), Non-functional requirements (NFRs)

Meaning and purpose of requirements

Foundation for project's assessment, planning, execution and monitoring

Customer expectations (stakeholders value)

Component of agreements, project plans

Setting of system boundaries, scope of delivery

Classification of requirements

Process requirements (project management / HOW), Needs and limitations of the business processes (e.g., management or production processes), e.g., costs, marketing, processing time, sales and distribution, organization, documentation

Product requirements (product delivery / WHAT), Functional (F), Non-functional (NF), External, Internal

Types of requirements

Customer requirements (business requirements)

Solution / system requirements

Product / component requirements

Managing requirements conflicts

A conflict may arise on one or more documented requirements.

Requirements themselves could be in conflict.

1. Record the conflict in the Issues Log

2. Analyze the conflict and its source

3. Resolve the conflict, Research (without a formal stakeholder session), Meeting involving affected stakeholders, Interviews with other parties

4. Keep an audit trail of the activity taken

5. Obtain sign off for the resolution

6. Document and distribute the results of resolution actions

Selecting the appropriate requirements format

Questions to be asked:, How detailed the requirements need to be?, What information is important to communicate?, What is the appropriate level of detail of the document?, What is the type of audience?, What is the stakeholder's preferred style of communication (technical vs. business)?

Requirements can be presented in various formats.

Requirements should be presented in formats understandable for the target audience.

Helps to obtain stakeholder understanding and approval of the requirements.

The type of requirement influences the presentation technique.

The project methodology may specify what tools will be used for documentation

Usually a combination of many formats in one requirements document is used.

e.g., Diagrams, Process Workflows, Entity Relationship Diagram, Process Decomposition Diagram, UML Use Cases, Text, Textual templates, Prototyping, Additional formats, User manuals, Presentation slides, User stories

Creating a requirements package

A comprehensive requirements document to be presented to the stakeholders.

Packaging the requirements supports effective requirements communication.

Requirements may be "packaged" at any point in a project.

Deliveries of the Business Analysis:, Assumptions, Business needs and objectives, Business process flow definition, Business requirements, Definition of the business process's products, Limitations, Stakeholders of the project

Process, 1. Determine which components of the overall requirements document should be grouped together., 2. Determine the audience to whom the requirements will be presented, 3. Evaluate the documentation required based on the type of project, 4. Package the requirements for presentation

Requirements presentation

The first step is to understand the objective of the presentation and the intended audience.

The objective:, To review, prioritize or to communicate status, To ensure quality of the requirements, To improve clarity, To obtain requirement's sign off

Subjects:, Business requirements, Data and behavior models, Functional requirements, Other models: Use Case models, Process / flow models

2 types:, Formal presentation, Used to:, Ensure that quality standards have been met, Obtain business acceptance and sign-off, Obtain delivery team or / and QA team sign-off, Examine solution options with a delivery team, Prioritize requirements, Informal presentation, Used to:, Perform informal status check of requirements, Communicate requirements to the delivery / testing team to ensure there is no ambiguity, Communicate requirements to affected business areas, Communicate requirements to other project teams

Formal requirements review

A working group session in order to review and discuss the requirements.

Participants should review the requirements before the session.

During the session each participant expresses questions; comments and suggestions.

All questions, issues are recorded.

Agreed changes are recorded.

After the session - additional requirements gathering, analysis and documentation and incorporating changes.

Significant changes may require a second review.

Process, 1. Prepare the document(s) to be reviewed, 2. Determine participants, 3. Organize / schedule the review, 4. Compile notes and results of the review, 5. Conduct the review, 6. Deliver document(s) to participants, 7. Re-review if necessary

Requirements quality characteristics (ISO 9126)

Functionality

Reliability

Usability

Efficiency

Maintainability

Portability

Requirements Scope

Managing requirements scope is considered as managing the list of the requirements of some or all of the following projects:, System or component development, Process improvement, Organizational change

Requirements Scope Management

1. Establishing requirements baseline, All requirements identified and approved by stakeholders must be baselined., The baseline:, Is a base for further system development, A point of reference for any changes in the content/scope of requirements

2. Creating a requirements structure for traceability, Requirements traceability is necessary for managing changes to the requirements done after the requirements are baselined.

3. Identifying impact to external systems and other areas of the project, Identification of all impacts to external systems and other areas of the project necessary to ensure that there is no work outside the baselined list of requirements., Impact to other systems / areas, External interface to another systems or hardware, Project and product risk, Project cost, Project resources, Project schedule

4. Identifying changes in the scope resulting from requirements changes, Requirements are not constant throughout the project's lifecycle., Impact on the project:, Minor change -> no impact on the project scope, time or cost, Major change -> may drastically change the project scope, time or cost, Changing business logic, Changing process flow for critical functionality

5. Maintaining scope approval, The list of requirements must be approved and baselined., The approved list of requirements is a mutual understanding between the customer and the vendor team about the requirements., Changes in the approved list of requirements must be managed via Change Management procedures.

Requirement Traceability

Traceability may exist between detailed requirements and both design models and test cases.

Traceability between requirements and other project artifacts allows to ensure all requirements are met.

Goals of Traceability, Scope management, Coverage analysis, Impact analysis, Use of the requirement, Proof of implementation, Defect reports

Tool support by Requirements Management software, Storing all requirements of all specifications of a technical system under development, Arranging requirements in structures (specification tree), Linking each one to the "parent" requirement in the higher specification, Requirements are realized into:, Design artefacts, Implementation, Test cases, Artifacts are traced back to the requirements.

Requirements Traceability Matrix (RTM), RTM is created at the Traceability Matrix is beginning of a project,, used to:, Track all requirements and check if they are being met by the current process, Assist in the creation of project's documentation, Supports verification process

Requirements Documentation

Purpose, Structuring the requirements, Providing clear and unambiguous explanation of the requirements, A basis for implementation and testing, A basis for requirement management, Documentation is a baseline

Requirements Document, No project deliverable information, costand time, Formalizes the project scope, A requirements document describes a set of related functional and non-functional requirements., Guidelines, The requirements must be unambiguous, precise and understandable, Superfluous information should be avoided, Templates as an aid to limit language, Models and diagrams makes the document clear and more understandable, Use formal graphical notation to express complex requirements, dependencies and relationships, Quality attributes, Complete, Consistent, Modifiable, Traceable

Forms:, Graphical models, Mathematic representation, Mixed techniques, Written text

Content::, Introduction, Secrecy clause, Regulations, Standards, Stakeholders, Purpose of the product, Overall descriptio, Functional requirements (FR), Non-functional requirements (NFR), Assumptions, Dependencies, Risks, Safety requirements Document acceptance

Formats:, Vision, What is it?, High-level consensus among stakeholders as to the overall scope of the solution domain, An output of Enterprise Analysis., Usually used in iterative development, Business Process Description (BPD), An executive summary of an initiative., Describes the problem and the proposed solution in high-level terms., Business Requirements Document (BRD), Describes the behavior required of a software application., Primarily describes the business requirements., The target audience is the customer and users, Request for Proposal / Request for Quotation (RFP/RFO.), Distributed to parties outside the organization., Basis for the contracting of solution development, Software Requirements Specification (SRS), Also known as a System Requirements Specification., Describes the behavior and implementation of a software application., The target audience is the development team., A description of the problem domain, Decomposition of the problem domain, Description of the functional requirements, Description of the non-functional requirements, Assumptions and constraints affecting the solution, Requirements attributes and traceability information

Common mistakes, Trivialities, Lengthy descriptions of commonly known issues, Information out of scope, Information without added value to the description of the solution, Thinking in solutions, Description of solutions, Requirement specification determining the technical design, Redundant details, Details unnecessarily complicating the implementation, Implementation details, Lacking rationale, No description of what shall be achieved with the solution (inc. concrete numbers and metrics)

Construction of a requirement (process)

1. Describe business justification for the requirement

2. Identify the business process

3. Identify the stakeholders

4. Identify the limitations and assumptions

5. Describe the context

6. Describe the requirement, Input, Output, Resources, Quality characteristics (if applicable)

7. Provide the graphical model (if applicable)

8. Describe risks

9. Provide references

Requirements Communication

An ongoing and iterative activity

Process, 1. Preparing requirements communication plan, 2. Managing requirements conflicts, 3. Establishing the most appropriate requirements format, 4. Performing formal requirements review, 5. Conducting requirements presentation, 6. Creating requirements package, 7. Obtaining requirements approval (Sign-off)

Requirement Acceptance

Requirements should be agreed and accepted by all relevant stakeholders.

All requirements must be formally approved.

Formal agreement:, Starting point for detailed system specification, designing the architecture and other works on the planned system.

Stakeholders with the acceptance authority, Architects, Business Analysts, Business Sponsor, Project Managers, Test/QA Manager

Requirement acceptance consequences, The list of requirements is binding for both the vendor and the customer., Any changes must be managed via Change Management.

Requirements Organization

Purpose, To determine the solution boundary, To determine the solution scope, To define the structure of requirements

Requirements are organized (structured) into packages, The problem model is decomposed to make each requirement more detailed and to ensure that the model correctly reflects the boundary for the business problem.

Requirements Decomposition

3 types, Functional decomposition, Functional decomposition is a breakdown of a list of items into classifications or groups on the basis of the function each item performs or is used for., Identifies the high-level functions, Breaks them down into sub-processes and activities, Used to:, Hierarchically decompose a system into functional components, Hierarchically decompose a business process into sub-processes, Provide a definition of all the business functions and sub-functions identified as system requirements, Levels of detail:, Enterprise Level of Detail, The root of the decomposition diagram contains:, The name of the organization, A major function within an organization, The second level represents major business functions, Planning, Execution, Control, Conceptual Level of Detail, Processes identified at this level typically reflect application systems or sub-systems:, Marketing, Sales, Finance, The lowest level functions on the Enterprise Level Chart are decomposed into the next level of detail, This identifies the major business processes needed for each function, Logical Level of Detail, Processes are decomposed into the lowest level of detail., At this level all the processes within the scope of the project are identified., This level identifies particular functions, Feature list decomposition, Feature is developed into completely described functional and supplemental requirements., Feature is a service that the solution provides to fulfill one or more stakeholder needs. Feature is an abstraction of the solution of the problem expressed on high-level., Goal decomposition, Allows ensuring the solution will satisfy stakeholder's needs, Breaks down high-level stakeholdergoals into lower-level goals, Lower-level goals have measurable objectives.

Glossary

Artefact

Describes the function, architecture, and design of software

Describes the process of development itself

All artefacts should be under version control.

Artefacts are either final or intermediate work products produced and used during a project.

e.g., Business Case, Class diagrams, Design document, Project's plan, Requirements document, Risk assessment, Use cases

Business Analyst

"A Business Analyst is a person responsible for identifying the business needs of the customer / stakeholders and to determine solutions to business problems.", source BABOK

Business Case

Business Case 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., source BABOK

The Business Case describes the justification for the project.

A Business Case captures the reasoning for initiating a project or task.

Determines the value to be added to the business as a result of the project outcomes vs. the cost to develop the solution.

Business Goal

Business Goal is an objective of an organization., Short- or long-term., Formulated by the requesting organization.

Business Need

A Business Need defines the business problem or opportunity.

Formulated by the requesting organization, with optional support of the Business Analyst on the vendor side.

Understanding needs is required to be able to recommend appropriate solutions.

Business Requirements Elicitation

Business Requirements Elicitation is a set of approaches, activities, tasks and techniques allowing to collect the business requirements of a planned solution, from the stakeholders and other available sources.

Business process

A set of activities designed to produce a specific output for a particular customer or market.

Focused on the way of organizing work, activities, relationships and dependencies between them.

Decision Package

Decision Package is a collection of the documents summarizing information about the proposed project

Includes or references all information gathered about the project so far.

May identify and justify the next steps in the overall process to continue.

Enterprise Analysis

A set of pre-project activities capturing the future view of the business in order to provide context to requirements identification and solution design fora given initiative/long-term strategic planning., source BABOK

Feasibility Study

Analysis and evaluation of a proposed project to determine if it:, Is technically feasible, Is feasible within the estimated cost, Will be profitable

Feasibility studies are almost always conducted when the initiative involves large sums.

Also called Feasibility Analysis.

Requirement

[IEEE Std 610.12-1990], 1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective., 2. 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., 3. A documented representation of a condition or capability as in 1 or 2.

Requirements Communication

The Requirements Communication consists of a set of activities for expressing the output of the Requirements Analysis and Documentation to a broad audience., source BABOK

Requirements Communication

Requirements Communication includes activities for expressing the output of the requirements analysis and documentation to the stakeholders.

Requirements Document

A requirements document describes a set of related functional and non-functional requirements.

Requirements Elicitation

Requirements Elicitation is the set of approaches, activities, tools and techniques for capturing the requirements of a planned solution from the stakeholders., source BABOK

Requirements signoff

Requirements signoff is a formal agreement by project stakeholders that the content and presentation of the requirements meet their expectations.

* May involve final review of requirements.

* The approval may be recorded either physically or electronically.

Risk Assessment

The purpose is to determine if the proposed project carries more risk than the organization is willing to bear.

Traceability

Traceability is an association existing between requirements when more detailed requirements are associated with the higher level requirements (needs and features. Traceability is an association between:, Requirements, Detailed requirements and design models, Detailed requirements and test cases, High level requirements and test cases, Requirements and design artefacts

lnterview

An interview is a systematic approach to elicit information from a person or group of people in an informal or formal setting by asking relevant questions and documenting the responses.

Feature

Feature is a service that the solution provides to fulfill one or more stakeholder needs. Feature is an abstraction of the solution of the problem expressed on high-level., source BABOK

Knowledge Areas in Business Analysis

Enterprise Analysis

Requirements Planningand Management

Requirements Elicitation (Identification)

Requirements Communication

Requirements Analysis and Documentation

Solution Assessment and Validation

Reasons why projects fail

UK Cabinet Office - 8 Common Causes of Project Failure

Lack of clear link to the organisation’s key strategic priorities

Lack of clear senior management ownership and leadership

Lack of effective engagement with stakeholders

Lack of skills and proven approach to project and risk management

Project not broken down into manageable steps

Evaluation of proposals linked to short term affordability rather than longer term value for money

Lack of understanding of and contact with suppliers

Lack of effective integration between the client, supplier and supply chain

Based on Standish Report.

10. Standard Tools and Infrastructure

9. Formal Methodology

8. Skilled Resources

7. Financial Management

6. Project Manager Expertise

5. Agile Process

4. Optimizing Scope

3; Cieor Business Objectives

2. Executive Management Support

1. User Involvement

Stakeholders

Classification

Stakeholders on the vendor's side (selected), Project Managers, Business and System Analysts, Developers and Architects, Database designers, GUI designers, Technical writers, Testers and Quality Assurance stuff, Installation and Operations personnel

Stakeholders on the customer's side (selected), Customer representative (so called "Business"), Project sponsor, End users (if are derived from the customer company), The person who installs and maintains the system, Quaiity Assurance / Testers, Installation and Operations personnel

External stakeholders, End users (clients of the customer), Other organizations (regulation entities)

Stakeholder identification

Techniques, Analyzing relationships with external organizations (suppliers etc.), Suppliers, subcontractors, partners - they can be affected by the solution as well., Their processes may also influence our solution., Identifying owners of business processes, Analyzing organizational structure of the customer's organization, Exploring the target market of the customer's organization, Analyzing relationships with external organizations, Investigating the business domain, internal/external customers and subcontractors allows to find stakeholders., Identifying owners of business processes, After identification of processes, the processes' owners have to be determined., Owners of the processes affected by the solution will be stakeholders of the initiative., Analyzing organizational structure of the customer's organization, Allows to identify stakeholders and their hierachy, relationships (what can be later used in determing the requirements' priorities and permission scheme for the planned solution)., Exploring the target market of the customer's organization, End customers, end users, institutions and other organizations affected by or affecting the solution., Investigating the business domain

Stakeholder identification problems

No knowledge about the real operators of business processes in the organization

Not clear responsibilities in the customer's organization

Missing stakeholders - not clearly and directly related with the process (the end customers)

Gaps in the analysis resulted in missing processes and activities

Different stakeholders may have different needs and expectations regarding the planned solution.

Identify all stakeholders and their needs.

Find a common understanding of the purpose of a system.

Stakeholders value

Determining stakeholders value is one of the key factors of the project's success.

The main goal of a project is achieving "realized value" (also known as "benefits"), for the stakeholders.

A value can be defined as '"the benefit we think we get from something" -T. Gilb.

Value is the potential consequence of system attributes, for one or more stakeholders.

Value is not linearly related to a system improvement:, A small change in an attribute level could add immense perceived value for one group of stakeholders for relatively low cost.

Value is the perceived usefulness, worth, utility or importance of a defined system component or system state, for defined stakeholders, under specified conditions.

"Benefit" is when some perceived value is actually produced by a defined system.

Value is not absolute: it is relative to a stakeholder.

Enterprise Analysis

Activities of the Enterprise Analysis

Determining business opportunities

Developing strategic goals to be achieved by the organization

Developing a strategic plan allowing to plan and execute the goals

Understanding and developing the business architecture

Determining the optimum project investment path for the organization, including:, Implementation of new business and technical system solutions, Implementation of process or organizational changes

Selecting the right solution approaches for projects and developing their business cases

Initiating projects

Enterprise Analysis is conducted:

As a stand-alone project, in large and complex organizations

By customer organization - before involving the vendor, the results are provided as part of initial requirements (in small organizations)

Not conducted at all, if the goal of the project is clear and measurable

Enterprise Analysis activities:

Identification of business processes

Creating the Business Architecture

Conducting Feasibility Studies

Conducting the initial Risk Assessment

Preparing the Business Case

Scoping and defining the new business opportunity

Preparing the Decision Package

Business Architecture

Defines an organization's current and future capabilities., High level business environment, Long term goals and objectives, Stakeholders, The businesses strategy, The external environment, The technological environment

Risk Assessment

1. Identifying project risks, 1. Identifying and analyzing business risks, 2. Identifying and analyzing financial risks, 3. Identifying and analyzing technical risks

2. Assessing risk probability and impact

3. Planning risk responses

4. Assessing organizational readiness / calcuiating an overall risk rating

Business process

Characteristics of a Business Process, Has a goal, Has specific inputs, Has specific outputs, Uses resources, Has a number of activities performed in some order, May affect more than one organizational unit, Creates value for the customer

Purpose of Business Process's identification, Understanding the goals of the organization., Determining activities and the flow required to achieve the planned business and strategic goals., Finding gaps and non-effective parts of the process to optimize the process.

Business Goal

Qualities of Business Goals, Specificity, Optimism, Realism, Short and long term

Importance of setting Business Goals, Provides a vision of what the organization wants to accomplish., Provides a clear picture of what the organization is trying to do with the business., Allows to understand and maintain a commitment to the business main objectives., It gives a metric to measure organization's progress.

SMART, A system and a tool for effective goal setting and goal quality., All goals should be SMART., S - Specific, M - Measurable, A - Attainable, R - Relevant, T - Timely, SMART - example of business goal, Obtain 3 new billion dollar corporate clients in the New York property insurance market by the end of this fiscal year through networking.

Business Need

Who defines the Business Need?

The person or group requesting the project, including:, High-level Subject Matter Expert (SME) [Pyzdek, Thomas and Paul A. Keller], Regulatory / compliance body, Sponsor, Steering committee, Subject Matter Expert (SME)

e.g., Branch managers need an access to transaction's reports and statistics., Insurance agents need a mobile application to analyze and document claims., Controlling department needs an access to structured information from all systems operating in the organization.

Business Case

A Business Case may cover the following topics:, Information about the opportunity in terms of the market trends, competitive environment and expected market penetration, Qualitative and quantitative benefits, Estimates of costand time to breakeven, Profit expectations, Follow-on opportunities, Cash flow consequences of the action, over time, and the methods used for quantifying benefits and costs, The impact of the project on the business operations, The impact of the project on the technology infrastructure, Constraints associated with the proposed project, Estimated budget, Alignment with priorities established by the business

Main idea of a Business Case, A Business Case demonstrates that:, The solution proposal has been analyzed properly, The full benefits will be realized in time, Any technical aspects have been thoroughly evaluated

Purpose of a Business Case, Buildingthe Business Case allows the organization to, Understand and apply a way of thinking where people with the authority to recommend projects will firstly analyze their value, risk and priority as a base of submitting the project proposal, Justify the value of proposals to the organization, Reject any proposals that are not of proven and measurable value, Decide if the proposal is of value to the business and is achievable in comparison to alternative proposal submitted, Track and measure the progress and achievements of the business case, Ensure that projects with inter-dependencies are undertaken in the optimum sequence

Content of a Business Case, Reference, Project name/reference, Origins/background/curr ent state, Context, Business objectives/opportunities, Business strategic alignment (priority), Value Proposition, Desired business outcomes, Business benefits, Quantified benefits value, Costs, ROI Financial scenarios, Risks / costs of not proceeding, Project risks (to project, benefits and business), Focus, Problem/solution scope, Assumptions, Constraints, Options identified / evaluated, Size assessment, Scale assessment, Complexity assessment, Deliverables, Outcomes, deliverables and benefits planned, Organizational areas impacted (internally and externally), Key stakeholders, Dependencies, Workload, Approach, Phase/stage definitions, Project activities, Technical delivery activities, Workload estimate/breakdown, Project plan, Project schedule, Required resources, Project leadership team, Project governance team, Team resources, Funding, Commitments, Project control, Reporting processes, Deliverables schedule, Financial budget/schedule

Quality attributes of a Business Case, Accountable, commitments for the delivery of benefits and management of costs are clear, Adaptable, adjusted to the size and risk of the proposal, Business oriented, concerned with the business capabilities / impact, Consistent, every project addresses the same basic business issues, Transparent, key elements can be justified, Understandable, the content is clear, relevant and logical

Procedure of building a Business Case, 1. Identify and quantify the benefits, Measure the benefits of the recommended solution {qualitative and quantitative gains to the enterprise)., Benefits should be quantified., Benefits of a non-financial nature should be listed., Estimates should be linked back to strategic goals., 2. Identify and quantify the costs, Estimate the total net cost of the solution., Estimate:, Capital expenditures for the new investment, Costs of developing and implementing the change, Opportunity costs of not investing in other options, Costs related to changing the work and practices, Total cost of ownership to support the new solution, 3. Prepare the Business Case, Develop the Business Case at the appropriate level of detail., Remember it should demonstrate project viability and secure a go/no go decision., 4. Determine the measurement process for the costs and benefits, Describe how the benefits will be assessed and evaluated., Build a plan for benefit measurement and reporting.

Sample structure of a Business Case, 1. Executive summary, 2. Introduction and summary, Project rationale for preferred option, Current business process, Description of the problem, Opportunity, Project objectives, Project scope, Business benefits, Project costs, Assumptions, Potential business and staff impact analysis, Potential technology impact analysis, Implementation plan, 3. Approach, Financial metrics, Privacy impact assessment, Alternative evaluation criterion, 4. Key selection criterion, Weighting, Constraints and limitations, 5. Preferred alternative, Business benefits, Alternative costs, Assumptions, Potential business and staff impact analysis, Other issues, 6. Risk Management Plan, Risk assessment, Risk response, Benefit realization, 7. Conclusion and recommendations

Solution scope

Determining solution scope

A base for establishing the scope of the project (project planning).

A base for detailed requirements development.

Based on the product/solution scope; the project manager determines the cost and duration of the project.

Techniques to determine solution scope

Work Breakdown Structure (WBS), A decomposition of work required to complete a project.

Product Breakdown Structure (PBS), A decomposition of the components of the product.

System Interface Analysis, Work required to integrate the new solution into the business and technical environments.

UML Use Cases

Use Case Diagrams allows to present the boundary of the solution.

Shows the connections with external systems and actors.

Map is under development, current state is an early ALPHA.

Requierements related standards

ISO 25000 (ISO / IEC 9126)

Defines a quality model with 6 categories, Efficiency, Functionality, Maintainability, Portability, Reliability, Usability

IEEE 830

Recommended Practice for Software Requirements Specifications

IEEE 1233

Guide for Developing of System Requirements Specifications

IEEE 1362

Guide for Information Technology - System Definition

Interactive Glossary

Interactive IQBBA® Glossary

This freeware, non-commercial mind map was carefully hand crafted with passion and love for learning and constant improvement as well for promotion the IQBBA® CFLBA certification and as a learning tool for candidates wanting to gain IQBBA® CFLBA qualification. (please share, like and give feedback - your feedback and comments are my main motivation for further elaboration. THX!)

Questions / issues / errors? What do you think about my work? Your comments are highly appreciated. Please don't hesitate to contact me for :-) Mirosław Dąbrowski, Poland/Warsaw.

http://www.linkedin.com/in/miroslawdabrowski

https://www.google.com/+MiroslawDabrowski

https://play.spotify.com/user/miroslawdabrowski/

http://www.miroslawdabrowski.com

https://twitter.com/mirodabrowski

miroslaw_dabrowski

Business Analysis Process Planning

Impact of a Business Analysis

Business Analysis provides input information to the following processes:, Project management (scope planning, scheduling and estimating development and testing), System analysis, Design (system specification and architecture), Implementation -Testing

Roles affected by a Business Analysis:, Project manager, Developers, System analysts, QA and Testers, Architects

Requirements Communication, Ongoing, iterative activity., Done in parallel with Requirements Elicitation, Analysis and Documentation., Includes:, Presenting, Communicating, Verifying, Gaining approval of the requirements, The main purpose of planning the Business Analysis communication is to define:, How to receive, distribute, access, update and escalate information to and from project stakeholders., How to organize schedule and structure of communication within a project.

Communication Planning, Business Analysis activities/deliveries can be communicated in formal and informal way., Communication activity should consider what kind of issues to be communicated:, Changes, Consequences, Information, Needs, Risks, Common ways of communication:, Documentation, Formal review, Informal review, Presentation, Workshop

Elements of Requirements Communication, Requirements communication plan, Managing requirements conflicts, Selecting the appropriate requirements format, Creating a requirements package, Requirements presentation, Formal requirements review

Requirements communication plan, How and when the BA will work with project stakeholders., On small projects it may be very brief and may not be formally documented., On large and complex projects it may be included as part of the project initiation documentation.

Requirements Engineering process planning

Goal, The goal is to define appropriate Requirements Engineering strategy, planning and estimation.

Determines the main activities and roles.

Includes definingthe process of managing Change Requests.

Factors to be considered in planning, Type of project:, Different projects types require a different amount of documentation, different processes and result in different deliverables., Small projects - basic documentation, communication may be partially informal, Complex, international project - more documentation and effective communication. Information is distributed to many teams, Communication formality:, Communication formality varies between projects, projects' phases and stakeholders., More formal when:, The project is large, Its domain is complex, The project is be critical or strategic, The project is dependent of legislation or sector standards or agreements, Communication frequency:, Communication frequency will differ among stakeholder for every form of communication., Communicating Business Analysis's deliveries usually follows a schedule:, I.e. Completing, reviewing and distributing of a requirements specification can be a project's milestone., Frequency of the status meetings, review meetings etc. is defined in communication plan, together with the people / roles involved., Geographical location:, Geographic disparity as a factor limiting communication possibilities., When stakeholders live in different time zones communication (calls, team meetings) must be adjusted to the capabilities., Culture:, Especially important in case of international projects., Culture may determine the preferred form of communication (e-mails instead of calls, face-to-face meetings instead of e-conferences).

Inputs for the Requirements Engineering, Business Analysis approach, Overall approach used by an organization to derive the Business Analysis processes., Business Analysis plan, Defines what deliverables (like requirements specification) will be produced and when., Organizational process assets, A set of standard templates of processes existing in an organization.

Process, Non-core process concerning all disciplines of the systems development:, Identification of requirements (Elicitation), Analysis of requirements, Specification of requirements, Changes of requirements, Quality assurance (with Verification and Validation)

Factors affecting communication, Availability of resources, Complexity, Organizational maturity, Organizational culture, Organizational standards, Stakeholders preference

Repository, The purpose of repository is to store requirements with theirs statuses., Repository allows to group requirements (i.e. by status):, Underdevelopment, Under review, Approved, Changed

Traceability, The process of tracing requirements is defined by the Business Analyst., The process has to be tailored to complexity of the project domain, stakeholder's needs, potential risks and available resources.

Selection of requirements attributes, Custom requirements attributes allow to include more detailed information in the description of requirements and to analyze them., The attributes need to be planned and determined in the Requirements Elicitation phase.

Requirements prioritization, Requirements are not equal for stakeholders and don't have the same value for project success., Priority as a factor of importance and impact should be determined by the Business Analysts along with proper stakeholders.

Configuration and Change Management, Configuration Management allows to identify and manage so called Configuration Items. A Configuration Items may be:, Single requirement, Requirements specification, Change Management is a process designed to track, identify and manage changes.

Configuration and Change Management process

The purpose of Configuration Management is to establish and maintain the integrity of the products (components, data and documentation) of the software artefacts within the project and product life cycle

Configuration Management is a discipline applying technical and administrative tools and techniques to [IEEE 610], Identify and document the functional and physical characteristics of a configuration item, Control changes requested to those characteristics, Record and report change processing and implementation status, Verify compliance with specified requirements

It allows managing changes in the requirements in an effective way

Change Management is a subdiscipline of the Configuration Management

Configuration Item, An artifact, document, product (hardware and / or software) that has an end-user purpose and designated for Configuration Management and treated as a single entity in the Configuration Management Process ' [IEEE 610], e.g., Single requirements, Business needs, Requirements specifications, Business cases, Models, …

Baseline, A baseline is a stable well- defined set of attributes that serve as a comparison for system change, A system baseline is any set of system attribute specifications that formally define the state of a system, under specified conditions

The process of Configuration Management includes the following activities:, 1. Configuration Identification, The purpose of Configuration Identification is to determine the attributes that define every aspect of a configuration item, The attributes are recorded in configuration documentation and baselined, 2. Configuration Change Control, Configuration Change Control is a set of processes and approval stages required to:, Change a configuration item's attributes, Establish a new baseline for changed item, 3. Configuration Status Accounting, Configuration Status Accounting is the ability to record and report on the configuration baselines associated with each configuration item at any moment of time, 4. Configuration Audits, Two types of Configuration Audits, Functional Configuration Audit, Ensures that functional and performance attributes of a configuration item are achieved, Physical Configuration Audit, Ensures that a configuration item is installed in accordance with the requirements of its detailed design documentation

Change Management Process:, 1. Identification of potential change, 2. Requesting new functionality, 3. Analysis of the change request, 4. Evaluating the change, 5. Planning the change, 6. Implementing the change, 7. Reviewing and closure of the change, 8. Roll out of the change

Change Request, An official document requesting modification of existing features, requirements or functions or new ones, Description of the current solution, Justification for a change, Suggested (desired) solution, Priority

Example of a Change Management, Defect report, Analysis of the report, Comparing with the specification, Discovering the mistake in the specification, Closing the defect report, Submitting a change request, Analysis of the change request, Approval of the change request, Implementation of the change request, Testing the implemented change, Change closure

Sources of a change, Defects found in the code, documentation, requirements, Business process improvement, System improvement efforts, New or changing requirements, External changes (regulation, law changes)

Planning of change implementation, Updating plans: Project Plan, Development Plan, Test Plan, Updating business and system documentation, Updating test cases and test scripts, Implementing the change (coding), Testing by vendor or / and customer test team, Deploying the change to production environment (if applicable)

Change Life Cycle, Possible statuses, Submitted, Open, Approved, Rejected, Deferred, In implementation, Implemented, In testing, Tested, Closed

Change Control Board (CCB), A group of people responsible for evaluating and approving or disapproving proposed changes to configuration items, and for ensuring implementation of approved changes [IEEE 610], Project manager, Business analysts, Development team, Quality assurance team, Business manager, Customer

Tools and techniques selection

Categories of tools, Text processing, Table calculations, Modeling tools, Tools for Requirements Management, Process simulation tools, Configuration Management tools, Change Management tools

Factors affecting tools selection, The goal of the initiative, Different tools for extending existing solution, different for process optimization, The type of planned solution, Enterprise software vs. Entertainment software, Designing software vs. Improving business process, Organization's IT infrastructure, The scope of the solution, The complexity of the solution, Number of requirements, Dependencies between requirements, Traceability requirements, Standards and norms to be applied, Experience and skills of the project team

Common Business Analysis techniques, Brainstorming, CATWOE, Data Flow Diagrams, Five Why's, Functional, decomposition, Interviews, MoSCoW, MOST, PESTLE, Prototyping, Requirements, Workshop, Risk Analysis, Scenarios and Use Cases, SWOT, User stories

Competences

Domain knowledge

Primary role of the BA is to provide business solutions to business issues by assessing business problems, and identifying root causes

Required to, Assess business problems, Find the most appropriate solution, Provide measurement framework

Having domain knowledge allows the Business Analyst to connect and communicate with Business Users

Lack of domain knowledge may lead to delays in providing the solution

Domain knowledge makes understanding and analyzing of business issues easier

Analytical skills, Financial analysis, Statistical analysis, Operations research, Requirements analysis, Systems analysis

Managerial skills, Project management capabilities, Understand organizational behavior

Technical skills, Working knowledge of science, Understanding of engineering principles, Ability to apply financial principles to feasibility studies

Soft skills

Soft skills are necessary

Business Analyst's job requires communication and cooperation with various people

Common Business Analysis activities, Negotiation, Discussion, Conflicts solving

Negotiation skills, Negotiate to obtain data, Negotiate to resolve conflicts, Negotiate to agree requirements

Facilitation skills

Communication and writing skills, Communicate with all levels of management, Communicate with stakeholders of various knowledge, Precise in articulating ideas and thoughts, Relate with line workers, Good technical writing skills, Familiar with all forms of communications, Public speaking skills

Facilitation

Facilitation is the process of enabling groups to work cooperatively and effectively

It is a way of providing leadership without taking the reins

A 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 goal - to support others to achieve high performance

Facilitator's tasks and activities, Helping the group to define the goals and its objectives, Providing processes helping to use the time effectively and make high-quality decisions, Guiding group discussions, Documenting main ideas and concepts raised during the discussion, Supporting people in assessing their current skills and building new skills, Using consensus to enable the group to make agreed decisions, Managing conflicts, Helping the group to communicate effectively, Helping the group to access resources needed to make decisions

Key competences, Communicates well, Processes ideas from people, Shows a natural interest Listens well Maintains control Empowers the group Handles uncertainty, Is quick to connect with the group, Systems Analysis & Design, Manages people's expectations, Understands and constantly explains the process, Focuses on the business not on their own solutions, Communication skills Negotiating Group dynamics Listen / draw conclusions Running meetings, The facilitator must always stay neutral and stay on track

Tools and techniques, Engagement Strategies, Creating Participation, Generating and Organizing Data, Ignite Action, Mobilizing Energy, Initiating Reflection, Recording Techniques, SWOT, Gap Analysis, Flipcharts, Checklists, Brainstorming, Root-Cause Analysis, Multi-Voting, Focus Group Framework, Managing Conflicts Tips Sheet

Innovation, Design and Customer

Role of the innovation

Achieving competitive advantage over other companies is more and more difficult

Traditional products and services do not guarantee a success on the market

Innovation as a tool helping the organization to achieve competitive advantage

Innovation, Innovation is the process of renewing something that exists, Innovation requires, Changing the way people make decisions, Doing things differently, Making choices outside of the norm, Innovation changes the values onto which the system is based, Types of innovation, Radical (breakthrough, destructive), Using or introducing new technology, Changing an existing market or creating a new one, Incremental (conservative, sustaining), Based upon existing knowledge and technology, Introducing small changes, Enabling short-term competitive advantage, User Innovation, The author of innovation is the end user who develops or refines acquired products and services at the site of use, Users share their ideas and solutions with the producer, Called as „free revealing"

Innovation vs. Invention, Innovation is not the introduction of something new - it is not invention but changing something already existing by adding values into it

Triggers for Innovation, No clear boundaries of the business, Organizations extends the business area (the offer) and the geographic area of activity using other communication and distributions channels, More demanding customers, Customers require a product, Of high usability, Compatible with other products, That makes them feel comfortable, Customer needs and expectations are on the first place, Customer's satisfaction as a success factor, More effort to meet the customer's requirements, The customer should be positively surprised and willing to come back to buy more products / services, More interest in integrated systems of, Products, Software, Services working as a single whole, Integrated systems as keys to expansion beyond core areas of the business, A way to meet customer expectations impossible to achieve by more isolated offering, Questions without any answer, Problems without a solution, Who finds the right answers or working solution firsts can achieve competitive advantage

Areas of application, Products, Introducing new merchandise to the market, Processes, New, better way of achieving something is introduced, Behavior, How people live their lives, perceive reality or achieve their goals

Categories of innovation, Degree, Disruptive innovation, Line extension innovation, Scope, Application innovation, Enhancement innovation, Business area, Product innovation, Process innovation, Source, Organic innovation, Acquisition innovation

Design, The specification of an object intended to accomplish goals in particular environment, A process which produces such specifications, A term often linked with innovation, From business perspective design is the process which allows the company to achieve a competitive advantage, Design supports achieving a competitive advantage by, Solving users or customers problems in the creative way, Creating unique value and unforgettable user experience, Joining functionality, aesthetics, ergonomics and user experience with the form, Distinguishing the company

Competition and Market Research

Market Research, A structured activity with the purpose to gather information about markets or customers, Important component of business strategy

Market Analysis, A structured and documented investigation of a market, Determines if there is a need or audience for a product / service, Provides information about market's needs and how it is currently serviced, Useful to plan, New products, An expansion of the business, Dimensions of a Market Analysis, Market size (current and future), Market growth rate, Market profitability, Industry cost structure, Distribution channels, Market trends, Key success factors

Market Research and Analysis process, Problem definition, Analysis of the situation, Obtaining data and information specific to the problem, Information analysis and interpretation, Formulating ideas and solution of problem

Techniques for collecting market data, Qualitative research, Quantitative research, Customer feedback, Mail questionnaire, Telephone / Personal Interview surveys, Observation, Direct work with the end users on site

Trend, Trend is a tendency of a market (or specific product or service) to move in a particular direction over time, Market Research together with Market Analysis allows to determine Market Trends, Analyzing the trends allows to predict the desired future solutions

Design Thinking

Design Thinking, A methodology for practical, creative resolution of problems or issues that look for an improved future result, The collaborative process by which the designer's sensibilities and methods are employed to match people's needs with what is technically feasible and a viable business strategy

Design Thinking is a team oriented discipline

Design Thinking converts need into demand

Three major phases, Inspiration, The main goal is to gather insights from customers, Insights are to be used as the basis for inspirations, Inspiration phase is performed from the user / customer perspective, No business constraints, Results of the inspiration phase, The target of the project, Understanding of the problem from organization and customer perspective, Insights, Knowledge about the opportunities and constraints, Documentation of the research, Pictures, Movies, Ideation, The goal is to analyze insights and turn them into ideas, The ideas become a part of the solution, New ideas should not be judged or rejected, even if they seem to be contradictory, Questionable ideas may be a source for further inspiration, The result of the ideation phase - the decision which ideas become part of the final solution, Tools for ideation, Stories, Sketches, Prototypes, Implementation, Precondition: ready and more or less stable prototypes of solutions, The goal is to convince the stakeholders that proposed solutions meet their expectations and guarantee success after release to the market, Sample tool - storytelling

Basic methods, tools and techniques

Multidisciplinary teams, Team consisted of people from various, often completely different functional areas, The teams is organized around the problem rather than a leader, Beneficial for, Making observations, Gathering insights, Generating ideas

Multi-vector research, An approach for analyzing all available points of view or sources of information, Procedure, Synthesize the vectors to uncover insights, Create a number of vectors to research H the problem from several directions, Typical vectors used in Multi-Vector Research, Customers, Competitors, Organization toolbox, Technology, Sales and Retail, Trends

Persona, Persona is a fictional character representing the different types of users, Persona represents a group of people with the same, Needs, Attitude, Behavior, Expectations towards the product, Sample personas in innovation process:, The Anthropologist, True observer of the human nature, The Experimenter, Prototypes, experiments and improves the solution using trial and error process, The Cross-Pollinator, Analyses other industries and cultures to gather findings that can be used in benefit of an enterprise, The Hurdier, Removes the obstacles waiting to delay or stop innovation from happening, The Collaborator, Organizes, supports and trains the project team, The Director, Builds the innovation culture in the organization encourages people and leads them towards his vision, The Experience Architect, Delivers the product to the customer, The Set Designer, Provides workplace with the best conditions for creative work, The Caregiver, Keeps the focus on the customer and anticipates his needs

Insights, Customer insights are the basis for the inspiration and innovation, The main idea - whatever is examined it should be examined from customer's point of view, Sources of insights, Customers and their feelings, needs, values and problems, Extreme users and outliers, children, seniors, Trends and general trends, Competition, Technology, Complementing and comparable organizations

Brainstorming, Technique used for generating of a large number of ideas for the solution of defined problems, A session involves a group of people, Members have different knowledge and experience, Brainstorming sessions should be rather facilitated than moderated, Rules applying to brainstorming sessions, Avoid judgment and criticism towards ideas of other team members, New ideas can be built on the ideas provided by others, Do not focus on the quality of the ideas, but on the quantity, The goal is to collect many various ideas

Prototyping, Encourages iterative approach to the problem solution, Using prototypes allows, Better explain and present ideas or solutions to others, Come up with new ideas, Test the solution, Gather the feedback from the stakeholders and customers

Enlightened trial and error, Trial and Error - the process of obtaining knowledge by generating solutions, testing them and learning from own mistakes, The testing is performed with the prototypes, The main idea: "Fail often in order to succeed sooner"

Storytelling, A persuasive technique used to convince the other side to the arguments of the storyteller, Stories, Based on assumptions or the real situations experienced during the research phase, Wrapped around the product, user and user's experience, The main idea: "show, don't tell", Tools, Pictures, Videos, Sketches

Working with the final user

Working with the user allows to, Identify the user's needs, Support the users in formulating the needs, Explore the needs and determine requirements, Provide the user with suggestions how to improve the desired solution