1. Process Improvement
1.1. Process Improvement
1.1.1. Process Improvement is a method to introduce process changes to improve quality, reduce costs or accelerate schedules
1.1.2. Improving the business process
1.1.2.1. Approaches
1.1.2.1.1. Manual re-designing of the process on the base of experience and domain knowledge
1.1.2.1.2. Introducing tools allowing to optimize the business processes in the organization
1.1.2.1.3. Process simulation and optimizing
1.1.2.1.4. Adopting selected methodology or strategy
1.1.3. Triggers of Process Improvement
1.1.3.1. Process Improvement may follow a specific methodology or strategy
1.1.3.1.1. Benchmarking
1.1.3.1.2. Business Process Improvement
1.1.3.1.3. Business process reengineering
1.1.3.1.4. Capability Maturity Model Integration / Capability Maturity Model
1.1.3.1.5. ISO 9000
1.1.3.1.6. IT Governance
1.1.3.2. Just In Time manufacturing
1.1.3.3. Lean manufacturing
1.1.3.4. Performance improvement
1.1.3.5. Process management
1.1.3.6. Process improvement and Management (PI&M)
1.1.3.7. Six Sigma
1.1.3.8. Total Quality Management
1.1.4. Business Process Improvement
1.1.4.1. BPI is a systematic approach to help an organization optimizing its underlying processes to achieve more efficient results
1.1.4.2. The goal - radically change the performance of an organization
1.1.4.3. No improvement by a series of small incremental changes
1.1.5. Methodology of BPI
1.1.5.1. Define the organization's strategic goals and purposes together with the existing structure and processes (AS-IS)
1.1.5.2. Determine the organization's stakeholders and identify
1.1.5.2.1. What outcomes adds value to the organization's objectives
1.1.5.2.2. What are the best ways to align its processes to achieve those outcomes (TO-BE)
1.1.5.3. Re-organize the business processes to realize the goals and to meet the new objectives
1.1.5.3.1. Supported by the tools available within the BPI methodology
1.1.6. Roles in BPI
1.1.6.1. Business Leader
1.1.6.1.1. Responsible for developing business plans (including strategic plans)
1.1.6.1.2. Responsible for developing resource plans
1.1.6.2. Process Owner
1.1.6.2.1. Designs processes
1.1.6.2.2. Responsible for the creation, update and approval of documents to support the process.
1.1.6.3. Operational Manager
1.1.6.3.1. Organizes the resources and processes in order to achieve the objectives of the business plans created by the Business Leaders
1.1.6.3.2. Instructs the Process Operators how to perform the processes
1.1.6.4. Process Operator
1.1.6.4.1. Performs the processes necessary to achieve the objectives of the business plans created by Business Leaders
1.1.6.4.2. Ensures the realization of a process meets performance objectives
1.1.6.4.3. Ensures the products of the processes meet the specifications
1.1.6.5. The roles has different responsibilities but they work together!
1.2. Process simulation and redesigning
1.2.1. Business Process Simulation
1.2.1.1. Business Process Simulation (BPS) is a part of Business Process Management (BPM)
1.2.1.2. BPS allows simulating
1.2.1.2.1. The execution of business processes
1.2.1.2.2. Parameters over time
1.2.1.3. Simulation is based on process models
1.2.1.4. The purpose
1.2.1.4.1. Understand, analyze and design (or re-design) business process models with respect to performance metrics
1.2.1.4.2. Evaluation and comparing the (re)designed processes and implementing the best choice
1.2.2. Process models
1.2.2.1. The process models must represent
1.2.2.1.1. The specific elements of the business process
1.2.2.1.2. The attributes of the business process
1.2.2.2. Running the simulation allows checking how the process is realized
1.2.2.3. BPS Procedure
1.2.2.3.1. Mapping the business process onto a process model
1.2.2.3.2. Identification of the sub processes and activities
1.2.2.3.3. Creating the control flow definition
1.2.2.3.4. Identification of the resources and assigning them to the activities
1.2.2.3.5. Defining performance characteristics
1.2.2.4. Running the simulation
1.2.2.4.1. Simulation should be executed for several sub runs
1.2.2.4.2. A simulation is run in a specific tool
1.2.2.4.3. Tools show an animated picture of the process flow or real-time fluctuations in the key performance measures
2. Tools and Techniques
2.1. Modeling tools
2.1.1. Modeling tools allow to
2.1.1.1. Link requirements in models
2.1.1.2. Create graphical representation of requirements
2.1.1.3. Represent relations between requirements, and between requirements and other artifacts
2.1.1.4. Establish and maintain traceability
2.1.1.5. Design the overall structure of the system
2.2. Business Analysis techniques
3. Solution Validation
3.1. Assessment
3.2. Validation
4. Requirements Analysis
4.1. Requirements Organization
4.1.1. Requirements are organized (structured) into packages
4.1.1.1. The purpose of organizing requirements
4.1.1.1.1. To determine the solution boundary
4.1.1.1.2. To determine the solution scope
4.1.1.1.3. To define the structure of requirements
4.1.1.2. The problem model is decomposed to make each requirement more detailed and to ensure that the model correctly reflects the boundary for the business problem
4.1.2. Decomposition
4.1.2.1. Goal decomposition
4.1.2.1.1. Allows ensuring the solution will satisfy stakeholder's needs
4.1.2.1.2. Breaks down high-level stakeholder goals into lower-level goals
4.1.2.1.3. Lower-level goals have measurable objectives
4.1.2.1.4. Goals are business requirements
4.1.2.2. Feature list decomposition
4.1.2.2.1. Feature is a service that the solution provides to fulfill one or more stakeholder needs
4.1.2.2.2. Feature is an abstraction of the solution of the problem expressed on high-level
4.1.2.2.3. Feature is developed into completely described functional and supplemental requirements
4.1.2.3. Functional decomposition
4.1.2.3.1. Functional decomposition is a breakdown of a list of items into classifications or groups on the basis of the function each item performs or is used for
4.1.2.3.2. Identifies the high-level functions
4.1.2.3.3. Breaks them down into sub-processes and activities
4.1.2.3.4. Functional decomposition is used to
4.1.2.3.5. Levels of detail for functional decomposition
4.2. Modeling and Specification
4.2.1. Model
4.2.1.1. Model is a representation of an object
4.2.1.2. System model is a conceptual description and representation of the system
4.2.1.3. Model describes
4.2.1.3.1. The structure of the system
4.2.1.3.2. Dependencies and relationships between the system's objects system model is a
4.2.1.3.3. Textual elements
4.2.1.3.4. Matrixes
4.2.1.3.5. Diagrams
4.2.1.4. Reflects the relationships and dependencies between requirements realizing identified business needs
4.2.2. Modeling
4.2.2.1. Modeling is a way of expressing requirements representing parts or the whole of the proposed solutions
4.2.2.2. Modeling is helpful but not always necessary
4.2.2.3. The organization may skip modeling when:
4.2.2.3.1. The solution is fully understood by the stakeholders
4.2.2.3.2. The solution is easy to implement
4.2.2.3.3. The requirements are mostly non-functional and difficult to express in the form of a model
4.2.2.3.4. The problem domain is well known
4.2.2.3.5. The solution is dedicated to use by very few people
4.2.2.3.6. The scope is declared as constant
4.2.2.3.7. The model representation would be less understandable by the key stakeholders than written text
4.2.2.4. Advantages of Modeling
4.2.2.4.1. Models allow to focus on the important aspects and areas of the solution
4.2.2.4.2. Models describes complex system in more clear and unambiguous way
4.2.2.4.3. Models are more readable and clear than written text
4.2.2.4.4. Looking at the problem from the overall perspective
4.2.2.5. Modeling Techniques
4.2.2.5.1. Archimate
4.2.2.5.2. BPMN
4.2.2.5.3. DSL
4.2.2.5.4. GUI modelling
4.2.2.5.5. OBASHI
4.2.2.5.6. SysML
4.2.2.5.7. UML
4.2.2.5.8. ...
4.3. Defining Assumptions and Constraints
4.3.1. Assumptions and constraints identify aspects of the problem domain that are not functional requirements of a solution, and will limit or impact the design of the solution
4.3.2. Constraint
4.3.2.1. A constraint is a requirement that explicitly and intentionally tries to directly restrict any system or process
4.3.2.2. Limitations on
4.3.2.2.1. Engineering process System's operation Lifecycle
4.3.3. Types of constraints
4.3.3.1. Business constraints
4.3.3.1.1. Financial or time restrictions, limits on the number of resources available, skills of the project team or any other organizational restriction
4.3.3.1.2. Limitations on the projects flexibility to implement requested solution
4.3.3.2. Technical constraints
4.3.3.2.1. Related to the architecture of the solution (hardware and software platforms, programming language or technology, supporting software)
4.3.3.2.2. Technical constraints include also: database size, resource utilization, message size, software size, maximum number of and size of files
4.3.4. Example constraints
4.3.4.1. Hardware or software environment
4.3.4.2. End-user environment
4.3.4.3. Availability or volatility of resources
4.3.4.4. Standards compliance
4.3.4.5. Interoperability requirements
4.3.4.6. Interface / protocol requirements
4.3.4.7. Data repository requirements
4.3.4.8. Data distribution requirements
4.3.4.9. Security requirements
4.3.4.10. Memory limitations
4.3.4.11. Performance requirements
4.3.4.12. Network communications
4.3.5. Assumption
4.3.5.1. Assumptions are things that are believed to be true but have not been confirmed
4.3.5.2. Assumptions are unproven conditions, which if not true at some defined point in time, would affect the initiative / solution
4.3.5.3. Assumptions often become limitations!
4.3.5.4. Goal
4.3.5.4.1. Assumptions are used to document
4.3.6. Types of assumptions
4.3.6.1. Business assumptions
4.3.6.1.1. The purpose: to inform the project team of key stakeholder expectations
4.3.6.2. Requirements assumptions
4.3.6.2.1. The purpose: to transfer business domain knowledge to the project team
4.3.7. Example assumptions
4.3.7.1. The back-end system is available
4.3.7.2. There is no more than 1000 transactions per day
4.3.7.3. All transactions are processed in EURO
4.4. Verification and Validation
4.4.1. Validation
4.4.1.1. Validation is an activity of confirmation by examination and through provision of objective evidence that the requirements for a specific intended use or application have been fulfilled [ISO 9000]
4.4.1.2. Goal
4.4.1.2.1. The goal of validation is to ensure that the stated requirements correctly implement the business requirements determined in Enterprise Analysis and Requirements Identification phases
4.4.2. Verification
4.4.2.1. Verification is a confirmation by examination and through provision of objective evidence that specified requirements have been fulfilled [ISO 9000]
4.4.2.2. Verification ensures that requirements are defined clearly enough to allow solution design and implementation and test preparation to begin
4.4.2.3. Verification process requires to involve and cooperate closely with
4.4.2.3.1. Customer
4.4.2.3.2. Users
4.4.2.3.3. Project team
4.4.2.4. Requirements can be stated as verified if
4.4.2.4.1. Project stakeholders agreed that the requirements are correctly understood
4.4.2.4.2. The requirements were checked with the stakeholders and confirmed as complete description of what has to be implemented
4.4.2.4.3. The requirements were stated as of high quality
4.5. Quality Assurance
4.5.1. Quality Assurance
4.5.1.1. Quality Assurance is a process of monitoring the quality of the process or project in order to ensure that minimum level of quality standards is achieved
4.5.2. Quality criteria for requirements
4.5.2.1. Allocatable
4.5.2.2. Complete
4.5.2.3. Consistent
4.5.2.4. Correct
4.5.2.5. Does not determine solution
4.5.2.6. Feasible
4.5.2.7. Measurable
4.5.2.8. Necessary
4.5.2.9. Prioritized
4.5.2.10. Testable
4.5.2.11. Traceable
4.5.2.12. Unambiguous
4.5.2.13. Understandable
4.5.3. Examples of QA techniques
4.5.3.1. Checklists
4.5.3.1.1. A common technique for quality control
4.5.3.1.2. A standard or customized set of quality elements to validate the Requirements Specification (or other artefact)
4.5.3.2. Reviews
4.5.3.2.1. A review is an evaluation of a product or project status to ascertain discrepancies from planned results and to recommend improvements [IEEE 1028]
4.5.3.2.2. Examples
4.5.3.3. Testing
5. Requirements Elicitation
5.1. The concept of Requirements Elicitation
5.1.1. Business Requirements Elicitation
5.1.1.1. Business Requirements Elicitation is a set of approaches, activities, tasks and techniques allowing to collect the business requirements of a planned solution, from the stakeholders and other available sources
5.1.2. The purpose of Business Requirements Elicitation
5.1.2.1. Identification of:
5.1.2.1.1. Desired functions
5.1.2.1.2. Attributes
5.1.2.1.3. Quality characteristics
5.1.2.1.4. Limitations and expectations
5.1.2.1.5. Requirements resulted from external regulations, norms etc.
5.1.2.1.6. Orientation of the requirements toward the project vision
5.1.2.2. Establishing the finał scope
5.1.2.3. Establishing business design of the system
5.1.2.4. Excluding functions that the customer does not want and need
5.1.3. Techniques for Requirements Elicitation
5.1.3.1. Q.uestionnaires
5.1.3.1.1. What is it?
5.1.3.1.2. Quastionnaire can collect information about:
5.1.3.1.3. 2 types:
5.1.3.1.4. Process:
5.1.3.1.5. Questions
5.1.3.2. lnterviews
5.1.3.2.1. What is it?
5.1.3.2.2. 2 types:
5.1.3.2.3. Process:
5.1.3.3. Self-recording
5.1.3.3.1. The user records his own activities (AS-IS).
5.1.3.3.2. Documents all steps, inputs and resources needed to complete a task / procedure.
5.1.3.3.3. The user describes also changes, desires and needs.
5.1.3.3.4. Advantages:
5.1.3.3.5. Disadvantages
5.1.3.4. Customer's representative
5.1.3.4.1. A main idea in Agile methods. Allows close cooperation and direct communication with the customer. One of the most effective requirements identification (and validation) method.
5.1.3.4.2. Assumption:
5.1.3.4.3. The representative:
5.1.3.5. Identification on the basis of existing documents
5.1.3.5.1. Allows to elicit requirements of an existing system by studying available documentation and identifying relevant information.
5.1.3.5.2. Used to gather details of the AS IS environment for the solution:
5.1.3.5.3. Process:
5.1.3.6. Reuse (Reusing the specification of a certain project)
5.1.3.6.1. Reuse of documentation / solution from previous projects.
5.1.3.6.2. Requirements specification prepared for previous project can be used in another, similar, project.
5.1.3.6.3. Shorts the duration of Business Analysis.
5.1.3.6.4. Important notice:
5.1.3.7. Brainstorming
5.1.3.7.1. A way of eliciting many creative ideas for an area of interest.
5.1.3.7.2. Produces numerous creative ideas about any given "central question" or topic.
5.1.3.7.3. Promotes diversion type of thinking.
5.1.3.7.4. Brainstorming to detail identified requirements and find new ones
5.1.3.7.5. Brainstorming helps answer specific questions:
5.1.3.7.6. Process:
5.1.3.8. Field observation
5.1.3.8.1. Conducting an assessment of the user's work environment.
5.1.3.8.2. Studying people performing their jobs-without any interventions!
5.1.3.8.3. Observation is usually used:
5.1.3.8.4. 2 types:
5.1.3.9. Apprenticing
5.1.3.9.1. Apprenticing is a process of learning from the user his job
5.1.3.9.2. The customer teaches the Business Analyst.
5.1.3.9.3. Master and student approach.
5.1.3.9.4. Useful when the customer is not able to provide full time support of his employees.
5.1.3.9.5. Overcomes the problem of abstract thinking and expressing the tasks in words
5.1.3.9.6. Users can always refer to the actual case and explain things on examples.
5.1.3.10. Workshops (after each iteration)
5.1.3.10.1. Workshop is a structured way to capture requirements.
5.1.3.10.2. May be used to scope, discover, define, prioritize and reach closure on requirements for the solution.
5.1.3.10.3. Its is not a traditional meeting.
5.1.3.10.4. Focused event attended by key stakeholders and subject matter experts for a short period.
5.1.3.10.5. Workshop roles
5.1.3.10.6. Process:
5.1.3.11. Prototyping
5.1.3.11.1. Helps uncover and visualize interface requirements before the solution is designed or developed
5.1.3.11.2. Prototyping to visualize implementation of identified requirements
5.1.3.12. Focus groups
5.1.3.12.1. Used to elicit ideas and attitudes about a specific problem in an interactive group environment
5.1.3.13. Interface Analysis
5.1.3.13.1. Helps to clarify the boundaries of the system
5.1.3.14. Important notice:
5.1.3.14.1. The best results are achieved when mixing some techniques.
5.1.4. Requirements quality characteristics
5.1.4.1. Functionality
5.1.4.2. Reliability
5.1.4.3. Usability
5.1.4.4. Efficiency
5.1.4.5. Maintainability
5.1.4.6. Portability
5.2. Requirements Scope Management
5.2.1. Managing requirements scope is considered as managing the list of the requirements of some or all of the following projects
5.2.1.1. System or component development
5.2.1.2. Process improvement
5.2.1.3. Organizational change
5.2.2. Requirements Scope Management
5.2.2.1. 1. Establishing requirements baseline
5.2.2.2. 2. Creating a requirements structure for traceability
5.2.2.3. 3. Identifying impact to external systems and other areas of the project
5.2.2.4. 4. Identifying changes in the scope resulting from requirements changes
5.2.2.5. 5. Maintaining scope approval
5.3. Establishing requirements baseline
5.3.1. All requirements identified and approved by stakeholders must be baselined
5.3.2. The baseline
5.3.2.1. Is a base for further system development
5.3.2.2. A point of reference for any changes in the content / scope of requirements
5.3.3. Creating a requirements structure for traceability
5.3.3.1. Requirements traceability is necessary for managing changes to the requirements done after the requirements are baselined
5.3.4. Impact to other systems / areas
5.3.4.1. Identification of all impacts to external systems and other areas of the project necessary to ensure that there is no work outside the baselined list of requirements
5.3.5. Changes in requirements scope affects
5.3.5.1. Project schedule
5.3.5.2. Project cost
5.3.5.3. Project and product risk
5.3.5.4. Project Resources
5.3.5.5. External interface to another systems or hardware
5.3.6. Identifying changes in the scope
5.3.6.1. Requirements are not constant throughout the project's lifecycle
5.3.6.2. Impact on the project
5.3.6.2.1. Minor change -> no impact on the project scope, time or cost
5.3.6.2.2. Major change -> may drastically change the project scope, time or cost
5.3.6.3. Major changes examples
5.3.6.3.1. Changing business logic
5.3.6.3.2. Changing process flow for critical functionality
5.3.7. Maintaining scope approval
5.3.7.1. The list of requirements must be approved and baselined
5.3.7.2. The approved list of requirements is a mutual understanding between the customer and the vendor team about the requirements
5.3.7.3. Changes in the approved list of requirements must be managed via Change Management procedures
5.4. Requirement Traceability
5.4.1. Goals
5.4.1.1. Scope management
5.4.1.2. Impact analysis
5.4.1.3. Coverage analysis
5.4.1.4. Proof of implementation
5.4.1.5. Use of the requirement
5.4.1.6. Defect reports
5.4.2. Traceability
5.4.2.1. Traceability is an association existing between requirements when more detailed requirements are associated with the higher level requirements (needs and features)
5.4.2.2. Traceability may exist between detailed requirements and both design models and test cases
5.4.2.3. Traceability between requirements and other project artefacts aIlows to ensure all requirements are met
5.4.2.4. Representing traceability on UML diagrams
5.4.3. Tool support
5.4.3.1. Requirements Management software
5.4.3.1.1. Storing all requirements of all specifications of a technical system under development
5.4.3.1.2. Arranging requirements in structures (specification tree)
5.4.3.1.3. Linking each one to the "parent" requirement in the higher specification
5.4.3.2. Requirements are realized into:
5.4.3.2.1. Design artefacts
5.4.3.2.2. Implementation
5.4.3.2.3. Test cases
5.4.3.3. Artefacts are traced back to the requirements.
5.4.4. Tools
5.4.4.1. Requirements Traceability Matrix
5.4.4.1.1. Track all requirements and check if they are being met by the current process
5.4.4.1.2. Assist in the creation of project's documentation
5.4.4.1.3. Supports verification process
5.4.4.1.4. RTM is created at the beginning of a project
5.4.4.2. Bi-directional Traceability Matrix
5.4.4.2.1. Bi-directional Traceability Matrix between Software Requirements Specification (SRS) and Software Design Document (SDD )
5.4.5. Software
5.4.5.1. i.e. Enterprise Analyst
5.4.5.2. i.e. Enterprise Architect
5.4.5.3. …
5.5. Requirements Documentation
5.5.1. Requirements document
5.5.1.1. A requirements document describes a set of related functional and non-functional requirements
5.5.1.2. No project deliverable information - constant time
5.5.1.3. Formalizes the project scope
5.5.2. Purpose of the requirements document
5.5.2.1. Structuring the requirements
5.5.2.2. Providing clear and unambiguous explanation of the requirements
5.5.2.3. A basis for implementation and testing
5.5.2.4. A basis for requirement management
5.5.2.4.1. Documentation is a baseline
5.5.3. Content of a requirements document
5.5.3.1. Assumptions
5.5.3.2. Business Process Description (BPD)
5.5.3.2.1. An executive summary of an initiative
5.5.3.2.2. Describes the problem and the proposed solution in high-level terms
5.5.3.3. Business Requirements Document (BRD)
5.5.3.3.1. Describes the behavior required of a software application
5.5.3.3.2. Primarily describes the business requirements
5.5.3.3.3. The target audience is the customer and users
5.5.3.4. Dependencies
5.5.3.5. Functional requirements
5.5.3.6. Introduction
5.5.3.7. Non-functional requirements
5.5.3.8. Overall description
5.5.3.9. Purpose of the product
5.5.3.10. Regulations
5.5.3.11. Request for Proposal / Request for Quotation (RFP / RFQ)
5.5.3.11.1. Distributed to parties outside the organization
5.5.3.11.2. Basis for the contracting of solution development services
5.5.3.12. Risks
5.5.3.13. Safety requirements Document acceptance
5.5.3.14. Secrecy clause
5.5.3.15. Software Requirements Specification (SRS)
5.5.3.15.1. Also known as a System Requirements Specification
5.5.3.15.2. Describes the behavior and implementation of a software application
5.5.3.15.3. The target audience is the development team
5.5.3.16. Stakeholders
5.5.3.17. Standards
5.5.3.18. ...
5.5.4. Common Document Formats
5.5.4.1. Software Requirements Specification (SRS)
5.5.4.1.1. A description of the problem domain
5.5.4.1.2. Decomposition of the problem domain
5.5.4.1.3. Description of the functional requirements
5.5.4.1.4. Description of the non-functional requirements
5.5.4.1.5. Assumptions and constraints affecting the solution
5.5.4.1.6. Requirements attributes and traceability information
5.5.5. Construction of a requirement
5.5.5.1. Describe business justification for the requirement
5.5.5.2. Identify the business process
5.5.5.3. Identify the stakeholders
5.5.5.4. Identify the limitations and assumptions
5.5.5.5. Describe the context
5.5.5.6. Describe the requirement
5.5.5.6.1. Input
5.5.5.6.2. Output
5.5.5.6.3. Resources
5.5.5.6.4. Quality characteristics (if applicable)
5.5.5.7. Provide the graphical model (if applicable)
5.5.5.8. Describe risks
5.5.5.9. Provide references
5.5.6. Guidelines for the requirements document
5.5.6.1. The requirements must be unambiguous, precise and understandable
5.5.6.2. Superfluous information should be avoided
5.5.6.3. Templates as an aid to limit language
5.5.6.4. Models and diagrams makes the document clear and more understandable
5.5.6.5. Use formal graphical notation to express complex requirements, dependencies and relationships
5.5.7. Common Document Problems
5.5.7.1. Trivialities
5.5.7.1.1. Lengthy descriptions of commonly known issues
5.5.7.2. Information out of scope
5.5.7.2.1. Information without added value to the description of the solution
5.5.7.3. Thinking in solutions
5.5.7.3.1. Description of solutions
5.5.7.3.2. Requirement specification determining the technical design
5.5.7.4. Redundant details
5.5.7.4.1. Details unnecessarily complicating the implementation
5.5.7.4.2. Implementation details
5.5.7.5. Lacking rationale
5.5.7.5.1. No description of what shall be achieved with the solution (inc. concrete numbers and metrics)
5.6. Requirements Communication
5.6.1. Requirements Communication
5.6.1.1. Requirements Communication includes activities for expressing the output of the requirements analysis and documentation to the stakeholders
5.6.2. Communication
5.6.2.1. An ongoing and iterative activity
5.6.2.1.1. Presenting
5.6.2.1.2. Communicating
5.6.2.1.3. Verifying
5.6.2.1.4. Obtaining approval
5.7. The role of a Business Analyst
5.7.1. Communicate requirements in a way allowing all stakeholders to gain the same understanding of a particular requirement
5.7.2. Consider and choose communication approach appropriate for the project
5.8. Requirements Communication process
5.8.1. 1. Preparing requirements communication Plan
5.8.2. 2. Managing requirements conflicts
5.8.3. 3. Establishing the most appropriate requirements format
5.8.4. 4. Creating requirements package
5.8.5. 5. Conducting requirements presentation
5.8.6. 6. Performing formal requirements review
5.8.7. 7. Obtaining requirements approval (Sign-off)
5.9. Requirement acceptance
5.9.1. Requirements should be agreed and accepted by all relevant stakeholders
5.9.2. All requirements must be formally approved
5.9.3. Formal agreement
5.9.3.1. Starting point for detailed system specification, designing the architecture and other works on the planned system
5.10. Stakeholders with the acceptance authority
5.10.1. Business Sponsor
5.10.2. Project Managers
5.10.3. Business Analysts
5.10.4. Architects
5.10.5. Test / QA Manager
5.11. Standards
5.11.1. ISO 25000 (ISO/IEC 9126)
5.11.1.1. Defines a quality model with 6 categories:
5.11.1.1.1. Functionality
5.11.1.1.2. Reliability
5.11.1.1.3. Usability
5.11.1.1.4. Efficiency
5.11.1.1.5. Maintainability
5.11.1.1.6. Portability
5.11.2. IEEE 830
5.11.2.1. Recommended Practice for Software Requirements Specifications
5.11.3. IEEE 1233
5.11.3.1. Guide for Developing of System Requirements Specifications
5.11.4. IEEE 1362
5.11.4.1. Guide for Information Technology - System Definition
6. Major reasons of neglecting Business Analysis
6.1. Time praccure
6.2. Exclusive orientation towards fast results
6.3. Exclusive fixation on costs
6.4. Perceiving documentation or analyzing and understanding business processes as a cost, not added value
6.5. Business process within an organization not known / understood as a result:
6.5.1. Imprecise, ambiguous, contradictory or missing requirements
6.5.2. Requirements that change
6.5.3. Requirements that do not fulfill the agreed criteria (i.e. quality criteria)
6.6. Products of the business processes not known
6.7. Stakeholders not identified or identified only pertially
6.8. Business goals or needs not identified
6.8.1. The organization needs not satisfied
6.8.2. The business goals not achieved
7. Common pitfalls in Business Analysis
7.1. Bad quality of the requirements and / or business needs:
7.1.1. Incomplete
7.1.2. Inconsistent
7.1.3. Not measurable
7.1.4. Unclear objectives
7.1.5. Communication problems
7.1.6. Language barriers
7.1.7. Knowledge barriers
7.1.8. Vague formulation
7.1.9. Too formal formulations
7.1.10. Ambiguous, overly specified, unclear, impossible, contradictory requirements
7.1.11. Instability of the requirements (frequent changes)
7.1.12. Redundant description of requirements
7.1.13. Insufficient user invelvement
7.1.14. Overlooked user classes
7.1.15. Minimal specification
8. Business Analyst
8.1. "A Business Analyst is a person responsible for identifying the business needs of the customer / stakeholders and to determine solutions to business problems."
8.1.1. source BABOK
8.2. “A business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate, and validate requirements for changes to business processes, policies, and information systems.”
8.3. The Business Analyst, ensures that the PRODUCT of the project is well-defined (product scope) throughout the project and meets the targeted business needs through expert requirements management, systems analysis, business analysis, and requirements analysis.
8.3.1. Product Scope
8.3.1.1. "The features and functions that characterize a product, service, or result."
8.3.2. Project Scope
8.3.2.1. "The work that needs to be accomplished to deliver a product, service, or result with the specified features and functions."
8.3.3. A Business Analyst might start “bridging” further up the stream in terms of business needs and problems and stop “bridging” at the functional requirements level or at WHAT the system will do and leave it to a systems analyst or a senior developer to determine HOW to do it.
8.4. Business Analyst Role
8.4.1. A liaison among stakeholders
8.4.2. Identify, analyze, communicate and validate requirements for changes to:
8.4.2.1. Business processes
8.4.2.2. Policies
8.4.2.3. Information Systems
8.5. Business Analyst Major tasks
8.5.1. Requirements elicitation (identification)
8.5.2. Requirements analysis and modelling
8.5.3. Requirements realization planning
8.5.4. Requirements communication
8.5.5. Requirements documenting
8.5.6. Requirements validation
8.5.7. Requirements configuration management
8.5.8. Business solution proposal
8.6. Specific activities of Business Analyst
8.6.1. Identification
8.6.2. Developing
8.6.3. Managing the requirements
8.7. Business Bnalysts want to achieve the following outcomes
8.7.1. Reduce waste
8.7.2. Create solutions
8.7.3. Complete projects on time
8.7.4. Improve efficiency
8.7.5. Document the right requirements
8.7.6. Identify the root causes of problems
8.8. Activities of Business Analyst
8.8.1. Requirements Elicitation (identification)
8.8.2. Requirements Analysis
8.8.3. Requirements Specification
8.8.4. Requirements Management
8.8.4.1. Including Configuration Management
8.8.5. Requirements Communication
8.8.5.1. Communicate requirements in a way allowing all stakeholders to gain the same understanding of a particular requirement
8.8.5.2. Consider and choose communication approach appropriate for the project
8.8.6. Requirements Documentation
8.8.7. Requirements Modeling
8.8.8. Requirements Validation
8.9. Business Analysis in different phases of the Software Development Lifecycle (SDLC)
8.9.1. Analysis phase
8.9.1.1. Identification and evaluating of the current business processes (AS IS analysis)
8.9.1.2. Gathering initial requirements for needed business solution (TO BE analysis)
8.9.1.3. Creating and analyzing Business Case
8.9.1.4. Conducting feasibility study
8.9.1.5. Preparing ideas of business solution
8.9.2. Specification phase
8.9.2.1. Identifying and documenting business requirements on more detailed level
8.9.2.2. Supporting System Analyst in preparing detailed system specifications
8.9.2.3. Validating proposed software design with the customer and other stakeholders
8.9.2.4. Managing requirements changes
8.9.3. Development phase
8.9.3.1. Supporting development team during implementation
8.9.3.2. Validating increments of solution according to intended requirements and needs
8.9.3.3. Supporting testers in preparing test cases and test scripts at business level
8.9.3.4. Managing potential changes in requirements
8.9.4. Testing phase
8.9.4.1. Checking test results
8.9.4.2. Resolving issues related to defects or gaps in the requirements
8.9.4.3. Supporting preparing test cases for User Acceptance Testing
8.9.4.4. Supporting acceptance testers in executing test cases
8.10. When a Business Analyst is needed?
8.10.1. When a need for clarification of business issues appears (implementation, testing)
8.10.2. When a need for new functionalities appears
8.10.3. When the business changes
8.10.4. When the end users need support with working with the solution
8.10.5. A Business Analyst is involved during the whole software life cycle, including maintenance phase
9. Objectives of Business Analysis
9.1. Collect and document the business requirements
9.2. Design business solutions to resolve the business problems
9.3. Assist in the timely completion of the project by providing accurate requirements identification and analysis
9.4. Improve efficiency by increasing the quality of requirements identification and analysis and therefore reducing the need for rework and fixes in the later stages of the project
10. System Analyst
10.1. A System Analyst writes technical requirements from the business requirements.
10.2. A Systems Analyst role requires a stronger programming skill set and often involves systems design responsibilities.
11. Requirements
11.1. Requirements descriptors / categories
11.1.1. Requirements should be preceded by descriptors like:
11.1.1.1. Business requirements
11.1.1.2. User requirements
11.1.1.3. Functional requirements (FRs)
11.1.1.4. Non-functional requirements (NFRs)
11.2. Meaning and purpose of requirements
11.2.1. Foundation for project's assessment, planning, execution and monitoring
11.2.2. Customer expectations (stakeholders value)
11.2.3. Component of agreements, project plans
11.2.4. Setting of system boundaries, scope of delivery
11.3. Classification of requirements
11.3.1. Process requirements (project management / HOW)
11.3.1.1. Needs and limitations of the business processes (e.g., management or production processes)
11.3.1.1.1. e.g.
11.3.2. Product requirements (product delivery / WHAT)
11.3.2.1. Functional (F)
11.3.2.2. Non-functional (NF)
11.3.2.3. External
11.3.2.4. Internal
11.4. Types of requirements
11.4.1. Customer requirements (business requirements)
11.4.2. Solution / system requirements
11.4.3. Product / component requirements
11.5. Managing requirements conflicts
11.5.1. A conflict may arise on one or more documented requirements.
11.5.2. Requirements themselves could be in conflict.
11.5.3. 1. Record the conflict in the Issues Log
11.5.4. 2. Analyze the conflict and its source
11.5.5. 3. Resolve the conflict
11.5.5.1. Research (without a formal stakeholder session)
11.5.5.2. Meeting involving affected stakeholders
11.5.5.3. Interviews with other parties
11.5.6. 4. Keep an audit trail of the activity taken
11.5.7. 5. Obtain sign off for the resolution
11.5.8. 6. Document and distribute the results of resolution actions
11.6. Selecting the appropriate requirements format
11.6.1. Questions to be asked:
11.6.1.1. How detailed the requirements need to be?
11.6.1.2. What information is important to communicate?
11.6.1.3. What is the appropriate level of detail of the document?
11.6.1.4. What is the type of audience?
11.6.1.5. What is the stakeholder's preferred style of communication (technical vs. business)?
11.6.2. Requirements can be presented in various formats.
11.6.3. Requirements should be presented in formats understandable for the target audience.
11.6.4. Helps to obtain stakeholder understanding and approval of the requirements.
11.6.5. The type of requirement influences the presentation technique.
11.6.6. The project methodology may specify what tools will be used for documentation
11.6.7. Usually a combination of many formats in one requirements document is used.
11.6.8. e.g.
11.6.8.1. Diagrams
11.6.8.1.1. Process Workflows
11.6.8.1.2. Entity Relationship Diagram
11.6.8.1.3. Process Decomposition Diagram
11.6.8.1.4. UML Use Cases
11.6.8.2. Text
11.6.8.2.1. Textual templates
11.6.8.3. Prototyping
11.6.8.4. Additional formats
11.6.8.4.1. User manuals
11.6.8.4.2. Presentation slides
11.6.8.4.3. User stories
11.7. Creating a requirements package
11.7.1. A comprehensive requirements document to be presented to the stakeholders.
11.7.2. Packaging the requirements supports effective requirements communication.
11.7.3. Requirements may be "packaged" at any point in a project.
11.7.4. Deliveries of the Business Analysis:
11.7.4.1. Assumptions
11.7.4.2. Business needs and objectives
11.7.4.3. Business process flow definition
11.7.4.4. Business requirements
11.7.4.5. Definition of the business process's products
11.7.4.6. Limitations
11.7.4.7. Stakeholders of the project
11.7.5. Process
11.7.5.1. 1. Determine which components of the overall requirements document should be grouped together.
11.7.5.2. 2. Determine the audience to whom the requirements will be presented
11.7.5.3. 3. Evaluate the documentation required based on the type of project
11.7.5.4. 4. Package the requirements for presentation
11.8. Requirements presentation
11.8.1. The first step is to understand the objective of the presentation and the intended audience.
11.8.2. The objective:
11.8.2.1. To review, prioritize or to communicate status
11.8.2.2. To ensure quality of the requirements
11.8.2.3. To improve clarity
11.8.2.4. To obtain requirement's sign off
11.8.3. Subjects:
11.8.3.1. Business requirements
11.8.3.2. Data and behavior models
11.8.3.3. Functional requirements
11.8.3.4. Other models: Use Case models
11.8.3.5. Process / flow models
11.8.4. 2 types:
11.8.4.1. Formal presentation
11.8.4.1.1. Used to:
11.8.4.2. Informal presentation
11.8.4.2.1. Used to:
11.9. Formal requirements review
11.9.1. A working group session in order to review and discuss the requirements.
11.9.2. Participants should review the requirements before the session.
11.9.3. During the session each participant expresses questions; comments and suggestions.
11.9.4. All questions, issues are recorded.
11.9.5. Agreed changes are recorded.
11.9.6. After the session - additional requirements gathering, analysis and documentation and incorporating changes.
11.9.7. Significant changes may require a second review.
11.9.8. Process
11.9.8.1. 1. Prepare the document(s) to be reviewed
11.9.8.2. 2. Determine participants
11.9.8.3. 3. Organize / schedule the review
11.9.8.4. 4. Compile notes and results of the review
11.9.8.5. 5. Conduct the review
11.9.8.6. 6. Deliver document(s) to participants
11.9.8.7. 7. Re-review if necessary
11.10. Requirements quality characteristics (ISO 9126)
11.10.1. Functionality
11.10.2. Reliability
11.10.3. Usability
11.10.4. Efficiency
11.10.5. Maintainability
11.10.6. Portability
11.11. Requirements Scope
11.11.1. Managing requirements scope is considered as managing the list of the requirements of some or all of the following projects:
11.11.1.1. System or component development
11.11.1.2. Process improvement
11.11.1.3. Organizational change
11.12. Requirements Scope Management
11.12.1. 1. Establishing requirements baseline
11.12.1.1. All requirements identified and approved by stakeholders must be baselined.
11.12.1.2. The baseline:
11.12.1.2.1. Is a base for further system development
11.12.1.2.2. A point of reference for any changes in the content/scope of requirements
11.12.2. 2. Creating a requirements structure for traceability
11.12.2.1. Requirements traceability is necessary for managing changes to the requirements done after the requirements are baselined.
11.12.3. 3. Identifying impact to external systems and other areas of the project
11.12.3.1. Identification of all impacts to external systems and other areas of the project necessary to ensure that there is no work outside the baselined list of requirements.
11.12.3.2. Impact to other systems / areas
11.12.3.2.1. External interface to another systems or hardware
11.12.3.2.2. Project and product risk
11.12.3.2.3. Project cost
11.12.3.2.4. Project resources
11.12.3.2.5. Project schedule
11.12.4. 4. Identifying changes in the scope resulting from requirements changes
11.12.4.1. Requirements are not constant throughout the project's lifecycle.
11.12.4.2. Impact on the project:
11.12.4.2.1. Minor change -> no impact on the project scope, time or cost
11.12.4.2.2. Major change -> may drastically change the project scope, time or cost
11.12.5. 5. Maintaining scope approval
11.12.5.1. The list of requirements must be approved and baselined.
11.12.5.2. The approved list of requirements is a mutual understanding between the customer and the vendor team about the requirements.
11.12.5.3. Changes in the approved list of requirements must be managed via Change Management procedures.
11.13. Requirement Traceability
11.13.1. Traceability may exist between detailed requirements and both design models and test cases.
11.13.2. Traceability between requirements and other project artifacts allows to ensure all requirements are met.
11.13.3. Goals of Traceability
11.13.3.1. Scope management
11.13.3.2. Coverage analysis
11.13.3.3. Impact analysis
11.13.3.4. Use of the requirement
11.13.3.5. Proof of implementation
11.13.3.6. Defect reports
11.13.4. Tool support by Requirements Management software
11.13.4.1. Storing all requirements of all specifications of a technical system under development
11.13.4.2. Arranging requirements in structures (specification tree)
11.13.4.3. Linking each one to the "parent" requirement in the higher specification
11.13.4.4. Requirements are realized into:
11.13.4.4.1. Design artefacts
11.13.4.4.2. Implementation
11.13.4.4.3. Test cases
11.13.4.5. Artifacts are traced back to the requirements.
11.13.5. Requirements Traceability Matrix (RTM)
11.13.5.1. RTM is created at the Traceability Matrix is beginning of a project,
11.13.5.2. used to:
11.13.5.2.1. Track all requirements and check if they are being met by the current process
11.13.5.2.2. Assist in the creation of project's documentation
11.13.5.2.3. Supports verification process
11.14. Requirements Documentation
11.14.1. Purpose
11.14.1.1. Structuring the requirements
11.14.1.2. Providing clear and unambiguous explanation of the requirements
11.14.1.3. A basis for implementation and testing
11.14.1.4. A basis for requirement management
11.14.1.4.1. Documentation is a baseline
11.14.2. Requirements Document
11.14.2.1. No project deliverable information
11.14.2.1.1. costand time
11.14.2.2. Formalizes the project scope
11.14.2.3. A requirements document describes a set of related functional and non-functional requirements.
11.14.2.4. Guidelines
11.14.2.4.1. The requirements must be unambiguous, precise and understandable
11.14.2.4.2. Superfluous information should be avoided
11.14.2.4.3. Templates as an aid to limit language
11.14.2.4.4. Models and diagrams makes the document clear and more understandable
11.14.2.4.5. Use formal graphical notation to express complex requirements, dependencies and relationships
11.14.2.5. Quality attributes
11.14.2.5.1. Complete
11.14.2.5.2. Consistent
11.14.2.5.3. Modifiable
11.14.2.5.4. Traceable
11.14.3. Forms:
11.14.3.1. Graphical models
11.14.3.2. Mathematic representation
11.14.3.3. Mixed techniques
11.14.3.4. Written text
11.14.4. Content::
11.14.4.1. Introduction
11.14.4.2. Secrecy clause
11.14.4.3. Regulations
11.14.4.4. Standards
11.14.4.5. Stakeholders
11.14.4.6. Purpose of the product
11.14.4.7. Overall descriptio
11.14.4.8. Functional requirements (FR)
11.14.4.9. Non-functional requirements (NFR)
11.14.4.10. Assumptions
11.14.4.11. Dependencies
11.14.4.12. Risks
11.14.4.13. Safety requirements Document acceptance
11.14.5. Formats:
11.14.5.1. Vision
11.14.5.1.1. What is it?
11.14.5.1.2. An output of Enterprise Analysis.
11.14.5.1.3. Usually used in iterative development
11.14.5.2. Business Process Description (BPD)
11.14.5.2.1. An executive summary of an initiative.
11.14.5.2.2. Describes the problem and the proposed solution in high-level terms.
11.14.5.3. Business Requirements Document (BRD)
11.14.5.3.1. Describes the behavior required of a software application.
11.14.5.3.2. Primarily describes the business requirements.
11.14.5.3.3. The target audience is the customer and users
11.14.5.4. Request for Proposal / Request for Quotation (RFP/RFO.)
11.14.5.4.1. Distributed to parties outside the organization.
11.14.5.4.2. Basis for the contracting of solution development
11.14.5.5. Software Requirements Specification (SRS)
11.14.5.5.1. Also known as a System Requirements Specification.
11.14.5.5.2. Describes the behavior and implementation of a software application.
11.14.5.5.3. The target audience is the development team.
11.14.5.5.4. A description of the problem domain
11.14.5.5.5. Decomposition of the problem domain
11.14.5.5.6. Description of the functional requirements
11.14.5.5.7. Description of the non-functional requirements
11.14.5.5.8. Assumptions and constraints affecting the solution
11.14.5.5.9. Requirements attributes and traceability information
11.14.6. Common mistakes
11.14.6.1. Trivialities
11.14.6.1.1. Lengthy descriptions of commonly known issues
11.14.6.2. Information out of scope
11.14.6.2.1. Information without added value to the description of the solution
11.14.6.3. Thinking in solutions
11.14.6.3.1. Description of solutions
11.14.6.3.2. Requirement specification determining the technical design
11.14.6.4. Redundant details
11.14.6.4.1. Details unnecessarily complicating the implementation
11.14.6.4.2. Implementation details
11.14.6.5. Lacking rationale
11.14.6.5.1. No description of what shall be achieved with the solution (inc. concrete numbers and metrics)
11.15. Construction of a requirement (process)
11.15.1. 1. Describe business justification for the requirement
11.15.2. 2. Identify the business process
11.15.3. 3. Identify the stakeholders
11.15.4. 4. Identify the limitations and assumptions
11.15.5. 5. Describe the context
11.15.6. 6. Describe the requirement
11.15.6.1. Input
11.15.6.2. Output
11.15.6.3. Resources
11.15.6.4. Quality characteristics (if applicable)
11.15.7. 7. Provide the graphical model (if applicable)
11.15.8. 8. Describe risks
11.15.9. 9. Provide references
11.16. Requirements Communication
11.16.1. An ongoing and iterative activity
11.16.2. Process
11.16.2.1. 1. Preparing requirements communication plan
11.16.2.2. 2. Managing requirements conflicts
11.16.2.3. 3. Establishing the most appropriate requirements format
11.16.2.4. 4. Performing formal requirements review
11.16.2.5. 5. Conducting requirements presentation
11.16.2.6. 6. Creating requirements package
11.16.2.7. 7. Obtaining requirements approval (Sign-off)
11.17. Requirement Acceptance
11.17.1. Requirements should be agreed and accepted by all relevant stakeholders.
11.17.2. All requirements must be formally approved.
11.17.3. Formal agreement:
11.17.3.1. Starting point for detailed system specification, designing the architecture and other works on the planned system.
11.17.4. Stakeholders with the acceptance authority
11.17.4.1. Architects
11.17.4.2. Business Analysts
11.17.4.3. Business Sponsor
11.17.4.4. Project Managers
11.17.4.5. Test/QA Manager
11.17.5. Requirement acceptance consequences
11.17.5.1. The list of requirements is binding for both the vendor and the customer.
11.17.5.2. Any changes must be managed via Change Management.
11.18. Requirements Organization
11.18.1. Purpose
11.18.1.1. To determine the solution boundary
11.18.1.2. To determine the solution scope
11.18.1.3. To define the structure of requirements
11.18.2. Requirements are organized (structured) into packages
11.18.2.1. The problem model is decomposed to make each requirement more detailed and to ensure that the model correctly reflects the boundary for the business problem.
11.19. Requirements Decomposition
11.19.1. 3 types
11.19.1.1. Functional decomposition
11.19.1.1.1. Functional decomposition is a breakdown of a list of items into classifications or groups on the basis of the function each item performs or is used for.
11.19.1.1.2. Identifies the high-level functions
11.19.1.1.3. Breaks them down into sub-processes and activities
11.19.1.1.4. Used to:
11.19.1.1.5. Levels of detail:
11.19.1.2. Feature list decomposition
11.19.1.2.1. Feature is developed into completely described functional and supplemental requirements.
11.19.1.2.2. Feature is a service that the solution provides to fulfill one or more stakeholder needs. Feature is an abstraction of the solution of the problem expressed on high-level.
11.19.1.3. Goal decomposition
11.19.1.3.1. Allows ensuring the solution will satisfy stakeholder's needs
11.19.1.3.2. Breaks down high-level stakeholdergoals into lower-level goals
11.19.1.3.3. Lower-level goals have measurable objectives.
12. Glossary
12.1. Artefact
12.1.1. Describes the function, architecture, and design of software
12.1.2. Describes the process of development itself
12.1.3. All artefacts should be under version control.
12.1.4. Artefacts are either final or intermediate work products produced and used during a project.
12.1.5. e.g.
12.1.5.1. Business Case
12.1.5.2. Class diagrams
12.1.5.3. Design document
12.1.5.4. Project's plan
12.1.5.5. Requirements document
12.1.5.6. Risk assessment
12.1.5.7. Use cases
12.2. Business Analyst
12.2.1. "A Business Analyst is a person responsible for identifying the business needs of the customer / stakeholders and to determine solutions to business problems."
12.2.1.1. source BABOK
12.3. Business Case
12.3.1. Business Case describes a justification for the project in terms of the value added to the business as a result of the project outcomes in comparison to the cost of developing the new solution.
12.3.1.1. source BABOK
12.3.2. The Business Case describes the justification for the project.
12.3.3. A Business Case captures the reasoning for initiating a project or task.
12.3.4. Determines the value to be added to the business as a result of the project outcomes vs. the cost to develop the solution.
12.4. Business Goal
12.4.1. Business Goal is an objective of an organization.
12.4.1.1. Short- or long-term.
12.4.1.2. Formulated by the requesting organization.
12.5. Business Need
12.5.1. A Business Need defines the business problem or opportunity.
12.5.2. Formulated by the requesting organization, with optional support of the Business Analyst on the vendor side.
12.5.3. Understanding needs is required to be able to recommend appropriate solutions.
12.6. Business Requirements Elicitation
12.6.1. Business Requirements Elicitation is a set of approaches, activities, tasks and techniques allowing to collect the business requirements of a planned solution, from the stakeholders and other available sources.
12.7. Business process
12.7.1. A set of activities designed to produce a specific output for a particular customer or market.
12.7.2. Focused on the way of organizing work, activities, relationships and dependencies between them.
12.8. Decision Package
12.8.1. Decision Package is a collection of the documents summarizing information about the proposed project
12.8.2. Includes or references all information gathered about the project so far.
12.8.3. May identify and justify the next steps in the overall process to continue.
12.9. Enterprise Analysis
12.9.1. A set of pre-project activities capturing the future view of the business in order to provide context to requirements identification and solution design fora given initiative/long-term strategic planning.
12.9.1.1. source BABOK
12.10. Feasibility Study
12.10.1. Analysis and evaluation of a proposed project to determine if it:
12.10.1.1. Is technically feasible
12.10.1.2. Is feasible within the estimated cost
12.10.1.3. Will be profitable
12.10.2. Feasibility studies are almost always conducted when the initiative involves large sums.
12.10.3. Also called Feasibility Analysis.
12.11. Requirement
12.11.1. [IEEE Std 610.12-1990]
12.11.1.1. 1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
12.11.1.2. 2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents.
12.11.1.3. 3. A documented representation of a condition or capability as in 1 or 2.
12.12. Requirements Communication
12.12.1. The Requirements Communication consists of a set of activities for expressing the output of the Requirements Analysis and Documentation to a broad audience.
12.12.1.1. source BABOK
12.13. Requirements Communication
12.13.1. Requirements Communication includes activities for expressing the output of the requirements analysis and documentation to the stakeholders.
12.14. Requirements Document
12.14.1. A requirements document describes a set of related functional and non-functional requirements.
12.15. Requirements Elicitation
12.15.1. Requirements Elicitation is the set of approaches, activities, tools and techniques for capturing the requirements of a planned solution from the stakeholders.
12.15.1.1. source BABOK
12.16. Requirements signoff
12.16.1. Requirements signoff is a formal agreement by project stakeholders that the content and presentation of the requirements meet their expectations.
12.16.2. * May involve final review of requirements.
12.16.3. * The approval may be recorded either physically or electronically.
12.17. Risk Assessment
12.17.1. The purpose is to determine if the proposed project carries more risk than the organization is willing to bear.
12.18. Traceability
12.18.1. Traceability is an association existing between requirements when more detailed requirements are associated with the higher level requirements (needs and features. Traceability is an association between:
12.18.1.1. Requirements
12.18.1.2. Detailed requirements and design models
12.18.1.3. Detailed requirements and test cases
12.18.1.4. High level requirements and test cases
12.18.1.5. Requirements and design artefacts
12.19. lnterview
12.19.1. An interview is a systematic approach to elicit information from a person or group of people in an informal or formal setting by asking relevant questions and documenting the responses.
12.20. Feature
12.20.1. Feature is a service that the solution provides to fulfill one or more stakeholder needs. Feature is an abstraction of the solution of the problem expressed on high-level.
12.20.1.1. source BABOK
13. Knowledge Areas in Business Analysis
13.1. Enterprise Analysis
13.2. Requirements Planningand Management
13.3. Requirements Elicitation (Identification)
13.4. Requirements Communication
13.5. Requirements Analysis and Documentation
13.6. Solution Assessment and Validation
14. Reasons why projects fail
14.1. UK Cabinet Office - 8 Common Causes of Project Failure
14.1.1. Lack of clear link to the organisation’s key strategic priorities
14.1.2. Lack of clear senior management ownership and leadership
14.1.3. Lack of effective engagement with stakeholders
14.1.4. Lack of skills and proven approach to project and risk management
14.1.5. Project not broken down into manageable steps
14.1.6. Evaluation of proposals linked to short term affordability rather than longer term value for money
14.1.7. Lack of understanding of and contact with suppliers
14.1.8. Lack of effective integration between the client, supplier and supply chain
14.2. Based on Standish Report.
14.2.1. 10. Standard Tools and Infrastructure
14.2.2. 9. Formal Methodology
14.2.3. 8. Skilled Resources
14.2.4. 7. Financial Management
14.2.5. 6. Project Manager Expertise
14.2.6. 5. Agile Process
14.2.7. 4. Optimizing Scope
14.2.8. 3; Cieor Business Objectives
14.2.9. 2. Executive Management Support
14.2.10. 1. User Involvement
15. Stakeholders
15.1. Classification
15.1.1. Stakeholders on the vendor's side (selected)
15.1.1.1. Project Managers
15.1.1.2. Business and System Analysts
15.1.1.3. Developers and Architects
15.1.1.4. Database designers
15.1.1.5. GUI designers
15.1.1.6. Technical writers
15.1.1.7. Testers and Quality Assurance stuff
15.1.1.8. Installation and Operations personnel
15.1.2. Stakeholders on the customer's side (selected)
15.1.2.1. Customer representative (so called "Business")
15.1.2.2. Project sponsor
15.1.2.3. End users (if are derived from the customer company)
15.1.2.4. The person who installs and maintains the system
15.1.2.5. Quaiity Assurance / Testers
15.1.2.6. Installation and Operations personnel
15.1.3. External stakeholders
15.1.3.1. End users (clients of the customer)
15.1.3.2. Other organizations (regulation entities)
15.2. Stakeholder identification
15.2.1. Techniques
15.2.1.1. Analyzing relationships with external organizations (suppliers etc.)
15.2.1.1.1. Suppliers, subcontractors, partners - they can be affected by the solution as well.
15.2.1.1.2. Their processes may also influence our solution.
15.2.1.2. Identifying owners of business processes
15.2.1.3. Analyzing organizational structure of the customer's organization
15.2.1.4. Exploring the target market of the customer's organization
15.2.1.5. Analyzing relationships with external organizations
15.2.1.6. Investigating the business domain
15.2.1.6.1. internal/external customers and subcontractors allows to find stakeholders.
15.2.1.7. Identifying owners of business processes
15.2.1.7.1. After identification of processes, the processes' owners have to be determined.
15.2.1.7.2. Owners of the processes affected by the solution will be stakeholders of the initiative.
15.2.1.8. Analyzing organizational structure of the customer's organization
15.2.1.8.1. Allows to identify stakeholders and their hierachy, relationships (what can be later used in determing the requirements' priorities and permission scheme for the planned solution).
15.2.1.9. Exploring the target market of the customer's organization
15.2.1.9.1. End customers, end users, institutions and other organizations affected by or affecting the solution.
15.2.1.10. Investigating the business domain
15.3. Stakeholder identification problems
15.3.1. No knowledge about the real operators of business processes in the organization
15.3.2. Not clear responsibilities in the customer's organization
15.3.3. Missing stakeholders - not clearly and directly related with the process (the end customers)
15.3.4. Gaps in the analysis resulted in missing processes and activities
15.4. Different stakeholders may have different needs and expectations regarding the planned solution.
15.4.1. Identify all stakeholders and their needs.
15.4.2. Find a common understanding of the purpose of a system.
15.5. Stakeholders value
15.5.1. Determining stakeholders value is one of the key factors of the project's success.
15.5.2. The main goal of a project is achieving "realized value" (also known as "benefits"), for the stakeholders.
15.5.3. A value can be defined as '"the benefit we think we get from something" -T. Gilb.
15.5.4. Value is the potential consequence of system attributes, for one or more stakeholders.
15.5.5. Value is not linearly related to a system improvement:
15.5.5.1. A small change in an attribute level could add immense perceived value for one group of stakeholders for relatively low cost.
15.5.6. Value is the perceived usefulness, worth, utility or importance of a defined system component or system state, for defined stakeholders, under specified conditions.
15.5.7. "Benefit" is when some perceived value is actually produced by a defined system.
15.5.8. Value is not absolute: it is relative to a stakeholder.
16. Enterprise Analysis
16.1. Activities of the Enterprise Analysis
16.1.1. Determining business opportunities
16.1.2. Developing strategic goals to be achieved by the organization
16.1.3. Developing a strategic plan allowing to plan and execute the goals
16.1.4. Understanding and developing the business architecture
16.1.5. Determining the optimum project investment path for the organization, including:
16.1.5.1. Implementation of new business and technical system solutions
16.1.5.2. Implementation of process or organizational changes
16.1.6. Selecting the right solution approaches for projects and developing their business cases
16.1.7. Initiating projects
16.2. Enterprise Analysis is conducted:
16.2.1. As a stand-alone project
16.2.1.1. in large and complex organizations
16.2.2. By customer organization - before involving the vendor
16.2.2.1. the results are provided as part of initial requirements (in small organizations)
16.2.3. Not conducted at all
16.2.3.1. if the goal of the project is clear and measurable
16.3. Enterprise Analysis activities:
16.3.1. Identification of business processes
16.3.2. Creating the Business Architecture
16.3.3. Conducting Feasibility Studies
16.3.4. Conducting the initial Risk Assessment
16.3.5. Preparing the Business Case
16.3.6. Scoping and defining the new business opportunity
16.3.7. Preparing the Decision Package
16.4. Business Architecture
16.4.1. Defines an organization's current and future capabilities.
16.4.1.1. High level business environment
16.4.1.2. Long term goals and objectives
16.4.1.3. Stakeholders
16.4.1.4. The businesses strategy
16.4.1.5. The external environment
16.4.1.6. The technological environment
16.5. Risk Assessment
16.5.1. 1. Identifying project risks
16.5.1.1. 1. Identifying and analyzing business risks
16.5.1.2. 2. Identifying and analyzing financial risks
16.5.1.3. 3. Identifying and analyzing technical risks
16.5.2. 2. Assessing risk probability and impact
16.5.3. 3. Planning risk responses
16.5.4. 4. Assessing organizational readiness / calcuiating an overall risk rating
16.6. Business process
16.6.1. Characteristics of a Business Process
16.6.1.1. Has a goal
16.6.1.2. Has specific inputs
16.6.1.3. Has specific outputs
16.6.1.4. Uses resources
16.6.1.5. Has a number of activities performed in some order
16.6.1.6. May affect more than one organizational unit
16.6.1.7. Creates value for the customer
16.6.2. Purpose of Business Process's identification
16.6.2.1. Understanding the goals of the organization.
16.6.2.2. Determining activities and the flow required to achieve the planned business and strategic goals.
16.6.2.3. Finding gaps and non-effective parts of the process to optimize the process.
16.7. Business Goal
16.7.1. Qualities of Business Goals
16.7.1.1. Specificity
16.7.1.2. Optimism
16.7.1.3. Realism
16.7.1.4. Short and long term
16.7.2. Importance of setting Business Goals
16.7.2.1. Provides a vision of what the organization wants to accomplish.
16.7.2.2. Provides a clear picture of what the organization is trying to do with the business.
16.7.2.3. Allows to understand and maintain a commitment to the business main objectives.
16.7.2.4. It gives a metric to measure organization's progress.
16.7.3. SMART
16.7.3.1. A system and a tool for effective goal setting and goal quality.
16.7.3.2. All goals should be SMART.
16.7.3.2.1. S - Specific
16.7.3.2.2. M - Measurable
16.7.3.2.3. A - Attainable
16.7.3.2.4. R - Relevant
16.7.3.2.5. T - Timely
16.7.3.3. SMART - example of business goal
16.7.3.3.1. Obtain 3 new billion dollar corporate clients in the New York property insurance market by the end of this fiscal year through networking.
16.8. Business Need
16.8.1. Who defines the Business Need?
16.8.2. The person or group requesting the project, including:
16.8.2.1. High-level Subject Matter Expert (SME) [Pyzdek, Thomas and Paul A. Keller]
16.8.2.2. Regulatory / compliance body
16.8.2.3. Sponsor
16.8.2.4. Steering committee
16.8.2.5. Subject Matter Expert (SME)
16.8.3. e.g.
16.8.3.1. Branch managers need an access to transaction's reports and statistics.
16.8.3.2. Insurance agents need a mobile application to analyze and document claims.
16.8.3.3. Controlling department needs an access to structured information from all systems operating in the organization.
16.9. Business Case
16.9.1. A Business Case may cover the following topics:
16.9.1.1. Information about the opportunity in terms of the market trends, competitive environment and expected market penetration
16.9.1.2. Qualitative and quantitative benefits
16.9.1.3. Estimates of costand time to breakeven
16.9.1.4. Profit expectations
16.9.1.5. Follow-on opportunities
16.9.1.6. Cash flow consequences of the action, over time, and the methods used for quantifying benefits and costs
16.9.1.7. The impact of the project on the business operations
16.9.1.8. The impact of the project on the technology infrastructure
16.9.1.9. Constraints associated with the proposed project
16.9.1.10. Estimated budget
16.9.1.11. Alignment with priorities established by the business
16.9.2. Main idea of a Business Case
16.9.2.1. A Business Case demonstrates that:
16.9.2.1.1. The solution proposal has been analyzed properly
16.9.2.1.2. The full benefits will be realized in time
16.9.2.1.3. Any technical aspects have been thoroughly evaluated
16.9.3. Purpose of a Business Case
16.9.3.1. Buildingthe Business Case allows the organization to
16.9.3.1.1. Understand and apply a way of thinking where people with the authority to recommend projects will firstly analyze their value, risk and priority as a base of submitting the project proposal
16.9.3.1.2. Justify the value of proposals to the organization
16.9.3.1.3. Reject any proposals that are not of proven and measurable value
16.9.3.1.4. Decide if the proposal is of value to the business and is achievable in comparison to alternative proposal submitted
16.9.3.1.5. Track and measure the progress and achievements of the business case
16.9.3.1.6. Ensure that projects with inter-dependencies are undertaken in the optimum sequence
16.9.4. Content of a Business Case
16.9.4.1. Reference
16.9.4.1.1. Project name/reference
16.9.4.1.2. Origins/background/curr ent state
16.9.4.2. Context
16.9.4.2.1. Business objectives/opportunities
16.9.4.2.2. Business strategic alignment (priority)
16.9.4.3. Value Proposition
16.9.4.3.1. Desired business outcomes
16.9.4.3.2. Business benefits
16.9.4.3.3. Quantified benefits value
16.9.4.3.4. Costs
16.9.4.3.5. ROI Financial scenarios
16.9.4.3.6. Risks / costs of not proceeding
16.9.4.3.7. Project risks (to project, benefits and business)
16.9.4.4. Focus
16.9.4.4.1. Problem/solution scope
16.9.4.4.2. Assumptions
16.9.4.4.3. Constraints
16.9.4.4.4. Options identified / evaluated
16.9.4.4.5. Size assessment
16.9.4.4.6. Scale assessment
16.9.4.4.7. Complexity assessment
16.9.4.5. Deliverables
16.9.4.5.1. Outcomes, deliverables and benefits planned
16.9.4.5.2. Organizational areas impacted (internally and externally)
16.9.4.5.3. Key stakeholders
16.9.4.5.4. Dependencies
16.9.4.6. Workload
16.9.4.6.1. Approach
16.9.4.6.2. Phase/stage definitions
16.9.4.6.3. Project activities
16.9.4.6.4. Technical delivery activities
16.9.4.6.5. Workload estimate/breakdown
16.9.4.6.6. Project plan
16.9.4.6.7. Project schedule
16.9.4.7. Required resources
16.9.4.7.1. Project leadership team
16.9.4.7.2. Project governance team
16.9.4.7.3. Team resources
16.9.4.7.4. Funding
16.9.4.8. Commitments
16.9.4.8.1. Project control
16.9.4.8.2. Reporting processes
16.9.4.8.3. Deliverables schedule
16.9.4.8.4. Financial budget/schedule
16.9.5. Quality attributes of a Business Case
16.9.5.1. Accountable
16.9.5.1.1. commitments for the delivery of benefits and management of costs are clear
16.9.5.2. Adaptable
16.9.5.2.1. adjusted to the size and risk of the proposal
16.9.5.3. Business oriented
16.9.5.3.1. concerned with the business capabilities / impact
16.9.5.4. Consistent
16.9.5.4.1. every project addresses the same basic business issues
16.9.5.5. Transparent
16.9.5.5.1. key elements can be justified
16.9.5.6. Understandable
16.9.5.6.1. the content is clear, relevant and logical
16.9.6. Procedure of building a Business Case
16.9.6.1. 1. Identify and quantify the benefits
16.9.6.1.1. Measure the benefits of the recommended solution {qualitative and quantitative gains to the enterprise).
16.9.6.1.2. Benefits should be quantified.
16.9.6.1.3. Benefits of a non-financial nature should be listed.
16.9.6.1.4. Estimates should be linked back to strategic goals.
16.9.6.2. 2. Identify and quantify the costs
16.9.6.2.1. Estimate the total net cost of the solution.
16.9.6.2.2. Estimate:
16.9.6.3. 3. Prepare the Business Case
16.9.6.3.1. Develop the Business Case at the appropriate level of detail.
16.9.6.3.2. Remember it should demonstrate project viability and secure a go/no go decision.
16.9.6.4. 4. Determine the measurement process for the costs and benefits
16.9.6.4.1. Describe how the benefits will be assessed and evaluated.
16.9.6.4.2. Build a plan for benefit measurement and reporting.
16.9.7. Sample structure of a Business Case
16.9.7.1. 1. Executive summary
16.9.7.2. 2. Introduction and summary
16.9.7.2.1. Project rationale for preferred option
16.9.7.2.2. Current business process
16.9.7.2.3. Description of the problem
16.9.7.2.4. Opportunity
16.9.7.2.5. Project objectives
16.9.7.2.6. Project scope
16.9.7.2.7. Business benefits
16.9.7.2.8. Project costs
16.9.7.2.9. Assumptions
16.9.7.2.10. Potential business and staff impact analysis
16.9.7.2.11. Potential technology impact analysis
16.9.7.2.12. Implementation plan
16.9.7.3. 3. Approach
16.9.7.3.1. Financial metrics
16.9.7.3.2. Privacy impact assessment
16.9.7.3.3. Alternative evaluation criterion
16.9.7.4. 4. Key selection criterion
16.9.7.4.1. Weighting
16.9.7.4.2. Constraints and limitations
16.9.7.5. 5. Preferred alternative
16.9.7.5.1. Business benefits
16.9.7.5.2. Alternative costs
16.9.7.5.3. Assumptions
16.9.7.5.4. Potential business and staff impact analysis
16.9.7.5.5. Other issues
16.9.7.6. 6. Risk Management Plan
16.9.7.6.1. Risk assessment
16.9.7.6.2. Risk response
16.9.7.6.3. Benefit realization
16.9.7.7. 7. Conclusion and recommendations
17. Solution scope
17.1. Determining solution scope
17.1.1. A base for establishing the scope of the project (project planning).
17.1.2. A base for detailed requirements development.
17.1.3. Based on the product/solution scope; the project manager determines the cost and duration of the project.
17.2. Techniques to determine solution scope
17.2.1. Work Breakdown Structure (WBS)
17.2.1.1. A decomposition of work required to complete a project.
17.2.2. Product Breakdown Structure (PBS)
17.2.2.1. A decomposition of the components of the product.
17.2.3. System Interface Analysis
17.2.3.1. Work required to integrate the new solution into the business and technical environments.
17.3. UML Use Cases
17.3.1. Use Case Diagrams allows to present the boundary of the solution.
17.3.2. Shows the connections with external systems and actors.
18. Map is under development, current state is an early ALPHA.
19. Requierements related standards
19.1. ISO 25000 (ISO / IEC 9126)
19.1.1. Defines a quality model with 6 categories
19.1.1.1. Efficiency
19.1.1.2. Functionality
19.1.1.3. Maintainability
19.1.1.4. Portability
19.1.1.5. Reliability
19.1.1.6. Usability
19.2. IEEE 830
19.2.1. Recommended Practice for Software Requirements Specifications
19.3. IEEE 1233
19.3.1. Guide for Developing of System Requirements Specifications
19.4. IEEE 1362
19.4.1. Guide for Information Technology - System Definition
20. Interactive Glossary
20.1. Interactive IQBBA® Glossary
21. This freeware, non-commercial mind map was carefully hand crafted with passion and love for learning and constant improvement as well for promotion the IQBBA® CFLBA certification and as a learning tool for candidates wanting to gain IQBBA® CFLBA qualification. (please share, like and give feedback - your feedback and comments are my main motivation for further elaboration. THX!)
21.1. Questions / issues / errors? What do you think about my work? Your comments are highly appreciated. Please don't hesitate to contact me for :-) Mirosław Dąbrowski, Poland/Warsaw.
21.1.1. http://www.linkedin.com/in/miroslawdabrowski
21.1.2. https://www.google.com/+MiroslawDabrowski
21.1.3. https://play.spotify.com/user/miroslawdabrowski/
21.1.4. http://www.miroslawdabrowski.com
21.1.5. https://twitter.com/mirodabrowski
21.1.6. miroslaw_dabrowski
22. Business Analysis Process Planning
22.1. Impact of a Business Analysis
22.1.1. Business Analysis provides input information to the following processes:
22.1.1.1. Project management (scope planning, scheduling and estimating development and testing)
22.1.1.2. System analysis
22.1.1.3. Design (system specification and architecture)
22.1.1.4. Implementation -Testing
22.1.2. Roles affected by a Business Analysis:
22.1.2.1. Project manager
22.1.2.2. Developers
22.1.2.3. System analysts
22.1.2.4. QA and Testers
22.1.2.5. Architects
22.1.3. Requirements Communication
22.1.3.1. Ongoing, iterative activity.
22.1.3.2. Done in parallel with Requirements Elicitation, Analysis and Documentation.
22.1.3.3. Includes:
22.1.3.3.1. Presenting
22.1.3.3.2. Communicating
22.1.3.3.3. Verifying
22.1.3.3.4. Gaining approval of the requirements
22.1.3.4. The main purpose of planning the Business Analysis communication is to define:
22.1.3.4.1. How to receive, distribute, access, update and escalate information to and from project stakeholders.
22.1.3.4.2. How to organize schedule and structure of communication within a project.
22.1.4. Communication Planning
22.1.4.1. Business Analysis activities/deliveries can be communicated in formal and informal way.
22.1.4.2. Communication activity should consider what kind of issues to be communicated:
22.1.4.2.1. Changes
22.1.4.2.2. Consequences
22.1.4.2.3. Information
22.1.4.2.4. Needs
22.1.4.2.5. Risks
22.1.4.3. Common ways of communication:
22.1.4.3.1. Documentation
22.1.4.3.2. Formal review
22.1.4.3.3. Informal review
22.1.4.3.4. Presentation
22.1.4.3.5. Workshop
22.1.5. Elements of Requirements Communication
22.1.5.1. Requirements communication plan
22.1.5.2. Managing requirements conflicts
22.1.5.3. Selecting the appropriate requirements format
22.1.5.4. Creating a requirements package
22.1.5.5. Requirements presentation
22.1.5.6. Formal requirements review
22.1.6. Requirements communication plan
22.1.6.1. How and when the BA will work with project stakeholders.
22.1.6.2. On small projects it may be very brief and may not be formally documented.
22.1.6.3. On large and complex projects it may be included as part of the project initiation documentation.
22.2. Requirements Engineering process planning
22.2.1. Goal
22.2.1.1. The goal is to define appropriate Requirements Engineering strategy, planning and estimation.
22.2.2. Determines the main activities and roles.
22.2.3. Includes definingthe process of managing Change Requests.
22.2.4. Factors to be considered in planning
22.2.4.1. Type of project:
22.2.4.1.1. Different projects types require a different amount of documentation, different processes and result in different deliverables.
22.2.4.2. Communication formality:
22.2.4.2.1. Communication formality varies between projects, projects' phases and stakeholders.
22.2.4.2.2. More formal when:
22.2.4.3. Communication frequency:
22.2.4.3.1. Communication frequency will differ among stakeholder for every form of communication.
22.2.4.3.2. Communicating Business Analysis's deliveries usually follows a schedule:
22.2.4.4. Geographical location:
22.2.4.4.1. Geographic disparity as a factor limiting communication possibilities.
22.2.4.4.2. When stakeholders live in different time zones communication (calls, team meetings) must be adjusted to the capabilities.
22.2.4.5. Culture:
22.2.4.5.1. Especially important in case of international projects.
22.2.4.5.2. Culture may determine the preferred form of communication (e-mails instead of calls, face-to-face meetings instead of e-conferences).
22.2.5. Inputs for the Requirements Engineering
22.2.5.1. Business Analysis approach
22.2.5.1.1. Overall approach used by an organization to derive the Business Analysis processes.
22.2.5.2. Business Analysis plan
22.2.5.2.1. Defines what deliverables (like requirements specification) will be produced and when.
22.2.5.3. Organizational process assets
22.2.5.3.1. A set of standard templates of processes existing in an organization.
22.2.6. Process
22.2.6.1. Non-core process concerning all disciplines of the systems development:
22.2.6.1.1. Identification of requirements (Elicitation)
22.2.6.1.2. Analysis of requirements
22.2.6.1.3. Specification of requirements
22.2.6.1.4. Changes of requirements
22.2.6.1.5. Quality assurance (with Verification and Validation)
22.2.7. Factors affecting communication
22.2.7.1. Availability of resources
22.2.7.2. Complexity
22.2.7.3. Organizational maturity
22.2.7.4. Organizational culture
22.2.7.5. Organizational standards
22.2.7.6. Stakeholders preference
22.2.8. Repository
22.2.8.1. The purpose of repository is to store requirements with theirs statuses.
22.2.8.2. Repository allows to group requirements (i.e. by status):
22.2.8.2.1. Underdevelopment
22.2.8.2.2. Under review
22.2.8.2.3. Approved
22.2.8.2.4. Changed
22.2.9. Traceability
22.2.9.1. The process of tracing requirements is defined by the Business Analyst.
22.2.9.2. The process has to be tailored to complexity of the project domain, stakeholder's needs, potential risks and available resources.
22.2.10. Selection of requirements attributes
22.2.10.1. Custom requirements attributes allow to include more detailed information in the description of requirements and to analyze them.
22.2.10.2. The attributes need to be planned and determined in the Requirements Elicitation phase.
22.2.11. Requirements prioritization
22.2.11.1. Requirements are not equal for stakeholders and don't have the same value for project success.
22.2.11.2. Priority as a factor of importance and impact should be determined by the Business Analysts along with proper stakeholders.
22.2.12. Configuration and Change Management
22.2.12.1. Configuration Management allows to identify and manage so called Configuration Items. A Configuration Items may be:
22.2.12.1.1. Single requirement
22.2.12.1.2. Requirements specification
22.2.12.2. Change Management is a process designed to track, identify and manage changes.
22.3. Configuration and Change Management process
22.3.1. The purpose of Configuration Management is to establish and maintain the integrity of the products (components, data and documentation) of the software artefacts within the project and product life cycle
22.3.2. Configuration Management is a discipline applying technical and administrative tools and techniques to [IEEE 610]
22.3.2.1. Identify and document the functional and physical characteristics of a configuration item
22.3.2.2. Control changes requested to those characteristics
22.3.2.3. Record and report change processing and implementation status
22.3.2.4. Verify compliance with specified requirements
22.3.3. It allows managing changes in the requirements in an effective way
22.3.4. Change Management is a subdiscipline of the Configuration Management
22.3.5. Configuration Item
22.3.5.1. An artifact, document, product (hardware and / or software) that has an end-user purpose and designated for Configuration Management and treated as a single entity in the Configuration Management Process ' [IEEE 610]
22.3.5.2. e.g.
22.3.5.2.1. Single requirements
22.3.5.2.2. Business needs
22.3.5.2.3. Requirements specifications
22.3.5.2.4. Business cases
22.3.5.2.5. Models
22.3.5.2.6. …
22.3.6. Baseline
22.3.6.1. A baseline is a stable well- defined set of attributes that serve as a comparison for system change
22.3.6.2. A system baseline is any set of system attribute specifications that formally define the state of a system, under specified conditions
22.3.7. The process of Configuration Management includes the following activities:
22.3.7.1. 1. Configuration Identification
22.3.7.1.1. The purpose of Configuration Identification is to determine the attributes that define every aspect of a configuration item
22.3.7.1.2. The attributes are recorded in configuration documentation and baselined
22.3.7.2. 2. Configuration Change Control
22.3.7.2.1. Configuration Change Control is a set of processes and approval stages required to:
22.3.7.3. 3. Configuration Status Accounting
22.3.7.3.1. Configuration Status Accounting is the ability to record and report on the configuration baselines associated with each configuration item at any moment of time
22.3.7.4. 4. Configuration Audits
22.3.7.4.1. Two types of Configuration Audits
22.3.8. Change Management Process:
22.3.8.1. 1. Identification of potential change
22.3.8.2. 2. Requesting new functionality
22.3.8.3. 3. Analysis of the change request
22.3.8.4. 4. Evaluating the change
22.3.8.5. 5. Planning the change
22.3.8.6. 6. Implementing the change
22.3.8.7. 7. Reviewing and closure of the change
22.3.8.8. 8. Roll out of the change
22.3.9. Change Request
22.3.9.1. An official document requesting modification of existing features, requirements or functions or new ones
22.3.9.2. Description of the current solution
22.3.9.3. Justification for a change
22.3.9.4. Suggested (desired) solution
22.3.9.5. Priority
22.3.10. Example of a Change Management
22.3.10.1. Defect report
22.3.10.2. Analysis of the report
22.3.10.3. Comparing with the specification
22.3.10.4. Discovering the mistake in the specification
22.3.10.5. Closing the defect report
22.3.10.6. Submitting a change request
22.3.10.7. Analysis of the change request
22.3.10.8. Approval of the change request
22.3.10.9. Implementation of the change request
22.3.10.10. Testing the implemented change
22.3.10.11. Change closure
22.3.11. Sources of a change
22.3.11.1. Defects found in the code, documentation, requirements
22.3.11.2. Business process improvement
22.3.11.3. System improvement efforts
22.3.11.4. New or changing requirements
22.3.11.5. External changes (regulation, law changes)
22.3.12. Planning of change implementation
22.3.12.1. Updating plans: Project Plan, Development Plan, Test Plan
22.3.12.2. Updating business and system documentation
22.3.12.3. Updating test cases and test scripts
22.3.12.4. Implementing the change (coding)
22.3.12.5. Testing by vendor or / and customer test team
22.3.12.6. Deploying the change to production environment (if applicable)
22.3.13. Change Life Cycle
22.3.13.1. Possible statuses
22.3.13.1.1. Submitted
22.3.13.1.2. Open
22.3.13.1.3. Approved
22.3.13.1.4. Rejected
22.3.13.1.5. Deferred
22.3.13.1.6. In implementation
22.3.13.1.7. Implemented
22.3.13.1.8. In testing
22.3.13.1.9. Tested
22.3.13.1.10. Closed
22.3.14. Change Control Board (CCB)
22.3.14.1. A group of people responsible for evaluating and approving or disapproving proposed changes to configuration items, and for ensuring implementation of approved changes [IEEE 610]
22.3.14.2. Project manager
22.3.14.3. Business analysts
22.3.14.4. Development team
22.3.14.5. Quality assurance team
22.3.14.6. Business manager
22.3.14.7. Customer
22.4. Tools and techniques selection
22.4.1. Categories of tools
22.4.1.1. Text processing
22.4.1.2. Table calculations
22.4.1.3. Modeling tools
22.4.1.4. Tools for Requirements Management
22.4.1.5. Process simulation tools
22.4.1.6. Configuration Management tools
22.4.1.7. Change Management tools
22.4.2. Factors affecting tools selection
22.4.2.1. The goal of the initiative
22.4.2.1.1. Different tools for extending existing solution, different for process optimization
22.4.2.2. The type of planned solution
22.4.2.2.1. Enterprise software vs. Entertainment software
22.4.2.2.2. Designing software vs. Improving business process
22.4.2.3. Organization's IT infrastructure
22.4.2.4. The scope of the solution
22.4.2.5. The complexity of the solution
22.4.2.6. Number of requirements
22.4.2.7. Dependencies between requirements
22.4.2.8. Traceability requirements
22.4.2.9. Standards and norms to be applied
22.4.2.10. Experience and skills of the project team
22.4.3. Common Business Analysis techniques
22.4.3.1. Brainstorming
22.4.3.2. CATWOE
22.4.3.3. Data Flow Diagrams
22.4.3.4. Five Why's
22.4.3.5. Functional
22.4.3.6. decomposition
22.4.3.7. Interviews
22.4.3.8. MoSCoW
22.4.3.9. MOST
22.4.3.10. PESTLE
22.4.3.11. Prototyping
22.4.3.12. Requirements
22.4.3.13. Workshop
22.4.3.14. Risk Analysis
22.4.3.15. Scenarios and Use Cases
22.4.3.16. SWOT
22.4.3.17. User stories
23. Competences
23.1. Domain knowledge
23.1.1. Primary role of the BA is to provide business solutions to business issues by assessing business problems, and identifying root causes
23.1.2. Required to
23.1.2.1. Assess business problems
23.1.2.2. Find the most appropriate solution
23.1.2.3. Provide measurement framework
23.1.3. Having domain knowledge allows the Business Analyst to connect and communicate with Business Users
23.1.4. Lack of domain knowledge may lead to delays in providing the solution
23.1.5. Domain knowledge makes understanding and analyzing of business issues easier
23.1.6. Analytical skills
23.1.6.1. Financial analysis
23.1.6.2. Statistical analysis
23.1.6.3. Operations research
23.1.6.4. Requirements analysis
23.1.6.5. Systems analysis
23.1.7. Managerial skills
23.1.7.1. Project management capabilities
23.1.7.2. Understand organizational behavior
23.1.8. Technical skills
23.1.8.1. Working knowledge of science
23.1.8.2. Understanding of engineering principles
23.1.8.3. Ability to apply financial principles to feasibility studies
23.2. Soft skills
23.2.1. Soft skills are necessary
23.2.2. Business Analyst's job requires communication and cooperation with various people
23.2.3. Common Business Analysis activities
23.2.3.1. Negotiation
23.2.3.2. Discussion
23.2.3.3. Conflicts solving
23.2.4. Negotiation skills
23.2.4.1. Negotiate to obtain data
23.2.4.2. Negotiate to resolve conflicts
23.2.4.3. Negotiate to agree requirements
23.2.5. Facilitation skills
23.2.6. Communication and writing skills
23.2.6.1. Communicate with all levels of management
23.2.6.2. Communicate with stakeholders of various knowledge
23.2.6.3. Precise in articulating ideas and thoughts
23.2.6.4. Relate with line workers
23.2.6.5. Good technical writing skills
23.2.6.6. Familiar with all forms of communications
23.2.6.7. Public speaking skills
23.3. Facilitation
23.3.1. Facilitation is the process of enabling groups to work cooperatively and effectively
23.3.2. It is a way of providing leadership without taking the reins
23.3.3. A facilitator is a person who contributes structure and process to interactions so that groups are able to function effectively and make high-quality decisions
23.3.3.1. The goal - to support others to achieve high performance
23.3.4. Facilitator's tasks and activities
23.3.4.1. Helping the group to define the goals and its objectives
23.3.4.2. Providing processes helping to use the time effectively and make high-quality decisions
23.3.4.3. Guiding group discussions
23.3.4.4. Documenting main ideas and concepts raised during the discussion
23.3.4.5. Supporting people in assessing their current skills and building new skills
23.3.4.6. Using consensus to enable the group to make agreed decisions
23.3.4.7. Managing conflicts
23.3.4.8. Helping the group to communicate effectively
23.3.4.9. Helping the group to access resources needed to make decisions
23.3.5. Key competences
23.3.5.1. Communicates well
23.3.5.2. Processes ideas from people
23.3.5.3. Shows a natural interest Listens well Maintains control Empowers the group Handles uncertainty
23.3.5.4. Is quick to connect with the group
23.3.5.5. Systems Analysis & Design
23.3.5.6. Manages people's expectations
23.3.5.7. Understands and constantly explains the process
23.3.5.8. Focuses on the business not on their own solutions
23.3.5.9. Communication skills Negotiating Group dynamics Listen / draw conclusions Running meetings
23.3.5.10. The facilitator must always stay neutral and stay on track
23.3.6. Tools and techniques
23.3.6.1. Engagement Strategies
23.3.6.2. Creating Participation
23.3.6.3. Generating and Organizing Data
23.3.6.4. Ignite Action
23.3.6.5. Mobilizing Energy
23.3.6.6. Initiating Reflection
23.3.6.7. Recording Techniques
23.3.6.8. SWOT
23.3.6.9. Gap Analysis
23.3.6.10. Flipcharts
23.3.6.11. Checklists
23.3.6.12. Brainstorming
23.3.6.13. Root-Cause Analysis
23.3.6.14. Multi-Voting
23.3.6.15. Focus Group Framework
23.3.6.16. Managing Conflicts Tips Sheet
24. Innovation, Design and Customer
24.1. Role of the innovation
24.1.1. Achieving competitive advantage over other companies is more and more difficult
24.1.2. Traditional products and services do not guarantee a success on the market
24.1.3. Innovation as a tool helping the organization to achieve competitive advantage
24.1.4. Innovation
24.1.4.1. Innovation is the process of renewing something that exists
24.1.4.2. Innovation requires
24.1.4.2.1. Changing the way people make decisions
24.1.4.2.2. Doing things differently
24.1.4.2.3. Making choices outside of the norm
24.1.4.2.4. Innovation changes the values onto which the system is based
24.1.4.3. Types of innovation
24.1.4.3.1. Radical (breakthrough, destructive)
24.1.4.3.2. Incremental (conservative, sustaining)
24.1.4.4. User Innovation
24.1.4.4.1. The author of innovation is the end user who develops or refines acquired products and services at the site of use
24.1.4.4.2. Users share their ideas and solutions with the producer
24.1.4.4.3. Called as „free revealing"
24.1.5. Innovation vs. Invention
24.1.5.1. Innovation is not the introduction of something new - it is not invention but changing something already existing by adding values into it
24.1.6. Triggers for Innovation
24.1.6.1. No clear boundaries of the business
24.1.6.1.1. Organizations extends the business area (the offer) and the geographic area of activity using other communication and distributions channels
24.1.6.2. More demanding customers
24.1.6.2.1. Customers require a product
24.1.6.3. Customer needs and expectations are on the first place
24.1.6.3.1. Customer's satisfaction as a success factor
24.1.6.3.2. More effort to meet the customer's requirements
24.1.6.4. The customer should be positively surprised and willing to come back to buy more products / services
24.1.6.5. More interest in integrated systems of
24.1.6.5.1. Products
24.1.6.5.2. Software
24.1.6.5.3. Services working as a single whole
24.1.6.6. Integrated systems as keys to expansion beyond core areas of the business
24.1.6.7. A way to meet customer expectations impossible to achieve by more isolated offering
24.1.6.8. Questions without any answer
24.1.6.8.1. Problems without a solution
24.1.6.8.2. Who finds the right answers or working solution firsts can achieve competitive advantage
24.1.7. Areas of application
24.1.7.1. Products
24.1.7.1.1. Introducing new merchandise to the market
24.1.7.2. Processes
24.1.7.2.1. New, better way of achieving something is introduced
24.1.7.3. Behavior
24.1.7.3.1. How people live their lives, perceive reality or achieve their goals
24.1.8. Categories of innovation
24.1.8.1. Degree
24.1.8.1.1. Disruptive innovation
24.1.8.1.2. Line extension innovation
24.1.8.2. Scope
24.1.8.2.1. Application innovation
24.1.8.2.2. Enhancement innovation
24.1.8.3. Business area
24.1.8.3.1. Product innovation
24.1.8.3.2. Process innovation
24.1.8.4. Source
24.1.8.4.1. Organic innovation
24.1.8.4.2. Acquisition innovation
24.1.9. Design
24.1.9.1. The specification of an object intended to accomplish goals in particular environment
24.1.9.2. A process which produces such specifications
24.1.9.3. A term often linked with innovation
24.1.9.4. From business perspective design is the process which allows the company to achieve a competitive advantage
24.1.9.5. Design supports achieving a competitive advantage by
24.1.9.5.1. Solving users or customers problems in the creative way
24.1.9.5.2. Creating unique value and unforgettable user experience
24.1.9.5.3. Joining functionality, aesthetics, ergonomics and user experience with the form
24.1.9.5.4. Distinguishing the company
24.2. Competition and Market Research
24.2.1. Market Research
24.2.1.1. A structured activity with the purpose to gather information about markets or customers
24.2.1.2. Important component of business strategy
24.2.2. Market Analysis
24.2.2.1. A structured and documented investigation of a market
24.2.2.2. Determines if there is a need or audience for a product / service
24.2.2.3. Provides information about market's needs and how it is currently serviced
24.2.2.4. Useful to plan
24.2.2.4.1. New products
24.2.2.4.2. An expansion of the business
24.2.2.5. Dimensions of a Market Analysis
24.2.2.5.1. Market size (current and future)
24.2.2.5.2. Market growth rate
24.2.2.5.3. Market profitability
24.2.2.5.4. Industry cost structure
24.2.2.5.5. Distribution channels
24.2.2.5.6. Market trends
24.2.2.5.7. Key success factors
24.2.3. Market Research and Analysis process
24.2.3.1. Problem definition
24.2.3.2. Analysis of the situation
24.2.3.3. Obtaining data and information specific to the problem
24.2.3.4. Information analysis and interpretation
24.2.3.5. Formulating ideas and solution of problem
24.2.4. Techniques for collecting market data
24.2.4.1. Qualitative research
24.2.4.2. Quantitative research
24.2.4.3. Customer feedback
24.2.4.4. Mail questionnaire
24.2.4.5. Telephone / Personal Interview surveys
24.2.4.6. Observation
24.2.4.7. Direct work with the end users on site
24.2.5. Trend
24.2.5.1. Trend is a tendency of a market (or specific product or service) to move in a particular direction over time
24.2.5.2. Market Research together with Market Analysis allows to determine Market Trends
24.2.5.3. Analyzing the trends allows to predict the desired future solutions
24.3. Design Thinking
24.3.1. Design Thinking
24.3.1.1. A methodology for practical, creative resolution of problems or issues that look for an improved future result
24.3.1.2. The collaborative process by which the designer's sensibilities and methods are employed to match people's needs with what is technically feasible and a viable business strategy
24.3.2. Design Thinking is a team oriented discipline
24.3.3. Design Thinking converts need into demand
24.3.4. Three major phases
24.3.4.1. Inspiration
24.3.4.1.1. The main goal is to gather insights from customers
24.3.4.1.2. Insights are to be used as the basis for inspirations
24.3.4.1.3. Inspiration phase is performed from the user / customer perspective
24.3.4.1.4. No business constraints
24.3.4.1.5. Results of the inspiration phase
24.3.4.2. Ideation
24.3.4.2.1. The goal is to analyze insights and turn them into ideas
24.3.4.2.2. The ideas become a part of the solution
24.3.4.2.3. New ideas should not be judged or rejected, even if they seem to be contradictory
24.3.4.2.4. Questionable ideas may be a source for further inspiration
24.3.4.2.5. The result of the ideation phase - the decision which ideas become part of the final solution
24.3.4.2.6. Tools for ideation
24.3.4.3. Implementation
24.3.4.3.1. Precondition: ready and more or less stable prototypes of solutions
24.3.4.3.2. The goal is to convince the stakeholders that proposed solutions meet their expectations and guarantee success after release to the market
24.3.4.3.3. Sample tool - storytelling
24.4. Basic methods, tools and techniques
24.4.1. Multidisciplinary teams
24.4.1.1. Team consisted of people from various, often completely different functional areas
24.4.1.2. The teams is organized around the problem rather than a leader
24.4.1.3. Beneficial for
24.4.1.3.1. Making observations
24.4.1.3.2. Gathering insights
24.4.1.3.3. Generating ideas
24.4.2. Multi-vector research
24.4.2.1. An approach for analyzing all available points of view or sources of information
24.4.2.2. Procedure
24.4.2.2.1. Synthesize the vectors to uncover insights
24.4.2.2.2. Create a number of vectors to research H the problem from several directions
24.4.2.3. Typical vectors used in Multi-Vector Research
24.4.2.3.1. Customers
24.4.2.3.2. Competitors
24.4.2.3.3. Organization toolbox
24.4.2.3.4. Technology
24.4.2.3.5. Sales and Retail
24.4.2.3.6. Trends
24.4.3. Persona
24.4.3.1. Persona is a fictional character representing the different types of users
24.4.3.2. Persona represents a group of people with the same
24.4.3.2.1. Needs
24.4.3.2.2. Attitude
24.4.3.2.3. Behavior
24.4.3.2.4. Expectations towards the product
24.4.3.3. Sample personas in innovation process:
24.4.3.3.1. The Anthropologist
24.4.3.3.2. The Experimenter
24.4.3.3.3. The Cross-Pollinator
24.4.3.3.4. The Hurdier
24.4.3.3.5. The Collaborator
24.4.3.3.6. The Director
24.4.3.3.7. The Experience Architect
24.4.3.3.8. The Set Designer
24.4.3.3.9. The Caregiver
24.4.4. Insights
24.4.4.1. Customer insights are the basis for the inspiration and innovation
24.4.4.2. The main idea - whatever is examined it should be examined from customer's point of view
24.4.4.3. Sources of insights
24.4.4.3.1. Customers and their feelings, needs, values and problems
24.4.4.3.2. Extreme users and outliers, children, seniors
24.4.4.3.3. Trends and general trends
24.4.4.3.4. Competition
24.4.4.3.5. Technology
24.4.4.3.6. Complementing and comparable organizations
24.4.5. Brainstorming
24.4.5.1. Technique used for generating of a large number of ideas for the solution of defined problems
24.4.5.2. A session involves a group of people
24.4.5.3. Members have different knowledge and experience
24.4.5.4. Brainstorming sessions should be rather facilitated than moderated
24.4.5.5. Rules applying to brainstorming sessions
24.4.5.5.1. Avoid judgment and criticism towards ideas of other team members
24.4.5.5.2. New ideas can be built on the ideas provided by others
24.4.5.5.3. Do not focus on the quality of the ideas, but on the quantity
24.4.5.5.4. The goal is to collect many various ideas
24.4.6. Prototyping
24.4.6.1. Encourages iterative approach to the problem solution
24.4.6.2. Using prototypes allows
24.4.6.2.1. Better explain and present ideas or solutions to others
24.4.6.2.2. Come up with new ideas
24.4.6.2.3. Test the solution
24.4.6.2.4. Gather the feedback from the stakeholders and customers
24.4.7. Enlightened trial and error
24.4.7.1. Trial and Error - the process of obtaining knowledge by generating solutions, testing them and learning from own mistakes
24.4.7.2. The testing is performed with the prototypes
24.4.7.3. The main idea: "Fail often in order to succeed sooner"
24.4.8. Storytelling
24.4.8.1. A persuasive technique used to convince the other side to the arguments of the storyteller
24.4.8.2. Stories
24.4.8.2.1. Based on assumptions or the real situations experienced during the research phase
24.4.8.2.2. Wrapped around the product, user and user's experience
24.4.8.2.3. The main idea: "show, don't tell"
24.4.8.3. Tools
24.4.8.3.1. Pictures
24.4.8.3.2. Videos
24.4.8.3.3. Sketches
24.5. Working with the final user
24.5.1. Working with the user allows to
24.5.1.1. Identify the user's needs
24.5.1.2. Support the users in formulating the needs
24.5.1.3. Explore the needs and determine requirements
24.5.1.4. Provide the user with suggestions how to improve the desired solution