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

1. Glossary

1.1. Artefact

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

1.1.2. Describes the process of development itself

1.1.3. All artefacts should be under version control.

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

1.1.5. e.g.

1.1.5.1. Business Case

1.1.5.2. Class diagrams

1.1.5.3. Design document

1.1.5.4. Project's plan

1.1.5.5. Requirements document

1.1.5.6. Risk assessment

1.1.5.7. Use cases

1.2. Business Analyst

1.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."

1.2.1.1. source BABOK

1.3. Business Case

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

1.3.1.1. source BABOK

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

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

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

1.4. Business Goal

1.4.1. Business Goal is an objective of an organization.

1.4.1.1. Short- or long-term.

1.4.1.2. Formulated by the requesting organization.

1.5. Business Need

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

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

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

1.6. Business Requirements Elicitation

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

1.7. Business process

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

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

1.8. Decision Package

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

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

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

1.9. Enterprise Analysis

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

1.9.1.1. source BABOK

1.10. Feasibility Study

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

1.10.1.1. Is technically feasible

1.10.1.2. Is feasible within the estimated cost

1.10.1.3. Will be profitable

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

1.10.3. Also called Feasibility Analysis.

1.11. Requirement

1.11.1. [IEEE Std 610.12-1990]

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

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

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

1.12. Requirements Communication

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

1.12.1.1. source BABOK

1.13. Requirements Communication

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

1.14. Requirements Document

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

1.15. Requirements Elicitation

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

1.15.1.1. source BABOK

1.16. Requirements signoff

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

1.16.2. * May involve final review of requirements.

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

1.17. Risk Assessment

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

1.18. Traceability

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

1.18.1.1. Requirements

1.18.1.2. Detailed requirements and design models

1.18.1.3. Detailed requirements and test cases

1.18.1.4. High level requirements and test cases

1.18.1.5. Requirements and design artefacts

1.19. lnterview

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

1.20. Feature

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

1.20.1.1. source BABOK

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

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

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

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

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

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

3.1.4. http://www.miroslawdabrowski.com

3.1.5. https://twitter.com/mirodabrowski

3.1.6. miroslaw_dabrowski

4. Process Improvement

4.1. Process Improvement

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

4.1.2. Improving the business process

4.1.2.1. Approaches

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

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

4.1.2.1.3. Process simulation and optimizing

4.1.2.1.4. Adopting selected methodology or strategy

4.1.3. Triggers of Process Improvement

4.1.3.1. Process Improvement may follow a specific methodology or strategy

4.1.3.1.1. Benchmarking

4.1.3.1.2. Business Process Improvement

4.1.3.1.3. Business process reengineering

4.1.3.1.4. Capability Maturity Model Integration / Capability Maturity Model

4.1.3.1.5. ISO 9000

4.1.3.1.6. IT Governance

4.1.3.2. Just In Time manufacturing

4.1.3.3. Lean manufacturing

4.1.3.4. Performance improvement

4.1.3.5. Process management

4.1.3.6. Process improvement and Management (PI&M)

4.1.3.7. Six Sigma

4.1.3.8. Total Quality Management

4.1.4. Business Process Improvement

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

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

4.1.4.3. No improvement by a series of small incremental changes

4.1.5. Methodology of BPI

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

4.1.5.2. Determine the organization's stakeholders and identify

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

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

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

4.1.5.3.1. Supported by the tools available within the BPI methodology

4.1.6. Roles in BPI

4.1.6.1. Business Leader

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

4.1.6.1.2. Responsible for developing resource plans

4.1.6.2. Process Owner

4.1.6.2.1. Designs processes

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

4.1.6.3. Operational Manager

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

4.1.6.3.2. Instructs the Process Operators how to perform the processes

4.1.6.4. Process Operator

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

4.1.6.4.2. Ensures the realization of a process meets performance objectives

4.1.6.4.3. Ensures the products of the processes meet the specifications

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

4.2. Process simulation and redesigning

4.2.1. Business Process Simulation

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

4.2.1.2. BPS allows simulating

4.2.1.2.1. The execution of business processes

4.2.1.2.2. Parameters over time

4.2.1.3. Simulation is based on process models

4.2.1.4. The purpose

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

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

4.2.2. Process models

4.2.2.1. The process models must represent

4.2.2.1.1. The specific elements of the business process

4.2.2.1.2. The attributes of the business process

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

4.2.2.3. BPS Procedure

4.2.2.3.1. Mapping the business process onto a process model

4.2.2.3.2. Identification of the sub processes and activities

4.2.2.3.3. Creating the control flow definition

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

4.2.2.3.5. Defining performance characteristics

4.2.2.4. Running the simulation

4.2.2.4.1. Simulation should be executed for several sub runs

4.2.2.4.2. A simulation is run in a specific tool

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

5. Tools and Techniques

5.1. Modeling tools

5.1.1. Modeling tools allow to

5.1.1.1. Link requirements in models

5.1.1.2. Create graphical representation of requirements

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

5.1.1.4. Establish and maintain traceability

5.1.1.5. Design the overall structure of the system

5.2. Business Analysis techniques

6. Solution Validation

6.1. Assessment

6.2. Validation

7. Requirements Analysis

7.1. Requirements Organization

7.1.1. Requirements are organized (structured) into packages

7.1.1.1. The purpose of organizing requirements

7.1.1.1.1. To determine the solution boundary

7.1.1.1.2. To determine the solution scope

7.1.1.1.3. To define the structure of requirements

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

7.1.2. Decomposition

7.1.2.1. Goal decomposition

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

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

7.1.2.1.3. Lower-level goals have measurable objectives

7.1.2.1.4. Goals are business requirements

7.1.2.2. Feature list decomposition

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

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

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

7.1.2.3. Functional decomposition

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

7.1.2.3.2. Identifies the high-level functions

7.1.2.3.3. Breaks them down into sub-processes and activities

7.1.2.3.4. Functional decomposition is used to

7.1.2.3.5. Levels of detail for functional decomposition

7.2. Modeling and Specification

7.2.1. Model

7.2.1.1. Model is a representation of an object

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

7.2.1.3. Model describes

7.2.1.3.1. The structure of the system

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

7.2.1.3.3. Textual elements

7.2.1.3.4. Matrixes

7.2.1.3.5. Diagrams

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

7.2.2. Modeling

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

7.2.2.2. Modeling is helpful but not always necessary

7.2.2.3. The organization may skip modeling when:

7.2.2.3.1. The solution is fully understood by the stakeholders

7.2.2.3.2. The solution is easy to implement

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

7.2.2.3.4. The problem domain is well known

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

7.2.2.3.6. The scope is declared as constant

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

7.2.2.4. Advantages of Modeling

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

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

7.2.2.4.3. Models are more readable and clear than written text

7.2.2.4.4. Looking at the problem from the overall perspective

7.2.2.5. Modeling Techniques

7.2.2.5.1. Archimate

7.2.2.5.2. BPMN

7.2.2.5.3. DSL

7.2.2.5.4. GUI modelling

7.2.2.5.5. OBASHI

7.2.2.5.6. SysML

7.2.2.5.7. UML

7.2.2.5.8. ...

7.3. Defining Assumptions and Constraints

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

7.3.2. Constraint

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

7.3.2.2. Limitations on

7.3.2.2.1. Engineering process System's operation Lifecycle

7.3.3. Types of constraints

7.3.3.1. Business constraints

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

7.3.3.1.2. Limitations on the projects flexibility to implement requested solution

7.3.3.2. Technical constraints

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

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

7.3.4. Example constraints

7.3.4.1. Hardware or software environment

7.3.4.2. End-user environment

7.3.4.3. Availability or volatility of resources

7.3.4.4. Standards compliance

7.3.4.5. Interoperability requirements

7.3.4.6. Interface / protocol requirements

7.3.4.7. Data repository requirements

7.3.4.8. Data distribution requirements

7.3.4.9. Security requirements

7.3.4.10. Memory limitations

7.3.4.11. Performance requirements

7.3.4.12. Network communications

7.3.5. Assumption

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

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

7.3.5.3. Assumptions often become limitations!

7.3.5.4. Goal

7.3.5.4.1. Assumptions are used to document

7.3.6. Types of assumptions

7.3.6.1. Business assumptions

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

7.3.6.2. Requirements assumptions

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

7.3.7. Example assumptions

7.3.7.1. The back-end system is available

7.3.7.2. There is no more than 1000 transactions per day

7.3.7.3. All transactions are processed in EURO

7.4. Verification and Validation

7.4.1. Validation

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

7.4.1.2. Goal

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

7.4.2. Verification

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

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

7.4.2.3. Verification process requires to involve and cooperate closely with

7.4.2.3.1. Customer

7.4.2.3.2. Users

7.4.2.3.3. Project team

7.4.2.4. Requirements can be stated as verified if

7.4.2.4.1. Project stakeholders agreed that the requirements are correctly understood

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

7.4.2.4.3. The requirements were stated as of high quality

7.5. Quality Assurance

7.5.1. Quality Assurance

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

7.5.2. Quality criteria for requirements

7.5.2.1. Allocatable

7.5.2.2. Complete

7.5.2.3. Consistent

7.5.2.4. Correct

7.5.2.5. Does not determine solution

7.5.2.6. Feasible

7.5.2.7. Measurable

7.5.2.8. Necessary

7.5.2.9. Prioritized

7.5.2.10. Testable

7.5.2.11. Traceable

7.5.2.12. Unambiguous

7.5.2.13. Understandable

7.5.3. Examples of QA techniques

7.5.3.1. Checklists

7.5.3.1.1. A common technique for quality control

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

7.5.3.2. Reviews

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

7.5.3.2.2. Examples

7.5.3.3. Testing

8. Requirements Elicitation

8.1. The concept of Requirements Elicitation

8.1.1. Business Requirements Elicitation

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

8.1.2. The purpose of Business Requirements Elicitation

8.1.2.1. Identification of:

8.1.2.1.1. Desired functions

8.1.2.1.2. Attributes

8.1.2.1.3. Quality characteristics

8.1.2.1.4. Limitations and expectations

8.1.2.1.5. Requirements resulted from external regulations, norms etc.

8.1.2.1.6. Orientation of the requirements toward the project vision

8.1.2.2. Establishing the finał scope

8.1.2.3. Establishing business design of the system

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

8.1.3. Techniques for Requirements Elicitation

8.1.3.1. Q.uestionnaires

8.1.3.1.1. What is it?

8.1.3.1.2. Quastionnaire can collect information about:

8.1.3.1.3. 2 types:

8.1.3.1.4. Process:

8.1.3.1.5. Questions

8.1.3.2. lnterviews

8.1.3.2.1. What is it?

8.1.3.2.2. 2 types:

8.1.3.2.3. Process:

8.1.3.3. Self-recording

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

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

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

8.1.3.3.4. Advantages:

8.1.3.3.5. Disadvantages

8.1.3.4. Customer's representative

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

8.1.3.4.2. Assumption:

8.1.3.4.3. The representative:

8.1.3.5. Identification on the basis of existing documents

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

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

8.1.3.5.3. Process:

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

8.1.3.6.1. Reuse of documentation / solution from previous projects.

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

8.1.3.6.3. Shorts the duration of Business Analysis.

8.1.3.6.4. Important notice:

8.1.3.7. Brainstorming

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

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

8.1.3.7.3. Promotes diversion type of thinking.

8.1.3.7.4. Brainstorming to detail identified requirements and find new ones

8.1.3.7.5. Brainstorming helps answer specific questions:

8.1.3.7.6. Process:

8.1.3.8. Field observation

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

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

8.1.3.8.3. Observation is usually used:

8.1.3.8.4. 2 types:

8.1.3.9. Apprenticing

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

8.1.3.9.2. The customer teaches the Business Analyst.

8.1.3.9.3. Master and student approach.

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

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

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

8.1.3.10. Workshops (after each iteration)

8.1.3.10.1. Workshop is a structured way to capture requirements.

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

8.1.3.10.3. Its is not a traditional meeting.

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

8.1.3.10.5. Workshop roles

8.1.3.10.6. Process:

8.1.3.11. Prototyping

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

8.1.3.11.2. Prototyping to visualize implementation of identified requirements

8.1.3.12. Focus groups

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

8.1.3.13. Interface Analysis

8.1.3.13.1. Helps to clarify the boundaries of the system

8.1.3.14. Important notice:

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

8.1.4. Requirements quality characteristics

8.1.4.1. Functionality

8.1.4.2. Reliability

8.1.4.3. Usability

8.1.4.4. Efficiency

8.1.4.5. Maintainability

8.1.4.6. Portability

8.2. Requirements Scope Management

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

8.2.1.1. System or component development

8.2.1.2. Process improvement

8.2.1.3. Organizational change

8.2.2. Requirements Scope Management

8.2.2.1. 1. Establishing requirements baseline

8.2.2.2. 2. Creating a requirements structure for traceability

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

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

8.2.2.5. 5. Maintaining scope approval

8.3. Establishing requirements baseline

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

8.3.2. The baseline

8.3.2.1. Is a base for further system development

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

8.3.3. Creating a requirements structure for traceability

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

8.3.4. Impact to other systems / areas

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

8.3.5. Changes in requirements scope affects

8.3.5.1. Project schedule

8.3.5.2. Project cost

8.3.5.3. Project and product risk

8.3.5.4. Project Resources

8.3.5.5. External interface to another systems or hardware

8.3.6. Identifying changes in the scope

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

8.3.6.2. Impact on the project

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

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

8.3.6.3. Major changes examples

8.3.6.3.1. Changing business logic

8.3.6.3.2. Changing process flow for critical functionality

8.3.7. Maintaining scope approval

8.3.7.1. The list of requirements must be approved and baselined

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

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

8.4. Requirement Traceability

8.4.1. Goals

8.4.1.1. Scope management

8.4.1.2. Impact analysis

8.4.1.3. Coverage analysis

8.4.1.4. Proof of implementation

8.4.1.5. Use of the requirement

8.4.1.6. Defect reports

8.4.2. Traceability

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

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

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

8.4.2.4. Representing traceability on UML diagrams

8.4.3. Tool support

8.4.3.1. Requirements Management software

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

8.4.3.1.2. Arranging requirements in structures (specification tree)

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

8.4.3.2. Requirements are realized into:

8.4.3.2.1. Design artefacts

8.4.3.2.2. Implementation

8.4.3.2.3. Test cases

8.4.3.3. Artefacts are traced back to the requirements.

8.4.4. Tools

8.4.4.1. Requirements Traceability Matrix

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

8.4.4.1.2. Assist in the creation of project's documentation

8.4.4.1.3. Supports verification process

8.4.4.1.4. RTM is created at the beginning of a project

8.4.4.2. Bi-directional Traceability Matrix

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

8.4.5. Software

8.4.5.1. i.e. Enterprise Analyst

8.4.5.2. i.e. Enterprise Architect

8.4.5.3. …

8.5. Requirements Documentation

8.5.1. Requirements document

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

8.5.1.2. No project deliverable information - constant time

8.5.1.3. Formalizes the project scope

8.5.2. Purpose of the requirements document

8.5.2.1. Structuring the requirements

8.5.2.2. Providing clear and unambiguous explanation of the requirements

8.5.2.3. A basis for implementation and testing

8.5.2.4. A basis for requirement management

8.5.2.4.1. Documentation is a baseline

8.5.3. Content of a requirements document

8.5.3.1. Assumptions

8.5.3.2. Business Process Description (BPD)

8.5.3.2.1. An executive summary of an initiative

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

8.5.3.3. Business Requirements Document (BRD)

8.5.3.3.1. Describes the behavior required of a software application

8.5.3.3.2. Primarily describes the business requirements

8.5.3.3.3. The target audience is the customer and users

8.5.3.4. Dependencies

8.5.3.5. Functional requirements

8.5.3.6. Introduction

8.5.3.7. Non-functional requirements

8.5.3.8. Overall description

8.5.3.9. Purpose of the product

8.5.3.10. Regulations

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

8.5.3.11.1. Distributed to parties outside the organization

8.5.3.11.2. Basis for the contracting of solution development services

8.5.3.12. Risks

8.5.3.13. Safety requirements Document acceptance

8.5.3.14. Secrecy clause

8.5.3.15. Software Requirements Specification (SRS)

8.5.3.15.1. Also known as a System Requirements Specification

8.5.3.15.2. Describes the behavior and implementation of a software application

8.5.3.15.3. The target audience is the development team

8.5.3.16. Stakeholders

8.5.3.17. Standards

8.5.3.18. ...

8.5.4. Common Document Formats

8.5.4.1. Software Requirements Specification (SRS)

8.5.4.1.1. A description of the problem domain

8.5.4.1.2. Decomposition of the problem domain

8.5.4.1.3. Description of the functional requirements

8.5.4.1.4. Description of the non-functional requirements

8.5.4.1.5. Assumptions and constraints affecting the solution

8.5.4.1.6. Requirements attributes and traceability information

8.5.5. Construction of a requirement

8.5.5.1. Describe business justification for the requirement

8.5.5.2. Identify the business process

8.5.5.3. Identify the stakeholders

8.5.5.4. Identify the limitations and assumptions

8.5.5.5. Describe the context

8.5.5.6. Describe the requirement

8.5.5.6.1. Input

8.5.5.6.2. Output

8.5.5.6.3. Resources

8.5.5.6.4. Quality characteristics (if applicable)

8.5.5.7. Provide the graphical model (if applicable)

8.5.5.8. Describe risks

8.5.5.9. Provide references

8.5.6. Guidelines for the requirements document

8.5.6.1. The requirements must be unambiguous, precise and understandable

8.5.6.2. Superfluous information should be avoided

8.5.6.3. Templates as an aid to limit language

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

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

8.5.7. Common Document Problems

8.5.7.1. Trivialities

8.5.7.1.1. Lengthy descriptions of commonly known issues

8.5.7.2. Information out of scope

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

8.5.7.3. Thinking in solutions

8.5.7.3.1. Description of solutions

8.5.7.3.2. Requirement specification determining the technical design

8.5.7.4. Redundant details

8.5.7.4.1. Details unnecessarily complicating the implementation

8.5.7.4.2. Implementation details

8.5.7.5. Lacking rationale

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

8.6. Requirements Communication

8.6.1. Requirements Communication

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

8.6.2. Communication

8.6.2.1. An ongoing and iterative activity

8.6.2.1.1. Presenting

8.6.2.1.2. Communicating

8.6.2.1.3. Verifying

8.6.2.1.4. Obtaining approval

8.7. The role of a Business Analyst

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

8.7.2. Consider and choose communication approach appropriate for the project

8.8. Requirements Communication process

8.8.1. 1. Preparing requirements communication Plan

8.8.2. 2. Managing requirements conflicts

8.8.3. 3. Establishing the most appropriate requirements format

8.8.4. 4. Creating requirements package

8.8.5. 5. Conducting requirements presentation

8.8.6. 6. Performing formal requirements review

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

8.9. Requirement acceptance

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

8.9.2. All requirements must be formally approved

8.9.3. Formal agreement

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

8.10. Stakeholders with the acceptance authority

8.10.1. Business Sponsor

8.10.2. Project Managers

8.10.3. Business Analysts

8.10.4. Architects

8.10.5. Test / QA Manager

8.11. Standards

8.11.1. ISO 25000 (ISO/IEC 9126)

8.11.1.1. Defines a quality model with 6 categories:

8.11.1.1.1. Functionality

8.11.1.1.2. Reliability

8.11.1.1.3. Usability

8.11.1.1.4. Efficiency

8.11.1.1.5. Maintainability

8.11.1.1.6. Portability

8.11.2. IEEE 830

8.11.2.1. Recommended Practice for Software Requirements Specifications

8.11.3. IEEE 1233

8.11.3.1. Guide for Developing of System Requirements Specifications

8.11.4. IEEE 1362

8.11.4.1. Guide for Information Technology - System Definition

9. Major reasons of neglecting Business Analysis

9.1. Time praccure

9.2. Exclusive orientation towards fast results

9.3. Exclusive fixation on costs

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

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

9.5.1. Imprecise, ambiguous, contradictory or missing requirements

9.5.2. Requirements that change

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

9.6. Products of the business processes not known

9.7. Stakeholders not identified or identified only pertially

9.8. Business goals or needs not identified

9.8.1. The organization needs not satisfied

9.8.2. The business goals not achieved

10. Common pitfalls in Business Analysis

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

10.1.1. Incomplete

10.1.2. Inconsistent

10.1.3. Not measurable

10.1.4. Unclear objectives

10.1.5. Communication problems

10.1.6. Language barriers

10.1.7. Knowledge barriers

10.1.8. Vague formulation

10.1.9. Too formal formulations

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

10.1.11. Instability of the requirements (frequent changes)

10.1.12. Redundant description of requirements

10.1.13. Insufficient user invelvement

10.1.14. Overlooked user classes

10.1.15. Minimal specification

11. Business Analyst

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

11.1.1. source BABOK

11.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.”

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

11.3.1. Product Scope

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

11.3.2. Project Scope

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

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

11.4. Business Analyst Role

11.4.1. A liaison among stakeholders

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

11.4.2.1. Business processes

11.4.2.2. Policies

11.4.2.3. Information Systems

11.5. Business Analyst Major tasks

11.5.1. Requirements elicitation (identification)

11.5.2. Requirements analysis and modelling

11.5.3. Requirements realization planning

11.5.4. Requirements communication

11.5.5. Requirements documenting

11.5.6. Requirements validation

11.5.7. Requirements configuration management

11.5.8. Business solution proposal

11.6. Specific activities of Business Analyst

11.6.1. Identification

11.6.2. Developing

11.6.3. Managing the requirements

11.7. Business Bnalysts want to achieve the following outcomes

11.7.1. Reduce waste

11.7.2. Create solutions

11.7.3. Complete projects on time

11.7.4. Improve efficiency

11.7.5. Document the right requirements

11.7.6. Identify the root causes of problems

11.8. Activities of Business Analyst

11.8.1. Requirements Elicitation (identification)

11.8.2. Requirements Analysis

11.8.3. Requirements Specification

11.8.4. Requirements Management

11.8.4.1. Including Configuration Management

11.8.5. Requirements Communication

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

11.8.5.2. Consider and choose communication approach appropriate for the project

11.8.6. Requirements Documentation

11.8.7. Requirements Modeling

11.8.8. Requirements Validation

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

11.9.1. Analysis phase

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

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

11.9.1.3. Creating and analyzing Business Case

11.9.1.4. Conducting feasibility study

11.9.1.5. Preparing ideas of business solution

11.9.2. Specification phase

11.9.2.1. Identifying and documenting business requirements on more detailed level

11.9.2.2. Supporting System Analyst in preparing detailed system specifications

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

11.9.2.4. Managing requirements changes

11.9.3. Development phase

11.9.3.1. Supporting development team during implementation

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

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

11.9.3.4. Managing potential changes in requirements

11.9.4. Testing phase

11.9.4.1. Checking test results

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

11.9.4.3. Supporting preparing test cases for User Acceptance Testing

11.9.4.4. Supporting acceptance testers in executing test cases

11.10. When a Business Analyst is needed?

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

11.10.2. When a need for new functionalities appears

11.10.3. When the business changes

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

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

12. Objectives of Business Analysis

12.1. Collect and document the business requirements

12.2. Design business solutions to resolve the business problems

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

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

13. System Analyst

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

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

14. Requirements

14.1. Requirements descriptors / categories

14.1.1. Requirements should be preceded by descriptors like:

14.1.1.1. Business requirements

14.1.1.2. User requirements

14.1.1.3. Functional requirements (FRs)

14.1.1.4. Non-functional requirements (NFRs)

14.2. Meaning and purpose of requirements

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

14.2.2. Customer expectations (stakeholders value)

14.2.3. Component of agreements, project plans

14.2.4. Setting of system boundaries, scope of delivery

14.3. Classification of requirements

14.3.1. Process requirements (project management / HOW)

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

14.3.1.1.1. e.g.

14.3.2. Product requirements (product delivery / WHAT)

14.3.2.1. Functional (F)

14.3.2.2. Non-functional (NF)

14.3.2.3. External

14.3.2.4. Internal

14.4. Types of requirements

14.4.1. Customer requirements (business requirements)

14.4.2. Solution / system requirements

14.4.3. Product / component requirements

14.5. Managing requirements conflicts

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

14.5.2. Requirements themselves could be in conflict.

14.5.3. 1. Record the conflict in the Issues Log

14.5.4. 2. Analyze the conflict and its source

14.5.5. 3. Resolve the conflict

14.5.5.1. Research (without a formal stakeholder session)

14.5.5.2. Meeting involving affected stakeholders

14.5.5.3. Interviews with other parties

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

14.5.7. 5. Obtain sign off for the resolution

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

14.6. Selecting the appropriate requirements format

14.6.1. Questions to be asked:

14.6.1.1. How detailed the requirements need to be?

14.6.1.2. What information is important to communicate?

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

14.6.1.4. What is the type of audience?

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

14.6.2. Requirements can be presented in various formats.

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

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

14.6.5. The type of requirement influences the presentation technique.

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

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

14.6.8. e.g.

14.6.8.1. Diagrams

14.6.8.1.1. Process Workflows

14.6.8.1.2. Entity Relationship Diagram

14.6.8.1.3. Process Decomposition Diagram

14.6.8.1.4. UML Use Cases

14.6.8.2. Text

14.6.8.2.1. Textual templates

14.6.8.3. Prototyping

14.6.8.4. Additional formats

14.6.8.4.1. User manuals

14.6.8.4.2. Presentation slides

14.6.8.4.3. User stories

14.7. Creating a requirements package

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

14.7.2. Packaging the requirements supports effective requirements communication.

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

14.7.4. Deliveries of the Business Analysis:

14.7.4.1. Assumptions

14.7.4.2. Business needs and objectives

14.7.4.3. Business process flow definition

14.7.4.4. Business requirements

14.7.4.5. Definition of the business process's products

14.7.4.6. Limitations

14.7.4.7. Stakeholders of the project

14.7.5. Process

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

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

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

14.7.5.4. 4. Package the requirements for presentation

14.8. Requirements presentation

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

14.8.2. The objective:

14.8.2.1. To review, prioritize or to communicate status

14.8.2.2. To ensure quality of the requirements

14.8.2.3. To improve clarity

14.8.2.4. To obtain requirement's sign off

14.8.3. Subjects:

14.8.3.1. Business requirements

14.8.3.2. Data and behavior models

14.8.3.3. Functional requirements

14.8.3.4. Other models: Use Case models

14.8.3.5. Process / flow models

14.8.4. 2 types:

14.8.4.1. Formal presentation

14.8.4.1.1. Used to:

14.8.4.2. Informal presentation

14.8.4.2.1. Used to:

14.9. Formal requirements review

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

14.9.2. Participants should review the requirements before the session.

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

14.9.4. All questions, issues are recorded.

14.9.5. Agreed changes are recorded.

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

14.9.7. Significant changes may require a second review.

14.9.8. Process

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

14.9.8.2. 2. Determine participants

14.9.8.3. 3. Organize / schedule the review

14.9.8.4. 4. Compile notes and results of the review

14.9.8.5. 5. Conduct the review

14.9.8.6. 6. Deliver document(s) to participants

14.9.8.7. 7. Re-review if necessary

14.10. Requirements quality characteristics (ISO 9126)

14.10.1. Functionality

14.10.2. Reliability

14.10.3. Usability

14.10.4. Efficiency

14.10.5. Maintainability

14.10.6. Portability

14.11. Requirements Scope

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

14.11.1.1. System or component development

14.11.1.2. Process improvement

14.11.1.3. Organizational change

14.12. Requirements Scope Management

14.12.1. 1. Establishing requirements baseline

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

14.12.1.2. The baseline:

14.12.1.2.1. Is a base for further system development

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

14.12.2. 2. Creating a requirements structure for traceability

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

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

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

14.12.3.2. Impact to other systems / areas

14.12.3.2.1. External interface to another systems or hardware

14.12.3.2.2. Project and product risk

14.12.3.2.3. Project cost

14.12.3.2.4. Project resources

14.12.3.2.5. Project schedule

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

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

14.12.4.2. Impact on the project:

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

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

14.12.5. 5. Maintaining scope approval

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

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

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

14.13. Requirement Traceability

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

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

14.13.3. Goals of Traceability

14.13.3.1. Scope management

14.13.3.2. Coverage analysis

14.13.3.3. Impact analysis

14.13.3.4. Use of the requirement

14.13.3.5. Proof of implementation

14.13.3.6. Defect reports

14.13.4. Tool support by Requirements Management software

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

14.13.4.2. Arranging requirements in structures (specification tree)

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

14.13.4.4. Requirements are realized into:

14.13.4.4.1. Design artefacts

14.13.4.4.2. Implementation

14.13.4.4.3. Test cases

14.13.4.5. Artifacts are traced back to the requirements.

14.13.5. Requirements Traceability Matrix (RTM)

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

14.13.5.2. used to:

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

14.13.5.2.2. Assist in the creation of project's documentation

14.13.5.2.3. Supports verification process

14.14. Requirements Documentation

14.14.1. Purpose

14.14.1.1. Structuring the requirements

14.14.1.2. Providing clear and unambiguous explanation of the requirements

14.14.1.3. A basis for implementation and testing

14.14.1.4. A basis for requirement management

14.14.1.4.1. Documentation is a baseline

14.14.2. Requirements Document

14.14.2.1. No project deliverable information

14.14.2.1.1. costand time

14.14.2.2. Formalizes the project scope

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

14.14.2.4. Guidelines

14.14.2.4.1. The requirements must be unambiguous, precise and understandable

14.14.2.4.2. Superfluous information should be avoided

14.14.2.4.3. Templates as an aid to limit language

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

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

14.14.2.5. Quality attributes

14.14.2.5.1. Complete

14.14.2.5.2. Consistent

14.14.2.5.3. Modifiable

14.14.2.5.4. Traceable

14.14.3. Forms:

14.14.3.1. Graphical models

14.14.3.2. Mathematic representation

14.14.3.3. Mixed techniques

14.14.3.4. Written text

14.14.4. Content::

14.14.4.1. Introduction

14.14.4.2. Secrecy clause

14.14.4.3. Regulations

14.14.4.4. Standards

14.14.4.5. Stakeholders

14.14.4.6. Purpose of the product

14.14.4.7. Overall descriptio

14.14.4.8. Functional requirements (FR)

14.14.4.9. Non-functional requirements (NFR)

14.14.4.10. Assumptions

14.14.4.11. Dependencies

14.14.4.12. Risks

14.14.4.13. Safety requirements Document acceptance

14.14.5. Formats:

14.14.5.1. Vision

14.14.5.1.1. What is it?

14.14.5.1.2. An output of Enterprise Analysis.

14.14.5.1.3. Usually used in iterative development

14.14.5.2. Business Process Description (BPD)

14.14.5.2.1. An executive summary of an initiative.

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

14.14.5.3. Business Requirements Document (BRD)

14.14.5.3.1. Describes the behavior required of a software application.

14.14.5.3.2. Primarily describes the business requirements.

14.14.5.3.3. The target audience is the customer and users

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

14.14.5.4.1. Distributed to parties outside the organization.

14.14.5.4.2. Basis for the contracting of solution development

14.14.5.5. Software Requirements Specification (SRS)

14.14.5.5.1. Also known as a System Requirements Specification.

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

14.14.5.5.3. The target audience is the development team.

14.14.5.5.4. A description of the problem domain

14.14.5.5.5. Decomposition of the problem domain

14.14.5.5.6. Description of the functional requirements

14.14.5.5.7. Description of the non-functional requirements

14.14.5.5.8. Assumptions and constraints affecting the solution

14.14.5.5.9. Requirements attributes and traceability information

14.14.6. Common mistakes

14.14.6.1. Trivialities

14.14.6.1.1. Lengthy descriptions of commonly known issues

14.14.6.2. Information out of scope

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

14.14.6.3. Thinking in solutions

14.14.6.3.1. Description of solutions

14.14.6.3.2. Requirement specification determining the technical design

14.14.6.4. Redundant details

14.14.6.4.1. Details unnecessarily complicating the implementation

14.14.6.4.2. Implementation details

14.14.6.5. Lacking rationale

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

14.15. Construction of a requirement (process)

14.15.1. 1. Describe business justification for the requirement

14.15.2. 2. Identify the business process

14.15.3. 3. Identify the stakeholders

14.15.4. 4. Identify the limitations and assumptions

14.15.5. 5. Describe the context

14.15.6. 6. Describe the requirement

14.15.6.1. Input

14.15.6.2. Output

14.15.6.3. Resources

14.15.6.4. Quality characteristics (if applicable)

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

14.15.8. 8. Describe risks

14.15.9. 9. Provide references

14.16. Requirements Communication

14.16.1. An ongoing and iterative activity

14.16.2. Process

14.16.2.1. 1. Preparing requirements communication plan

14.16.2.2. 2. Managing requirements conflicts

14.16.2.3. 3. Establishing the most appropriate requirements format

14.16.2.4. 4. Performing formal requirements review

14.16.2.5. 5. Conducting requirements presentation

14.16.2.6. 6. Creating requirements package

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

14.17. Requirement Acceptance

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

14.17.2. All requirements must be formally approved.

14.17.3. Formal agreement:

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

14.17.4. Stakeholders with the acceptance authority

14.17.4.1. Architects

14.17.4.2. Business Analysts

14.17.4.3. Business Sponsor

14.17.4.4. Project Managers

14.17.4.5. Test/QA Manager

14.17.5. Requirement acceptance consequences

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

14.17.5.2. Any changes must be managed via Change Management.

14.18. Requirements Organization

14.18.1. Purpose

14.18.1.1. To determine the solution boundary

14.18.1.2. To determine the solution scope

14.18.1.3. To define the structure of requirements

14.18.2. Requirements are organized (structured) into packages

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

14.19. Requirements Decomposition

14.19.1. 3 types

14.19.1.1. Functional decomposition

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

14.19.1.1.2. Identifies the high-level functions

14.19.1.1.3. Breaks them down into sub-processes and activities

14.19.1.1.4. Used to:

14.19.1.1.5. Levels of detail:

14.19.1.2. Feature list decomposition

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

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

14.19.1.3. Goal decomposition

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

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

14.19.1.3.3. Lower-level goals have measurable objectives.

15. Knowledge Areas in Business Analysis

15.1. Enterprise Analysis

15.2. Requirements Planningand Management

15.3. Requirements Elicitation (Identification)

15.4. Requirements Communication

15.5. Requirements Analysis and Documentation

15.6. Solution Assessment and Validation

16. Reasons why projects fail

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

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

16.1.2. Lack of clear senior management ownership and leadership

16.1.3. Lack of effective engagement with stakeholders

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

16.1.5. Project not broken down into manageable steps

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

16.1.7. Lack of understanding of and contact with suppliers

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

16.2. Based on Standish Report.

16.2.1. 10. Standard Tools and Infrastructure

16.2.2. 9. Formal Methodology

16.2.3. 8. Skilled Resources

16.2.4. 7. Financial Management

16.2.5. 6. Project Manager Expertise

16.2.6. 5. Agile Process

16.2.7. 4. Optimizing Scope

16.2.8. 3; Cieor Business Objectives

16.2.9. 2. Executive Management Support

16.2.10. 1. User Involvement

17. Stakeholders

17.1. Classification

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

17.1.1.1. Project Managers

17.1.1.2. Business and System Analysts

17.1.1.3. Developers and Architects

17.1.1.4. Database designers

17.1.1.5. GUI designers

17.1.1.6. Technical writers

17.1.1.7. Testers and Quality Assurance stuff

17.1.1.8. Installation and Operations personnel

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

17.1.2.1. Customer representative (so called "Business")

17.1.2.2. Project sponsor

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

17.1.2.4. The person who installs and maintains the system

17.1.2.5. Quaiity Assurance / Testers

17.1.2.6. Installation and Operations personnel

17.1.3. External stakeholders

17.1.3.1. End users (clients of the customer)

17.1.3.2. Other organizations (regulation entities)

17.2. Stakeholder identification

17.2.1. Techniques

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

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

17.2.1.1.2. Their processes may also influence our solution.

17.2.1.2. Identifying owners of business processes

17.2.1.3. Analyzing organizational structure of the customer's organization

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

17.2.1.5. Analyzing relationships with external organizations

17.2.1.6. Investigating the business domain

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

17.2.1.7. Identifying owners of business processes

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

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

17.2.1.8. Analyzing organizational structure of the customer's organization

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

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

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

17.2.1.10. Investigating the business domain

17.3. Stakeholder identification problems

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

17.3.2. Not clear responsibilities in the customer's organization

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

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

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

17.4.1. Identify all stakeholders and their needs.

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

17.5. Stakeholders value

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

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

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

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

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

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

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

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

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

18. Enterprise Analysis

18.1. Activities of the Enterprise Analysis

18.1.1. Determining business opportunities

18.1.2. Developing strategic goals to be achieved by the organization

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

18.1.4. Understanding and developing the business architecture

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

18.1.5.1. Implementation of new business and technical system solutions

18.1.5.2. Implementation of process or organizational changes

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

18.1.7. Initiating projects

18.2. Enterprise Analysis is conducted:

18.2.1. As a stand-alone project

18.2.1.1. in large and complex organizations

18.2.2. By customer organization - before involving the vendor

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

18.2.3. Not conducted at all

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

18.3. Enterprise Analysis activities:

18.3.1. Identification of business processes

18.3.2. Creating the Business Architecture

18.3.3. Conducting Feasibility Studies

18.3.4. Conducting the initial Risk Assessment

18.3.5. Preparing the Business Case

18.3.6. Scoping and defining the new business opportunity

18.3.7. Preparing the Decision Package

18.4. Business Architecture

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

18.4.1.1. High level business environment

18.4.1.2. Long term goals and objectives

18.4.1.3. Stakeholders

18.4.1.4. The businesses strategy

18.4.1.5. The external environment

18.4.1.6. The technological environment

18.5. Risk Assessment

18.5.1. 1. Identifying project risks

18.5.1.1. 1. Identifying and analyzing business risks

18.5.1.2. 2. Identifying and analyzing financial risks

18.5.1.3. 3. Identifying and analyzing technical risks

18.5.2. 2. Assessing risk probability and impact

18.5.3. 3. Planning risk responses

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

18.6. Business process

18.6.1. Characteristics of a Business Process

18.6.1.1. Has a goal

18.6.1.2. Has specific inputs

18.6.1.3. Has specific outputs

18.6.1.4. Uses resources

18.6.1.5. Has a number of activities performed in some order

18.6.1.6. May affect more than one organizational unit

18.6.1.7. Creates value for the customer

18.6.2. Purpose of Business Process's identification

18.6.2.1. Understanding the goals of the organization.

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

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

18.7. Business Goal

18.7.1. Qualities of Business Goals

18.7.1.1. Specificity

18.7.1.2. Optimism

18.7.1.3. Realism

18.7.1.4. Short and long term

18.7.2. Importance of setting Business Goals

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

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

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

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

18.7.3. SMART

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

18.7.3.2. All goals should be SMART.

18.7.3.2.1. S - Specific

18.7.3.2.2. M - Measurable

18.7.3.2.3. A - Attainable

18.7.3.2.4. R - Relevant

18.7.3.2.5. T - Timely

18.7.3.3. SMART - example of business goal

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

18.8. Business Need

18.8.1. Who defines the Business Need?

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

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

18.8.2.2. Regulatory / compliance body

18.8.2.3. Sponsor

18.8.2.4. Steering committee

18.8.2.5. Subject Matter Expert (SME)

18.8.3. e.g.

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

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

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

18.9. Business Case

18.9.1. A Business Case may cover the following topics:

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

18.9.1.2. Qualitative and quantitative benefits

18.9.1.3. Estimates of costand time to breakeven

18.9.1.4. Profit expectations

18.9.1.5. Follow-on opportunities

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

18.9.1.7. The impact of the project on the business operations

18.9.1.8. The impact of the project on the technology infrastructure

18.9.1.9. Constraints associated with the proposed project

18.9.1.10. Estimated budget

18.9.1.11. Alignment with priorities established by the business

18.9.2. Main idea of a Business Case

18.9.2.1. A Business Case demonstrates that:

18.9.2.1.1. The solution proposal has been analyzed properly

18.9.2.1.2. The full benefits will be realized in time

18.9.2.1.3. Any technical aspects have been thoroughly evaluated

18.9.3. Purpose of a Business Case

18.9.3.1. Buildingthe Business Case allows the organization to

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

18.9.3.1.2. Justify the value of proposals to the organization

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

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

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

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

18.9.4. Content of a Business Case

18.9.4.1. Reference

18.9.4.1.1. Project name/reference

18.9.4.1.2. Origins/background/curr ent state

18.9.4.2. Context

18.9.4.2.1. Business objectives/opportunities

18.9.4.2.2. Business strategic alignment (priority)

18.9.4.3. Value Proposition

18.9.4.3.1. Desired business outcomes

18.9.4.3.2. Business benefits

18.9.4.3.3. Quantified benefits value

18.9.4.3.4. Costs

18.9.4.3.5. ROI Financial scenarios

18.9.4.3.6. Risks / costs of not proceeding

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

18.9.4.4. Focus

18.9.4.4.1. Problem/solution scope

18.9.4.4.2. Assumptions

18.9.4.4.3. Constraints

18.9.4.4.4. Options identified / evaluated

18.9.4.4.5. Size assessment

18.9.4.4.6. Scale assessment

18.9.4.4.7. Complexity assessment

18.9.4.5. Deliverables

18.9.4.5.1. Outcomes, deliverables and benefits planned

18.9.4.5.2. Organizational areas impacted (internally and externally)

18.9.4.5.3. Key stakeholders

18.9.4.5.4. Dependencies

18.9.4.6. Workload

18.9.4.6.1. Approach

18.9.4.6.2. Phase/stage definitions

18.9.4.6.3. Project activities

18.9.4.6.4. Technical delivery activities

18.9.4.6.5. Workload estimate/breakdown

18.9.4.6.6. Project plan

18.9.4.6.7. Project schedule

18.9.4.7. Required resources

18.9.4.7.1. Project leadership team

18.9.4.7.2. Project governance team

18.9.4.7.3. Team resources

18.9.4.7.4. Funding

18.9.4.8. Commitments

18.9.4.8.1. Project control

18.9.4.8.2. Reporting processes

18.9.4.8.3. Deliverables schedule

18.9.4.8.4. Financial budget/schedule

18.9.5. Quality attributes of a Business Case

18.9.5.1. Accountable

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

18.9.5.2. Adaptable

18.9.5.2.1. adjusted to the size and risk of the proposal

18.9.5.3. Business oriented

18.9.5.3.1. concerned with the business capabilities / impact

18.9.5.4. Consistent

18.9.5.4.1. every project addresses the same basic business issues

18.9.5.5. Transparent

18.9.5.5.1. key elements can be justified

18.9.5.6. Understandable

18.9.5.6.1. the content is clear, relevant and logical

18.9.6. Procedure of building a Business Case

18.9.6.1. 1. Identify and quantify the benefits

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

18.9.6.1.2. Benefits should be quantified.

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

18.9.6.1.4. Estimates should be linked back to strategic goals.

18.9.6.2. 2. Identify and quantify the costs

18.9.6.2.1. Estimate the total net cost of the solution.

18.9.6.2.2. Estimate:

18.9.6.3. 3. Prepare the Business Case

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

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

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

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

18.9.6.4.2. Build a plan for benefit measurement and reporting.

18.9.7. Sample structure of a Business Case

18.9.7.1. 1. Executive summary

18.9.7.2. 2. Introduction and summary

18.9.7.2.1. Project rationale for preferred option

18.9.7.2.2. Current business process

18.9.7.2.3. Description of the problem

18.9.7.2.4. Opportunity

18.9.7.2.5. Project objectives

18.9.7.2.6. Project scope

18.9.7.2.7. Business benefits

18.9.7.2.8. Project costs

18.9.7.2.9. Assumptions

18.9.7.2.10. Potential business and staff impact analysis

18.9.7.2.11. Potential technology impact analysis

18.9.7.2.12. Implementation plan

18.9.7.3. 3. Approach

18.9.7.3.1. Financial metrics

18.9.7.3.2. Privacy impact assessment

18.9.7.3.3. Alternative evaluation criterion

18.9.7.4. 4. Key selection criterion

18.9.7.4.1. Weighting

18.9.7.4.2. Constraints and limitations

18.9.7.5. 5. Preferred alternative

18.9.7.5.1. Business benefits

18.9.7.5.2. Alternative costs

18.9.7.5.3. Assumptions

18.9.7.5.4. Potential business and staff impact analysis

18.9.7.5.5. Other issues

18.9.7.6. 6. Risk Management Plan

18.9.7.6.1. Risk assessment

18.9.7.6.2. Risk response

18.9.7.6.3. Benefit realization

18.9.7.7. 7. Conclusion and recommendations

19. Solution scope

19.1. Determining solution scope

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

19.1.2. A base for detailed requirements development.

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

19.2. Techniques to determine solution scope

19.2.1. Work Breakdown Structure (WBS)

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

19.2.2. Product Breakdown Structure (PBS)

19.2.2.1. A decomposition of the components of the product.

19.2.3. System Interface Analysis

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

19.3. UML Use Cases

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

19.3.2. Shows the connections with external systems and actors.

20. Requierements related standards

20.1. ISO 25000 (ISO / IEC 9126)

20.1.1. Defines a quality model with 6 categories

20.1.1.1. Efficiency

20.1.1.2. Functionality

20.1.1.3. Maintainability

20.1.1.4. Portability

20.1.1.5. Reliability

20.1.1.6. Usability

20.2. IEEE 830

20.2.1. Recommended Practice for Software Requirements Specifications

20.3. IEEE 1233

20.3.1. Guide for Developing of System Requirements Specifications

20.4. IEEE 1362

20.4.1. Guide for Information Technology - System Definition

21. Interactive Glossary

21.1. Interactive IQBBA® Glossary

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