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

1. Process Improvement

1.1. Process Improvement

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

1.1.2. Improving the business process

1.1.2.1. Approaches

1.1.2.1.1. Manual re-designing of the process on the base of experience and domain knowledge

1.1.2.1.2. Introducing tools allowing to optimize the business processes in the organization

1.1.2.1.3. Process simulation and optimizing

1.1.2.1.4. Adopting selected methodology or strategy

1.1.3. Triggers of Process Improvement

1.1.3.1. Process Improvement may follow a specific methodology or strategy

1.1.3.1.1. Benchmarking

1.1.3.1.2. Business Process Improvement

1.1.3.1.3. Business process reengineering

1.1.3.1.4. Capability Maturity Model Integration / Capability Maturity Model

1.1.3.1.5. ISO 9000

1.1.3.1.6. IT Governance

1.1.3.2. Just In Time manufacturing

1.1.3.3. Lean manufacturing

1.1.3.4. Performance improvement

1.1.3.5. Process management

1.1.3.6. Process improvement and Management (PI&M)

1.1.3.7. Six Sigma

1.1.3.8. Total Quality Management

1.1.4. Business Process Improvement

1.1.4.1. BPI is a systematic approach to help an organization optimizing its underlying processes to achieve more efficient results

1.1.4.2. The goal - radically change the performance of an organization

1.1.4.3. No improvement by a series of small incremental changes

1.1.5. Methodology of BPI

1.1.5.1. Define the organization's strategic goals and purposes together with the existing structure and processes (AS-IS)

1.1.5.2. Determine the organization's stakeholders and identify

1.1.5.2.1. What outcomes adds value to the organization's objectives

1.1.5.2.2. What are the best ways to align its processes to achieve those outcomes (TO-BE)

1.1.5.3. Re-organize the business processes to realize the goals and to meet the new objectives

1.1.5.3.1. Supported by the tools available within the BPI methodology

1.1.6. Roles in BPI

1.1.6.1. Business Leader

1.1.6.1.1. Responsible for developing business plans (including strategic plans)

1.1.6.1.2. Responsible for developing resource plans

1.1.6.2. Process Owner

1.1.6.2.1. Designs processes

1.1.6.2.2. Responsible for the creation, update and approval of documents to support the process.

1.1.6.3. Operational Manager

1.1.6.3.1. Organizes the resources and processes in order to achieve the objectives of the business plans created by the Business Leaders

1.1.6.3.2. Instructs the Process Operators how to perform the processes

1.1.6.4. Process Operator

1.1.6.4.1. Performs the processes necessary to achieve the objectives of the business plans created by Business Leaders

1.1.6.4.2. Ensures the realization of a process meets performance objectives

1.1.6.4.3. Ensures the products of the processes meet the specifications

1.1.6.5. The roles has different responsibilities but they work together!

1.2. Process simulation and redesigning

1.2.1. Business Process Simulation

1.2.1.1. Business Process Simulation (BPS) is a part of Business Process Management (BPM)

1.2.1.2. BPS allows simulating

1.2.1.2.1. The execution of business processes

1.2.1.2.2. Parameters over time

1.2.1.3. Simulation is based on process models

1.2.1.4. The purpose

1.2.1.4.1. Understand, analyze and design (or re-design) business process models with respect to performance metrics

1.2.1.4.2. Evaluation and comparing the (re)designed processes and implementing the best choice

1.2.2. Process models

1.2.2.1. The process models must represent

1.2.2.1.1. The specific elements of the business process

1.2.2.1.2. The attributes of the business process

1.2.2.2. Running the simulation allows checking how the process is realized

1.2.2.3. BPS Procedure

1.2.2.3.1. Mapping the business process onto a process model

1.2.2.3.2. Identification of the sub processes and activities

1.2.2.3.3. Creating the control flow definition

1.2.2.3.4. Identification of the resources and assigning them to the activities

1.2.2.3.5. Defining performance characteristics

1.2.2.4. Running the simulation

1.2.2.4.1. Simulation should be executed for several sub runs

1.2.2.4.2. A simulation is run in a specific tool

1.2.2.4.3. Tools show an animated picture of the process flow or real-time fluctuations in the key performance measures

2. Tools and Techniques

2.1. Modeling tools

2.1.1. Modeling tools allow to

2.1.1.1. Link requirements in models

2.1.1.2. Create graphical representation of requirements

2.1.1.3. Represent relations between requirements, and between requirements and other artifacts

2.1.1.4. Establish and maintain traceability

2.1.1.5. Design the overall structure of the system

2.2. Business Analysis techniques

3. Solution Validation

3.1. Assessment

3.2. Validation

4. Requirements Analysis

4.1. Requirements Organization

4.1.1. Requirements are organized (structured) into packages

4.1.1.1. The purpose of organizing requirements

4.1.1.1.1. To determine the solution boundary

4.1.1.1.2. To determine the solution scope

4.1.1.1.3. To define the structure of requirements

4.1.1.2. 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

4.1.2. Decomposition

4.1.2.1. Goal decomposition

4.1.2.1.1. Allows ensuring the solution will satisfy stakeholder's needs

4.1.2.1.2. Breaks down high-level stakeholder goals into lower-level goals

4.1.2.1.3. Lower-level goals have measurable objectives

4.1.2.1.4. Goals are business requirements

4.1.2.2. Feature list decomposition

4.1.2.2.1. Feature is a service that the solution provides to fulfill one or more stakeholder needs

4.1.2.2.2. Feature is an abstraction of the solution of the problem expressed on high-level

4.1.2.2.3. Feature is developed into completely described functional and supplemental requirements

4.1.2.3. Functional decomposition

4.1.2.3.1. 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

4.1.2.3.2. Identifies the high-level functions

4.1.2.3.3. Breaks them down into sub-processes and activities

4.1.2.3.4. Functional decomposition is used to

4.1.2.3.5. Levels of detail for functional decomposition

4.2. Modeling and Specification

4.2.1. Model

4.2.1.1. Model is a representation of an object

4.2.1.2. System model is a conceptual description and representation of the system

4.2.1.3. Model describes

4.2.1.3.1. The structure of the system

4.2.1.3.2. Dependencies and relationships between the system's objects system model is a

4.2.1.3.3. Textual elements

4.2.1.3.4. Matrixes

4.2.1.3.5. Diagrams

4.2.1.4. Reflects the relationships and dependencies between requirements realizing identified business needs

4.2.2. Modeling

4.2.2.1. Modeling is a way of expressing requirements representing parts or the whole of the proposed solutions

4.2.2.2. Modeling is helpful but not always necessary

4.2.2.3. The organization may skip modeling when:

4.2.2.3.1. The solution is fully understood by the stakeholders

4.2.2.3.2. The solution is easy to implement

4.2.2.3.3. The requirements are mostly non-functional and difficult to express in the form of a model

4.2.2.3.4. The problem domain is well known

4.2.2.3.5. The solution is dedicated to use by very few people

4.2.2.3.6. The scope is declared as constant

4.2.2.3.7. The model representation would be less understandable by the key stakeholders than written text

4.2.2.4. Advantages of Modeling

4.2.2.4.1. Models allow to focus on the important aspects and areas of the solution

4.2.2.4.2. Models describes complex system in more clear and unambiguous way

4.2.2.4.3. Models are more readable and clear than written text

4.2.2.4.4. Looking at the problem from the overall perspective

4.2.2.5. Modeling Techniques

4.2.2.5.1. Archimate

4.2.2.5.2. BPMN

4.2.2.5.3. DSL

4.2.2.5.4. GUI modelling

4.2.2.5.5. OBASHI

4.2.2.5.6. SysML

4.2.2.5.7. UML

4.2.2.5.8. ...

4.3. Defining Assumptions and Constraints

4.3.1. 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

4.3.2. Constraint

4.3.2.1. A constraint is a requirement that explicitly and intentionally tries to directly restrict any system or process

4.3.2.2. Limitations on

4.3.2.2.1. Engineering process System's operation Lifecycle

4.3.3. Types of constraints

4.3.3.1. Business constraints

4.3.3.1.1. Financial or time restrictions, limits on the number of resources available, skills of the project team or any other organizational restriction

4.3.3.1.2. Limitations on the projects flexibility to implement requested solution

4.3.3.2. Technical constraints

4.3.3.2.1. Related to the architecture of the solution (hardware and software platforms, programming language or technology, supporting software)

4.3.3.2.2. Technical constraints include also: database size, resource utilization, message size, software size, maximum number of and size of files

4.3.4. Example constraints

4.3.4.1. Hardware or software environment

4.3.4.2. End-user environment

4.3.4.3. Availability or volatility of resources

4.3.4.4. Standards compliance

4.3.4.5. Interoperability requirements

4.3.4.6. Interface / protocol requirements

4.3.4.7. Data repository requirements

4.3.4.8. Data distribution requirements

4.3.4.9. Security requirements

4.3.4.10. Memory limitations

4.3.4.11. Performance requirements

4.3.4.12. Network communications

4.3.5. Assumption

4.3.5.1. Assumptions are things that are believed to be true but have not been confirmed

4.3.5.2. Assumptions are unproven conditions, which if not true at some defined point in time, would affect the initiative / solution

4.3.5.3. Assumptions often become limitations!

4.3.5.4. Goal

4.3.5.4.1. Assumptions are used to document

4.3.6. Types of assumptions

4.3.6.1. Business assumptions

4.3.6.1.1. The purpose: to inform the project team of key stakeholder expectations

4.3.6.2. Requirements assumptions

4.3.6.2.1. The purpose: to transfer business domain knowledge to the project team

4.3.7. Example assumptions

4.3.7.1. The back-end system is available

4.3.7.2. There is no more than 1000 transactions per day

4.3.7.3. All transactions are processed in EURO

4.4. Verification and Validation

4.4.1. Validation

4.4.1.1. 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]

4.4.1.2. Goal

4.4.1.2.1. The goal of validation is to ensure that the stated requirements correctly implement the business requirements determined in Enterprise Analysis and Requirements Identification phases

4.4.2. Verification

4.4.2.1. Verification is a confirmation by examination and through provision of objective evidence that specified requirements have been fulfilled [ISO 9000]

4.4.2.2. Verification ensures that requirements are defined clearly enough to allow solution design and implementation and test preparation to begin

4.4.2.3. Verification process requires to involve and cooperate closely with

4.4.2.3.1. Customer

4.4.2.3.2. Users

4.4.2.3.3. Project team

4.4.2.4. Requirements can be stated as verified if

4.4.2.4.1. Project stakeholders agreed that the requirements are correctly understood

4.4.2.4.2. The requirements were checked with the stakeholders and confirmed as complete description of what has to be implemented

4.4.2.4.3. The requirements were stated as of high quality

4.5. Quality Assurance

4.5.1. Quality Assurance

4.5.1.1. 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

4.5.2. Quality criteria for requirements

4.5.2.1. Allocatable

4.5.2.2. Complete

4.5.2.3. Consistent

4.5.2.4. Correct

4.5.2.5. Does not determine solution

4.5.2.6. Feasible

4.5.2.7. Measurable

4.5.2.8. Necessary

4.5.2.9. Prioritized

4.5.2.10. Testable

4.5.2.11. Traceable

4.5.2.12. Unambiguous

4.5.2.13. Understandable

4.5.3. Examples of QA techniques

4.5.3.1. Checklists

4.5.3.1.1. A common technique for quality control

4.5.3.1.2. A standard or customized set of quality elements to validate the Requirements Specification (or other artefact)

4.5.3.2. Reviews

4.5.3.2.1. A review is an evaluation of a product or project status to ascertain discrepancies from planned results and to recommend improvements [IEEE 1028]

4.5.3.2.2. Examples

4.5.3.3. Testing

5. Requirements Elicitation

5.1. The concept of Requirements Elicitation

5.1.1. Business Requirements Elicitation

5.1.1.1. 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

5.1.2. The purpose of Business Requirements Elicitation

5.1.2.1. Identification of:

5.1.2.1.1. Desired functions

5.1.2.1.2. Attributes

5.1.2.1.3. Quality characteristics

5.1.2.1.4. Limitations and expectations

5.1.2.1.5. Requirements resulted from external regulations, norms etc.

5.1.2.1.6. Orientation of the requirements toward the project vision

5.1.2.2. Establishing the finał scope

5.1.2.3. Establishing business design of the system

5.1.2.4. Excluding functions that the customer does not want and need

5.1.3. Techniques for Requirements Elicitation

5.1.3.1. Q.uestionnaires

5.1.3.1.1. What is it?

5.1.3.1.2. Quastionnaire can collect information about:

5.1.3.1.3. 2 types:

5.1.3.1.4. Process:

5.1.3.1.5. Questions

5.1.3.2. lnterviews

5.1.3.2.1. What is it?

5.1.3.2.2. 2 types:

5.1.3.2.3. Process:

5.1.3.3. Self-recording

5.1.3.3.1. The user records his own activities (AS-IS).

5.1.3.3.2. Documents all steps, inputs and resources needed to complete a task / procedure.

5.1.3.3.3. The user describes also changes, desires and needs.

5.1.3.3.4. Advantages:

5.1.3.3.5. Disadvantages

5.1.3.4. Customer's representative

5.1.3.4.1. 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.

5.1.3.4.2. Assumption:

5.1.3.4.3. The representative:

5.1.3.5. Identification on the basis of existing documents

5.1.3.5.1. Allows to elicit requirements of an existing system by studying available documentation and identifying relevant information.

5.1.3.5.2. Used to gather details of the AS IS environment for the solution:

5.1.3.5.3. Process:

5.1.3.6. Reuse (Reusing the specification of a certain project)

5.1.3.6.1. Reuse of documentation / solution from previous projects.

5.1.3.6.2. Requirements specification prepared for previous project can be used in another, similar, project.

5.1.3.6.3. Shorts the duration of Business Analysis.

5.1.3.6.4. Important notice:

5.1.3.7. Brainstorming

5.1.3.7.1. A way of eliciting many creative ideas for an area of interest.

5.1.3.7.2. Produces numerous creative ideas about any given "central question" or topic.

5.1.3.7.3. Promotes diversion type of thinking.

5.1.3.7.4. Brainstorming to detail identified requirements and find new ones

5.1.3.7.5. Brainstorming helps answer specific questions:

5.1.3.7.6. Process:

5.1.3.8. Field observation

5.1.3.8.1. Conducting an assessment of the user's work environment.

5.1.3.8.2. Studying people performing their jobs-without any interventions!

5.1.3.8.3. Observation is usually used:

5.1.3.8.4. 2 types:

5.1.3.9. Apprenticing

5.1.3.9.1. Apprenticing is a process of learning from the user his job

5.1.3.9.2. The customer teaches the Business Analyst.

5.1.3.9.3. Master and student approach.

5.1.3.9.4. Useful when the customer is not able to provide full time support of his employees.

5.1.3.9.5. Overcomes the problem of abstract thinking and expressing the tasks in words

5.1.3.9.6. Users can always refer to the actual case and explain things on examples.

5.1.3.10. Workshops (after each iteration)

5.1.3.10.1. Workshop is a structured way to capture requirements.

5.1.3.10.2. May be used to scope, discover, define, prioritize and reach closure on requirements for the solution.

5.1.3.10.3. Its is not a traditional meeting.

5.1.3.10.4. Focused event attended by key stakeholders and subject matter experts for a short period.

5.1.3.10.5. Workshop roles

5.1.3.10.6. Process:

5.1.3.11. Prototyping

5.1.3.11.1. Helps uncover and visualize interface requirements before the solution is designed or developed

5.1.3.11.2. Prototyping to visualize implementation of identified requirements

5.1.3.12. Focus groups

5.1.3.12.1. Used to elicit ideas and attitudes about a specific problem in an interactive group environment

5.1.3.13. Interface Analysis

5.1.3.13.1. Helps to clarify the boundaries of the system

5.1.3.14. Important notice:

5.1.3.14.1. The best results are achieved when mixing some techniques.

5.1.4. Requirements quality characteristics

5.1.4.1. Functionality

5.1.4.2. Reliability

5.1.4.3. Usability

5.1.4.4. Efficiency

5.1.4.5. Maintainability

5.1.4.6. Portability

5.2. Requirements Scope Management

5.2.1. Managing requirements scope is considered as managing the list of the requirements of some or all of the following projects

5.2.1.1. System or component development

5.2.1.2. Process improvement

5.2.1.3. Organizational change

5.2.2. Requirements Scope Management

5.2.2.1. 1. Establishing requirements baseline

5.2.2.2. 2. Creating a requirements structure for traceability

5.2.2.3. 3. Identifying impact to external systems and other areas of the project

5.2.2.4. 4. Identifying changes in the scope resulting from requirements changes

5.2.2.5. 5. Maintaining scope approval

5.3. Establishing requirements baseline

5.3.1. All requirements identified and approved by stakeholders must be baselined

5.3.2. The baseline

5.3.2.1. Is a base for further system development

5.3.2.2. A point of reference for any changes in the content / scope of requirements

5.3.3. Creating a requirements structure for traceability

5.3.3.1. Requirements traceability is necessary for managing changes to the requirements done after the requirements are baselined

5.3.4. Impact to other systems / areas

5.3.4.1. 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

5.3.5. Changes in requirements scope affects

5.3.5.1. Project schedule

5.3.5.2. Project cost

5.3.5.3. Project and product risk

5.3.5.4. Project Resources

5.3.5.5. External interface to another systems or hardware

5.3.6. Identifying changes in the scope

5.3.6.1. Requirements are not constant throughout the project's lifecycle

5.3.6.2. Impact on the project

5.3.6.2.1. Minor change -> no impact on the project scope, time or cost

5.3.6.2.2. Major change -> may drastically change the project scope, time or cost

5.3.6.3. Major changes examples

5.3.6.3.1. Changing business logic

5.3.6.3.2. Changing process flow for critical functionality

5.3.7. Maintaining scope approval

5.3.7.1. The list of requirements must be approved and baselined

5.3.7.2. The approved list of requirements is a mutual understanding between the customer and the vendor team about the requirements

5.3.7.3. Changes in the approved list of requirements must be managed via Change Management procedures

5.4. Requirement Traceability

5.4.1. Goals

5.4.1.1. Scope management

5.4.1.2. Impact analysis

5.4.1.3. Coverage analysis

5.4.1.4. Proof of implementation

5.4.1.5. Use of the requirement

5.4.1.6. Defect reports

5.4.2. Traceability

5.4.2.1. Traceability is an association existing between requirements when more detailed requirements are associated with the higher level requirements (needs and features)

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

5.4.2.3. Traceability between requirements and other project artefacts aIlows to ensure all requirements are met

5.4.2.4. Representing traceability on UML diagrams

5.4.3. Tool support

5.4.3.1. Requirements Management software

5.4.3.1.1. Storing all requirements of all specifications of a technical system under development

5.4.3.1.2. Arranging requirements in structures (specification tree)

5.4.3.1.3. Linking each one to the "parent" requirement in the higher specification

5.4.3.2. Requirements are realized into:

5.4.3.2.1. Design artefacts

5.4.3.2.2. Implementation

5.4.3.2.3. Test cases

5.4.3.3. Artefacts are traced back to the requirements.

5.4.4. Tools

5.4.4.1. Requirements Traceability Matrix

5.4.4.1.1. Track all requirements and check if they are being met by the current process

5.4.4.1.2. Assist in the creation of project's documentation

5.4.4.1.3. Supports verification process

5.4.4.1.4. RTM is created at the beginning of a project

5.4.4.2. Bi-directional Traceability Matrix

5.4.4.2.1. Bi-directional Traceability Matrix between Software Requirements Specification (SRS) and Software Design Document (SDD )

5.4.5. Software

5.4.5.1. i.e. Enterprise Analyst

5.4.5.2. i.e. Enterprise Architect

5.4.5.3. …

5.5. Requirements Documentation

5.5.1. Requirements document

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

5.5.1.2. No project deliverable information - constant time

5.5.1.3. Formalizes the project scope

5.5.2. Purpose of the requirements document

5.5.2.1. Structuring the requirements

5.5.2.2. Providing clear and unambiguous explanation of the requirements

5.5.2.3. A basis for implementation and testing

5.5.2.4. A basis for requirement management

5.5.2.4.1. Documentation is a baseline

5.5.3. Content of a requirements document

5.5.3.1. Assumptions

5.5.3.2. Business Process Description (BPD)

5.5.3.2.1. An executive summary of an initiative

5.5.3.2.2. Describes the problem and the proposed solution in high-level terms

5.5.3.3. Business Requirements Document (BRD)

5.5.3.3.1. Describes the behavior required of a software application

5.5.3.3.2. Primarily describes the business requirements

5.5.3.3.3. The target audience is the customer and users

5.5.3.4. Dependencies

5.5.3.5. Functional requirements

5.5.3.6. Introduction

5.5.3.7. Non-functional requirements

5.5.3.8. Overall description

5.5.3.9. Purpose of the product

5.5.3.10. Regulations

5.5.3.11. Request for Proposal / Request for Quotation (RFP / RFQ)

5.5.3.11.1. Distributed to parties outside the organization

5.5.3.11.2. Basis for the contracting of solution development services

5.5.3.12. Risks

5.5.3.13. Safety requirements Document acceptance

5.5.3.14. Secrecy clause

5.5.3.15. Software Requirements Specification (SRS)

5.5.3.15.1. Also known as a System Requirements Specification

5.5.3.15.2. Describes the behavior and implementation of a software application

5.5.3.15.3. The target audience is the development team

5.5.3.16. Stakeholders

5.5.3.17. Standards

5.5.3.18. ...

5.5.4. Common Document Formats

5.5.4.1. Software Requirements Specification (SRS)

5.5.4.1.1. A description of the problem domain

5.5.4.1.2. Decomposition of the problem domain

5.5.4.1.3. Description of the functional requirements

5.5.4.1.4. Description of the non-functional requirements

5.5.4.1.5. Assumptions and constraints affecting the solution

5.5.4.1.6. Requirements attributes and traceability information

5.5.5. Construction of a requirement

5.5.5.1. Describe business justification for the requirement

5.5.5.2. Identify the business process

5.5.5.3. Identify the stakeholders

5.5.5.4. Identify the limitations and assumptions

5.5.5.5. Describe the context

5.5.5.6. Describe the requirement

5.5.5.6.1. Input

5.5.5.6.2. Output

5.5.5.6.3. Resources

5.5.5.6.4. Quality characteristics (if applicable)

5.5.5.7. Provide the graphical model (if applicable)

5.5.5.8. Describe risks

5.5.5.9. Provide references

5.5.6. Guidelines for the requirements document

5.5.6.1. The requirements must be unambiguous, precise and understandable

5.5.6.2. Superfluous information should be avoided

5.5.6.3. Templates as an aid to limit language

5.5.6.4. Models and diagrams makes the document clear and more understandable

5.5.6.5. Use formal graphical notation to express complex requirements, dependencies and relationships

5.5.7. Common Document Problems

5.5.7.1. Trivialities

5.5.7.1.1. Lengthy descriptions of commonly known issues

5.5.7.2. Information out of scope

5.5.7.2.1. Information without added value to the description of the solution

5.5.7.3. Thinking in solutions

5.5.7.3.1. Description of solutions

5.5.7.3.2. Requirement specification determining the technical design

5.5.7.4. Redundant details

5.5.7.4.1. Details unnecessarily complicating the implementation

5.5.7.4.2. Implementation details

5.5.7.5. Lacking rationale

5.5.7.5.1. No description of what shall be achieved with the solution (inc. concrete numbers and metrics)

5.6. Requirements Communication

5.6.1. Requirements Communication

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

5.6.2. Communication

5.6.2.1. An ongoing and iterative activity

5.6.2.1.1. Presenting

5.6.2.1.2. Communicating

5.6.2.1.3. Verifying

5.6.2.1.4. Obtaining approval

5.7. The role of a Business Analyst

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

5.7.2. Consider and choose communication approach appropriate for the project

5.8. Requirements Communication process

5.8.1. 1. Preparing requirements communication Plan

5.8.2. 2. Managing requirements conflicts

5.8.3. 3. Establishing the most appropriate requirements format

5.8.4. 4. Creating requirements package

5.8.5. 5. Conducting requirements presentation

5.8.6. 6. Performing formal requirements review

5.8.7. 7. Obtaining requirements approval (Sign-off)

5.9. Requirement acceptance

5.9.1. Requirements should be agreed and accepted by all relevant stakeholders

5.9.2. All requirements must be formally approved

5.9.3. Formal agreement

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

5.10. Stakeholders with the acceptance authority

5.10.1. Business Sponsor

5.10.2. Project Managers

5.10.3. Business Analysts

5.10.4. Architects

5.10.5. Test / QA Manager

5.11. Standards

5.11.1. ISO 25000 (ISO/IEC 9126)

5.11.1.1. Defines a quality model with 6 categories:

5.11.1.1.1. Functionality

5.11.1.1.2. Reliability

5.11.1.1.3. Usability

5.11.1.1.4. Efficiency

5.11.1.1.5. Maintainability

5.11.1.1.6. Portability

5.11.2. IEEE 830

5.11.2.1. Recommended Practice for Software Requirements Specifications

5.11.3. IEEE 1233

5.11.3.1. Guide for Developing of System Requirements Specifications

5.11.4. IEEE 1362

5.11.4.1. Guide for Information Technology - System Definition

6. Major reasons of neglecting Business Analysis

6.1. Time praccure

6.2. Exclusive orientation towards fast results

6.3. Exclusive fixation on costs

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

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

6.5.1. Imprecise, ambiguous, contradictory or missing requirements

6.5.2. Requirements that change

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

6.6. Products of the business processes not known

6.7. Stakeholders not identified or identified only pertially

6.8. Business goals or needs not identified

6.8.1. The organization needs not satisfied

6.8.2. The business goals not achieved

7. Common pitfalls in Business Analysis

7.1. Bad quality of the requirements and / or business needs:

7.1.1. Incomplete

7.1.2. Inconsistent

7.1.3. Not measurable

7.1.4. Unclear objectives

7.1.5. Communication problems

7.1.6. Language barriers

7.1.7. Knowledge barriers

7.1.8. Vague formulation

7.1.9. Too formal formulations

7.1.10. Ambiguous, overly specified, unclear, impossible, contradictory requirements

7.1.11. Instability of the requirements (frequent changes)

7.1.12. Redundant description of requirements

7.1.13. Insufficient user invelvement

7.1.14. Overlooked user classes

7.1.15. Minimal specification

8. Business Analyst

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

8.1.1. source BABOK

8.2. “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.”

8.3. 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.

8.3.1. Product Scope

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

8.3.2. Project Scope

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

8.3.3. 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.

8.4. Business Analyst Role

8.4.1. A liaison among stakeholders

8.4.2. Identify, analyze, communicate and validate requirements for changes to:

8.4.2.1. Business processes

8.4.2.2. Policies

8.4.2.3. Information Systems

8.5. Business Analyst Major tasks

8.5.1. Requirements elicitation (identification)

8.5.2. Requirements analysis and modelling

8.5.3. Requirements realization planning

8.5.4. Requirements communication

8.5.5. Requirements documenting

8.5.6. Requirements validation

8.5.7. Requirements configuration management

8.5.8. Business solution proposal

8.6. Specific activities of Business Analyst

8.6.1. Identification

8.6.2. Developing

8.6.3. Managing the requirements

8.7. Business Bnalysts want to achieve the following outcomes

8.7.1. Reduce waste

8.7.2. Create solutions

8.7.3. Complete projects on time

8.7.4. Improve efficiency

8.7.5. Document the right requirements

8.7.6. Identify the root causes of problems

8.8. Activities of Business Analyst

8.8.1. Requirements Elicitation (identification)

8.8.2. Requirements Analysis

8.8.3. Requirements Specification

8.8.4. Requirements Management

8.8.4.1. Including Configuration Management

8.8.5. Requirements Communication

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

8.8.5.2. Consider and choose communication approach appropriate for the project

8.8.6. Requirements Documentation

8.8.7. Requirements Modeling

8.8.8. Requirements Validation

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

8.9.1. Analysis phase

8.9.1.1. Identification and evaluating of the current business processes (AS IS analysis)

8.9.1.2. Gathering initial requirements for needed business solution (TO BE analysis)

8.9.1.3. Creating and analyzing Business Case

8.9.1.4. Conducting feasibility study

8.9.1.5. Preparing ideas of business solution

8.9.2. Specification phase

8.9.2.1. Identifying and documenting business requirements on more detailed level

8.9.2.2. Supporting System Analyst in preparing detailed system specifications

8.9.2.3. Validating proposed software design with the customer and other stakeholders

8.9.2.4. Managing requirements changes

8.9.3. Development phase

8.9.3.1. Supporting development team during implementation

8.9.3.2. Validating increments of solution according to intended requirements and needs

8.9.3.3. Supporting testers in preparing test cases and test scripts at business level

8.9.3.4. Managing potential changes in requirements

8.9.4. Testing phase

8.9.4.1. Checking test results

8.9.4.2. Resolving issues related to defects or gaps in the requirements

8.9.4.3. Supporting preparing test cases for User Acceptance Testing

8.9.4.4. Supporting acceptance testers in executing test cases

8.10. When a Business Analyst is needed?

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

8.10.2. When a need for new functionalities appears

8.10.3. When the business changes

8.10.4. When the end users need support with working with the solution

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

9. Objectives of Business Analysis

9.1. Collect and document the business requirements

9.2. Design business solutions to resolve the business problems

9.3. Assist in the timely completion of the project by providing accurate requirements identification and analysis

9.4. 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

10. System Analyst

10.1. A System Analyst writes technical requirements from the business requirements.

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

11. Requirements

11.1. Requirements descriptors / categories

11.1.1. Requirements should be preceded by descriptors like:

11.1.1.1. Business requirements

11.1.1.2. User requirements

11.1.1.3. Functional requirements (FRs)

11.1.1.4. Non-functional requirements (NFRs)

11.2. Meaning and purpose of requirements

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

11.2.2. Customer expectations (stakeholders value)

11.2.3. Component of agreements, project plans

11.2.4. Setting of system boundaries, scope of delivery

11.3. Classification of requirements

11.3.1. Process requirements (project management / HOW)

11.3.1.1. Needs and limitations of the business processes (e.g., management or production processes)

11.3.1.1.1. e.g.

11.3.2. Product requirements (product delivery / WHAT)

11.3.2.1. Functional (F)

11.3.2.2. Non-functional (NF)

11.3.2.3. External

11.3.2.4. Internal

11.4. Types of requirements

11.4.1. Customer requirements (business requirements)

11.4.2. Solution / system requirements

11.4.3. Product / component requirements

11.5. Managing requirements conflicts

11.5.1. A conflict may arise on one or more documented requirements.

11.5.2. Requirements themselves could be in conflict.

11.5.3. 1. Record the conflict in the Issues Log

11.5.4. 2. Analyze the conflict and its source

11.5.5. 3. Resolve the conflict

11.5.5.1. Research (without a formal stakeholder session)

11.5.5.2. Meeting involving affected stakeholders

11.5.5.3. Interviews with other parties

11.5.6. 4. Keep an audit trail of the activity taken

11.5.7. 5. Obtain sign off for the resolution

11.5.8. 6. Document and distribute the results of resolution actions

11.6. Selecting the appropriate requirements format

11.6.1. Questions to be asked:

11.6.1.1. How detailed the requirements need to be?

11.6.1.2. What information is important to communicate?

11.6.1.3. What is the appropriate level of detail of the document?

11.6.1.4. What is the type of audience?

11.6.1.5. What is the stakeholder's preferred style of communication (technical vs. business)?

11.6.2. Requirements can be presented in various formats.

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

11.6.4. Helps to obtain stakeholder understanding and approval of the requirements.

11.6.5. The type of requirement influences the presentation technique.

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

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

11.6.8. e.g.

11.6.8.1. Diagrams

11.6.8.1.1. Process Workflows

11.6.8.1.2. Entity Relationship Diagram

11.6.8.1.3. Process Decomposition Diagram

11.6.8.1.4. UML Use Cases

11.6.8.2. Text

11.6.8.2.1. Textual templates

11.6.8.3. Prototyping

11.6.8.4. Additional formats

11.6.8.4.1. User manuals

11.6.8.4.2. Presentation slides

11.6.8.4.3. User stories

11.7. Creating a requirements package

11.7.1. A comprehensive requirements document to be presented to the stakeholders.

11.7.2. Packaging the requirements supports effective requirements communication.

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

11.7.4. Deliveries of the Business Analysis:

11.7.4.1. Assumptions

11.7.4.2. Business needs and objectives

11.7.4.3. Business process flow definition

11.7.4.4. Business requirements

11.7.4.5. Definition of the business process's products

11.7.4.6. Limitations

11.7.4.7. Stakeholders of the project

11.7.5. Process

11.7.5.1. 1. Determine which components of the overall requirements document should be grouped together.

11.7.5.2. 2. Determine the audience to whom the requirements will be presented

11.7.5.3. 3. Evaluate the documentation required based on the type of project

11.7.5.4. 4. Package the requirements for presentation

11.8. Requirements presentation

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

11.8.2. The objective:

11.8.2.1. To review, prioritize or to communicate status

11.8.2.2. To ensure quality of the requirements

11.8.2.3. To improve clarity

11.8.2.4. To obtain requirement's sign off

11.8.3. Subjects:

11.8.3.1. Business requirements

11.8.3.2. Data and behavior models

11.8.3.3. Functional requirements

11.8.3.4. Other models: Use Case models

11.8.3.5. Process / flow models

11.8.4. 2 types:

11.8.4.1. Formal presentation

11.8.4.1.1. Used to:

11.8.4.2. Informal presentation

11.8.4.2.1. Used to:

11.9. Formal requirements review

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

11.9.2. Participants should review the requirements before the session.

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

11.9.4. All questions, issues are recorded.

11.9.5. Agreed changes are recorded.

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

11.9.7. Significant changes may require a second review.

11.9.8. Process

11.9.8.1. 1. Prepare the document(s) to be reviewed

11.9.8.2. 2. Determine participants

11.9.8.3. 3. Organize / schedule the review

11.9.8.4. 4. Compile notes and results of the review

11.9.8.5. 5. Conduct the review

11.9.8.6. 6. Deliver document(s) to participants

11.9.8.7. 7. Re-review if necessary

11.10. Requirements quality characteristics (ISO 9126)

11.10.1. Functionality

11.10.2. Reliability

11.10.3. Usability

11.10.4. Efficiency

11.10.5. Maintainability

11.10.6. Portability

11.11. Requirements Scope

11.11.1. Managing requirements scope is considered as managing the list of the requirements of some or all of the following projects:

11.11.1.1. System or component development

11.11.1.2. Process improvement

11.11.1.3. Organizational change

11.12. Requirements Scope Management

11.12.1. 1. Establishing requirements baseline

11.12.1.1. All requirements identified and approved by stakeholders must be baselined.

11.12.1.2. The baseline:

11.12.1.2.1. Is a base for further system development

11.12.1.2.2. A point of reference for any changes in the content/scope of requirements

11.12.2. 2. Creating a requirements structure for traceability

11.12.2.1. Requirements traceability is necessary for managing changes to the requirements done after the requirements are baselined.

11.12.3. 3. Identifying impact to external systems and other areas of the project

11.12.3.1. 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.

11.12.3.2. Impact to other systems / areas

11.12.3.2.1. External interface to another systems or hardware

11.12.3.2.2. Project and product risk

11.12.3.2.3. Project cost

11.12.3.2.4. Project resources

11.12.3.2.5. Project schedule

11.12.4. 4. Identifying changes in the scope resulting from requirements changes

11.12.4.1. Requirements are not constant throughout the project's lifecycle.

11.12.4.2. Impact on the project:

11.12.4.2.1. Minor change -> no impact on the project scope, time or cost

11.12.4.2.2. Major change -> may drastically change the project scope, time or cost

11.12.5. 5. Maintaining scope approval

11.12.5.1. The list of requirements must be approved and baselined.

11.12.5.2. The approved list of requirements is a mutual understanding between the customer and the vendor team about the requirements.

11.12.5.3. Changes in the approved list of requirements must be managed via Change Management procedures.

11.13. Requirement Traceability

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

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

11.13.3. Goals of Traceability

11.13.3.1. Scope management

11.13.3.2. Coverage analysis

11.13.3.3. Impact analysis

11.13.3.4. Use of the requirement

11.13.3.5. Proof of implementation

11.13.3.6. Defect reports

11.13.4. Tool support by Requirements Management software

11.13.4.1. Storing all requirements of all specifications of a technical system under development

11.13.4.2. Arranging requirements in structures (specification tree)

11.13.4.3. Linking each one to the "parent" requirement in the higher specification

11.13.4.4. Requirements are realized into:

11.13.4.4.1. Design artefacts

11.13.4.4.2. Implementation

11.13.4.4.3. Test cases

11.13.4.5. Artifacts are traced back to the requirements.

11.13.5. Requirements Traceability Matrix (RTM)

11.13.5.1. RTM is created at the Traceability Matrix is beginning of a project,

11.13.5.2. used to:

11.13.5.2.1. Track all requirements and check if they are being met by the current process

11.13.5.2.2. Assist in the creation of project's documentation

11.13.5.2.3. Supports verification process

11.14. Requirements Documentation

11.14.1. Purpose

11.14.1.1. Structuring the requirements

11.14.1.2. Providing clear and unambiguous explanation of the requirements

11.14.1.3. A basis for implementation and testing

11.14.1.4. A basis for requirement management

11.14.1.4.1. Documentation is a baseline

11.14.2. Requirements Document

11.14.2.1. No project deliverable information

11.14.2.1.1. costand time

11.14.2.2. Formalizes the project scope

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

11.14.2.4. Guidelines

11.14.2.4.1. The requirements must be unambiguous, precise and understandable

11.14.2.4.2. Superfluous information should be avoided

11.14.2.4.3. Templates as an aid to limit language

11.14.2.4.4. Models and diagrams makes the document clear and more understandable

11.14.2.4.5. Use formal graphical notation to express complex requirements, dependencies and relationships

11.14.2.5. Quality attributes

11.14.2.5.1. Complete

11.14.2.5.2. Consistent

11.14.2.5.3. Modifiable

11.14.2.5.4. Traceable

11.14.3. Forms:

11.14.3.1. Graphical models

11.14.3.2. Mathematic representation

11.14.3.3. Mixed techniques

11.14.3.4. Written text

11.14.4. Content::

11.14.4.1. Introduction

11.14.4.2. Secrecy clause

11.14.4.3. Regulations

11.14.4.4. Standards

11.14.4.5. Stakeholders

11.14.4.6. Purpose of the product

11.14.4.7. Overall descriptio

11.14.4.8. Functional requirements (FR)

11.14.4.9. Non-functional requirements (NFR)

11.14.4.10. Assumptions

11.14.4.11. Dependencies

11.14.4.12. Risks

11.14.4.13. Safety requirements Document acceptance

11.14.5. Formats:

11.14.5.1. Vision

11.14.5.1.1. What is it?

11.14.5.1.2. An output of Enterprise Analysis.

11.14.5.1.3. Usually used in iterative development

11.14.5.2. Business Process Description (BPD)

11.14.5.2.1. An executive summary of an initiative.

11.14.5.2.2. Describes the problem and the proposed solution in high-level terms.

11.14.5.3. Business Requirements Document (BRD)

11.14.5.3.1. Describes the behavior required of a software application.

11.14.5.3.2. Primarily describes the business requirements.

11.14.5.3.3. The target audience is the customer and users

11.14.5.4. Request for Proposal / Request for Quotation (RFP/RFO.)

11.14.5.4.1. Distributed to parties outside the organization.

11.14.5.4.2. Basis for the contracting of solution development

11.14.5.5. Software Requirements Specification (SRS)

11.14.5.5.1. Also known as a System Requirements Specification.

11.14.5.5.2. Describes the behavior and implementation of a software application.

11.14.5.5.3. The target audience is the development team.

11.14.5.5.4. A description of the problem domain

11.14.5.5.5. Decomposition of the problem domain

11.14.5.5.6. Description of the functional requirements

11.14.5.5.7. Description of the non-functional requirements

11.14.5.5.8. Assumptions and constraints affecting the solution

11.14.5.5.9. Requirements attributes and traceability information

11.14.6. Common mistakes

11.14.6.1. Trivialities

11.14.6.1.1. Lengthy descriptions of commonly known issues

11.14.6.2. Information out of scope

11.14.6.2.1. Information without added value to the description of the solution

11.14.6.3. Thinking in solutions

11.14.6.3.1. Description of solutions

11.14.6.3.2. Requirement specification determining the technical design

11.14.6.4. Redundant details

11.14.6.4.1. Details unnecessarily complicating the implementation

11.14.6.4.2. Implementation details

11.14.6.5. Lacking rationale

11.14.6.5.1. No description of what shall be achieved with the solution (inc. concrete numbers and metrics)

11.15. Construction of a requirement (process)

11.15.1. 1. Describe business justification for the requirement

11.15.2. 2. Identify the business process

11.15.3. 3. Identify the stakeholders

11.15.4. 4. Identify the limitations and assumptions

11.15.5. 5. Describe the context

11.15.6. 6. Describe the requirement

11.15.6.1. Input

11.15.6.2. Output

11.15.6.3. Resources

11.15.6.4. Quality characteristics (if applicable)

11.15.7. 7. Provide the graphical model (if applicable)

11.15.8. 8. Describe risks

11.15.9. 9. Provide references

11.16. Requirements Communication

11.16.1. An ongoing and iterative activity

11.16.2. Process

11.16.2.1. 1. Preparing requirements communication plan

11.16.2.2. 2. Managing requirements conflicts

11.16.2.3. 3. Establishing the most appropriate requirements format

11.16.2.4. 4. Performing formal requirements review

11.16.2.5. 5. Conducting requirements presentation

11.16.2.6. 6. Creating requirements package

11.16.2.7. 7. Obtaining requirements approval (Sign-off)

11.17. Requirement Acceptance

11.17.1. Requirements should be agreed and accepted by all relevant stakeholders.

11.17.2. All requirements must be formally approved.

11.17.3. Formal agreement:

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

11.17.4. Stakeholders with the acceptance authority

11.17.4.1. Architects

11.17.4.2. Business Analysts

11.17.4.3. Business Sponsor

11.17.4.4. Project Managers

11.17.4.5. Test/QA Manager

11.17.5. Requirement acceptance consequences

11.17.5.1. The list of requirements is binding for both the vendor and the customer.

11.17.5.2. Any changes must be managed via Change Management.

11.18. Requirements Organization

11.18.1. Purpose

11.18.1.1. To determine the solution boundary

11.18.1.2. To determine the solution scope

11.18.1.3. To define the structure of requirements

11.18.2. Requirements are organized (structured) into packages

11.18.2.1. 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.

11.19. Requirements Decomposition

11.19.1. 3 types

11.19.1.1. Functional decomposition

11.19.1.1.1. 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.

11.19.1.1.2. Identifies the high-level functions

11.19.1.1.3. Breaks them down into sub-processes and activities

11.19.1.1.4. Used to:

11.19.1.1.5. Levels of detail:

11.19.1.2. Feature list decomposition

11.19.1.2.1. Feature is developed into completely described functional and supplemental requirements.

11.19.1.2.2. 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.

11.19.1.3. Goal decomposition

11.19.1.3.1. Allows ensuring the solution will satisfy stakeholder's needs

11.19.1.3.2. Breaks down high-level stakeholdergoals into lower-level goals

11.19.1.3.3. Lower-level goals have measurable objectives.

12. Glossary

12.1. Artefact

12.1.1. Describes the function, architecture, and design of software

12.1.2. Describes the process of development itself

12.1.3. All artefacts should be under version control.

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

12.1.5. e.g.

12.1.5.1. Business Case

12.1.5.2. Class diagrams

12.1.5.3. Design document

12.1.5.4. Project's plan

12.1.5.5. Requirements document

12.1.5.6. Risk assessment

12.1.5.7. Use cases

12.2. Business Analyst

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

12.2.1.1. source BABOK

12.3. Business Case

12.3.1. 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.

12.3.1.1. source BABOK

12.3.2. The Business Case describes the justification for the project.

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

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

12.4. Business Goal

12.4.1. Business Goal is an objective of an organization.

12.4.1.1. Short- or long-term.

12.4.1.2. Formulated by the requesting organization.

12.5. Business Need

12.5.1. A Business Need defines the business problem or opportunity.

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

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

12.6. Business Requirements Elicitation

12.6.1. 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.

12.7. Business process

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

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

12.8. Decision Package

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

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

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

12.9. Enterprise Analysis

12.9.1. 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.

12.9.1.1. source BABOK

12.10. Feasibility Study

12.10.1. Analysis and evaluation of a proposed project to determine if it:

12.10.1.1. Is technically feasible

12.10.1.2. Is feasible within the estimated cost

12.10.1.3. Will be profitable

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

12.10.3. Also called Feasibility Analysis.

12.11. Requirement

12.11.1. [IEEE Std 610.12-1990]

12.11.1.1. 1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective.

12.11.1.2. 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.

12.11.1.3. 3. A documented representation of a condition or capability as in 1 or 2.

12.12. Requirements Communication

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

12.12.1.1. source BABOK

12.13. Requirements Communication

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

12.14. Requirements Document

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

12.15. Requirements Elicitation

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

12.15.1.1. source BABOK

12.16. Requirements signoff

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

12.16.2. * May involve final review of requirements.

12.16.3. * The approval may be recorded either physically or electronically.

12.17. Risk Assessment

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

12.18. Traceability

12.18.1. 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:

12.18.1.1. Requirements

12.18.1.2. Detailed requirements and design models

12.18.1.3. Detailed requirements and test cases

12.18.1.4. High level requirements and test cases

12.18.1.5. Requirements and design artefacts

12.19. lnterview

12.19.1. 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.

12.20. Feature

12.20.1. 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.

12.20.1.1. source BABOK

13. Knowledge Areas in Business Analysis

13.1. Enterprise Analysis

13.2. Requirements Planningand Management

13.3. Requirements Elicitation (Identification)

13.4. Requirements Communication

13.5. Requirements Analysis and Documentation

13.6. Solution Assessment and Validation

14. Reasons why projects fail

14.1. UK Cabinet Office - 8 Common Causes of Project Failure

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

14.1.2. Lack of clear senior management ownership and leadership

14.1.3. Lack of effective engagement with stakeholders

14.1.4. Lack of skills and proven approach to project and risk management

14.1.5. Project not broken down into manageable steps

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

14.1.7. Lack of understanding of and contact with suppliers

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

14.2. Based on Standish Report.

14.2.1. 10. Standard Tools and Infrastructure

14.2.2. 9. Formal Methodology

14.2.3. 8. Skilled Resources

14.2.4. 7. Financial Management

14.2.5. 6. Project Manager Expertise

14.2.6. 5. Agile Process

14.2.7. 4. Optimizing Scope

14.2.8. 3; Cieor Business Objectives

14.2.9. 2. Executive Management Support

14.2.10. 1. User Involvement

15. Stakeholders

15.1. Classification

15.1.1. Stakeholders on the vendor's side (selected)

15.1.1.1. Project Managers

15.1.1.2. Business and System Analysts

15.1.1.3. Developers and Architects

15.1.1.4. Database designers

15.1.1.5. GUI designers

15.1.1.6. Technical writers

15.1.1.7. Testers and Quality Assurance stuff

15.1.1.8. Installation and Operations personnel

15.1.2. Stakeholders on the customer's side (selected)

15.1.2.1. Customer representative (so called "Business")

15.1.2.2. Project sponsor

15.1.2.3. End users (if are derived from the customer company)

15.1.2.4. The person who installs and maintains the system

15.1.2.5. Quaiity Assurance / Testers

15.1.2.6. Installation and Operations personnel

15.1.3. External stakeholders

15.1.3.1. End users (clients of the customer)

15.1.3.2. Other organizations (regulation entities)

15.2. Stakeholder identification

15.2.1. Techniques

15.2.1.1. Analyzing relationships with external organizations (suppliers etc.)

15.2.1.1.1. Suppliers, subcontractors, partners - they can be affected by the solution as well.

15.2.1.1.2. Their processes may also influence our solution.

15.2.1.2. Identifying owners of business processes

15.2.1.3. Analyzing organizational structure of the customer's organization

15.2.1.4. Exploring the target market of the customer's organization

15.2.1.5. Analyzing relationships with external organizations

15.2.1.6. Investigating the business domain

15.2.1.6.1. internal/external customers and subcontractors allows to find stakeholders.

15.2.1.7. Identifying owners of business processes

15.2.1.7.1. After identification of processes, the processes' owners have to be determined.

15.2.1.7.2. Owners of the processes affected by the solution will be stakeholders of the initiative.

15.2.1.8. Analyzing organizational structure of the customer's organization

15.2.1.8.1. 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).

15.2.1.9. Exploring the target market of the customer's organization

15.2.1.9.1. End customers, end users, institutions and other organizations affected by or affecting the solution.

15.2.1.10. Investigating the business domain

15.3. Stakeholder identification problems

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

15.3.2. Not clear responsibilities in the customer's organization

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

15.3.4. Gaps in the analysis resulted in missing processes and activities

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

15.4.1. Identify all stakeholders and their needs.

15.4.2. Find a common understanding of the purpose of a system.

15.5. Stakeholders value

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

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

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

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

15.5.5. Value is not linearly related to a system improvement:

15.5.5.1. A small change in an attribute level could add immense perceived value for one group of stakeholders for relatively low cost.

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

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

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

16. Enterprise Analysis

16.1. Activities of the Enterprise Analysis

16.1.1. Determining business opportunities

16.1.2. Developing strategic goals to be achieved by the organization

16.1.3. Developing a strategic plan allowing to plan and execute the goals

16.1.4. Understanding and developing the business architecture

16.1.5. Determining the optimum project investment path for the organization, including:

16.1.5.1. Implementation of new business and technical system solutions

16.1.5.2. Implementation of process or organizational changes

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

16.1.7. Initiating projects

16.2. Enterprise Analysis is conducted:

16.2.1. As a stand-alone project

16.2.1.1. in large and complex organizations

16.2.2. By customer organization - before involving the vendor

16.2.2.1. the results are provided as part of initial requirements (in small organizations)

16.2.3. Not conducted at all

16.2.3.1. if the goal of the project is clear and measurable

16.3. Enterprise Analysis activities:

16.3.1. Identification of business processes

16.3.2. Creating the Business Architecture

16.3.3. Conducting Feasibility Studies

16.3.4. Conducting the initial Risk Assessment

16.3.5. Preparing the Business Case

16.3.6. Scoping and defining the new business opportunity

16.3.7. Preparing the Decision Package

16.4. Business Architecture

16.4.1. Defines an organization's current and future capabilities.

16.4.1.1. High level business environment

16.4.1.2. Long term goals and objectives

16.4.1.3. Stakeholders

16.4.1.4. The businesses strategy

16.4.1.5. The external environment

16.4.1.6. The technological environment

16.5. Risk Assessment

16.5.1. 1. Identifying project risks

16.5.1.1. 1. Identifying and analyzing business risks

16.5.1.2. 2. Identifying and analyzing financial risks

16.5.1.3. 3. Identifying and analyzing technical risks

16.5.2. 2. Assessing risk probability and impact

16.5.3. 3. Planning risk responses

16.5.4. 4. Assessing organizational readiness / calcuiating an overall risk rating

16.6. Business process

16.6.1. Characteristics of a Business Process

16.6.1.1. Has a goal

16.6.1.2. Has specific inputs

16.6.1.3. Has specific outputs

16.6.1.4. Uses resources

16.6.1.5. Has a number of activities performed in some order

16.6.1.6. May affect more than one organizational unit

16.6.1.7. Creates value for the customer

16.6.2. Purpose of Business Process's identification

16.6.2.1. Understanding the goals of the organization.

16.6.2.2. Determining activities and the flow required to achieve the planned business and strategic goals.

16.6.2.3. Finding gaps and non-effective parts of the process to optimize the process.

16.7. Business Goal

16.7.1. Qualities of Business Goals

16.7.1.1. Specificity

16.7.1.2. Optimism

16.7.1.3. Realism

16.7.1.4. Short and long term

16.7.2. Importance of setting Business Goals

16.7.2.1. Provides a vision of what the organization wants to accomplish.

16.7.2.2. Provides a clear picture of what the organization is trying to do with the business.

16.7.2.3. Allows to understand and maintain a commitment to the business main objectives.

16.7.2.4. It gives a metric to measure organization's progress.

16.7.3. SMART

16.7.3.1. A system and a tool for effective goal setting and goal quality.

16.7.3.2. All goals should be SMART.

16.7.3.2.1. S - Specific

16.7.3.2.2. M - Measurable

16.7.3.2.3. A - Attainable

16.7.3.2.4. R - Relevant

16.7.3.2.5. T - Timely

16.7.3.3. SMART - example of business goal

16.7.3.3.1. Obtain 3 new billion dollar corporate clients in the New York property insurance market by the end of this fiscal year through networking.

16.8. Business Need

16.8.1. Who defines the Business Need?

16.8.2. The person or group requesting the project, including:

16.8.2.1. High-level Subject Matter Expert (SME) [Pyzdek, Thomas and Paul A. Keller]

16.8.2.2. Regulatory / compliance body

16.8.2.3. Sponsor

16.8.2.4. Steering committee

16.8.2.5. Subject Matter Expert (SME)

16.8.3. e.g.

16.8.3.1. Branch managers need an access to transaction's reports and statistics.

16.8.3.2. Insurance agents need a mobile application to analyze and document claims.

16.8.3.3. Controlling department needs an access to structured information from all systems operating in the organization.

16.9. Business Case

16.9.1. A Business Case may cover the following topics:

16.9.1.1. Information about the opportunity in terms of the market trends, competitive environment and expected market penetration

16.9.1.2. Qualitative and quantitative benefits

16.9.1.3. Estimates of costand time to breakeven

16.9.1.4. Profit expectations

16.9.1.5. Follow-on opportunities

16.9.1.6. Cash flow consequences of the action, over time, and the methods used for quantifying benefits and costs

16.9.1.7. The impact of the project on the business operations

16.9.1.8. The impact of the project on the technology infrastructure

16.9.1.9. Constraints associated with the proposed project

16.9.1.10. Estimated budget

16.9.1.11. Alignment with priorities established by the business

16.9.2. Main idea of a Business Case

16.9.2.1. A Business Case demonstrates that:

16.9.2.1.1. The solution proposal has been analyzed properly

16.9.2.1.2. The full benefits will be realized in time

16.9.2.1.3. Any technical aspects have been thoroughly evaluated

16.9.3. Purpose of a Business Case

16.9.3.1. Buildingthe Business Case allows the organization to

16.9.3.1.1. 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

16.9.3.1.2. Justify the value of proposals to the organization

16.9.3.1.3. Reject any proposals that are not of proven and measurable value

16.9.3.1.4. Decide if the proposal is of value to the business and is achievable in comparison to alternative proposal submitted

16.9.3.1.5. Track and measure the progress and achievements of the business case

16.9.3.1.6. Ensure that projects with inter-dependencies are undertaken in the optimum sequence

16.9.4. Content of a Business Case

16.9.4.1. Reference

16.9.4.1.1. Project name/reference

16.9.4.1.2. Origins/background/curr ent state

16.9.4.2. Context

16.9.4.2.1. Business objectives/opportunities

16.9.4.2.2. Business strategic alignment (priority)

16.9.4.3. Value Proposition

16.9.4.3.1. Desired business outcomes

16.9.4.3.2. Business benefits

16.9.4.3.3. Quantified benefits value

16.9.4.3.4. Costs

16.9.4.3.5. ROI Financial scenarios

16.9.4.3.6. Risks / costs of not proceeding

16.9.4.3.7. Project risks (to project, benefits and business)

16.9.4.4. Focus

16.9.4.4.1. Problem/solution scope

16.9.4.4.2. Assumptions

16.9.4.4.3. Constraints

16.9.4.4.4. Options identified / evaluated

16.9.4.4.5. Size assessment

16.9.4.4.6. Scale assessment

16.9.4.4.7. Complexity assessment

16.9.4.5. Deliverables

16.9.4.5.1. Outcomes, deliverables and benefits planned

16.9.4.5.2. Organizational areas impacted (internally and externally)

16.9.4.5.3. Key stakeholders

16.9.4.5.4. Dependencies

16.9.4.6. Workload

16.9.4.6.1. Approach

16.9.4.6.2. Phase/stage definitions

16.9.4.6.3. Project activities

16.9.4.6.4. Technical delivery activities

16.9.4.6.5. Workload estimate/breakdown

16.9.4.6.6. Project plan

16.9.4.6.7. Project schedule

16.9.4.7. Required resources

16.9.4.7.1. Project leadership team

16.9.4.7.2. Project governance team

16.9.4.7.3. Team resources

16.9.4.7.4. Funding

16.9.4.8. Commitments

16.9.4.8.1. Project control

16.9.4.8.2. Reporting processes

16.9.4.8.3. Deliverables schedule

16.9.4.8.4. Financial budget/schedule

16.9.5. Quality attributes of a Business Case

16.9.5.1. Accountable

16.9.5.1.1. commitments for the delivery of benefits and management of costs are clear

16.9.5.2. Adaptable

16.9.5.2.1. adjusted to the size and risk of the proposal

16.9.5.3. Business oriented

16.9.5.3.1. concerned with the business capabilities / impact

16.9.5.4. Consistent

16.9.5.4.1. every project addresses the same basic business issues

16.9.5.5. Transparent

16.9.5.5.1. key elements can be justified

16.9.5.6. Understandable

16.9.5.6.1. the content is clear, relevant and logical

16.9.6. Procedure of building a Business Case

16.9.6.1. 1. Identify and quantify the benefits

16.9.6.1.1. Measure the benefits of the recommended solution {qualitative and quantitative gains to the enterprise).

16.9.6.1.2. Benefits should be quantified.

16.9.6.1.3. Benefits of a non-financial nature should be listed.

16.9.6.1.4. Estimates should be linked back to strategic goals.

16.9.6.2. 2. Identify and quantify the costs

16.9.6.2.1. Estimate the total net cost of the solution.

16.9.6.2.2. Estimate:

16.9.6.3. 3. Prepare the Business Case

16.9.6.3.1. Develop the Business Case at the appropriate level of detail.

16.9.6.3.2. Remember it should demonstrate project viability and secure a go/no go decision.

16.9.6.4. 4. Determine the measurement process for the costs and benefits

16.9.6.4.1. Describe how the benefits will be assessed and evaluated.

16.9.6.4.2. Build a plan for benefit measurement and reporting.

16.9.7. Sample structure of a Business Case

16.9.7.1. 1. Executive summary

16.9.7.2. 2. Introduction and summary

16.9.7.2.1. Project rationale for preferred option

16.9.7.2.2. Current business process

16.9.7.2.3. Description of the problem

16.9.7.2.4. Opportunity

16.9.7.2.5. Project objectives

16.9.7.2.6. Project scope

16.9.7.2.7. Business benefits

16.9.7.2.8. Project costs

16.9.7.2.9. Assumptions

16.9.7.2.10. Potential business and staff impact analysis

16.9.7.2.11. Potential technology impact analysis

16.9.7.2.12. Implementation plan

16.9.7.3. 3. Approach

16.9.7.3.1. Financial metrics

16.9.7.3.2. Privacy impact assessment

16.9.7.3.3. Alternative evaluation criterion

16.9.7.4. 4. Key selection criterion

16.9.7.4.1. Weighting

16.9.7.4.2. Constraints and limitations

16.9.7.5. 5. Preferred alternative

16.9.7.5.1. Business benefits

16.9.7.5.2. Alternative costs

16.9.7.5.3. Assumptions

16.9.7.5.4. Potential business and staff impact analysis

16.9.7.5.5. Other issues

16.9.7.6. 6. Risk Management Plan

16.9.7.6.1. Risk assessment

16.9.7.6.2. Risk response

16.9.7.6.3. Benefit realization

16.9.7.7. 7. Conclusion and recommendations

17. Solution scope

17.1. Determining solution scope

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

17.1.2. A base for detailed requirements development.

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

17.2. Techniques to determine solution scope

17.2.1. Work Breakdown Structure (WBS)

17.2.1.1. A decomposition of work required to complete a project.

17.2.2. Product Breakdown Structure (PBS)

17.2.2.1. A decomposition of the components of the product.

17.2.3. System Interface Analysis

17.2.3.1. Work required to integrate the new solution into the business and technical environments.

17.3. UML Use Cases

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

17.3.2. Shows the connections with external systems and actors.

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

19. Requierements related standards

19.1. ISO 25000 (ISO / IEC 9126)

19.1.1. Defines a quality model with 6 categories

19.1.1.1. Efficiency

19.1.1.2. Functionality

19.1.1.3. Maintainability

19.1.1.4. Portability

19.1.1.5. Reliability

19.1.1.6. Usability

19.2. IEEE 830

19.2.1. Recommended Practice for Software Requirements Specifications

19.3. IEEE 1233

19.3.1. Guide for Developing of System Requirements Specifications

19.4. IEEE 1362

19.4.1. Guide for Information Technology - System Definition

20. Interactive Glossary

20.1. Interactive IQBBA® Glossary

21. 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!)

21.1. 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.

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

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

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

21.1.4. http://www.miroslawdabrowski.com

21.1.5. https://twitter.com/mirodabrowski

21.1.6. miroslaw_dabrowski

22. Business Analysis Process Planning

22.1. Impact of a Business Analysis

22.1.1. Business Analysis provides input information to the following processes:

22.1.1.1. Project management (scope planning, scheduling and estimating development and testing)

22.1.1.2. System analysis

22.1.1.3. Design (system specification and architecture)

22.1.1.4. Implementation -Testing

22.1.2. Roles affected by a Business Analysis:

22.1.2.1. Project manager

22.1.2.2. Developers

22.1.2.3. System analysts

22.1.2.4. QA and Testers

22.1.2.5. Architects

22.1.3. Requirements Communication

22.1.3.1. Ongoing, iterative activity.

22.1.3.2. Done in parallel with Requirements Elicitation, Analysis and Documentation.

22.1.3.3. Includes:

22.1.3.3.1. Presenting

22.1.3.3.2. Communicating

22.1.3.3.3. Verifying

22.1.3.3.4. Gaining approval of the requirements

22.1.3.4. The main purpose of planning the Business Analysis communication is to define:

22.1.3.4.1. How to receive, distribute, access, update and escalate information to and from project stakeholders.

22.1.3.4.2. How to organize schedule and structure of communication within a project.

22.1.4. Communication Planning

22.1.4.1. Business Analysis activities/deliveries can be communicated in formal and informal way.

22.1.4.2. Communication activity should consider what kind of issues to be communicated:

22.1.4.2.1. Changes

22.1.4.2.2. Consequences

22.1.4.2.3. Information

22.1.4.2.4. Needs

22.1.4.2.5. Risks

22.1.4.3. Common ways of communication:

22.1.4.3.1. Documentation

22.1.4.3.2. Formal review

22.1.4.3.3. Informal review

22.1.4.3.4. Presentation

22.1.4.3.5. Workshop

22.1.5. Elements of Requirements Communication

22.1.5.1. Requirements communication plan

22.1.5.2. Managing requirements conflicts

22.1.5.3. Selecting the appropriate requirements format

22.1.5.4. Creating a requirements package

22.1.5.5. Requirements presentation

22.1.5.6. Formal requirements review

22.1.6. Requirements communication plan

22.1.6.1. How and when the BA will work with project stakeholders.

22.1.6.2. On small projects it may be very brief and may not be formally documented.

22.1.6.3. On large and complex projects it may be included as part of the project initiation documentation.

22.2. Requirements Engineering process planning

22.2.1. Goal

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

22.2.2. Determines the main activities and roles.

22.2.3. Includes definingthe process of managing Change Requests.

22.2.4. Factors to be considered in planning

22.2.4.1. Type of project:

22.2.4.1.1. Different projects types require a different amount of documentation, different processes and result in different deliverables.

22.2.4.2. Communication formality:

22.2.4.2.1. Communication formality varies between projects, projects' phases and stakeholders.

22.2.4.2.2. More formal when:

22.2.4.3. Communication frequency:

22.2.4.3.1. Communication frequency will differ among stakeholder for every form of communication.

22.2.4.3.2. Communicating Business Analysis's deliveries usually follows a schedule:

22.2.4.4. Geographical location:

22.2.4.4.1. Geographic disparity as a factor limiting communication possibilities.

22.2.4.4.2. When stakeholders live in different time zones communication (calls, team meetings) must be adjusted to the capabilities.

22.2.4.5. Culture:

22.2.4.5.1. Especially important in case of international projects.

22.2.4.5.2. Culture may determine the preferred form of communication (e-mails instead of calls, face-to-face meetings instead of e-conferences).

22.2.5. Inputs for the Requirements Engineering

22.2.5.1. Business Analysis approach

22.2.5.1.1. Overall approach used by an organization to derive the Business Analysis processes.

22.2.5.2. Business Analysis plan

22.2.5.2.1. Defines what deliverables (like requirements specification) will be produced and when.

22.2.5.3. Organizational process assets

22.2.5.3.1. A set of standard templates of processes existing in an organization.

22.2.6. Process

22.2.6.1. Non-core process concerning all disciplines of the systems development:

22.2.6.1.1. Identification of requirements (Elicitation)

22.2.6.1.2. Analysis of requirements

22.2.6.1.3. Specification of requirements

22.2.6.1.4. Changes of requirements

22.2.6.1.5. Quality assurance (with Verification and Validation)

22.2.7. Factors affecting communication

22.2.7.1. Availability of resources

22.2.7.2. Complexity

22.2.7.3. Organizational maturity

22.2.7.4. Organizational culture

22.2.7.5. Organizational standards

22.2.7.6. Stakeholders preference

22.2.8. Repository

22.2.8.1. The purpose of repository is to store requirements with theirs statuses.

22.2.8.2. Repository allows to group requirements (i.e. by status):

22.2.8.2.1. Underdevelopment

22.2.8.2.2. Under review

22.2.8.2.3. Approved

22.2.8.2.4. Changed

22.2.9. Traceability

22.2.9.1. The process of tracing requirements is defined by the Business Analyst.

22.2.9.2. The process has to be tailored to complexity of the project domain, stakeholder's needs, potential risks and available resources.

22.2.10. Selection of requirements attributes

22.2.10.1. Custom requirements attributes allow to include more detailed information in the description of requirements and to analyze them.

22.2.10.2. The attributes need to be planned and determined in the Requirements Elicitation phase.

22.2.11. Requirements prioritization

22.2.11.1. Requirements are not equal for stakeholders and don't have the same value for project success.

22.2.11.2. Priority as a factor of importance and impact should be determined by the Business Analysts along with proper stakeholders.

22.2.12. Configuration and Change Management

22.2.12.1. Configuration Management allows to identify and manage so called Configuration Items. A Configuration Items may be:

22.2.12.1.1. Single requirement

22.2.12.1.2. Requirements specification

22.2.12.2. Change Management is a process designed to track, identify and manage changes.

22.3. Configuration and Change Management process

22.3.1. 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

22.3.2. Configuration Management is a discipline applying technical and administrative tools and techniques to [IEEE 610]

22.3.2.1. Identify and document the functional and physical characteristics of a configuration item

22.3.2.2. Control changes requested to those characteristics

22.3.2.3. Record and report change processing and implementation status

22.3.2.4. Verify compliance with specified requirements

22.3.3. It allows managing changes in the requirements in an effective way

22.3.4. Change Management is a subdiscipline of the Configuration Management

22.3.5. Configuration Item

22.3.5.1. 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]

22.3.5.2. e.g.

22.3.5.2.1. Single requirements

22.3.5.2.2. Business needs

22.3.5.2.3. Requirements specifications

22.3.5.2.4. Business cases

22.3.5.2.5. Models

22.3.5.2.6. …

22.3.6. Baseline

22.3.6.1. A baseline is a stable well- defined set of attributes that serve as a comparison for system change

22.3.6.2. A system baseline is any set of system attribute specifications that formally define the state of a system, under specified conditions

22.3.7. The process of Configuration Management includes the following activities:

22.3.7.1. 1. Configuration Identification

22.3.7.1.1. The purpose of Configuration Identification is to determine the attributes that define every aspect of a configuration item

22.3.7.1.2. The attributes are recorded in configuration documentation and baselined

22.3.7.2. 2. Configuration Change Control

22.3.7.2.1. Configuration Change Control is a set of processes and approval stages required to:

22.3.7.3. 3. Configuration Status Accounting

22.3.7.3.1. Configuration Status Accounting is the ability to record and report on the configuration baselines associated with each configuration item at any moment of time

22.3.7.4. 4. Configuration Audits

22.3.7.4.1. Two types of Configuration Audits

22.3.8. Change Management Process:

22.3.8.1. 1. Identification of potential change

22.3.8.2. 2. Requesting new functionality

22.3.8.3. 3. Analysis of the change request

22.3.8.4. 4. Evaluating the change

22.3.8.5. 5. Planning the change

22.3.8.6. 6. Implementing the change

22.3.8.7. 7. Reviewing and closure of the change

22.3.8.8. 8. Roll out of the change

22.3.9. Change Request

22.3.9.1. An official document requesting modification of existing features, requirements or functions or new ones

22.3.9.2. Description of the current solution

22.3.9.3. Justification for a change

22.3.9.4. Suggested (desired) solution

22.3.9.5. Priority

22.3.10. Example of a Change Management

22.3.10.1. Defect report

22.3.10.2. Analysis of the report

22.3.10.3. Comparing with the specification

22.3.10.4. Discovering the mistake in the specification

22.3.10.5. Closing the defect report

22.3.10.6. Submitting a change request

22.3.10.7. Analysis of the change request

22.3.10.8. Approval of the change request

22.3.10.9. Implementation of the change request

22.3.10.10. Testing the implemented change

22.3.10.11. Change closure

22.3.11. Sources of a change

22.3.11.1. Defects found in the code, documentation, requirements

22.3.11.2. Business process improvement

22.3.11.3. System improvement efforts

22.3.11.4. New or changing requirements

22.3.11.5. External changes (regulation, law changes)

22.3.12. Planning of change implementation

22.3.12.1. Updating plans: Project Plan, Development Plan, Test Plan

22.3.12.2. Updating business and system documentation

22.3.12.3. Updating test cases and test scripts

22.3.12.4. Implementing the change (coding)

22.3.12.5. Testing by vendor or / and customer test team

22.3.12.6. Deploying the change to production environment (if applicable)

22.3.13. Change Life Cycle

22.3.13.1. Possible statuses

22.3.13.1.1. Submitted

22.3.13.1.2. Open

22.3.13.1.3. Approved

22.3.13.1.4. Rejected

22.3.13.1.5. Deferred

22.3.13.1.6. In implementation

22.3.13.1.7. Implemented

22.3.13.1.8. In testing

22.3.13.1.9. Tested

22.3.13.1.10. Closed

22.3.14. Change Control Board (CCB)

22.3.14.1. 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]

22.3.14.2. Project manager

22.3.14.3. Business analysts

22.3.14.4. Development team

22.3.14.5. Quality assurance team

22.3.14.6. Business manager

22.3.14.7. Customer

22.4. Tools and techniques selection

22.4.1. Categories of tools

22.4.1.1. Text processing

22.4.1.2. Table calculations

22.4.1.3. Modeling tools

22.4.1.4. Tools for Requirements Management

22.4.1.5. Process simulation tools

22.4.1.6. Configuration Management tools

22.4.1.7. Change Management tools

22.4.2. Factors affecting tools selection

22.4.2.1. The goal of the initiative

22.4.2.1.1. Different tools for extending existing solution, different for process optimization

22.4.2.2. The type of planned solution

22.4.2.2.1. Enterprise software vs. Entertainment software

22.4.2.2.2. Designing software vs. Improving business process

22.4.2.3. Organization's IT infrastructure

22.4.2.4. The scope of the solution

22.4.2.5. The complexity of the solution

22.4.2.6. Number of requirements

22.4.2.7. Dependencies between requirements

22.4.2.8. Traceability requirements

22.4.2.9. Standards and norms to be applied

22.4.2.10. Experience and skills of the project team

22.4.3. Common Business Analysis techniques

22.4.3.1. Brainstorming

22.4.3.2. CATWOE

22.4.3.3. Data Flow Diagrams

22.4.3.4. Five Why's

22.4.3.5. Functional

22.4.3.6. decomposition

22.4.3.7. Interviews

22.4.3.8. MoSCoW

22.4.3.9. MOST

22.4.3.10. PESTLE

22.4.3.11. Prototyping

22.4.3.12. Requirements

22.4.3.13. Workshop

22.4.3.14. Risk Analysis

22.4.3.15. Scenarios and Use Cases

22.4.3.16. SWOT

22.4.3.17. User stories

23. Competences

23.1. Domain knowledge

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

23.1.2. Required to

23.1.2.1. Assess business problems

23.1.2.2. Find the most appropriate solution

23.1.2.3. Provide measurement framework

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

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

23.1.5. Domain knowledge makes understanding and analyzing of business issues easier

23.1.6. Analytical skills

23.1.6.1. Financial analysis

23.1.6.2. Statistical analysis

23.1.6.3. Operations research

23.1.6.4. Requirements analysis

23.1.6.5. Systems analysis

23.1.7. Managerial skills

23.1.7.1. Project management capabilities

23.1.7.2. Understand organizational behavior

23.1.8. Technical skills

23.1.8.1. Working knowledge of science

23.1.8.2. Understanding of engineering principles

23.1.8.3. Ability to apply financial principles to feasibility studies

23.2. Soft skills

23.2.1. Soft skills are necessary

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

23.2.3. Common Business Analysis activities

23.2.3.1. Negotiation

23.2.3.2. Discussion

23.2.3.3. Conflicts solving

23.2.4. Negotiation skills

23.2.4.1. Negotiate to obtain data

23.2.4.2. Negotiate to resolve conflicts

23.2.4.3. Negotiate to agree requirements

23.2.5. Facilitation skills

23.2.6. Communication and writing skills

23.2.6.1. Communicate with all levels of management

23.2.6.2. Communicate with stakeholders of various knowledge

23.2.6.3. Precise in articulating ideas and thoughts

23.2.6.4. Relate with line workers

23.2.6.5. Good technical writing skills

23.2.6.6. Familiar with all forms of communications

23.2.6.7. Public speaking skills

23.3. Facilitation

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

23.3.2. It is a way of providing leadership without taking the reins

23.3.3. 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

23.3.3.1. The goal - to support others to achieve high performance

23.3.4. Facilitator's tasks and activities

23.3.4.1. Helping the group to define the goals and its objectives

23.3.4.2. Providing processes helping to use the time effectively and make high-quality decisions

23.3.4.3. Guiding group discussions

23.3.4.4. Documenting main ideas and concepts raised during the discussion

23.3.4.5. Supporting people in assessing their current skills and building new skills

23.3.4.6. Using consensus to enable the group to make agreed decisions

23.3.4.7. Managing conflicts

23.3.4.8. Helping the group to communicate effectively

23.3.4.9. Helping the group to access resources needed to make decisions

23.3.5. Key competences

23.3.5.1. Communicates well

23.3.5.2. Processes ideas from people

23.3.5.3. Shows a natural interest Listens well Maintains control Empowers the group Handles uncertainty

23.3.5.4. Is quick to connect with the group

23.3.5.5. Systems Analysis & Design

23.3.5.6. Manages people's expectations

23.3.5.7. Understands and constantly explains the process

23.3.5.8. Focuses on the business not on their own solutions

23.3.5.9. Communication skills Negotiating Group dynamics Listen / draw conclusions Running meetings

23.3.5.10. The facilitator must always stay neutral and stay on track

23.3.6. Tools and techniques

23.3.6.1. Engagement Strategies

23.3.6.2. Creating Participation

23.3.6.3. Generating and Organizing Data

23.3.6.4. Ignite Action

23.3.6.5. Mobilizing Energy

23.3.6.6. Initiating Reflection

23.3.6.7. Recording Techniques

23.3.6.8. SWOT

23.3.6.9. Gap Analysis

23.3.6.10. Flipcharts

23.3.6.11. Checklists

23.3.6.12. Brainstorming

23.3.6.13. Root-Cause Analysis

23.3.6.14. Multi-Voting

23.3.6.15. Focus Group Framework

23.3.6.16. Managing Conflicts Tips Sheet

24. Innovation, Design and Customer

24.1. Role of the innovation

24.1.1. Achieving competitive advantage over other companies is more and more difficult

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

24.1.3. Innovation as a tool helping the organization to achieve competitive advantage

24.1.4. Innovation

24.1.4.1. Innovation is the process of renewing something that exists

24.1.4.2. Innovation requires

24.1.4.2.1. Changing the way people make decisions

24.1.4.2.2. Doing things differently

24.1.4.2.3. Making choices outside of the norm

24.1.4.2.4. Innovation changes the values onto which the system is based

24.1.4.3. Types of innovation

24.1.4.3.1. Radical (breakthrough, destructive)

24.1.4.3.2. Incremental (conservative, sustaining)

24.1.4.4. User Innovation

24.1.4.4.1. The author of innovation is the end user who develops or refines acquired products and services at the site of use

24.1.4.4.2. Users share their ideas and solutions with the producer

24.1.4.4.3. Called as „free revealing"

24.1.5. Innovation vs. Invention

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

24.1.6. Triggers for Innovation

24.1.6.1. No clear boundaries of the business

24.1.6.1.1. Organizations extends the business area (the offer) and the geographic area of activity using other communication and distributions channels

24.1.6.2. More demanding customers

24.1.6.2.1. Customers require a product

24.1.6.3. Customer needs and expectations are on the first place

24.1.6.3.1. Customer's satisfaction as a success factor

24.1.6.3.2. More effort to meet the customer's requirements

24.1.6.4. The customer should be positively surprised and willing to come back to buy more products / services

24.1.6.5. More interest in integrated systems of

24.1.6.5.1. Products

24.1.6.5.2. Software

24.1.6.5.3. Services working as a single whole

24.1.6.6. Integrated systems as keys to expansion beyond core areas of the business

24.1.6.7. A way to meet customer expectations impossible to achieve by more isolated offering

24.1.6.8. Questions without any answer

24.1.6.8.1. Problems without a solution

24.1.6.8.2. Who finds the right answers or working solution firsts can achieve competitive advantage

24.1.7. Areas of application

24.1.7.1. Products

24.1.7.1.1. Introducing new merchandise to the market

24.1.7.2. Processes

24.1.7.2.1. New, better way of achieving something is introduced

24.1.7.3. Behavior

24.1.7.3.1. How people live their lives, perceive reality or achieve their goals

24.1.8. Categories of innovation

24.1.8.1. Degree

24.1.8.1.1. Disruptive innovation

24.1.8.1.2. Line extension innovation

24.1.8.2. Scope

24.1.8.2.1. Application innovation

24.1.8.2.2. Enhancement innovation

24.1.8.3. Business area

24.1.8.3.1. Product innovation

24.1.8.3.2. Process innovation

24.1.8.4. Source

24.1.8.4.1. Organic innovation

24.1.8.4.2. Acquisition innovation

24.1.9. Design

24.1.9.1. The specification of an object intended to accomplish goals in particular environment

24.1.9.2. A process which produces such specifications

24.1.9.3. A term often linked with innovation

24.1.9.4. From business perspective design is the process which allows the company to achieve a competitive advantage

24.1.9.5. Design supports achieving a competitive advantage by

24.1.9.5.1. Solving users or customers problems in the creative way

24.1.9.5.2. Creating unique value and unforgettable user experience

24.1.9.5.3. Joining functionality, aesthetics, ergonomics and user experience with the form

24.1.9.5.4. Distinguishing the company

24.2. Competition and Market Research

24.2.1. Market Research

24.2.1.1. A structured activity with the purpose to gather information about markets or customers

24.2.1.2. Important component of business strategy

24.2.2. Market Analysis

24.2.2.1. A structured and documented investigation of a market

24.2.2.2. Determines if there is a need or audience for a product / service

24.2.2.3. Provides information about market's needs and how it is currently serviced

24.2.2.4. Useful to plan

24.2.2.4.1. New products

24.2.2.4.2. An expansion of the business

24.2.2.5. Dimensions of a Market Analysis

24.2.2.5.1. Market size (current and future)

24.2.2.5.2. Market growth rate

24.2.2.5.3. Market profitability

24.2.2.5.4. Industry cost structure

24.2.2.5.5. Distribution channels

24.2.2.5.6. Market trends

24.2.2.5.7. Key success factors

24.2.3. Market Research and Analysis process

24.2.3.1. Problem definition

24.2.3.2. Analysis of the situation

24.2.3.3. Obtaining data and information specific to the problem

24.2.3.4. Information analysis and interpretation

24.2.3.5. Formulating ideas and solution of problem

24.2.4. Techniques for collecting market data

24.2.4.1. Qualitative research

24.2.4.2. Quantitative research

24.2.4.3. Customer feedback

24.2.4.4. Mail questionnaire

24.2.4.5. Telephone / Personal Interview surveys

24.2.4.6. Observation

24.2.4.7. Direct work with the end users on site

24.2.5. Trend

24.2.5.1. Trend is a tendency of a market (or specific product or service) to move in a particular direction over time

24.2.5.2. Market Research together with Market Analysis allows to determine Market Trends

24.2.5.3. Analyzing the trends allows to predict the desired future solutions

24.3. Design Thinking

24.3.1. Design Thinking

24.3.1.1. A methodology for practical, creative resolution of problems or issues that look for an improved future result

24.3.1.2. 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

24.3.2. Design Thinking is a team oriented discipline

24.3.3. Design Thinking converts need into demand

24.3.4. Three major phases

24.3.4.1. Inspiration

24.3.4.1.1. The main goal is to gather insights from customers

24.3.4.1.2. Insights are to be used as the basis for inspirations

24.3.4.1.3. Inspiration phase is performed from the user / customer perspective

24.3.4.1.4. No business constraints

24.3.4.1.5. Results of the inspiration phase

24.3.4.2. Ideation

24.3.4.2.1. The goal is to analyze insights and turn them into ideas

24.3.4.2.2. The ideas become a part of the solution

24.3.4.2.3. New ideas should not be judged or rejected, even if they seem to be contradictory

24.3.4.2.4. Questionable ideas may be a source for further inspiration

24.3.4.2.5. The result of the ideation phase - the decision which ideas become part of the final solution

24.3.4.2.6. Tools for ideation

24.3.4.3. Implementation

24.3.4.3.1. Precondition: ready and more or less stable prototypes of solutions

24.3.4.3.2. The goal is to convince the stakeholders that proposed solutions meet their expectations and guarantee success after release to the market

24.3.4.3.3. Sample tool - storytelling

24.4. Basic methods, tools and techniques

24.4.1. Multidisciplinary teams

24.4.1.1. Team consisted of people from various, often completely different functional areas

24.4.1.2. The teams is organized around the problem rather than a leader

24.4.1.3. Beneficial for

24.4.1.3.1. Making observations

24.4.1.3.2. Gathering insights

24.4.1.3.3. Generating ideas

24.4.2. Multi-vector research

24.4.2.1. An approach for analyzing all available points of view or sources of information

24.4.2.2. Procedure

24.4.2.2.1. Synthesize the vectors to uncover insights

24.4.2.2.2. Create a number of vectors to research H the problem from several directions

24.4.2.3. Typical vectors used in Multi-Vector Research

24.4.2.3.1. Customers

24.4.2.3.2. Competitors

24.4.2.3.3. Organization toolbox

24.4.2.3.4. Technology

24.4.2.3.5. Sales and Retail

24.4.2.3.6. Trends

24.4.3. Persona

24.4.3.1. Persona is a fictional character representing the different types of users

24.4.3.2. Persona represents a group of people with the same

24.4.3.2.1. Needs

24.4.3.2.2. Attitude

24.4.3.2.3. Behavior

24.4.3.2.4. Expectations towards the product

24.4.3.3. Sample personas in innovation process:

24.4.3.3.1. The Anthropologist

24.4.3.3.2. The Experimenter

24.4.3.3.3. The Cross-Pollinator

24.4.3.3.4. The Hurdier

24.4.3.3.5. The Collaborator

24.4.3.3.6. The Director

24.4.3.3.7. The Experience Architect

24.4.3.3.8. The Set Designer

24.4.3.3.9. The Caregiver

24.4.4. Insights

24.4.4.1. Customer insights are the basis for the inspiration and innovation

24.4.4.2. The main idea - whatever is examined it should be examined from customer's point of view

24.4.4.3. Sources of insights

24.4.4.3.1. Customers and their feelings, needs, values and problems

24.4.4.3.2. Extreme users and outliers, children, seniors

24.4.4.3.3. Trends and general trends

24.4.4.3.4. Competition

24.4.4.3.5. Technology

24.4.4.3.6. Complementing and comparable organizations

24.4.5. Brainstorming

24.4.5.1. Technique used for generating of a large number of ideas for the solution of defined problems

24.4.5.2. A session involves a group of people

24.4.5.3. Members have different knowledge and experience

24.4.5.4. Brainstorming sessions should be rather facilitated than moderated

24.4.5.5. Rules applying to brainstorming sessions

24.4.5.5.1. Avoid judgment and criticism towards ideas of other team members

24.4.5.5.2. New ideas can be built on the ideas provided by others

24.4.5.5.3. Do not focus on the quality of the ideas, but on the quantity

24.4.5.5.4. The goal is to collect many various ideas

24.4.6. Prototyping

24.4.6.1. Encourages iterative approach to the problem solution

24.4.6.2. Using prototypes allows

24.4.6.2.1. Better explain and present ideas or solutions to others

24.4.6.2.2. Come up with new ideas

24.4.6.2.3. Test the solution

24.4.6.2.4. Gather the feedback from the stakeholders and customers

24.4.7. Enlightened trial and error

24.4.7.1. Trial and Error - the process of obtaining knowledge by generating solutions, testing them and learning from own mistakes

24.4.7.2. The testing is performed with the prototypes

24.4.7.3. The main idea: "Fail often in order to succeed sooner"

24.4.8. Storytelling

24.4.8.1. A persuasive technique used to convince the other side to the arguments of the storyteller

24.4.8.2. Stories

24.4.8.2.1. Based on assumptions or the real situations experienced during the research phase

24.4.8.2.2. Wrapped around the product, user and user's experience

24.4.8.2.3. The main idea: "show, don't tell"

24.4.8.3. Tools

24.4.8.3.1. Pictures

24.4.8.3.2. Videos

24.4.8.3.3. Sketches

24.5. Working with the final user

24.5.1. Working with the user allows to

24.5.1.1. Identify the user's needs

24.5.1.2. Support the users in formulating the needs

24.5.1.3. Explore the needs and determine requirements

24.5.1.4. Provide the user with suggestions how to improve the desired solution