text:
IBAQB® is a registered trademark of the International Business Analysis Qualifications Board. Trademarks are properties of the holders, who are not affiliated with mind map author.
Process Improvement is a method to introduce process changes to improve quality, reduce costs or accelerate schedules
Improving the business process, Approaches, Manual re-designing of the process on the base of experience and domain knowledge, Introducing tools allowing to optimize the business processes in the organization, Process simulation and optimizing, Adopting selected methodology or strategy
Triggers of Process Improvement, Process Improvement may follow a specific methodology or strategy, Benchmarking, Business Process Improvement, Business process reengineering, Capability Maturity Model Integration / Capability Maturity Model, ISO 9000, IT Governance, Just In Time manufacturing, Lean manufacturing, Performance improvement, Process management, Process improvement and Management (PI&M), Six Sigma, Total Quality Management
Business Process Improvement, BPI is a systematic approach to help an organization optimizing its underlying processes to achieve more efficient results, The goal - radically change the performance of an organization, No improvement by a series of small incremental changes
Methodology of BPI, Define the organization's strategic goals and purposes together with the existing structure and processes (AS-IS), Determine the organization's stakeholders and identify, What outcomes adds value to the organization's objectives, What are the best ways to align its processes to achieve those outcomes (TO-BE), Re-organize the business processes to realize the goals and to meet the new objectives, Supported by the tools available within the BPI methodology
Roles in BPI, Business Leader, Responsible for developing business plans (including strategic plans), Responsible for developing resource plans, Process Owner, Designs processes, Necessary to achieve the objectives of the business plans created by the Business Leaders, Responsible for the creation, update and approval of documents to support the process., Procedures, Work instructions / protocols, Operational Manager, Organizes the resources and processes in order to achieve the objectives of the business plans created by the Business Leaders, Instructs the Process Operators how to perform the processes, Process Operator, Performs the processes necessary to achieve the objectives of the business plans created by Business Leaders, Ensures the realization of a process meets performance objectives, Ensures the products of the processes meet the specifications, The roles has different responsibilities but they work together!
Business Process Simulation, Business Process Simulation (BPS) is a part of Business Process Management (BPM), BPS allows simulating, The execution of business processes, Parameters over time, Simulation is based on process models, The purpose, Understand, analyze and design (or re-design) business process models with respect to performance metrics, Evaluation and comparing the (re)designed processes and implementing the best choice
Process models, The process models must represent, The specific elements of the business process, The attributes of the business process, Execution time, Resource usage, Costs, Running the simulation allows checking how the process is realized, BPS Procedure, Mapping the business process onto a process model, Identification of the sub processes and activities, Creating the control flow definition, Identification of the resources and assigning them to the activities, Defining performance characteristics, Running the simulation, Simulation should be executed for several sub runs, A simulation is run in a specific tool, Tools show an animated picture of the process flow or real-time fluctuations in the key performance measures
Modeling tools allow to, Link requirements in models, Create graphical representation of requirements, Represent relations between requirements, and between requirements and other artifacts, Establish and maintain traceability, Design the overall structure of the system
Requirements are organized (structured) into packages, The purpose of organizing requirements, To determine the solution boundary, To determine the solution scope, To define the structure of requirements, The problem model is decomposed to make each requirement more detailed and to ensure that the model correctly reflects the boundary for the business problem
Decomposition, Goal decomposition, Allows ensuring the solution will satisfy stakeholder's needs, Breaks down high-level stakeholder goals into lower-level goals, Lower-level goals have measurable objectives, Goals are business requirements, Feature list decomposition, Feature is a service that the solution provides to fulfill one or more stakeholder needs, Feature is an abstraction of the solution of the problem expressed on high-level, Feature is developed into completely described functional and supplemental requirements, Functional decomposition, Functional decomposition is a breakdown of a list of items into classifications or groups on the basis of the function each item performs or is used for, Identifies the high-level functions, Breaks them down into sub-processes and activities, To analyze the processes in detail, To ensure proper coverage of all major processes, Functional decomposition is used to, Hierarchically decompose a system into functional components, Hierarchically decompose a business process into sub-processes, Provide a definition of all the business functions and sub-functions identified as system requirements, Levels of detail for functional decomposition, Enterprise Level of Detail, The root of the decomposition diagram contains, The name of the organization, A major function within an organization, The second level represents major business functions, Planning, Execution, Control, Conceptual Level of Detail, Processes identified at this level typically reflect application systems or sub-systems, Marketing, Sales, Finance, The lowest level functions on the Enterprise Level Chart are decomposed into the next level of detail, This identifies the major business processes needed for each function, Logical Level of Detail, Processes are decomposed into the lowest level of detail., At this level all the processes within the scope of the project are identified., This level identifies particular functions
Model, Model is a representation of an object, System model is a conceptual description and representation of the system, Model describes, The structure of the system, Dependencies and relationships between the system's objects system model is a, Textual elements, Matrixes, Diagrams, Reflects the relationships and dependencies between requirements realizing identified business needs
Modeling, Modeling is a way of expressing requirements representing parts or the whole of the proposed solutions, Modeling is helpful but not always necessary, The organization may skip modeling when:, The solution is fully understood by the stakeholders, The solution is easy to implement, The requirements are mostly non-functional and difficult to express in the form of a model, The problem domain is well known, The solution is dedicated to use by very few people, The scope is declared as constant, The model representation would be less understandable by the key stakeholders than written text, Advantages of Modeling, Models allow to focus on the important aspects and areas of the solution, Models describes complex system in more clear and unambiguous way, Models are more readable and clear than written text, Looking at the problem from the overall perspective, Modeling Techniques, Archimate, BPMN, A graphical notation that depicts the steps in a business process, The end to end flow of a business process, The notation is designed to, Coordinate the sequence of processes, Coordinate the messages that flow between different process participants, BMPN diagrams provides a view on the various processes performed within an organization, Help in understanding the organization's performance, Allows effective requirements analyzing and modeling, Quality criteria for business process models, Systematic design, Correctness (syntactic and semantic), Relevance, Economic efficiency, Clarity, Comparability, DSL, GUI modelling, Allows to design the user interface, Allows stahekolders to verify the visual side of the solution and the way of meeting requirments, Supports development works - allows to avoid misinterpretation, Prototyping is the activity of creating prototypes of software application, its components or modules or single screens, Common techniques, Storyboarding, Card sorting, Protytyping, OBASHI, SysML, A general purpose modeling language for systems engineering applications, A dialect of UML, Supports, Specification, Analysis, Design, Verification and validation of a broad range of systems and systems-of-systems, Structure diagrams, The Block Definition Diagram (BDD), replacing the UML2 class diagram, The Internal Block Diagram (IBD), replacing the UML2 composite structure diagram, The Parametric Diagram, a SysML extension to analyze critical system parameters, The Package Diagram remains unchanged, Dynamic diagrams, The activity diagram has been slightly modified in SysML, The sequence, state chart, and use case diagrams remain unchanged, The requirements diagrams is a SysML extension, UML, UML combines techniques from, Data modeling (entity relationship diagrams), Business modeling (work flows), Object modeling, Component modeling, UML diagrams:, Static (or structural):, Class diagrams, Composite structure diagrams, ..., Dynamic (or behavioral):, Use case diagrams, Sequence diagrams, Activity diagrams, State machine diagrams, ...
Assumptions and constraints identify aspects of the problem domain that are not functional requirements of a solution, and will limit or impact the design of the solution
Constraint, A constraint is a requirement that explicitly and intentionally tries to directly restrict any system or process, Limitations on, Engineering process System's operation Lifecycle
Types of constraints, Business constraints, Financial or time restrictions, limits on the number of resources available, skills of the project team or any other organizational restriction, Limitations on the projects flexibility to implement requested solution, Technical constraints, Related to the architecture of the solution (hardware and software platforms, programming language or technology, supporting software), Technical constraints include also: database size, resource utilization, message size, software size, maximum number of and size of files
Example constraints, Hardware or software environment, End-user environment, Availability or volatility of resources, Standards compliance, Interoperability requirements, Interface / protocol requirements, Data repository requirements, Data distribution requirements, Security requirements, Memory limitations, Performance requirements, Network communications
Assumption, Assumptions are things that are believed to be true but have not been confirmed, Assumptions are unproven conditions, which if not true at some defined point in time, would affect the initiative / solution, Assumptions often become limitations!, Goal, Assumptions are used to document, Issues identified as true but impossible to verify, Issues identified as true in the current situation that, if they change, can have negative or even destructive impact on the project
Types of assumptions, Business assumptions, The purpose: to inform the project team of key stakeholder expectations, Requirements assumptions, The purpose: to transfer business domain knowledge to the project team
Example assumptions, The back-end system is available, There is no more than 1000 transactions per day, All transactions are processed in EURO
Validation, Validation is an activity of confirmation by examination and through provision of objective evidence that the requirements for a specific intended use or application have been fulfilled [ISO 9000], Goal, The goal of validation is to ensure that the stated requirements correctly implement the business requirements determined in Enterprise Analysis and Requirements Identification phases
Verification, Verification is a confirmation by examination and through provision of objective evidence that specified requirements have been fulfilled [ISO 9000], Verification ensures that requirements are defined clearly enough to allow solution design and implementation and test preparation to begin, Verification process requires to involve and cooperate closely with, Customer, Users, Project team, Requirements can be stated as verified if, Project stakeholders agreed that the requirements are correctly understood, The requirements were checked with the stakeholders and confirmed as complete description of what has to be implemented, The requirements were stated as of high quality
Quality Assurance, Quality Assurance is a process of monitoring the quality of the process or project in order to ensure that minimum level of quality standards is achieved
Quality criteria for requirements, Allocatable, Complete, Consistent, Correct, Does not determine solution, Feasible, Measurable, Necessary, Prioritized, Testable, Traceable, Unambiguous, Understandable
Examples of QA techniques, Checklists, A common technique for quality control, A standard or customized set of quality elements to validate the Requirements Specification (or other artefact), Reviews, A review is an evaluation of a product or project status to ascertain discrepancies from planned results and to recommend improvements [IEEE 1028], Examples, Management review, Informal review, Technical review, Group discussion focused on achieving consensus on the technical approach to be taken, Inspection, Visual examination of documents to detect defects, Walkthrough, Step-by-step presentation by the author of a document in order to gather information and to establish a common understanding of its content, Peer review, A review of a work product by colleagues of the author of the product for the purpose of identifying defects and improvements, Testing
Business Requirements Elicitation, Business Requirements Elicitation is a set of approaches, activities, tasks and techniques allowing to collect the business requirements of a planned solution, from the stakeholders and other available sources
The purpose of Business Requirements Elicitation, Identification of:, Desired functions, Attributes, Quality characteristics, Limitations and expectations, Requirements resulted from external regulations, norms etc., Orientation of the requirements toward the project vision, Establishing the finał scope, Establishing business design of the system, Excluding functions that the customer does not want and need
Techniques for Requirements Elicitation, Q.uestionnaires, What is it?, Eliciting information from many people, anonymously, in a relatively short time., Quastionnaire can collect information about:, Customers, Products, Work practices, Attitudes, 2 types:, Closed, The respondent is asked to select from available responses., Used if the issues are know., Open-ended, The respondent answes the questions in free way., Used if there is range of users responses is pretty well understood., Process:, 1. Prepare the questionnaire, 1. Define the purpose / target group, 2. Choose the questionnaire type, 3. Select the sample group, 4. Determine if individual interviews are needed, 5. Determine desired level of response, 6. Select the distribution and collection methods, 7. Write the survey questions, 2. Distributethe questionnaire, 3. Communicate the results, Questions, The questionnaire should be short., The questionnaire should be easy and fast to complete., Guestion wording must be elear and unambigous., No double questions in a single question., No questions involving negatives., No complex branching structures., No questions that make respondents feel uncomfortable., lnterviews, What is it?, An interview is a systematic approach to elicit information from a person or group of people in an informal or formal setting by asking relevant questions and documenting the responses., 2 types:, Structured interview, A pre-defined set of ąuestions., Unstructured interview, Without any pre-defined questions., Open-ended discussion about what the business expects from the target system., Process:, 1. Opening the interview, 2. Conducting the interview, 3. Closing the interview, 4. Post interview follow-up and review, Self-recording, The user records his own activities (AS-IS)., Documents all steps, inputs and resources needed to complete a task / procedure., The user describes also changes, desires and needs., Advantages:, Low time and work effort on software vendor side, Disadvantages, Highly dependent from the motivation and experience of the user performing self-recording, Customer's representative, A main idea in Agile methods. Allows close cooperation and direct communication with the customer. One of the most effective requirements identification (and validation) method., Assumption:, The representative has adequate knowledge and communication skills., The representative:, Systematically monitors the progress -Verifies correctness of the design, Provides quick feedback and additional information wherever necessary, Identification on the basis of existing documents, Allows to elicit requirements of an existing system by studying available documentation and identifying relevant information., Used to gather details of the AS IS environment for the solution:, Existing business rules, Entities, Attributes, Process:, Prepare the documents, Analyze the documents, Review and follow-up, Review and confirm the selected details with subject matter experts, Obtain answers to follow up questions, Reuse (Reusing the specification of a certain project), Reuse of documentation / solution from previous projects., Requirements specification prepared for previous project can be used in another, similar, project., Shorts the duration of Business Analysis., Important notice:, Only some parts of existing specifications can be used in new project., The documentation to be reused should be checked against the compliance with the current needs., Brainstorming, A way of eliciting many creative ideas for an area of interest., Produces numerous creative ideas about any given "central question" or topic., Promotes diversion type of thinking., Brainstorming to detail identified requirements and find new ones, Brainstorming helps answer specific questions:, What options are available to resolve the problem?, What factors are influencing or constraining the proposed solution?, How should we design the usability of the solution?, How can be the process improved?, Process:, 1. Prepare for Brainstorming, 2. Conduct Brainstorming session, 3. Wrap-up the brainstorming, 1. Discuss and evaluate the ideas., 2. Create a list and rate the ideas., 3. Communicate the results to the team., Field observation, Conducting an assessment of the user's work environment., Studying people performing their jobs-without any interventions!, Observation is usually used:, To document the current processes, When the purose of the project is to enhance or change a current process, 2 types:, Passive / invisible observation, Observing the user working without asking questions., The Business Analyst writes notes about what he/she sees., Waiting until the process has been completed before asking any questions., Active/visible observation, Dialog with the worker., In case of questions, the Business Analyst asks the worker - even if it breaks the routine., The Business Analyst may participate in the work., Apprenticing, Apprenticing is a process of learning from the user his job, The customer teaches the Business Analyst., Master and student approach., The "student" is watching the "master" working., The student is asking questions in case of problems., The masteris explaining the tasks being performed., Useful when the customer is not able to provide full time support of his employees., Overcomes the problem of abstract thinking and expressing the tasks in words, Users can always refer to the actual case and explain things on examples., Workshops (after each iteration), Workshop is a structured way to capture requirements., May be used to scope, discover, define, prioritize and reach closure on requirements for the solution., Its is not a traditional meeting., Focused event attended by key stakeholders and subject matter experts for a short period., Workshop roles, Facilitator, Enforces discipline, Introduces the goals and agenda for the workshop, Keeps the team on track, Facilitates a process of decision making and builds consensus, Scribe (Recorder), Documents the business, requirements elicited, Documents outstanding issues, Participants, Process:, Prepare for the workshop, Conduct the workshop, Post Requirements Workshop wrap-up (done by Facilitator), Prototyping, Helps uncover and visualize interface requirements before the solution is designed or developed, Prototyping to visualize implementation of identified requirements, Focus groups, Used to elicit ideas and attitudes about a specific problem in an interactive group environment, Interface Analysis, Helps to clarify the boundaries of the system, Important notice:, The best results are achieved when mixing some techniques.
Requirements quality characteristics, Functionality, Reliability, Usability, Efficiency, Maintainability, Portability
Managing requirements scope is considered as managing the list of the requirements of some or all of the following projects, System or component development, Process improvement, Organizational change
Requirements Scope Management, 1. Establishing requirements baseline, 2. Creating a requirements structure for traceability, 3. Identifying impact to external systems and other areas of the project, 4. Identifying changes in the scope resulting from requirements changes, 5. Maintaining scope approval
All requirements identified and approved by stakeholders must be baselined
The baseline, Is a base for further system development, A point of reference for any changes in the content / scope of requirements
Creating a requirements structure for traceability, Requirements traceability is necessary for managing changes to the requirements done after the requirements are baselined
Impact to other systems / areas, Identification of all impacts to external systems and other areas of the project necessary to ensure that there is no work outside the baselined list of requirements
Changes in requirements scope affects, Project schedule, Project cost, Project and product risk, Project Resources, External interface to another systems or hardware
Identifying changes in the scope, Requirements are not constant throughout the project's lifecycle, Impact on the project, Minor change -> no impact on the project scope, time or cost, Major change -> may drastically change the project scope, time or cost, Major changes examples, Changing business logic, Changing process flow for critical functionality
Maintaining scope approval, The list of requirements must be approved and baselined, The approved list of requirements is a mutual understanding between the customer and the vendor team about the requirements, Changes in the approved list of requirements must be managed via Change Management procedures
Goals, Scope management, Impact analysis, Coverage analysis, Proof of implementation, Use of the requirement, Defect reports
Traceability, Traceability is an association existing between requirements when more detailed requirements are associated with the higher level requirements (needs and features), Traceability may exist between detailed requirements and both design models and test cases, Traceability between requirements and other project artefacts aIlows to ensure all requirements are met, Representing traceability on UML diagrams
Tool support, Requirements Management software, Storing all requirements of all specifications of a technical system under development, Arranging requirements in structures (specification tree), Linking each one to the "parent" requirement in the higher specification, Requirements are realized into:, Design artefacts, Implementation, Test cases, Artefacts are traced back to the requirements.
Tools, Requirements Traceability Matrix, Track all requirements and check if they are being met by the current process, Assist in the creation of project's documentation, Supports verification process, RTM is created at the beginning of a project, Bi-directional Traceability Matrix, Bi-directional Traceability Matrix between Software Requirements Specification (SRS) and Software Design Document (SDD )
Software, i.e. Enterprise Analyst, i.e. Enterprise Architect, …
Requirements document, A requirements document describes a set of related functional and non-functional requirements, No project deliverable information - constant time, Formalizes the project scope
Purpose of the requirements document, Structuring the requirements, Providing clear and unambiguous explanation of the requirements, A basis for implementation and testing, A basis for requirement management, Documentation is a baseline
Content of a requirements document, Assumptions, Business Process Description (BPD), An executive summary of an initiative, Describes the problem and the proposed solution in high-level terms, Business Requirements Document (BRD), Describes the behavior required of a software application, Primarily describes the business requirements, The target audience is the customer and users, Dependencies, Functional requirements, Introduction, Non-functional requirements, Overall description, Purpose of the product, Regulations, Request for Proposal / Request for Quotation (RFP / RFQ), Distributed to parties outside the organization, Basis for the contracting of solution development services, Risks, Safety requirements Document acceptance, Secrecy clause, Software Requirements Specification (SRS), Also known as a System Requirements Specification, Describes the behavior and implementation of a software application, The target audience is the development team, Stakeholders, Standards, ...
Common Document Formats, Software Requirements Specification (SRS), A description of the problem domain, Decomposition of the problem domain, Description of the functional requirements, Description of the non-functional requirements, Assumptions and constraints affecting the solution, Requirements attributes and traceability information
Construction of a requirement, Describe business justification for the requirement, Identify the business process, Identify the stakeholders, Identify the limitations and assumptions, Describe the context, Describe the requirement, Input, Output, Resources, Quality characteristics (if applicable), Provide the graphical model (if applicable), Describe risks, Provide references
Guidelines for the requirements document, The requirements must be unambiguous, precise and understandable, Superfluous information should be avoided, Templates as an aid to limit language, Models and diagrams makes the document clear and more understandable, Use formal graphical notation to express complex requirements, dependencies and relationships
Common Document Problems, Trivialities, Lengthy descriptions of commonly known issues, Information out of scope, Information without added value to the description of the solution, Thinking in solutions, Description of solutions, Requirement specification determining the technical design, Redundant details, Details unnecessarily complicating the implementation, Implementation details, Lacking rationale, No description of what shall be achieved with the solution (inc. concrete numbers and metrics)
Requirements Communication, Requirements Communication includes activities for expressing the output of the requirements analysis and documentation to the stakeholders
Communication, An ongoing and iterative activity, Presenting, Communicating, Verifying, Obtaining approval
Communicate requirements in a way allowing all stakeholders to gain the same understanding of a particular requirement
Consider and choose communication approach appropriate for the project
1. Preparing requirements communication Plan
2. Managing requirements conflicts
3. Establishing the most appropriate requirements format
4. Creating requirements package
5. Conducting requirements presentation
6. Performing formal requirements review
7. Obtaining requirements approval (Sign-off)
Requirements should be agreed and accepted by all relevant stakeholders
All requirements must be formally approved
Formal agreement, Starting point for detailed system specification, designing the architecture and other works on the planned system
Business Sponsor
Project Managers
Business Analysts
Test / QA Manager
ISO 25000 (ISO/IEC 9126), Defines a quality model with 6 categories:, Functionality, Reliability, Usability, Efficiency, Maintainability, Portability
IEEE 830, Recommended Practice for Software Requirements Specifications
IEEE 1233, Guide for Developing of System Requirements Specifications
IEEE 1362, Guide for Information Technology - System Definition
Imprecise, ambiguous, contradictory or missing requirements
Requirements that change
Requirements that do not fulfill the agreed criteria (i.e. quality criteria)
The organization needs not satisfied
The business goals not achieved
Not measurable
Unclear objectives
Communication problems
Language barriers
Knowledge barriers
Vague formulation
Too formal formulations
Ambiguous, overly specified, unclear, impossible, contradictory requirements
Instability of the requirements (frequent changes)
Redundant description of requirements
Insufficient user invelvement
Overlooked user classes
Minimal specification
source BABOK
Product Scope, "The features and functions that characterize a product, service, or result."
Project Scope, "The work that needs to be accomplished to deliver a product, service, or result with the specified features and functions."
A Business Analyst might start "bridging" further up the stream in terms of business needs and problems and stop "bridging" at the functional requirements level or at WHAT the system will do and leave it to a systems analyst or a senior developer to determine HOW to do it.
A liaison among stakeholders
Identify, analyze, communicate and validate requirements for changes to:, Business processes, Policies, Information Systems
Requirements elicitation (identification)
Requirements analysis and modelling
Requirements realization planning
Requirements communication
Requirements documenting
Requirements validation
Requirements configuration management
Business solution proposal
Managing the requirements
Reduce waste
Create solutions
Complete projects on time
Improve efficiency
Document the right requirements
Identify the root causes of problems
Requirements Elicitation (identification)
Requirements Analysis
Requirements Specification
Requirements Management, Including Configuration Management
Requirements Communication, Communicate requirements in a way allowing all stakeholders to gain the same understanding of a particular requirement, Consider and choose communication approach appropriate for the project
Requirements Documentation
Requirements Modeling
Requirements Validation
Analysis phase, Identification and evaluating of the current business processes (AS IS analysis), Gathering initial requirements for needed business solution (TO BE analysis), Creating and analyzing Business Case, Conducting feasibility study, Preparing ideas of business solution
Specification phase, Identifying and documenting business requirements on more detailed level, Supporting System Analyst in preparing detailed system specifications, Validating proposed software design with the customer and other stakeholders, Managing requirements changes
Development phase, Supporting development team during implementation, Validating increments of solution according to intended requirements and needs, Supporting testers in preparing test cases and test scripts at business level, Managing potential changes in requirements
Testing phase, Checking test results, Resolving issues related to defects or gaps in the requirements, Supporting preparing test cases for User Acceptance Testing, Supporting acceptance testers in executing test cases
When a need for clarification of business issues appears (implementation, testing)
When a need for new functionalities appears
When the business changes
When the end users need support with working with the solution
A Business Analyst is involved during the whole software life cycle, including maintenance phase
Requirements should be preceded by descriptors like:, Business requirements, User requirements, Functional requirements (FRs), Non-functional requirements (NFRs)
Foundation for project's assessment, planning, execution and monitoring
Customer expectations (stakeholders value)
Component of agreements, project plans
Setting of system boundaries, scope of delivery
Process requirements (project management / HOW), Needs and limitations of the business processes (e.g., management or production processes), e.g., costs, marketing, processing time, sales and distribution, organization, documentation
Product requirements (product delivery / WHAT), Functional (F), Non-functional (NF), External, Internal
Customer requirements (business requirements)
Solution / system requirements
Product / component requirements
A conflict may arise on one or more documented requirements.
Requirements themselves could be in conflict.
1. Record the conflict in the Issues Log
2. Analyze the conflict and its source
3. Resolve the conflict, Research (without a formal stakeholder session), Meeting involving affected stakeholders, Interviews with other parties
4. Keep an audit trail of the activity taken
5. Obtain sign off for the resolution
6. Document and distribute the results of resolution actions
Questions to be asked:, How detailed the requirements need to be?, What information is important to communicate?, What is the appropriate level of detail of the document?, What is the type of audience?, What is the stakeholder's preferred style of communication (technical vs. business)?
Requirements can be presented in various formats.
Requirements should be presented in formats understandable for the target audience.
Helps to obtain stakeholder understanding and approval of the requirements.
The type of requirement influences the presentation technique.
The project methodology may specify what tools will be used for documentation
Usually a combination of many formats in one requirements document is used.
e.g., Diagrams, Process Workflows, Entity Relationship Diagram, Process Decomposition Diagram, UML Use Cases, Text, Textual templates, Prototyping, Additional formats, User manuals, Presentation slides, User stories
A comprehensive requirements document to be presented to the stakeholders.
Packaging the requirements supports effective requirements communication.
Requirements may be "packaged" at any point in a project.
Deliveries of the Business Analysis:, Assumptions, Business needs and objectives, Business process flow definition, Business requirements, Definition of the business process's products, Limitations, Stakeholders of the project
Process, 1. Determine which components of the overall requirements document should be grouped together., 2. Determine the audience to whom the requirements will be presented, 3. Evaluate the documentation required based on the type of project, 4. Package the requirements for presentation
The first step is to understand the objective of the presentation and the intended audience.
The objective:, To review, prioritize or to communicate status, To ensure quality of the requirements, To improve clarity, To obtain requirement's sign off
Subjects:, Business requirements, Data and behavior models, Functional requirements, Other models: Use Case models, Process / flow models
2 types:, Formal presentation, Used to:, Ensure that quality standards have been met, Obtain business acceptance and sign-off, Obtain delivery team or / and QA team sign-off, Examine solution options with a delivery team, Prioritize requirements, Informal presentation, Used to:, Perform informal status check of requirements, Communicate requirements to the delivery / testing team to ensure there is no ambiguity, Communicate requirements to affected business areas, Communicate requirements to other project teams
A working group session in order to review and discuss the requirements.
Participants should review the requirements before the session.
During the session each participant expresses questions; comments and suggestions.
All questions, issues are recorded.
Agreed changes are recorded.
After the session - additional requirements gathering, analysis and documentation and incorporating changes.
Significant changes may require a second review.
Process, 1. Prepare the document(s) to be reviewed, 2. Determine participants, 3. Organize / schedule the review, 4. Compile notes and results of the review, 5. Conduct the review, 6. Deliver document(s) to participants, 7. Re-review if necessary
Managing requirements scope is considered as managing the list of the requirements of some or all of the following projects:, System or component development, Process improvement, Organizational change
1. Establishing requirements baseline, All requirements identified and approved by stakeholders must be baselined., The baseline:, Is a base for further system development, A point of reference for any changes in the content/scope of requirements
2. Creating a requirements structure for traceability, Requirements traceability is necessary for managing changes to the requirements done after the requirements are baselined.
3. Identifying impact to external systems and other areas of the project, Identification of all impacts to external systems and other areas of the project necessary to ensure that there is no work outside the baselined list of requirements., Impact to other systems / areas, External interface to another systems or hardware, Project and product risk, Project cost, Project resources, Project schedule
4. Identifying changes in the scope resulting from requirements changes, Requirements are not constant throughout the project's lifecycle., Impact on the project:, Minor change -> no impact on the project scope, time or cost, Major change -> may drastically change the project scope, time or cost, Changing business logic, Changing process flow for critical functionality
5. Maintaining scope approval, The list of requirements must be approved and baselined., The approved list of requirements is a mutual understanding between the customer and the vendor team about the requirements., Changes in the approved list of requirements must be managed via Change Management procedures.
Traceability may exist between detailed requirements and both design models and test cases.
Traceability between requirements and other project artifacts allows to ensure all requirements are met.
Goals of Traceability, Scope management, Coverage analysis, Impact analysis, Use of the requirement, Proof of implementation, Defect reports
Tool support by Requirements Management software, Storing all requirements of all specifications of a technical system under development, Arranging requirements in structures (specification tree), Linking each one to the "parent" requirement in the higher specification, Requirements are realized into:, Design artefacts, Implementation, Test cases, Artifacts are traced back to the requirements.
Requirements Traceability Matrix (RTM), RTM is created at the Traceability Matrix is beginning of a project,, used to:, Track all requirements and check if they are being met by the current process, Assist in the creation of project's documentation, Supports verification process
Purpose, Structuring the requirements, Providing clear and unambiguous explanation of the requirements, A basis for implementation and testing, A basis for requirement management, Documentation is a baseline
Requirements Document, No project deliverable information, costand time, Formalizes the project scope, A requirements document describes a set of related functional and non-functional requirements., Guidelines, The requirements must be unambiguous, precise and understandable, Superfluous information should be avoided, Templates as an aid to limit language, Models and diagrams makes the document clear and more understandable, Use formal graphical notation to express complex requirements, dependencies and relationships, Quality attributes, Complete, Consistent, Modifiable, Traceable
Forms:, Graphical models, Mathematic representation, Mixed techniques, Written text
Content::, Introduction, Secrecy clause, Regulations, Standards, Stakeholders, Purpose of the product, Overall descriptio, Functional requirements (FR), Non-functional requirements (NFR), Assumptions, Dependencies, Risks, Safety requirements Document acceptance
Formats:, Vision, What is it?, High-level consensus among stakeholders as to the overall scope of the solution domain, An output of Enterprise Analysis., Usually used in iterative development, Business Process Description (BPD), An executive summary of an initiative., Describes the problem and the proposed solution in high-level terms., Business Requirements Document (BRD), Describes the behavior required of a software application., Primarily describes the business requirements., The target audience is the customer and users, Request for Proposal / Request for Quotation (RFP/RFO.), Distributed to parties outside the organization., Basis for the contracting of solution development, Software Requirements Specification (SRS), Also known as a System Requirements Specification., Describes the behavior and implementation of a software application., The target audience is the development team., A description of the problem domain, Decomposition of the problem domain, Description of the functional requirements, Description of the non-functional requirements, Assumptions and constraints affecting the solution, Requirements attributes and traceability information
Common mistakes, Trivialities, Lengthy descriptions of commonly known issues, Information out of scope, Information without added value to the description of the solution, Thinking in solutions, Description of solutions, Requirement specification determining the technical design, Redundant details, Details unnecessarily complicating the implementation, Implementation details, Lacking rationale, No description of what shall be achieved with the solution (inc. concrete numbers and metrics)
1. Describe business justification for the requirement
2. Identify the business process
3. Identify the stakeholders
4. Identify the limitations and assumptions
5. Describe the context
6. Describe the requirement, Input, Output, Resources, Quality characteristics (if applicable)
7. Provide the graphical model (if applicable)
8. Describe risks
9. Provide references
An ongoing and iterative activity
Process, 1. Preparing requirements communication plan, 2. Managing requirements conflicts, 3. Establishing the most appropriate requirements format, 4. Performing formal requirements review, 5. Conducting requirements presentation, 6. Creating requirements package, 7. Obtaining requirements approval (Sign-off)
Requirements should be agreed and accepted by all relevant stakeholders.
All requirements must be formally approved.
Formal agreement:, Starting point for detailed system specification, designing the architecture and other works on the planned system.
Stakeholders with the acceptance authority, Architects, Business Analysts, Business Sponsor, Project Managers, Test/QA Manager
Requirement acceptance consequences, The list of requirements is binding for both the vendor and the customer., Any changes must be managed via Change Management.
Purpose, To determine the solution boundary, To determine the solution scope, To define the structure of requirements
Requirements are organized (structured) into packages, The problem model is decomposed to make each requirement more detailed and to ensure that the model correctly reflects the boundary for the business problem.
3 types, Functional decomposition, Functional decomposition is a breakdown of a list of items into classifications or groups on the basis of the function each item performs or is used for., Identifies the high-level functions, Breaks them down into sub-processes and activities, Used to:, Hierarchically decompose a system into functional components, Hierarchically decompose a business process into sub-processes, Provide a definition of all the business functions and sub-functions identified as system requirements, Levels of detail:, Enterprise Level of Detail, The root of the decomposition diagram contains:, The name of the organization, A major function within an organization, The second level represents major business functions, Planning, Execution, Control, Conceptual Level of Detail, Processes identified at this level typically reflect application systems or sub-systems:, Marketing, Sales, Finance, The lowest level functions on the Enterprise Level Chart are decomposed into the next level of detail, This identifies the major business processes needed for each function, Logical Level of Detail, Processes are decomposed into the lowest level of detail., At this level all the processes within the scope of the project are identified., This level identifies particular functions, Feature list decomposition, Feature is developed into completely described functional and supplemental requirements., Feature is a service that the solution provides to fulfill one or more stakeholder needs. Feature is an abstraction of the solution of the problem expressed on high-level., Goal decomposition, Allows ensuring the solution will satisfy stakeholder's needs, Breaks down high-level stakeholdergoals into lower-level goals, Lower-level goals have measurable objectives.
Describes the function, architecture, and design of software
Describes the process of development itself
All artefacts should be under version control.
Artefacts are either final or intermediate work products produced and used during a project.
e.g., Business Case, Class diagrams, Design document, Project's plan, Requirements document, Risk assessment, Use cases
"A Business Analyst is a person responsible for identifying the business needs of the customer / stakeholders and to determine solutions to business problems.", source BABOK
Business Case describes a justification for the project in terms of the value added to the business as a result of the project outcomes in comparison to the cost of developing the new solution., source BABOK
The Business Case describes the justification for the project.
A Business Case captures the reasoning for initiating a project or task.
Determines the value to be added to the business as a result of the project outcomes vs. the cost to develop the solution.
Business Goal is an objective of an organization., Short- or long-term., Formulated by the requesting organization.
A Business Need defines the business problem or opportunity.
Formulated by the requesting organization, with optional support of the Business Analyst on the vendor side.
Understanding needs is required to be able to recommend appropriate solutions.
Business Requirements Elicitation 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.
A set of activities designed to produce a specific output for a particular customer or market.
Focused on the way of organizing work, activities, relationships and dependencies between them.
Decision Package is a collection of the documents summarizing information about the proposed project
Includes or references all information gathered about the project so far.
May identify and justify the next steps in the overall process to continue.
A set of pre-project activities capturing the future view of the business in order to provide context to requirements identification and solution design fora given initiative/long-term strategic planning., source BABOK
Analysis and evaluation of a proposed project to determine if it:, Is technically feasible, Is feasible within the estimated cost, Will be profitable
Feasibility studies are almost always conducted when the initiative involves large sums.
Also called Feasibility Analysis.
[IEEE Std 610.12-1990], 1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective., 2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents., 3. A documented representation of a condition or capability as in 1 or 2.
The Requirements Communication consists of a set of activities for expressing the output of the Requirements Analysis and Documentation to a broad audience., source BABOK
Requirements Communication includes activities for expressing the output of the requirements analysis and documentation to the stakeholders.
A requirements document describes a set of related functional and non-functional requirements.
Requirements Elicitation is the set of approaches, activities, tools and techniques for capturing the requirements of a planned solution from the stakeholders., source BABOK
Requirements signoff is a formal agreement by project stakeholders that the content and presentation of the requirements meet their expectations.
* May involve final review of requirements.
* The approval may be recorded either physically or electronically.
The purpose is to determine if the proposed project carries more risk than the organization is willing to bear.
Traceability is an association existing between requirements when more detailed requirements are associated with the higher level requirements (needs and features. Traceability is an association between:, Requirements, Detailed requirements and design models, Detailed requirements and test cases, High level requirements and test cases, Requirements and design artefacts
An interview is a systematic approach to elicit information from a person or group of people in an informal or formal setting by asking relevant questions and documenting the responses.
Feature is a service that the solution provides to fulfill one or more stakeholder needs. Feature is an abstraction of the solution of the problem expressed on high-level., source BABOK
Lack of clear link to the organisation's key strategic priorities
Lack of clear senior management ownership and leadership
Lack of effective engagement with stakeholders
Lack of skills and proven approach to project and risk management
Project not broken down into manageable steps
Evaluation of proposals linked to short term affordability rather than longer term value for money
Lack of understanding of and contact with suppliers
Lack of effective integration between the client, supplier and supply chain
10. Standard Tools and Infrastructure
9. Formal Methodology
8. Skilled Resources
7. Financial Management
6. Project Manager Expertise
5. Agile Process
4. Optimizing Scope
3; Cieor Business Objectives
2. Executive Management Support
1. User Involvement
Stakeholders on the vendor's side (selected), Project Managers, Business and System Analysts, Developers and Architects, Database designers, GUI designers, Technical writers, Testers and Quality Assurance stuff, Installation and Operations personnel
Stakeholders on the customer's side (selected), Customer representative (so called "Business"), Project sponsor, End users (if are derived from the customer company), The person who installs and maintains the system, Quaiity Assurance / Testers, Installation and Operations personnel
External stakeholders, End users (clients of the customer), Other organizations (regulation entities)
Techniques, Analyzing relationships with external organizations (suppliers etc.), Suppliers, subcontractors, partners - they can be affected by the solution as well., Their processes may also influence our solution., Identifying owners of business processes, Analyzing organizational structure of the customer's organization, Exploring the target market of the customer's organization, Analyzing relationships with external organizations, Investigating the business domain, internal/external customers and subcontractors allows to find stakeholders., Identifying owners of business processes, After identification of processes, the processes' owners have to be determined., Owners of the processes affected by the solution will be stakeholders of the initiative., Analyzing organizational structure of the customer's organization, Allows to identify stakeholders and their hierachy, relationships (what can be later used in determing the requirements' priorities and permission scheme for the planned solution)., Exploring the target market of the customer's organization, End customers, end users, institutions and other organizations affected by or affecting the solution., Investigating the business domain
No knowledge about the real operators of business processes in the organization
Not clear responsibilities in the customer's organization
Missing stakeholders - not clearly and directly related with the process (the end customers)
Gaps in the analysis resulted in missing processes and activities
Identify all stakeholders and their needs.
Find a common understanding of the purpose of a system.
Determining stakeholders value is one of the key factors of the project's success.
The main goal of a project is achieving "realized value" (also known as "benefits"), for the stakeholders.
A value can be defined as '"the benefit we think we get from something" -T. Gilb.
Value is the potential consequence of system attributes, for one or more stakeholders.
Value is not linearly related to a system improvement:, A small change in an attribute level could add immense perceived value for one group of stakeholders for relatively low cost.
Value is the perceived usefulness, worth, utility or importance of a defined system component or system state, for defined stakeholders, under specified conditions.
"Benefit" is when some perceived value is actually produced by a defined system.
Value is not absolute: it is relative to a stakeholder.
Determining business opportunities
Developing strategic goals to be achieved by the organization
Developing a strategic plan allowing to plan and execute the goals
Understanding and developing the business architecture
Determining the optimum project investment path for the organization, including:, Implementation of new business and technical system solutions, Implementation of process or organizational changes
Selecting the right solution approaches for projects and developing their business cases
Initiating projects
As a stand-alone project, in large and complex organizations
By customer organization - before involving the vendor, the results are provided as part of initial requirements (in small organizations)
Not conducted at all, if the goal of the project is clear and measurable
Identification of business processes
Creating the Business Architecture
Conducting Feasibility Studies
Conducting the initial Risk Assessment
Preparing the Business Case
Scoping and defining the new business opportunity
Preparing the Decision Package
Defines an organization's current and future capabilities., High level business environment, Long term goals and objectives, Stakeholders, The businesses strategy, The external environment, The technological environment
1. Identifying project risks, 1. Identifying and analyzing business risks, 2. Identifying and analyzing financial risks, 3. Identifying and analyzing technical risks
2. Assessing risk probability and impact
3. Planning risk responses
4. Assessing organizational readiness / calcuiating an overall risk rating
Characteristics of a Business Process, Has a goal, Has specific inputs, Has specific outputs, Uses resources, Has a number of activities performed in some order, May affect more than one organizational unit, Creates value for the customer
Purpose of Business Process's identification, Understanding the goals of the organization., Determining activities and the flow required to achieve the planned business and strategic goals., Finding gaps and non-effective parts of the process to optimize the process.
Qualities of Business Goals, Specificity, Optimism, Realism, Short and long term
Importance of setting Business Goals, Provides a vision of what the organization wants to accomplish., Provides a clear picture of what the organization is trying to do with the business., Allows to understand and maintain a commitment to the business main objectives., It gives a metric to measure organization's progress.
SMART, A system and a tool for effective goal setting and goal quality., All goals should be SMART., S - Specific, M - Measurable, A - Attainable, R - Relevant, T - Timely, SMART - example of business goal, Obtain 3 new billion dollar corporate clients in the New York property insurance market by the end of this fiscal year through networking.
Who defines the Business Need?
The person or group requesting the project, including:, High-level Subject Matter Expert (SME) [Pyzdek, Thomas and Paul A. Keller], Regulatory / compliance body, Sponsor, Steering committee, Subject Matter Expert (SME)
e.g., Branch managers need an access to transaction's reports and statistics., Insurance agents need a mobile application to analyze and document claims., Controlling department needs an access to structured information from all systems operating in the organization.
A Business Case may cover the following topics:, Information about the opportunity in terms of the market trends, competitive environment and expected market penetration, Qualitative and quantitative benefits, Estimates of costand time to breakeven, Profit expectations, Follow-on opportunities, Cash flow consequences of the action, over time, and the methods used for quantifying benefits and costs, The impact of the project on the business operations, The impact of the project on the technology infrastructure, Constraints associated with the proposed project, Estimated budget, Alignment with priorities established by the business
Main idea of a Business Case, A Business Case demonstrates that:, The solution proposal has been analyzed properly, The full benefits will be realized in time, Any technical aspects have been thoroughly evaluated
Purpose of a Business Case, Buildingthe Business Case allows the organization to, Understand and apply a way of thinking where people with the authority to recommend projects will firstly analyze their value, risk and priority as a base of submitting the project proposal, Justify the value of proposals to the organization, Reject any proposals that are not of proven and measurable value, Decide if the proposal is of value to the business and is achievable in comparison to alternative proposal submitted, Track and measure the progress and achievements of the business case, Ensure that projects with inter-dependencies are undertaken in the optimum sequence
Content of a Business Case, Reference, Project name/reference, Origins/background/curr ent state, Context, Business objectives/opportunities, Business strategic alignment (priority), Value Proposition, Desired business outcomes, Business benefits, Quantified benefits value, Costs, ROI Financial scenarios, Risks / costs of not proceeding, Project risks (to project, benefits and business), Focus, Problem/solution scope, Assumptions, Constraints, Options identified / evaluated, Size assessment, Scale assessment, Complexity assessment, Deliverables, Outcomes, deliverables and benefits planned, Organizational areas impacted (internally and externally), Key stakeholders, Dependencies, Workload, Approach, Phase/stage definitions, Project activities, Technical delivery activities, Workload estimate/breakdown, Project plan, Project schedule, Required resources, Project leadership team, Project governance team, Team resources, Funding, Commitments, Project control, Reporting processes, Deliverables schedule, Financial budget/schedule
Quality attributes of a Business Case, Accountable, commitments for the delivery of benefits and management of costs are clear, Adaptable, adjusted to the size and risk of the proposal, Business oriented, concerned with the business capabilities / impact, Consistent, every project addresses the same basic business issues, Transparent, key elements can be justified, Understandable, the content is clear, relevant and logical
Procedure of building a Business Case, 1. Identify and quantify the benefits, Measure the benefits of the recommended solution {qualitative and quantitative gains to the enterprise)., Benefits should be quantified., Benefits of a non-financial nature should be listed., Estimates should be linked back to strategic goals., 2. Identify and quantify the costs, Estimate the total net cost of the solution., Estimate:, Capital expenditures for the new investment, Costs of developing and implementing the change, Opportunity costs of not investing in other options, Costs related to changing the work and practices, Total cost of ownership to support the new solution, 3. Prepare the Business Case, Develop the Business Case at the appropriate level of detail., Remember it should demonstrate project viability and secure a go/no go decision., 4. Determine the measurement process for the costs and benefits, Describe how the benefits will be assessed and evaluated., Build a plan for benefit measurement and reporting.
Sample structure of a Business Case, 1. Executive summary, 2. Introduction and summary, Project rationale for preferred option, Current business process, Description of the problem, Opportunity, Project objectives, Project scope, Business benefits, Project costs, Assumptions, Potential business and staff impact analysis, Potential technology impact analysis, Implementation plan, 3. Approach, Financial metrics, Privacy impact assessment, Alternative evaluation criterion, 4. Key selection criterion, Weighting, Constraints and limitations, 5. Preferred alternative, Business benefits, Alternative costs, Assumptions, Potential business and staff impact analysis, Other issues, 6. Risk Management Plan, Risk assessment, Risk response, Benefit realization, 7. Conclusion and recommendations
A base for establishing the scope of the project (project planning).
A base for detailed requirements development.
Based on the product/solution scope; the project manager determines the cost and duration of the project.
Work Breakdown Structure (WBS), A decomposition of work required to complete a project.
Product Breakdown Structure (PBS), A decomposition of the components of the product.
System Interface Analysis, Work required to integrate the new solution into the business and technical environments.
Use Case Diagrams allows to present the boundary of the solution.
Shows the connections with external systems and actors.
Defines a quality model with 6 categories, Efficiency, Functionality, Maintainability, Portability, Reliability, Usability
Recommended Practice for Software Requirements Specifications
Guide for Developing of System Requirements Specifications
Guide for Information Technology - System Definition
Business Analysis provides input information to the following processes:, Project management (scope planning, scheduling and estimating development and testing), System analysis, Design (system specification and architecture), Implementation -Testing
Roles affected by a Business Analysis:, Project manager, Developers, System analysts, QA and Testers, Architects
Requirements Communication, Ongoing, iterative activity., Done in parallel with Requirements Elicitation, Analysis and Documentation., Includes:, Presenting, Communicating, Verifying, Gaining approval of the requirements, The main purpose of planning the Business Analysis communication is to define:, How to receive, distribute, access, update and escalate information to and from project stakeholders., How to organize schedule and structure of communication within a project.
Communication Planning, Business Analysis activities/deliveries can be communicated in formal and informal way., Communication activity should consider what kind of issues to be communicated:, Changes, Consequences, Information, Needs, Risks, Common ways of communication:, Documentation, Formal review, Informal review, Presentation, Workshop
Elements of Requirements Communication, Requirements communication plan, Managing requirements conflicts, Selecting the appropriate requirements format, Creating a requirements package, Requirements presentation, Formal requirements review
Requirements communication plan, How and when the BA will work with project stakeholders., On small projects it may be very brief and may not be formally documented., On large and complex projects it may be included as part of the project initiation documentation.
Goal, The goal is to define appropriate Requirements Engineering strategy, planning and estimation.
Determines the main activities and roles.
Includes definingthe process of managing Change Requests.
Factors to be considered in planning, Type of project:, Different projects types require a different amount of documentation, different processes and result in different deliverables., Small projects - basic documentation, communication may be partially informal, Complex, international project - more documentation and effective communication. Information is distributed to many teams, Communication formality:, Communication formality varies between projects, projects' phases and stakeholders., More formal when:, The project is large, Its domain is complex, The project is be critical or strategic, The project is dependent of legislation or sector standards or agreements, Communication frequency:, Communication frequency will differ among stakeholder for every form of communication., Communicating Business Analysis's deliveries usually follows a schedule:, I.e. Completing, reviewing and distributing of a requirements specification can be a project's milestone., Frequency of the status meetings, review meetings etc. is defined in communication plan, together with the people / roles involved., Geographical location:, Geographic disparity as a factor limiting communication possibilities., When stakeholders live in different time zones communication (calls, team meetings) must be adjusted to the capabilities., Culture:, Especially important in case of international projects., Culture may determine the preferred form of communication (e-mails instead of calls, face-to-face meetings instead of e-conferences).
Inputs for the Requirements Engineering, Business Analysis approach, Overall approach used by an organization to derive the Business Analysis processes., Business Analysis plan, Defines what deliverables (like requirements specification) will be produced and when., Organizational process assets, A set of standard templates of processes existing in an organization.
Process, Non-core process concerning all disciplines of the systems development:, Identification of requirements (Elicitation), Analysis of requirements, Specification of requirements, Changes of requirements, Quality assurance (with Verification and Validation)
Factors affecting communication, Availability of resources, Complexity, Organizational maturity, Organizational culture, Organizational standards, Stakeholders preference
Repository, The purpose of repository is to store requirements with theirs statuses., Repository allows to group requirements (i.e. by status):, Underdevelopment, Under review, Approved, Changed
Traceability, The process of tracing requirements is defined by the Business Analyst., The process has to be tailored to complexity of the project domain, stakeholder's needs, potential risks and available resources.
Selection of requirements attributes, Custom requirements attributes allow to include more detailed information in the description of requirements and to analyze them., The attributes need to be planned and determined in the Requirements Elicitation phase.
Requirements prioritization, Requirements are not equal for stakeholders and don't have the same value for project success., Priority as a factor of importance and impact should be determined by the Business Analysts along with proper stakeholders.
Configuration and Change Management, Configuration Management allows to identify and manage so called Configuration Items. A Configuration Items may be:, Single requirement, Requirements specification, Change Management is a process designed to track, identify and manage changes.
The purpose of Configuration Management is to establish and maintain the integrity of the products (components, data and documentation) of the software artefacts within the project and product life cycle
Configuration Management is a discipline applying technical and administrative tools and techniques to [IEEE 610], Identify and document the functional and physical characteristics of a configuration item, Control changes requested to those characteristics, Record and report change processing and implementation status, Verify compliance with specified requirements
It allows managing changes in the requirements in an effective way
Change Management is a subdiscipline of the Configuration Management
Configuration Item, An artifact, document, product (hardware and / or software) that has an end-user purpose and designated for Configuration Management and treated as a single entity in the Configuration Management Process ' [IEEE 610], e.g., Single requirements, Business needs, Requirements specifications, Business cases, Models, …
Baseline, A baseline is a stable well- defined set of attributes that serve as a comparison for system change, A system baseline is any set of system attribute specifications that formally define the state of a system, under specified conditions
The process of Configuration Management includes the following activities:, 1. Configuration Identification, The purpose of Configuration Identification is to determine the attributes that define every aspect of a configuration item, The attributes are recorded in configuration documentation and baselined, 2. Configuration Change Control, Configuration Change Control is a set of processes and approval stages required to:, Change a configuration item's attributes, Establish a new baseline for changed item, 3. Configuration Status Accounting, Configuration Status Accounting is the ability to record and report on the configuration baselines associated with each configuration item at any moment of time, 4. Configuration Audits, Two types of Configuration Audits, Functional Configuration Audit, Ensures that functional and performance attributes of a configuration item are achieved, Physical Configuration Audit, Ensures that a configuration item is installed in accordance with the requirements of its detailed design documentation
Change Management Process:, 1. Identification of potential change, 2. Requesting new functionality, 3. Analysis of the change request, 4. Evaluating the change, 5. Planning the change, 6. Implementing the change, 7. Reviewing and closure of the change, 8. Roll out of the change
Change Request, An official document requesting modification of existing features, requirements or functions or new ones, Description of the current solution, Justification for a change, Suggested (desired) solution, Priority
Example of a Change Management, Defect report, Analysis of the report, Comparing with the specification, Discovering the mistake in the specification, Closing the defect report, Submitting a change request, Analysis of the change request, Approval of the change request, Implementation of the change request, Testing the implemented change, Change closure
Sources of a change, Defects found in the code, documentation, requirements, Business process improvement, System improvement efforts, New or changing requirements, External changes (regulation, law changes)
Planning of change implementation, Updating plans: Project Plan, Development Plan, Test Plan, Updating business and system documentation, Updating test cases and test scripts, Implementing the change (coding), Testing by vendor or / and customer test team, Deploying the change to production environment (if applicable)
Change Life Cycle, Possible statuses, Submitted, Open, Approved, Rejected, Deferred, In implementation, Implemented, In testing, Tested, Closed
Change Control Board (CCB), A group of people responsible for evaluating and approving or disapproving proposed changes to configuration items, and for ensuring implementation of approved changes [IEEE 610], Project manager, Business analysts, Development team, Quality assurance team, Business manager, Customer
Categories of tools, Text processing, Table calculations, Modeling tools, Tools for Requirements Management, Process simulation tools, Configuration Management tools, Change Management tools
Factors affecting tools selection, The goal of the initiative, Different tools for extending existing solution, different for process optimization, The type of planned solution, Enterprise software vs. Entertainment software, Designing software vs. Improving business process, Organization's IT infrastructure, The scope of the solution, The complexity of the solution, Number of requirements, Dependencies between requirements, Traceability requirements, Standards and norms to be applied, Experience and skills of the project team
Common Business Analysis techniques, Brainstorming, CATWOE, Data Flow Diagrams, Five Why's, Functional, decomposition, Interviews, MoSCoW, MOST, PESTLE, Prototyping, Requirements, Workshop, Risk Analysis, Scenarios and Use Cases, SWOT, User stories
Primary role of the BA is to provide business solutions to business issues by assessing business problems, and identifying root causes
Required to, Assess business problems, Find the most appropriate solution, Provide measurement framework
Having domain knowledge allows the Business Analyst to connect and communicate with Business Users
Lack of domain knowledge may lead to delays in providing the solution
Domain knowledge makes understanding and analyzing of business issues easier
Analytical skills, Financial analysis, Statistical analysis, Operations research, Requirements analysis, Systems analysis
Managerial skills, Project management capabilities, Understand organizational behavior
Technical skills, Working knowledge of science, Understanding of engineering principles, Ability to apply financial principles to feasibility studies
Soft skills are necessary
Business Analyst's job requires communication and cooperation with various people
Common Business Analysis activities, Negotiation, Discussion, Conflicts solving
Negotiation skills, Negotiate to obtain data, Negotiate to resolve conflicts, Negotiate to agree requirements
Facilitation skills
Communication and writing skills, Communicate with all levels of management, Communicate with stakeholders of various knowledge, Precise in articulating ideas and thoughts, Relate with line workers, Good technical writing skills, Familiar with all forms of communications, Public speaking skills
Facilitation is the process of enabling groups to work cooperatively and effectively
It is a way of providing leadership without taking the reins
A facilitator is a person who contributes structure and process to interactions so that groups are able to function effectively and make high-quality decisions, The goal - to support others to achieve high performance
Facilitator's tasks and activities, Helping the group to define the goals and its objectives, Providing processes helping to use the time effectively and make high-quality decisions, Guiding group discussions, Documenting main ideas and concepts raised during the discussion, Supporting people in assessing their current skills and building new skills, Using consensus to enable the group to make agreed decisions, Managing conflicts, Helping the group to communicate effectively, Helping the group to access resources needed to make decisions
Key competences, Communicates well, Processes ideas from people, Shows a natural interest Listens well Maintains control Empowers the group Handles uncertainty, Is quick to connect with the group, Systems Analysis & Design, Manages people's expectations, Understands and constantly explains the process, Focuses on the business not on their own solutions, Communication skills Negotiating Group dynamics Listen / draw conclusions Running meetings, The facilitator must always stay neutral and stay on track
Tools and techniques, Engagement Strategies, Creating Participation, Generating and Organizing Data, Ignite Action, Mobilizing Energy, Initiating Reflection, Recording Techniques, SWOT, Gap Analysis, Flipcharts, Checklists, Brainstorming, Root-Cause Analysis, Multi-Voting, Focus Group Framework, Managing Conflicts Tips Sheet
Achieving competitive advantage over other companies is more and more difficult
Traditional products and services do not guarantee a success on the market
Innovation as a tool helping the organization to achieve competitive advantage
Innovation, Innovation is the process of renewing something that exists, Innovation requires, Changing the way people make decisions, Doing things differently, Making choices outside of the norm, Innovation changes the values onto which the system is based, Types of innovation, Radical (breakthrough, destructive), Using or introducing new technology, Changing an existing market or creating a new one, Incremental (conservative, sustaining), Based upon existing knowledge and technology, Introducing small changes, Enabling short-term competitive advantage, User Innovation, The author of innovation is the end user who develops or refines acquired products and services at the site of use, Users share their ideas and solutions with the producer, Called as "free revealing"
Innovation vs. Invention, Innovation is not the introduction of something new - it is not invention but changing something already existing by adding values into it
Triggers for Innovation, No clear boundaries of the business, Organizations extends the business area (the offer) and the geographic area of activity using other communication and distributions channels, More demanding customers, Customers require a product, Of high usability, Compatible with other products, That makes them feel comfortable, Customer needs and expectations are on the first place, Customer's satisfaction as a success factor, More effort to meet the customer's requirements, The customer should be positively surprised and willing to come back to buy more products / services, More interest in integrated systems of, Products, Software, Services working as a single whole, Integrated systems as keys to expansion beyond core areas of the business, A way to meet customer expectations impossible to achieve by more isolated offering, Questions without any answer, Problems without a solution, Who finds the right answers or working solution firsts can achieve competitive advantage
Areas of application, Products, Introducing new merchandise to the market, Processes, New, better way of achieving something is introduced, Behavior, How people live their lives, perceive reality or achieve their goals
Categories of innovation, Degree, Disruptive innovation, Line extension innovation, Scope, Application innovation, Enhancement innovation, Business area, Product innovation, Process innovation, Source, Organic innovation, Acquisition innovation
Design, The specification of an object intended to accomplish goals in particular environment, A process which produces such specifications, A term often linked with innovation, From business perspective design is the process which allows the company to achieve a competitive advantage, Design supports achieving a competitive advantage by, Solving users or customers problems in the creative way, Creating unique value and unforgettable user experience, Joining functionality, aesthetics, ergonomics and user experience with the form, Distinguishing the company
Market Research, A structured activity with the purpose to gather information about markets or customers, Important component of business strategy
Market Analysis, A structured and documented investigation of a market, Determines if there is a need or audience for a product / service, Provides information about market's needs and how it is currently serviced, Useful to plan, New products, An expansion of the business, Dimensions of a Market Analysis, Market size (current and future), Market growth rate, Market profitability, Industry cost structure, Distribution channels, Market trends, Key success factors
Market Research and Analysis process, Problem definition, Analysis of the situation, Obtaining data and information specific to the problem, Information analysis and interpretation, Formulating ideas and solution of problem
Techniques for collecting market data, Qualitative research, Quantitative research, Customer feedback, Mail questionnaire, Telephone / Personal Interview surveys, Observation, Direct work with the end users on site
Trend, Trend is a tendency of a market (or specific product or service) to move in a particular direction over time, Market Research together with Market Analysis allows to determine Market Trends, Analyzing the trends allows to predict the desired future solutions
Design Thinking, A methodology for practical, creative resolution of problems or issues that look for an improved future result, The collaborative process by which the designer's sensibilities and methods are employed to match people's needs with what is technically feasible and a viable business strategy
Design Thinking is a team oriented discipline
Design Thinking converts need into demand
Three major phases, Inspiration, The main goal is to gather insights from customers, Insights are to be used as the basis for inspirations, Inspiration phase is performed from the user / customer perspective, No business constraints, Results of the inspiration phase, The target of the project, Understanding of the problem from organization and customer perspective, Insights, Knowledge about the opportunities and constraints, Documentation of the research, Pictures, Movies, Ideation, The goal is to analyze insights and turn them into ideas, The ideas become a part of the solution, New ideas should not be judged or rejected, even if they seem to be contradictory, Questionable ideas may be a source for further inspiration, The result of the ideation phase - the decision which ideas become part of the final solution, Tools for ideation, Stories, Sketches, Prototypes, Implementation, Precondition: ready and more or less stable prototypes of solutions, The goal is to convince the stakeholders that proposed solutions meet their expectations and guarantee success after release to the market, Sample tool - storytelling
Multidisciplinary teams, Team consisted of people from various, often completely different functional areas, The teams is organized around the problem rather than a leader, Beneficial for, Making observations, Gathering insights, Generating ideas
Multi-vector research, An approach for analyzing all available points of view or sources of information, Procedure, Synthesize the vectors to uncover insights, Create a number of vectors to research H the problem from several directions, Typical vectors used in Multi-Vector Research, Customers, Competitors, Organization toolbox, Technology, Sales and Retail, Trends
Persona, Persona is a fictional character representing the different types of users, Persona represents a group of people with the same, Needs, Attitude, Behavior, Expectations towards the product, Sample personas in innovation process:, The Anthropologist, True observer of the human nature, The Experimenter, Prototypes, experiments and improves the solution using trial and error process, The Cross-Pollinator, Analyses other industries and cultures to gather findings that can be used in benefit of an enterprise, The Hurdier, Removes the obstacles waiting to delay or stop innovation from happening, The Collaborator, Organizes, supports and trains the project team, The Director, Builds the innovation culture in the organization encourages people and leads them towards his vision, The Experience Architect, Delivers the product to the customer, The Set Designer, Provides workplace with the best conditions for creative work, The Caregiver, Keeps the focus on the customer and anticipates his needs
Insights, Customer insights are the basis for the inspiration and innovation, The main idea - whatever is examined it should be examined from customer's point of view, Sources of insights, Customers and their feelings, needs, values and problems, Extreme users and outliers, children, seniors, Trends and general trends, Competition, Technology, Complementing and comparable organizations
Brainstorming, Technique used for generating of a large number of ideas for the solution of defined problems, A session involves a group of people, Members have different knowledge and experience, Brainstorming sessions should be rather facilitated than moderated, Rules applying to brainstorming sessions, Avoid judgment and criticism towards ideas of other team members, New ideas can be built on the ideas provided by others, Do not focus on the quality of the ideas, but on the quantity, The goal is to collect many various ideas
Prototyping, Encourages iterative approach to the problem solution, Using prototypes allows, Better explain and present ideas or solutions to others, Come up with new ideas, Test the solution, Gather the feedback from the stakeholders and customers
Enlightened trial and error, Trial and Error - the process of obtaining knowledge by generating solutions, testing them and learning from own mistakes, The testing is performed with the prototypes, The main idea: "Fail often in order to succeed sooner"
Storytelling, A persuasive technique used to convince the other side to the arguments of the storyteller, Stories, Based on assumptions or the real situations experienced during the research phase, Wrapped around the product, user and user's experience, The main idea: "show, don't tell", Tools, Pictures, Videos, Sketches
Working with the user allows to, Identify the user's needs, Support the users in formulating the needs, Explore the needs and determine requirements, Provide the user with suggestions how to improve the desired solution


text:
This Baseball Prospectus
piece by Joe Sheehan comes at a convenient time:I feel like
I write more about umpires than many people do, and it's because I feel
strongly that what happens on the field isn't subject to interpretation. If a
player's foot hits a base before a glove with a ball in it touches that player,
that player is entitled to the base, he's safe, and that doesn't change because
some middle-management functionary says otherwise. If a breaking ball crosses
the plate at a point between a batter's knees and the midpoint between his
shoulders and pants, it's a strike, no matter what the anachronism behind the
plate thinks he sees. In eighteendicketysix, a human being was state-of-the-art
technology for making these decisions. Now, you can get better information-we
do get better information-by using better technology. Championships should be
decided by the players and by what actually happened, not by what somebody
thinks happened....I wonder if
"Don't Call Me Bill" Bucknor has read it.Curt
Schilling told
us this would happen. "[T]hat might be the worst umpiring crew in the
history of post season baseball. Bucknor, Gibson AND Merriweather? Oh and Joe
West, the umpire who is well known to hate the Sox as much as any man ever."In the Phoenix this week, I
lament the
death of accountability, wondering why so very few people are held to task
for what they do or say anymore.What does
it take, when the first base umpire is so blind he cannot see a first baseman tag
the bag before the runner — contact that couldn't have been made plainer if
he'd "squatted
down and laid an egg on it" — for that man to be penalized somehow?"This is a
joke," wrote
another SoSHer after the 3,745th blown call. "Even the NBA would have put a
lid on this now. Is Mike
Port just pissed or does
Selig actually have no power?"Oh well,
maybe it's enough that one fifth of major leaguers think he's the worst ump
in the game, so, uh, maybe his feelings are hurt.Props, at
least, to Youkilis for keeping
his cool. Cold
comfort, I suppose, that this shit happens to everyone?Look, bad
umpiring did not cost us this game. Lackey threw the ball better than Lester
did. David Ortiz whiffed three times. The Greek God of Walks, couldn't see fit
to remove the bat from his shoulder at a crucial juncture of the game. And a
bunch of other stuff.(For one
thing, we really don't
seem to like playing on the road very much.)Still, as
this fascinating breakdown
points out, dumb
umps did more damage than you might've figured.And if the
Angels don't beat the Red Sox — which, truth be told, seems likely at this
point — and the Red Sox don't beat themselves, it seems entirely possible that
the umpires will take that responsibility upon themselves sooner rather than
Schilling predicted: "Greg Gibson will have major impact on one or more
games this post season. The obvious choice would be for the game(s) he's behind
the plate, and I can assure you I'd lobby to not be on the mound for that
game."He's not behind the plate tonight. But guess who is!In much
better news, the Phoenix
is giving away copies of the new Dustin Pedroia book, Born to Play.Enter
here to win! Hopefully you won't have time to read it until November 6.

subset: commoncrawl


text:
ED Magedson – Founder
Ripoff Report
Scoresence.com8144 Walnut Hill Ln, Suite 510 Dallas, Texas United States of America
Does your business have a bad reputation?
Fix it the right way.
Corporate Advocacy Program™
This report was posted on Ripoff Report on 10/02/2012 02:34 PM and is a permanent record located here: http://www.ripoffreport.com/reports/scoresencecom/dallas-texas-75231-0987/scoresencecom-dba-2211-partners-free-credit-report-not-free-dallas-texas-949858. The posting time indicated is Arizona local time. Arizona does not observe daylight savings so the post time may be Mountain or Pacific depending on the time of year.
Ripoff Report has an exclusive license to this report. It may not be copied without the written permission of Ripoff Report. READ: Foreign websites steal our content
Click Here to read other Ripoff Reports on Scoresence.com
If you would like to see more Rip-off Reports on this company/individual, search here:Search Tips
In order to assure the best results in your search:
Advertisers above have met our
strict standards for business conduct.


text:
You'll find plenty of vampire costumes for adults among the many Gothic and steampunk costumes that Costume Craze has to offer. And if the whole family decides to go out as a clan of vampires, we've got you covered with some of the cutest kids' and baby vampire costumes on the Internet. Your little baby bloodsucker will be adorably spooky in a Dracula costume! Vampires are especially popular with teens, and we have so many stylish looks to choose from, including costumes based on Monster High. … more
Vampire Costumes
With legends dating back to the mid-1400s, vampires have been the main characters of horror stories and nightmares for generations. Bram Stoker's Dracula was the book that helped usher the vampire wave into infamy, and it continues to help make vampire costumes one of our most popular Halloween costume options. Whether you want to celebrate Halloween in classic fashion with a Dracula costume or go for a more modernized and stylish appearance, we have whatever you need in our selection of vampire Halloween costumes.
If you've got questions about sizing or styles, be sure to consult with our customer support staff over chat. They can quickly guide you away from the garlic and help you find the most realistic vampire costumes and accessories. Make sure to check out our selection of capes, walking sticks, hats, stockings, gloves, and more. Don't forget your fangs! And a little bit of blood couldn't hurt, either. We have everything you need to form complete vampire costumes for adults.
Whether you want to look like Edward Cullen or a sexy female vampire, we've got a wide selection of affordable vampire costumes that we know you'll bite for. A word of caution, though: When people see you slinking through the shadows in one of our vampire Halloween costumes, they may just believe that you're the real deal. Costume Craze takes no responsibility for any vampire hunters you encounter! But if you do want to look like you just climbed out of your coffin, there's no doubt that we are your one-stop costume shop, and with our 115% low price guarantee, our deals can't be beat.


text:
The Russian connection: See all our coverage | Read about our investigation
A blackcurrant drink produced by drug giant GlaxoSmithKline was advertised as having way more Vitamin C than it actually does. What's cool is that the independent investigation was conducted by two 14-year-old girls for a science fair project. As Seed Magazine reports, New Zealanders Anna Devathasan and Jenny Suo tested the Vitamin C content of eight juices, with most matching their advertised C content. But Ribena, which claimed to have four times as much Vitamin C as oranges, fell far short. The teens tried to contact the company directly, but failed to get a response. So they went to a consumer affairs TV show and then the Commerce Commission. After two years, GlaxoSmithKline finally admitted breaching the Fair Trading Act. They'll pay a fine and change the labeling on the drink. Tch tch. How about detention?--Julia Whitty


text: 8/14/08 8/14/08 POPSUGAR Beauty POPSUGAR Celebrity Mary Tyler Moore August 14, 2008 by Beauty 0 Shares Chat with us on Facebook Messenger. Learn what's trending across POPSUGAR. View on One Page Photo 1 of 11 ADVERTISEMENT () Share This Link Copy ← Use Arrows Keys → 1 Mary Tyler Moore Take a trip through time to see Mary's looks from the 1960s to today. Previous Next Share this post


text:
Social activist Anna Hazare on Saturday announced a new-look "apolitical" team that included some of his old colleagues who did not join former aide Arvind Kejriwal's political outfit.
Former army chief General VK Singh, however, is yet to formally join the group.
"Today, there was a meeting among 13 old members of our group for over five hours. Soon, there will be a national campaign against corruption. I will start a nationwide tour from January 30, 2013," Hazare said.
Asked whether he had invited General Singh to the meeting, Hazare replied: "I had sent an invite to General Singh, but he could not attend due to some problem. He will meet me later."
The first list of committee members did not include the names of activists PV Rajagopal, Rajinder and Devender Sharma, who were associated with the erstwhile Team Anna.
Hazare, however, announced the constitution of a 15-member coordination committee, which included Justice Santosh Hegde, Kiran Bedi, Medha Patkar and Akhil Gogoi.
Former Punjab police chief Shashikant and former IAS officer Avinash Dharmadhikari were the new faces in the team.
Hazare said that within a month, the coordination committee would be expanded through the inclusion of around 40 additional members.
On the controversy surrounding the use of the 'India Against Corruption (IAC)' title, Hazare said he would like to avoid a confrontation with Kejriwal's party.
However, he would take the title if Kejriwal chooses to give it, the activist added.