Business Analysis Cheatsheet

Business Analysis Cheat Sheet
by Natalie Moore (NatalieMoore) via cheatography.com/19119/cs/9837/
What is Business Analysis? Role of BA in project phases (cont) What is a Business Goal? (cont)
The practice of enabling change in an Analyzing and documenting change - It keeps a clear picture of what the
organizational context, by defining needs requests for the requirements organization is trying to do with the
and recommending solutions that deliver Processing new requirements (new regula‐ business, and helps focus motivation
value to stakeholders. tions, standards, etc.) - It allows the organization to understand
disciplined approach Processing the requests to fulfill new needs and maintain a commitment to the
Business analysts identify and define the requested by the customer or user business’ main objectives
solutions that will maximize the value - It provides a metric against which to
delivered by an organization to its stakeh‐ What is an artefact? measure the organization’s progress
olders SMART
Final or intermediate work products that are
Business analysts work across all levels of produced and used during a project SMART is a system and a tool that is used
an organization and may be involved in to establish goals and define their quality
Might describe the function, architecture,
everything from defining strategy, to objectives. SMART requires that all goals
and design of software
creating the enterprise architecture, to have the following characteristics
Might be concerned with the process of
taking a leadership role by defining the
development itself, such as project plans, - Specific
goals and requirements for programs and
business cases and risk assessments - Measurable
projects or supporting continuous improv‐
ement in its technology and processes. Should use version control - Attainable
Business Analysis is the set of tasks, Should be correctly traced to their origin - Relevant
knowledge, tools and techniques required to - Timely
identify business needs and determine What is a Business Goal?
solutions to business problems [BABOK] A Business Goal is a short- or long-term What is a requirement?
BA Solutions may include: objective of an organization. Business
A condition or capability needed by a
Goals should be characterized by the
- Development of software systems stakeholder to solve a problem, or achieve
following qualities
- Development of software components an objective.
- Specificity
- Extensions of existing software A condition or capability that must be met or
- Optimism possessed by a system or system
- Improvements to the business process
- Realism component, to satisfy a contract, standard,
- Changes to the organization
specification, or other formally imposed
- Both short- and long-term scope
documents
Role of BA in project phases Setting Business Goals is important
A documented representation of a condition
because:
Supporting implementation work in order to or capability
ensure developers understand and - The organization needs to have a vision
Requirements are the foundation of
implement the requirements properly of what it wants to accomplish. This is
systems, or system components. They can
facilitated by having clearly stated goals,
Business Analyst supports the project from be obligatory (required functions, constr‐
along with establishing time periods in
the beginning through the system aints, etc.), essential for the software to
which they need to be achieved
deployment (and sometimes to the system perform its functions, and meet the expect‐
retirement). ations and needs of the intended stakeh‐
Supporting testing, for example by olders
validating test cases in order to ensure that
testing will adequately cover all the requir‐
ements
By Natalie Moore Published 16th November, 2016. Sponsored by Readable.com

(NatalieMoore) Last updated 16th November, 2016. Measure your website readability!
Page 1 of 15. https://readable.com
cheatography.com/nataliemoore/
www.jchmedia.com/
What is a requirement? (cont) What is a requirement? (cont) Requirement Analysis (cont)
Requirements should be placed into one of - Customer requirements Capture and assess these requests
the following categories - Solution or system requirements Outputs: Assumptions and Constraints
- Business requirements - Product or component requirements Task: Verify Requirements
- User requirements Outputs: Verified requirements
- Functional requirements Requirement Analysis
Task: Validate Requirements
- Non-functional requirements Elaborate the solution definition in order to
Validate that a requirement will satisfy a
enable the project team to design and build
Purpose of requirements: business need.
a solution that will meet the needs of the
- Provide a foundation for assessment, Outputs: Validated requirements
business and stakeholders
planning, execution and monitoring of
Task: Organize Requirements
the project activities Elicitation
Structure and organize a set of requir‐
- Define customer expectations Business Requirements Elicitation is
ements into logical sets. The organization
(expressed as real requirements and defined as a set of approaches, techniques,
may be based on defining multiple “levels”
stakeholder’s value of those requir‐ activities, and tasks used to capture the
of requirements, packaging related
ements) business requirements of a planned solution
functions together, and so forth.
- Serve as a component of agreements, from the stakeholders and other available
Inputs: Business Case, Solution Scope, sources [
orders, project plans
Requirements
- Establish system boundaries, scope of Purpose: Explore, identify and document
Outputs: Structured requirements stakeholder needs. Orienting the requir‐
delivery, and the services classification
of the requirements Task: Prioritize Requirements ements toward the project vision. Excluding
Determine the business priority of requir‐ features that the customer does not want
Requirement classifications
ements (including voting, ranking, benefit and need
Process requirements
analysis and so forth). Identify logical Describes how we work with stakeholders
- describe needs and limitations of the
dependencies between requirements and to find out what their needs are and ensure
business processes
requirements packages. that we have correctly and completely
- Costs understood their needs.
Inputs: Requirements, Business Case
- Marketing Task: Prepare for Elicitation
Outputs: Prioritized requirements
- Processing time Purpose: Prepare for elicitation by ensuring
Task: Specify and Model Requirements
- Sales and distribution all needed resources are organised and
Describes standard practices for writing
- Organisation scheduled for conducting the elicitation
textual requirements and creating models or
activities
- Documentation diagrams. Specific models are addressed
as techniques. Includes capturing the Outputs
Product requirements
requirements attributes - Scheduled resources
- functional and non-functional product
requirements Inputs: Requirements - Supporting materials
- POV of customer and team Outputs: Specified or modeled Requir‐ Task: Conduct Elicitation
ements Meet with stakeholder(s) to elicit inform‐
Types of requirement
Task: Determine Assumptions and Constr‐ ation regarding their needs
aints Outputs
Identify stakeholder requests that are not Elicitation activity results
properly requirements but based on
Assumptions, constraints, risks, issues
assumptions regarding what the solution
team is capable of delivering

www.jchmedia.com/
Elicitation (cont) What is a stakeholder Business Analysis Communication

Planning
Documentation based on technique (e.g., Any person involved in, or with an interest
interview notes, workshop results, survey in, a project The main purpose of planning the Business
responses, etc.) Stakeholders on the vendor side Analysis communication is to define how to
Task: Document Elicitation Results receive, distribute, access, update and
Project Managers
escalate information to and from the project
Purpose: Record stakeholder info for use in Business and System Analysts
stakeholders, as well as how to organize
analysis.
Developers and Architects the schedule and structure of the commun‐
Outputs: Stated requirements
Database designers ication within a project.
Task: Confirm Elicitation Results
GUI designers Business Analysis is the starting point for
Purpose: Play back the requirements to designing and implementing a software
Technical writers
validate that the stakeholder’s intentions solution. Its deliverables are inputs to many
Testers and Quality Assurance staff
have been correctly captured and unders‐ other project phases and processes, such
tood. Installation and Operations personnel as establishing the system architecture that
Outputs: Validated stated requirements Stakeholders on the customer side will allow meeting the business goals,
Customer representatives (i.e., “Business”) creating detailed functional and non-funct‐
Techniques
ional system specifications, and planning
Questionnaires Project sponsors
and executing QA activities.
Interviews End users (from the customer company)
Outputs from the Business Analysis are
Self-recording Installation and Operations personnel
also inputs to system acceptance testing,
Reviewing existing documents External stakeholders may be: which is the final check before the
Reusing a specification from a previous End users who are not a part of the production release.
project customer’s organization System acceptance testing is conducted to
Brainstorming Other organizations (e.g., regulatory verify that the software is working as
entities) expected, and is needed in order to realize
Field observation
its goals (i.e., improving efficiency of
Apprenticing
Stakeholder Identification Problems performing the business process
Conducting workshops to refine the requir‐
A lack of understanding of the real BA provides info to the following
ements after each iteration
operators of the business processes in the - Project management (scope planning,
Requirements Elicitation should apply to
organization scheduling, and estimating development
enterprise requirements as well as user or
Unclear definition of responsibilities within and testing)
customer requirements.
the customer’s organization - Systems analysis
Requirement characteristics
Excluding stakeholders who are not clearly - Design (system specification and archit‐
Functionality
and directly related to the process ecture)
Reliability
Incomplete analysis resulting in missing - Implementation
Usability processes and activities, and the related - Testing
Efficiency stakeholders
Common methods of communication
Maintainability include:
Portability - Workshops
- Presentations
- Reviews

www.jchmedia.com/
Business Analysis Communication Planning Principles for Successful Requirements Acceptance and Evaluation Criteria (cont)
(cont) (cont)
Acceptance criteria describe the minimum
Factors to be Considered 4. Quantify quality requirements as a set of requirements that must be met in
- Type of project basis for software engineering. order for a particular solution to be worth
5. Don’t mix ends and means implementing. They may be used to
- Communication formality
determine if a solution or solution
- Communication frequency 6. Capture explicit information about
component can meet a requirement.
value.
- Geographical location
Acceptance criteria are typically used when
7. Ensure there is “rich specification”;
- Culture only one possible solution is being
requirement specifications need much
evaluated, and are generally expressed as
more information than just the requir‐
Common BA techniques a pass or fail
ement itself.
Brainstorming Valuation criteria define a set of measur‐
8. Carry out specification quality control
CATWOE (Clients, Actors, Transformation, ements which allow for ranking of solutions
(SQC).
Worldview, Owner, Environmental constr‐ and alternative designs according to their
9. Consider the total lifecycle and apply
aints) value for stakeholders.
systems-thinking, not just a focus on
Data Flow Diagrams Attributes that cannot be measured directly
software
are evaluated using expert judgment or
Five Why’s 10. Recognize that requirements change;
various scoring technique
Functional decomposition use feedback and update requir‐
Elements
Interviews ements as necessary.
~ Value attributes ~
MoSCoW
Acceptance and Evaluation Criteria - are the characteristics of a solution that
PESTLE (P for Political, E for Economic, S
determine or substantially influence its
Acceptance criteria are used to define the
for Social, T for Technological, L for Legal
value for stakeholders
requirements, outcomes, or conditions that
and E for Environmental)
must be met in order for a solution to be - represent a meaningful and agreed-
MOST (Mission, Objectives, Strategies,
considered acceptable to key stakeholders. upon decomposition of the value
Tactics)
Evaluation criteria are the measures used to proposition into its constituent parts,
Prototyping assess a set of requirements in order to which can be described as qualities that
Requirements Workshops choose between multiple solutions the solution should either possess or
avoid
Risk Analysis Define measures of value attributes to be
used for assessing and comparing solutions examples
Scenarios and Use Cases
and alternative designs ability to provide specific information
SWOT
Measurable and testable criteria allow for ability to perform or support specific
User stories
the objective and consistent assessment of operations
solutions and designs
Principles for Successful Requirements performance and responsiveness charac‐
teristics
1. Understand the top level critical
objectives applicability of the solution in specific
situations and contexts
2. Think stakeholders, not just users and
customers availability of specific features and capabi‐
lities
3. Focus on the required system quality,
not just its functionality usability, security, scalability, and reliability

www.jchmedia.com/
Acceptance and Evaluation Criteria (cont) Acceptance and Evaluation Criteria (cont) Why is Business Analysis Necessary?
(cont)
~ Assessment ~ Acceptance criteria may express contra‐
In order to assess a solution against ctual obligations and as such may be - Instability of the requirements (frequent
acceptance or evaluation criteria, it must be difficult to change for legal or political and uncontrolled changes in requir‐
constructed in a measurable format reasons ements)
Evaluation criteria provide a way to Achieving agreement on evaluation criteria - Poor translation of the business needs
determine if features provide the value for different needs among diverse stakeh‐ to requirements (incomplete, incons‐
necessary to satisfy stakeholder needs. olders can be challenging. istent, or not measurable requirements)
The criteria are presented as parameters - Unclear objectives of the initiative

What is a business analyst?
that can be measured against a continuous - Communication problems
or discrete scale. A person responsible for:
- Language barriers
Acceptance criteria are expressed in a identifying the business needs of the
- Knowledge barriers
testable form customer (external or internal) and other
- Vague wording
stakeholders
Acceptance criteria are presented in the
- Overly formal wording
form of statements which can be verified as determining solutions to business problems
- Redundancy
true or false. This is often achieved through BA activities include identifying, analyzing,
user acceptance testing (UAT) developing and managing the requirements. - Gold plating (adding unnecessary
scope)
Usage Considerations Business Analyst is not responsible for
determining the solution implementation - Insufficient user involvement
Agile methodologies may require that all
requirements be expressed in the form of (creating the product’s design) - Overlooked user classes
testable acceptance criteria The Business Analyst acts as a bridge - Minimal specification
Acceptance criteria are necessary when the between the customer and other stakeh‐ Consequences of low quality BA
requirements express contractual obliga‐ olders (e.g., the project team), identifying,
- Problems during during scope definition
tions negotiating and achieving a consensus
- Planning difficulties
between the needs of the various represent‐
Acceptance criteria provide the ability to
ative individuals and groups. - Implementation problems
assess requirements based on agreed-upon
criteria - Testing problems
Why is Business Analysis Necessary?
Evaluation criteria provide the ability to - Unclear requirements, or low quality
assess diverse needs based on agreed- Problems with requirements can cause business design of the solution, can
upon criteria, such as features, common projects to fail. In most cases those lead to confusion and questions
indicators, local or global benchmarks, and problems are caused by poor or incorrectly regarding the intended software product
agreed ratios conducted Business Analysis (especially or process solution
Requirements Engineering, a part of the - risk of the project’s failure increases
Evaluation criteria assist in the delivery of
Business Analysis knowledge area).
expected return on investment (ROI) or - Requirements are imprecise
otherwise specified potential value Common problems
- Requirements are ambiguous
Evaluation criteria helps in defining priorities - Ambiguous, under-specified, unclear,
impossible, contradictory business
Limitations
requirements

www.jchmedia.com/
Why is Business Analysis Necessary? Traceability (cont) What is Enterprise Analysis? (cont)
(cont)
- Requirements (mapping the higher level Output: Defined Problem/Opportunity
- Requirements are contradictory requirements that defined the needs and Task: Determine Solution Approach
- Requirements do not fulfill the agreed features to the more detailed requir‐
Purpose:
criteria ements)
- Identify potential solutions
- Requirements are missing - Detailed requirements to design models
- Analyze feasibility of options
- Business processes and artifacts are - Detailed requirements to test cases
- Recommend viable business solution
not covered by requirements or are - High level requirements to test cases
- Validate with decision makers
described incompletely - Requirements to release/code
Output: Solution Approach
- All stakeholders are not identified branch/version
Task: Define Solution Scope
- Business goals or needs are not Allows BA to ensure all business requir‐
identified causing the designed solution ements have been met. Projects inevitably struggle at some point or
to fail to meet the organization’s needs the other if the scope is not defined properly
Important from the change management
and not achieve the business goals perspective, to determine the impact of a Solution scope may be determined using
Common reasons for neglecting BA change on the system or process the following techniques
- Time pressure For the testers and developers, traceability - Work Breakdown Structure (WBS) - a
ensures that the requirements coverage has decomposition of the work that is
- Exclusive focus on fast results
been achieved required to complete a project, and
- Exclusive fixation on costs
accomplish the business objectives
- Perceiving documentation or the
What is Enterprise Analysis? - Product Breakdown Structure (PBS) - a
analysis and understanding of the
Purpose: Identify and propose projects that decomposition of the components of the
business processes within an organi‐
meet strategic needs and goals. product
zation as a cost, not an added value
Task: Identifying business processes - System Interface Analysis - a definition
performed in the organization of the work required to integrate the new
Requirements Elicitation
solution into the existing business and
Requirements Elicitation is the collection of Purpose: Evaluate the internal and external
technical environments
activities, approaches, tools and techniques environment
Context diagram
for capturing the requirements for a planned Conducting feasibility studies to determine
software system (or other business solution) the optimum business solution Product Breakdown Structure
from the stakeholders\ Define/refine current/future business archit‐ Output: Solution Scope
ecture Task: Develop the Business Case
Traceability
Assess the current state of technology - Define project objectives and expected
Traceability is an association that exists (infrastructure and applications) business benefits
between different types of requirements and
Benchmark analysis - Develop project scope
the following items:
Competitive studies - Estimate time, cost, resources
Fully define business problem/opportunity - Analyze cost vs. benefit

www.jchmedia.com/
What is Enterprise Analysis? (cont) Solution Assessment and Validation (cont) Solution Assessment and Validation (cont)
- Evaluate risk Allocate requirements to hardware, Purpose:

- Inputs: Business Architecture, Business software, manual procedures, etc. - Assess the value of the solution as
Goal(s), Defined Business Problem/O‐ Recommend the release/delivery strategy deployed to the business (to determine
pportunity Solution Scope Understand trade-offs between different if the original goals are met).
- Outputs: Business Case implementation approaches - Compare actual vs. expected costs and
Inputs: Solution Design, Validated Requir‐ benefits.
Solution Assessment and Validation ements Outputs: Cost/Benefit Analysis
How to assess proposed solutions to Outputs: Allocated Requirements
determine which solution best fits the Stakeholder Identification Techniques
Task: Determine Organizational Readiness
business need, identify gaps and shortc‐ Investigating the business domain
Purpose:
omings in solutions, and determine
Identifying owners of the business
necessary workarounds or changes to the Determine organizational readiness to
processes
solution effectively operate the new solution
Analyzing the structure of the customer’s
How we assess deployed solutions to see - Conduct organizational readiness
organization
how well they met the original need in order assessment
Exploring the target market of the
to enable businesses to assess the perfor‐ - Recommend ways to optimize the
customer’s organization
mance and effectiveness of projects. organizational deployment
Analyzing relationships with external
Purpose: Assess solutions to ensure that Outputs: Organizational Readiness Assess‐
organizations (suppliers, etc.)
strategic goals are met and requirements ment, Organizational Change Recommend‐
are satisfied. ations
Stakeholder Needs and Expectations
Task: Assess Requirements Coverage Task: Validate Solution
Different stakeholders may have different
Purpose: Determine how well possible Purpose:
needs and expectations regarding the
options for solution designs will meet the Validate the verified and deployed solution
planned solution. It is very important to
requirements. The assessment may include meets the business need
identify all the stakeholders and their needs,
a recommendation of a particular solution,
Define acceptance criteria (including what and to find a common understanding of the
rejection of all solutions, or an assessment
level of conformance to requirements is purpose of a solution, in order to avoid the
of possible trade-offs.
acceptable) situation where the final product may meet
Examples: RFI/RFP responses, Internal
Identify defects/shortcomings (this should the requirements of only a selected group of
designs, Manual procedures
be distinguished from functional testing) stakeholders.
Inputs: Solution Design Option(s)
Analyze impact Ensure that the features to be implemented
Outputs: Solution Design Assessment will not conflict with the requirement of other
Define corrective actions
Task: Allocate Requirements stakeholders
Validate corrective actions
Purpose: Allocate requirements among One of the responsibilities of a Business
When a problem is identified with the
releases and/or solutions components. Analyst is to identify all the stakeholders
deployed solution determine what is the
Ensures that the possible release options and define their requirements and expect‐
most appropriate response
are designed in a way to maximize the ations
Outputs: Validated Solution, Defect Impact
possible business value given the options Determines the initial scope and requir‐
Analysis, Validated Corrective, Actions
and alternatives generated by the design ements of the system
team. Task: Evaluate Solution
Activities

www.jchmedia.com/
Business Case Definition Business Case Definition (cont) Requirements Documentation (cont)
Provides the reasoning for initiating a - Prepare the Business Case - Document acceptance
project - Define the procedures that will be used When creating a requirements document,
Describes a justification for the project in to measure the costs and benefits the Business Analyst should remember that
terms of the value added to the business as requirements specifications must be
a result of the project outcomes, in Requirements Documentation complete, consistent, modifiable, and
comparison to the cost of developing the traceable [Wiegers].
Follow common standards and guidelines
new solution Common Mistakes
Important guidelines
May be in form of Trivialities - Lengthy descriptions of
- Each requirement must be unambi‐
- Structured document commonly known issues should not be
guous, precise, and understandable
- Short argument included
- Superfluous information should be
- Presentation Information out of scope
avoided
Topics may include Thinking in solutions - The requirements
- Templates should be used as an aid
specification should discuss the problem to
- Information about the opportunity - Models and diagrams should be used to
be solved not the technical design of the
(market trends, competitors) make the specification document clear
solution
- Qualitative and quantitative benefits and more understandable for readers.
Redundant details
- Estimates of cost and time to breakeven - Formal graphical notation should be
Lacking rationale
used as a method for presenting
- Profit expectations
complex requirements, dependencies,
- Follow-on opportunities Modelling
and relationships
- Cash flow consequences of the action, Modeling is a way of expressing requir‐
A requirements document may include
over time, and the methods used for ements by representing parts, or the whole,
- Introduction
quantifying benefits and costs of the proposed solutions
- Secrecy clause
- The impact of the proposed project on Way of presenting complex requirements
the business operations or business - Regulations
and relationships in the form of a model,
process - Standards especially some graphical form such as
- The impact of the proposed project on - Stakeholders diagrams, helps ensure the solution is
the technology infrastructure understood by other stakeholders
- Purpose of the product
- Constraints associated with the Easier to read and comprehend than written
- Overall description
proposed project text
- Functional requirements
- Estimated budget Not mandatory but very helpful in big
- Non-functional requirements
- Alignment with priorities established by projects
- Limitations and assumptions
the business Can skip modeling in the following
- Dependencies situations
Procedure of Building the Business Case
- Risks - The solution is fully understood by the
- Identify and quantify the benefits
- Safety requirements stakeholders and is easy to implement.
- Identify and quantify the costs
- The requirements are mostly non-funct‐
ional 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

www.jchmedia.com/
Modelling (cont) Modelling (cont) Tools and Techniques of Facilitation
- The scope is declared as constant and - Relevance (no irrelevant details) Applying engagement strategies
there is a low probability of changes in - Economic efficiency (designed for a Creating participation
the scope resulting from future requir‐ particular purpose) Generating and organizing data
ements or needs.
- Clarity (understandable by the Initiating reflection
- model representation would be less audience)
Mobilizing energy
understandable by the key stakeholders
- Comparability (based on the same
than written text Igniting action
modeling conventions within and
Benefits of modeling Recording information
between models)
- simplified expression of real processes Applying SWOT analysis
- Systematic design (contains well-d‐
- describe a complex system in the most efined interfaces to other types of Tools
clear and unambiguous way. models) Gap analysis
- Models present the whole system and Flipcharts
its context in a single diagram and Domain Knowledge
Checklists
therefore help to look at the problem The goal of a Business Analyst is to provide
Multi-voting
from the overall perspective. business solutions to business issues by
Root cause analysis
Common techniques assessing business problems, and identi‐
fying and analyzing root causes. Brainstorming
- UML notation to express requirements
as use case diagrams, activity The success of Business Analysis is Managing conflicts tips sheet
diagrams, component diagrams, state determined by the benefit that the solution Focus group framework
machine diagrams, etc. provides to the business either in terms of
savings in costs, improvement in produc‐ Process Improvement
- BPMN
tivity, and/or increase in customer satisf‐
- Using prototyping as a technique of GUI Process Improvement supports the introd‐
action.
modeling uction of change into the current process in
To be able to provide a business solution order to improve quality, reduce costs
- Using SysML notation to develop specif‐
that provides a measurable benefit to the and/or accelerate schedules
ications, analysis, design, verification
organization, the Business Analyst must
and validation documentation for Supporting Process Improvement is one of
have knowledge of the business domain.
systems and systems-of-systems. The the tasks of a Business Analyst.
Importance
specifications may include hardware, The Business Analyst models and analyzes
software, information, processes, Domain knowledge makes it easier for the business processes used within an organi‐
personnel and facilities. Business Analyst to connect and commun‐ zation in order to discover any ineffective
icate with Business Users. elements.
Quality criteria for business process models
Domain knowledge makes understanding Techniques
- Correctness (syntactic and semantic
and analyzing business issues easier
correctness) - Manually re-design processes on the
Lack of domain knowledge may lead to basis of experience and domain
delays in providing the solution, since the knowledge with the goal of eliminating
business process and business rules must bottlenecks and making the execution
first be understood times shorter and more efficient

www.jchmedia.com/
Process Improvement (cont) Common Objectives of Business Analysis Business needs (cont)
- Introduce tools, including software, to Collect and document the requirements for the projects that help the organization
optimize the business processes in the Design business solutions to resolve the reach its vision, strategic goals, and
organization (e.g., SAP, ERP, CRM business problems business objectives.
software) Business Analysts are often supported by
Assist in the timely completion of the project
- Simulate and optimize processes by providing accurate requirements identi‐ Project Managers and Product Managers in
- Adopt a selected methodology or fication and analysis defining Business Needs
strategy Improve efficiency by increasing the quality One of the responsibilities of a Business
Methods: of requirements identification and analysis Analyst is to cooperate with the person or
and therefore reducing the need for rework group requesting the project, including
Benchmarking
and fixes in the later stages of the project users or proxy users, and to help them
Business process improvement
articulate the real need.
Business process reengineering
Business Analysis influences other project
Capability Maturity Model Integration/Cap‐ areas What is a business process?
ability Maturity Model (CMMI/CMM) set of activities aimed at producing a
Significant impact on project management
ISO 9000 (especially scope and time management) specific output for a particular customer or
IT Governance market.
Design – Business Analysis determines the
Just In Time manufacturing required business architecture and scope of focuses on how the work is done within an
the solution organization, the way of organizing work,
Lean manufacturing
activities, relationships and the depend‐
Performance improvement Development – The Systems Analyst (who
encies between them. A process can be
determines detailed requirement specifica‐
Process management considered as the ordering of work activities
tions) uses the Business Analysis to
Process Improvement and Management across time and place, with a beginning, an
determine what has to be implemented.
(PI&M) end, and clearly defined inputs and outputs [
Testing and other Quality Assurance
Six Sigma A business process must have the following
activities – Products of Business and
characteristics
Total Quality Management (TQM) Systems Analysis are a basis for testing
- Has a goal
BA Knowledge Areas Business needs - Has specific inputs
1. Business Analysis Planning and A Business Need describes the business - Has specific outputs
Monitoring (Orange) problem or opportunity which the Business - Uses resources
2. Enterprise Analysis (Dark Green) Analyst must understand and analyze in
- Has a number of activities that are
order to recommend appropriate solutions
3. Elicitation (Light blue) performed in some order
before a project starts, the Business Need
4. Requirement Analysis (light pink) - Affects at least one organisational unit
(understood as a problem or an opport‐
5. Solution Assessment and Validation - Creates value for the customer (both
unity) and Business Case (understood as
6. Requirements Management and internal and external)
costs vs. benefits) are defined, either
Communication formally or informally. Identification of processes allows the
Business Analyst to understand the organi‐
zation’s goals,

www.jchmedia.com/
What is a business process? (cont) BA in Phases of the Software Life Cycle BA in Phases of the Software Life Cycle
(cont) (cont)
Helps determine the activities and the flow
required to achieve future planned business - Supporting the Systems Analyst in - Participating in the preparation of test
and strategic goals preparing the detailed system specifica‐ cases for User Acceptance Testing
Identification of business processes helps tions (e.g., covering such items as data, - Supporting the acceptance testers by
find possible gaps and ineffective parts of mapping, integration issues, user interf‐ answering questions during test
the process, which may then be improved aces) execution
via process optimisation - Validating the proposed software design
If business processes are not established with the customer and other stakeh‐ BA Planning and Monitoring
and understood, then the organization may olders
The parameters which are defined and set
have a low maturity level, which makes - Managing any requirements changes during the planning phase should retain
measuring and controlling processes very Development phase their validity throughout the project phases
difficult. In addition, there are likely to be and it becomes the responsibility of the
- Supporting the development team
significant problems with the definition of the business analyst to perform the activities
during implementation (e.g., clarifying
business goals and needs. classified under this knowledge area
issues related to the requirements,
precisely.
validating business rules to be applied in
BA in Phases of the Software Life Cycle
the code) Activities
Analysis phase Identify the stakeholders
- Validating the evolving solution
- Identifying and evaluating the current according to the intended requirements - Identify stakeholders who may be
business processes in an organization and needs (when possible) impacted by a proposed initiative or
(“as is” analysis) who share a common business need.
- Supporting testers in preparing test
- Gathering initial requirements for the cases and test scripts at the business - determining appropriate stakeholders for
needed business solution (“to be” level and validating the resulting work the project or project phase, and
analysis) products analyzing stakeholder influence,
- Creating and analyzing the business - Managing any required changes to the authority (approve, sign off, veto), and
case requirements (resulting from detected project attitude.
- Conducting a feasibility study defects, regulatory or legal changes, Outputs: Stakeholder list, Stakeholder
needs for new or extended functionality, roles and responsibility designation
- Preparing ideas for the business
etc.)
solution - RACI matrix (also known as RASCI
Testing phase matrix) plays very important role in this
Specification phase
- BA role varies process.
- Identifying and documenting business
requirements on a more detailed level - verifying test results - Scope of the tasks and the dependency
can be defined easily
- resolving issues related to defects or
gaps in the requirements - estimates related to cost, timings and
resources
Communication Planning

www.jchmedia.com/
BA Planning and Monitoring (cont) BA Planning and Monitoring (cont) Requirements Management and Commun‐
ication
- Determine what information the various - Determine tasks in the Knowledge
stakeholders need to be provided about Areas: How we manage conflicts, issues and
the results of business analysis and the - Identifies task dependencies changes and ensure that stakeholders and
forms it should take (verbal, written, etc). the project team remain in agreement on
- Develop estimates for BA work (time,
It includes considerations for, as well as the solution scope
skill level, complexity of tasks, etc.)
constraints, impacts, durability and Purpose
- Inputs: Stakeholder list, Stakeholder
trade-offs of different communications
roles and responsibility designation, Recognise that communication takes places
media
Organizational Standards throughout all knowledge areas and is
- Communication plays very important important for managing requirements
- Outputs: Business Analysis Plans for
role in any stage of project life-cycle and
each KA Manage the approved solution and requir‐
in order to avoid ambiguity or conflicts in
ements scope
the requirements and end results, the Plan Requirements Management Process
Ensure stakeholders have access to
communication should be precise and - Describes how to determine the approp‐
business analysis work products
controlled. riate requirements process for a
particular initiative Prepare and communicate requirements to
- Each stakeholder should understand the
stakeholders
details of the requirements - Consider whether and how requir‐
ements are changed Task: Manage Solution and Requirements
- WHAT, WHO and WHEN are the
Scope
important questions related to commun‐ - Which stakeholders need to approve
ication Baseline and manage changes to business
- Who will be consulted on, or informed of
case, solution and requirements
Monitoring BA work changes,
Approve requirements (according to the
- metrics that can be used for monitoring - includes the approach to requirements
approval authority stated in the Requir‐
business analysis work are determined. traceability and determining which
ements Management Plan)
- helps in improving future business requirements attributes we will capture
Control multiple versions of requirements
analysis plans - Output: Requirements Management
work products
- performance measures, reporting and Plan
Manage requirements conflicts and issues
corrective actions RASCI: R- Responsible (does the work), A-
Inputs: Stakeholder roles and responsibility
Plan Business Analysis Activities Accountable (decision maker, only one), S-
designation, Requirements, Requirements
- Determine which activities are required Support (provides support during any phase
management plan
to define the solution to a business of lifecycle), C- Consulted (consulted prior
to the work and provides input), I- Informed Outputs: Approved Requirements, Decision
problem, how those activities will be
(informed about the work progress). Record
carried out, the work effort involved, and
an estimate of how long the activities will Task: Manage Requirements Traceability
take. Purpose:
Trace requirements (update and mainta‐
ining relationships between requirements
components)
Perform impact analysis when changes are
requested and supply this information to the
change control process
Support the allocation of requirements to the
solution in Solution Assessment and
Validation.

www.jchmedia.com/
Requirements Management and Commun‐ Change Management process (cont) Change Management process (cont)
ication (cont)
A defect found in the code, documentation Updating plans as needed depending on
Outputs: Traced Requirements or requirements the phase of the project (e.g., Project Plan,
Tasks: Maintain Requirements for re-use System improvement efforts Development Plan, and Test Plan)
Purpose: External changes (regulatory, legal, etc.) Updating business and system docume‐
ntation (e.g., specifications, architecture
Select which implemented requirements will New or changing requirements (resulting
design, user manuals)
be maintained after solution implementation from new regulations, changes within the
business domain, new features requested Updating test cases and test scripts
Name the responsible party who will
maintain the requirements by the users, etc.) Implementing the change (coding)
Facilitate ongoing use of requirements for Business process improvement initiatives Testing by vendor or/and customer test
impact analysis and solution maintenance Change Request team
Facilitate re-use of requirements on related When the need for a change appears, there Deploying the change to the production
projects to encourage enterprise consis‐ should be a Change Request raised by a environment
tency of business models stakeholder requesting new or modified
functionality. Important elements of a Requirements Organization
Inputs: Implemented requirements
change request are a unique identifier, the Requirements can be organized (struc‐
Outputs: Maintained/re-used requirements
author, the deadline (if applicable), an tured) into packages. This packaging
Task: Prepare Requirements Package
indication whether the change is required or conforms to the boundaries (limitations) and
Determine appropriate format for requir‐ optional, the change type, and an abstract, solution scope established during
ements, Create a requirements package or description, of the proposed change Enterprise Analysis and helps to further
Outputs: Requirements package (e.g., All changes should be tracked in a Change define those boundaries
executive summary, formal documentation, Log or Change List BA decomposes the problem model to
RFI, RFP, etc.) make each requirement more detailed
Changes should be managed by the
Task: Communicate requirements Change Control Board (CCB). The CCB is Ensure that the model correctly reflects the
Interaction with all stakeholders before, not allowed to submit, approve, reject, or boundaries for the business problem
during and after projects. implement changes without discussion with
Ensure proper level of detail is achieved
the other stakeholders.
Interaction with solution team to assure that Types of decomposition
requirements are correctly understood and may have significant impact on other
Goal decomposition
implemented elements of the system, such as compon‐
ents, interfaces, functionality, etc. - Goals are business requirements
Change Management process Impact analysis should be performed - Goal decomposition helps to ensure the
solution will satisfy stakeholder’s needs
Identifying a potential change Impact analysis includes analysis of the
changes needed in the project schedule or Feature list decomposition
Requesting new functionality
budget that would be necessitated if the - A feature is a service that the solution
Analyzing the change request
change were to be implemented provides to fulfill one or more stakeh‐
Evaluating the change
The planning of change implementation older need
Planning the change
includes: - an abstraction of the solution of the
Implementing the change problem expressed at a high-level
Reviewing and closing the change request
Potential changes might be a result of:

www.jchmedia.com/
Requirements Organization (cont) Acceptance and Evaluation Criteria BA necessary skills (cont)
- A feature is developed into completely Communication and writing skills

described functional and supplemental - Ability to communicate with all levels of
requirements management
Functional decomposition - Ability to communicate with stakeh‐
- breakdown of a list of items into classi‐ olders of various knowledge levels
fications or groups based on the - Precision in articulating ideas and
function each item performs or the use it thoughts
provides
- Ability to relate with line workers
- identifies the high-level functions of the
- Good technical writing skills
proposed solution, or the organization
- Strong communication skills in all forms
itself, and then breaks them down into
(verbal, non-verbal, written, etc.)
sub-processes and activities.
- Public speaking skills
- usually performed by a Systems Analyst
Facilitation skills
Quality Assurance Facilitation can be defined as a process of
Quality Assurance is a process of enabling groups to work cooperatively and
systematic monitoring and evaluation of the effectively. Facilitation provides leadership
various aspects of a project or solution. The Facilitation serves to improve the following
goal is to maximize the probability that the skills
BA necessary skills
solution has achieved a desired standard of - Leading
quality Analytical skills
- Solving issues
Quality Criteria for Requirements Financial analysis
- Building team and community
Allocatable Feasible Statistical analysis
- Empowering
Complete Measurable Operations research
- Resolving conflicts
Consistent Necessary Requirements analysis
- Transforming
Correct Prioritized Systems analysis
- Evoking wise democracy
Testable Traceable Technical skills
- Building personal effectiveness
Unambiguous Understandable Working knowledge of technology
Facilitator
Does not determine solution Understanding of engineering principles
facilitator is a person who contributes
Checklists Ability to apply financial principles to feasib‐ structure and process to interactions so that
One of the most common techniques for ility studies groups are able to function effectively and
requirements’ quality control is the use of Managerial skills make high-quality decisions. The facili‐
checklists. Project management capabilities tator’s goal is to support others and enable
them to achieve high performance
Understanding of organizational behavior
Tasks and activities
Soft skills
Negotiation skills
- Ability to negotiate to obtain data
- Ability to negotiate with stakeholders to
implement projects

www.jchmedia.com/
BA necessary skills (cont) BA necessary skills (cont)
- Helping the group to define its goals and - Focuses on the business not on
objectives personal solutions
- Providing processes to support - Negotiates between parties
members of the group to help them use - Understands group dynamics
their time effectively and to make high-q‐
- Helps the group to listen and draw
uality decisions
logical conclusions
- Guiding group discussions to ensure
- Runs meetings
objectives are met, and noting any ideas
- Manages people’s expectations
and concepts raised by members during
the discussion - Understands and explains the process
- Supporting members of the group in

assessing their current skills and
building new skills
- Using consensus to enable the group to
make decisions
- Managing conflicts using a collaborative
approach
- Helping the group to communicate
effectively and to access resources
needed to make decisions
The facilitator must always stay neutral,
listen actively and ask questions that allow
the group to identify and collect ideas and
concepts. One of the facilitator’s tasks is to
note and summarize all ideas raised by the
members of the group.
Facilitator competancies
- Communicates well
- Processes ideas from people
- Shows a natural interest
- Listens well
- Maintains control
- Empowers the group
- Handles uncertainty
- Connects with the group quickly

www.jchmedia.com/
Agile software development Cheat Sheet
Agile software development Manifesto for Agile Software Development Agile Principles
Group of software development methods in We are uncovering better ways of Customer satisfaction by rapid delivery of
which requirements and solutions evolve developing software by doing it and helping useful software
through collaboration between self-orga‐ others do it. Through this work we have Welcome changing requirements, even late
nizing, cross-functional teams. come to value: in development
Promotes: - Individuals and interactions over
Working software is delivered frequently
- Adaptive planning Processes and tools
(weeks rather than months)
- Evolutionary development - Working software over Comprehensive
Close, daily cooperation between business
- Early delivery documentation
people and developers
- Continuous improvement - Customer collaboration over Contract
- Rapid and flexible response to change negotiation Projects are built around motivated indivi‐
- Responding to change over Following a duals, who should be trusted
Agile software development frameworks plan Face-to-face conversation is the best form
- That is, while there is value in the items on of communication (co-location)
Adaptive software development (ASD)
the right, we value the items on the left
Agile modeling Working software is the principal measure
more.[2]
of progress
Agile Unified Process (AUP) Kent Beck, James Grenning, Robert C.
Sustainable development, able to maintain
Crystal Clear Methods Martin, Mike Beedle, Jim Highsmith, Steve
a constant pace
Disciplined agile delivery Mellor, Arie van Bennekum, Andrew Hunt,
Ken Schwaber, Alistair Cockburn, Ron Continuous attention to technical excellence
Dynamic systems development method
Jeffries, Jeff Sutherland, Ward Cunnin‐ and good design
(DSDM)
gham, Jon Kern, Dave Thomas, Martin Simplicity—the art of maximizing the
Extreme programming (XP)
Fowler, Brian Marick amount of work not done—is essential
Feature-driven development (FDD) © 2001, the above authors. This declaration Self-organizing teams
Lean software development may be freely copied in any form, but only
Regular adaptation to changing circum‐
in its entirety through this notice.
Kanban (development) stance
Scrum The Agile Manifesto is based on 12
Scrum ban principles
By Natalie Moore Published 31st May, 2015. Sponsored by Readable.com

(NatalieMoore) Last updated 13th May, 2016. Measure your website readability!
www.jchmedia.com/
Mod 5 - Requirements Analysis & Design Definition Cheat Sheet
by mmckenzi87 via cheatography.com/25019/cs/6405/
PURPOSE Business Process Analysis
Manage the requirements and designs for a

project
Allocate Requirements
 Tasks
 Specify & Model Requirements -

 Definitions
analyzing needs using a variety of models.
 Verify Requirements - ensures that the Model representation of a real-world
requirements & models are of sufficient quality process, device or concept
to be used for further work. Business used in any methodology that is
 Validate Requirements - ensures that all aiming to improve process
Process
requirements deliver value to the business, performce
Analysis
contribute to the fulfillment of goals and
objectives and meet a specific stakeholder
 Study Q & A
need.
 Define Requirements Architecture- What is the difference between requirement
describes how the requirements are organized verification & validation?
into various models & documents.  REQUIREMENT VERIFICATION
 Define Design Options- define the solution  Verification of requirements ensures that
approach, identify opportunities to improve the the requirements and models are of sufficient
business, allocate requirements across solution quality to be used for further work.
components and represent design option that  making sure that requirements are ready
achieve the desired future state. for stakeholder
 Analyze Potentials Value & Recommend review and approval.
Solution - determining which design options  making sure that requirements provide all
will be selected to meet the stakeholder the information
requirements. needed for the next steps in constructing the
solution (i.e. ready for design
Requirement Analysis Techniques efforts)
 REQUIREMENT VALIDATION
 Requirement validation ensures that all
requirements deliver value to the business,
Tasks, Inputs & Outputs Diagram
contribute to the fulfillment of goals and
objectives and meet a specific stakeholder
need.
 BA should Tie the requirement to a
business value that will be
delivered.
 Define evaluation criteria and process
 Define any dependencies the requirement
has in order to gain
desired result (including assumptions)
 Make sure the requirement aligns to the
business case
Discuss the tasks of Define Design Options
and Analyze Potential Value & Recommend
Solution
How does a BA Evaluate and manage
requirements to keep the solution focused
on business goals?
By mmckenzi87 Not published yet. Sponsored by Readability-Score.com

cheatography.com/mmckenzi87/ Last updated 29th January, 2016. Measure your website readability!
Page 1 of 1. https://readability-score.com
Use Cases - Defining Requirements Cheat Sheet
Labelled use case automation boundary Use case names Event Decomposition (cont)
Name a use case with a verb-noun phrase d. For each, name a use case and define
that states the actor's goal. Action, Name. when it occurs
e. Identify relevant state events
User goal technique (Use case method) f. For each, name a use case
g. Omit trivial use cases (like log in), but
1. Identify all potential users for a system
keep system controls
2. (Optional) Classify users by functional
role (shipping, marketing, sales) and operat‐
Develop a use case diagram
ional level (operational, management,
executive) 1. ID all stakeholders who need a use case
3. Interview each user and determine what diagram.
goals they have when using the system 2. Determine what each stakeholder or user
Use Cases 4. Make a preliminary list of use cases for needs to review in a use case diagram.
Define requirements activity each type of user Could be subsystem, user focused, for use
Lists steps defining interactions between a 5. Look for duplicates and inconsistencies cases with the includes relationship, and for
role (aka UML "actor") and a system, to across users use cases that are of interest to specific
achieve a goal. The actor can be a human, 6. Identify when multiple users need the stakeholders.
an external system, or time. same use case 3. For each potential communication need
7. Review completed list with users and select the use cases and actors to show
Benefits
other stakeholders for validation and draw the use case diagram.
Short summary of what the system will offer. 4.Carefully name each use case diagram
Provides a project planning skeleton, to be Event Decomposition and then note how and when the diagram
used to build initial priorities, estimates, should be used to review use cases with
This approach looks for all events that
team allocation and timing. stakeholders and users
would lead to the information system being
Provides everyone with an agreement as to used. Each event typically leads to a use
what the system will/won't do. CRUD - Create, Read or Report, Update
case. Simplify events to ones that have a
and Delete
Provides context for requirements clearly defined start and end, and achieve a
Helps in investigating small details which clear business purpose. These are: 1. ID all data entities or domain classes
could cause big problems. Elementary Business Processes (EBPs) = involved

use cases. 2. For each verify a use case has been
Answers often detailed / tricky / ignored
Keeps attention on the macro scale created that creates a new instance,
business questions: “What are we supposed
purpose of the system, not internal details updates existing instances reads or reports
to do in this case?”
Events can be: values of instances and deletes (archives)
Shows that the investigators have thought - External – caused by an actor an instance
through every user’s needs, every user - Temporal – done at fixed time intervals 3. If a needed use case has been
system goal, every business variant - State – triggered by an internal condition, overlooked add a new one and ID stakeh‐
involved. e.g. low inventory olders
Limits Steps: 4. With integrated apps make clear app
not good for non-interaction based requir‐ a. Identify relevant external events responsible for adding and maintain data
ements b. For each, name a use case and which merely uses the data
c. Identify relevant temporal events
Clarity depends on the skill of the writer(s).
Sometimes use cases are complex to write
and to understand
No fully standard definitions of use cases
By Natalie Moore Published 29th May, 2015. Sponsored by CrosswordCheats.com

(NatalieMoore) Last updated 13th May, 2016. Learn to solve cryptic crosswords!
Page 1 of 2. http://crosswordcheats.com
www.jchmedia.com/
Use Cases - Defining Requirements Cheat Sheet
CRUD
UML - Unified Modeling Language
1. General-purpose modeling language in

the field of software engineering, which is
designed to provide a standard way to
visualize the design of a system.
2. UML has been evolving since the second
half of the 1990s and has its roots in the
object-oriented methods developed in the
late 1980s and early 1990s.
Why
Visualise through an assortment of types of
diagrams: Activities, Components and how
they interact with other software, How
system will run, How entities interact with
others, external user interface
What
UML diagrams include (part of unit):
Component, Activity, Sequence, Class, Use
case*, Communication
By Natalie Moore Published 29th May, 2015. Sponsored by CrosswordCheats.com

www.jchmedia.com/
Project Management Cheat Sheet
WBS Deliverables Key terms and definitions
Work Breakdown Structure

Project
Deliverables Deliverables are milestones, not tasks
Includes internal and external deliverables

External things the project produces for the organisation
1. Work Breakdown Structure (WBS)
deliverables
One of the main reasons for producing a WBS is to focus your Internal delive‐ Things the project produces to enable the project
thinking. Take a top down view and document the major work areas. rables to continue towards completion
You can then subdivide further if the major work areas are too big.
Major Delive‐ Major areas of work within the project. One or two
Level- Start with an overall project rables words.
1
Intermediate Component deliverables to be completed for each
Level- Determine major deliverables / products to be produced. Deliverables major deliverable
2 What major intermediate or final products or deliverables
Milestones completion of a deliverable. Starts with a noun.
must be produced to achieve the project’s objectives?
Tasks Work packages for each Intermediate Deliverable.
Level- Divide each major deliverable into its component delive‐
It must start with a verb.
3 rables in the same manner.
Level- Divide each of these work pieces into its component tasks. 3. Dependencies
4 What deliverables must I have to complete these compon‐
Now start to add dependencies:
ents?
1. Look for what needs to be done before each step can be
2. Start the project plan undertaken
1. All deliverables go into the project plan as milestones 2. Create your a. May lead to changing the order in your Gantt
dependencies chart to make it more logical
2. A second set of milestones are the deliverables ready for QA. For
example 'Brief ready for approval'. These occur close to the final b. Might need to create another level in your WBS
deliverable but allow time for rework. to clearly identify a group of activities
3. Add all the tasks or actions required to produce these delive‐ Example: WBS heading “Feasibility”. When you add your tasks and
rables. Estimate the time for each task. milestones, you realize that there are two major chunks of work: Plan
and carry out workshops, and write a report. It may be worth creating
Important notes:
two levels called “Workshops” and “Report”
• Don’t fall into the trap of thinking ‘if all goes well it will take #’. Be
realistic. Some tasks will go to plan and some will take longer. Some
may take less but these rarely cancel out the overruns.
• There will be tasks that become evident only after the project is
underway. Consider making allowance in the plan for unspecified
tasks. Look for any milestones along the way. Add these to the plan.
By Natalie Moore Published 13th June, 2014. Sponsored by ApolloPad.com

(NatalieMoore) Last updated 13th May, 2016. Everyone has a novel in them. Finish
Page 1 of 2. Yours!
https://apollopad.com
www.jchmedia.com/
Project Management Cheat Sheet
4. Resourcing
1. You can now work out who is going to do all this work
2. Add resources to the tasks
3. Next to milestones only put one name, the person responsible for
delivery
5. Review the Plan
Check the plan to make sure it is well structured. Here ten checks to
carry out:
Are all deliverables included as milestones?
Do they have a quality check scheduled if required?
Is there time for rework after QA?

Are the work too big? Can you go down another level with the WBS?
Do all the tasks start with a verb
Do all the mile stone start with a noun?
Milestones keep focus, are there regular milestones?
Are all dependencies in place?
How reliant is the timing on everything going exactly as planned? Is
there a buffer when something doesn't go to plan?
Are resources assigned to all tasks and milestones?
Big Verbs
Finalise Resolve Handle

Look into Submit Maximise
Organise Design Complete
Ensure Roll out Update
Install Implement Set-up
Develop Construct Define
Note: Most big verbs pop open to reveal they contain lots of little
verbs
Little Verbs
Call Organise Review

Buy Fill out Find
Purge Look into Gather
Print Take Waiting for
Load Draft Email
By Natalie Moore Published 13th June, 2014. Sponsored by ApolloPad.com

Page 2 of 2. Yours!
www.jchmedia.com/
Project Planning Cheat Sheet
Prior to planning Gantt Chart Example Activity on node example
Business Case should be set out. Outlines

how projects benefits outweigh costs
Project objectives should be ID'd and
agreed. Objectives define successful project
outcomes
Activity planning
Work out activity order. Draw up an activity Each node then given information in image
network diagram. There are two ways: 'Layout of an activity node'
1. Activity on node used in this cheatsheet
Resource allocation
- Activities are represented on nodes
- Used by most PM tools inc MS Project Resources = raw materials, staff & equip
Useful equations For each activity ID the resource type
2. Activity on arrow
Earliest finish = earliest start + duration needed
- Activities are represented by arrow
Latest start = latest finish – duration For HR identify role to carry out the task
Identifying Milestones
Latest finish = earliest of 'latest start' On activity network diagram for each node
Events which do not take up time or energy.
activities dependent on the activity note resources needed
Estimating elapsed time
Float = latest finish – earliest start – duration Problems you may encounter
- Estimate how long each activity will take
Activity span = latest finish – earliest start Not enough staff available – resource clash
- Add these to the nodes in your diagram
- Use the float to delay until staff available
- If task finishes on day 4, the next task Product based planning - Delay start even though float used up.
should start on day 5
1. ID project deliverables: project outputs Will delay completion
- Float is leeway time between activities
delivered to client. Tangible. - Buy in staff to cover deficiency. ^ cost
Critical path (CP)
2. ID intermediate products: created during - Split into sub activities to spread evenly
Chain of activities from beginning to end project, but not delivered to client.
- Need to keep workflow steady
with no float. A CP activity delayed then
3. List deliverables or display them in a
project delayed. Activity span = total period Put into a form that everyone will
work breakdown structure
during which the activity has to take place understand e.g. Gantt chart
4. Produce definitions for stakeholders
- Activities left hand side
ES = Earliest start, EF = Earliest finish, LS =
- ID or name of the product
Latest start, LF = Latest finish - Calendar units along the top
- Description
- Block symbols used to show when
- Product/s that need to exist before this activities will be taken out
one, those it is derived from
- Free float shown in light blocks
- Components that make up the product
- Arrows show dependencies
- Quality criteria which explain how
product will be judged as satisfactory
By Natalie Moore Published 5th November, 2015. Sponsored by CrosswordCheats.com

www.jchmedia.com/
Project Planning Cheat Sheet
Work / activity based planning
Very similar to 'Product based planning' but

replace the products with activities
Product flow diagram (PFD)
Part of the Product approach

Visual representation of order in which a
sequence of products is created according
to product based planning principles
Should contain all of the products of the
Product Breakdown Structure (equivalent to
a Work Breakdown Structure) - the PFD
should be kept simple
Flows top to bottom and left to right
Looping back is not allowed
Product flow diagram (PFD) - Example
The activity span
Layout of an activity node
By Natalie Moore Published 5th November, 2015. Sponsored by CrosswordCheats.com

www.jchmedia.com/
System Design Cheat Sheet
Two Levels of Design Components of design (cont) Design Activities (cont)
Architectural Design Applic‐ Server based apps, mobile User Spec how users will interact
Broad design of the overall system structure ation devices, PCs. All components interface with system to carry out all
Also called General Design and Conceptual software must itegrate as a functioning their tasks? (Use Cases)
Design whole Database Spec in detail all info storage
Detailed Design User Screens and reports o devices reqs
Low level design that includes the design of interface connected to the system System Spec elements to ensure
the specific program details
System Comm interfaces between controls system and data are secure
Design of each use case
interface other automated systems and and protected
Design of the database
Database Data structures, deployment security
Design of user and system interfaces
methods.
Design of controls and security
Design the user interfaces
Security Firewalls, Access, data
Abstract Three Layer Architecture and protection in transit between Dialog design begins with requirements, so
controls devices. External, internal use Use case flow of activities, etc
checks and measures. Considerations:
- Workflow
Logical design - Dialogs
- Form Layout
Design the system interfaces abstract representation of the data flows,
- Look and feel
inputs and outputs of the system. This is
So other systems can talk to each other. - Multiple interfaces (s/w, web, mobile)
often conducted via modelling. ER
System interfaces connect with other - Multiple devices (laptop, touch, phone)
Modelling is commonly used.
systems in many different ways:
To the user, the interface is the system!
- Save data another system uses
Design Activities
- Read data another system saved
Systems Design
- Real time request for information Enviro‐ have we spc in detail enviro‐
- Software services nment nment and options in which Process of defining and developing systems
software will execute? to satisfy specified requirements of the user.
Relational Table Labelled Object-oriented analysis and design
App Detail spec elements of
methods are becoming most widely used.
archit‐ software and how each use
UML standard language in object-oriented
ecture and case is executed
analysis and design. Widely used for
software
modeling software systems & increasingly
System Spec how system will comm
used for high designing non-software
interfaces with all other systems inside
systems and organizations.
and outside the org
Components of design
Enviro‐ Network and deployment

nment architecture
By Natalie Moore Published 31st May, 2015. Sponsored by ApolloPad.com

Page 1 of 2. Yours!
www.jchmedia.com/
System Design Cheat Sheet
Physical design Issues when considering hosting
Relates to the actual input and output Reliability, security, physical facilities, staff,
processes of the system. How data is input potential for growth
into a system, how it is verified/authentic‐
ated, how it is processed, and how it is Design the Database
displayed as In Physical design, the
Architecture: distributed or central
following reqs about the system are
Schema: Tables and columns in relational
decided:
Referential integrity constraints: Foreign key
1. Input requirement
references – for linking tables
2. Output requirements
Uses domain model class diagram (or ERD)
3. Storage requirements
4. Processing Requirements
Design the security and system controls
5. System control and backup or recovery.
Physical portion of systems design can User interface User Authorization
generally be broken down into three sub- controls
tasks: User Interface Design, Data Design, Application Transactions are
Process Design controls “atomic”
Database controls No database
Design the application architecture and
anomalies
software
Network controls Firewalls, access
1. Partition system into subsystems.
2. Define software architecture. Three layer
Architectural design
or model-view-controller
The architectural design of a system
3. Detailed design of each use case: Design
emphasizes on the design of the systems
class diagrams, Sequence diagrams, State
architecture which describes the structure,
machine diagrams
behavior, and more views of that system
and analysis.
Design Class Diagram
Design models (primary)
Package diagrams
Nodes and locations diagrams
Design class diagrams
Sequence Diagrams
Database Schema
User interface screens and reports
System and security controls
Communication diagrams

Page 2 of 2. Yours!
www.jchmedia.com/
Systems Analysis Cheat Sheet
Systems Analysis Activities FURPS+ Requirements Acronym Some analysis and design models 3
Gather Interviews, questionnaires,

detailed documents, observing business
inform‐ processes, researching vendors,
ation comments and suggestions
Define Modeling functional requir‐
requir‐ ements and non-functional
ements requirements
Prioritize Essential, important, vs. nice to
Reasons for Modeling
requir‐ have Some analysis and design models 4
ements Learning from the modeling process
Reducing complexity by abstraction
Develop Flow of interaction between user
Remembering all the details
user and system
Communicating with other development
interface
team members
dialogs
Communicating with a variety of users and
Evaluate User involvement, feedback,
stakeholders
requir‐ adapt to changes
Documenting what was done for future
ements
maintenance/enhancement
with
users
Stakeholders Example
Stakeholders
Internal – persons within the organization

External – persons outside the organization
Operational – persons who regularly interact
with the system
Executive – persons who don’t directly
interact, but use the information or have
financial interest
Persons who have an interest in the Interviewing Users and Other Stakeholders
successful implementation of the system Prepare detailed questions
Meet with individuals or groups of users

Information Gathering Techniques
Obtain and discuss answers to the
Interviewing users and other stakeholders questions
Distributing and collecting questionnaires Document the answers
Review inputs, outputs, and doc Follow up as needed in future meetings or
Observe & document business processes interviews
Research vendor solutions
Some analysis and design models 1
Collectt active user comment / suggestions
What Are Requirements?
Functional – the activities the system

Requir‐ must perform. Business uses
ements and functions system must
carry out
Non-Fu‐ Other system characteristics.
nctional Constraints and performance
Requir‐ goals. Some analysis and design models 2
ements
Page 1 of 2. Yours!
www.jchmedia.com/
Systems Development Life Cycle Cheat Sheet
Core Process 1 - Pre project activities Core Process 2 - Plan and Monitor Core Process 3 - Analysis Activities
Activities
Identify the problem and obtain approval. Discover and understand details
System vision document. Plan and monitor the project - Gather detailed information
- ID the problem - Establish the project environment - Define requirements
- Quantify project approval factors - Schedule the work - Prioritize requirements
- Perform risk and feasibility analysis - Staff and allocate resources - Develop user interface dialogs
- Review with client and obtain approval - Evaluate work processes - Evaluate requirements with users
System Vision doc - Monitor progress and make corrections
Problem description Core process 6: Deployment activities
System Capabilities Core Process 5: Implementation activities
Complete system tests and deploy solution.
Business Benefits
Build, test, and integrate system compon‐ - Perform system and stress tests
ents. - Perform user acceptance tests
Core Process 4 - Design activities
- Program the software - Convert existing data
Design system components - Unit test the software - Build training materials and conduct
Design: - Identify and build test cases training
- The environment - Integrate and test components - Configure and set up production enviro‐
- App architecture and software nment
- User interfaces The process is iterative, cyclical. - Deploy the solution
- System interfaces
- The database Core Processes
- System controls and security
By Natalie Moore Published 30th May, 2015. Sponsored by ApolloPad.com

(NatalieMoore) Last updated 7th March, 2017. Everyone has a novel in them. Finish
Page 1 of 1. Yours!
www.jchmedia.com/
User and System Interfaces Cheat Sheet
User Centered Design Metaphors of Human Computer Interaction User Interface Design Guidelines
User is the last judge of the quality of a Design for Consistency

system. Ie will it help them perform their Provide Shortcuts
task?
Provide Feedback
Principles of User Centered Design:
Dialogs Should Yield Closure
1. Focus early on users and their work
2. Evaluate designs to ensure usability Error Handling that Provides Guidance
3. Use iterative development Easy Reversal of Actions
Reduce Short Term Memory Load
Use Cases and the Menu Hierarchy
Menus are a typical way to organize access Guidelines: Web Browser User Interfaces
to use case functionality
Consistency
Different menus for different actors
Cascading Style Sheets (CSS) – Web page
Useful to design an overall menu hierarchy System Outputs
encoding standard that enables a Web site
and then subsets for different users
Detailed reports: specific information on designer to specify parts of a page that will
business transactions always look the same and parts that will
System Inputs
Summary reports: summarize detail or vary by task or audience
Primary Objective is Error Free Input recap periodic activity Performance Considerations
Use electronic devices wherever possible Exception reports: provide details or Sensitive to network connection, amount of
Avoid human involvement as much as summary information about transactions or information transmitted, type of information
possible operating results that fall outside a transmitted
If information is already available in predefined normal range of values Pictures, Video, and Sound
electronic form, use it instead of re-entering Executive reports: used by high level Powerful, but compatibility issues arise
information managers to assess overall organizational
Validate and correct information at time and health and performance Dialog Design
location entered Internal outputs produced for use within the
For each use case, think of the natural flow
Device Examples organization
of a dialog between user and computer
Magnetic card strip readers, bar code External outputsproduced for use by people
Based on the flow of activities in use case
readers, optical character recognition, radio outside the organization. Statements,
description or activity diagram
frequency ID tags (RFID), touch screen, notices, stockholder reports. Higher quality,
electronic pens, digitizers, speech recogn‐ color, reflect image of organization Use natural language to dialog with user
ition Turnaround documents external outputs Create a storyboard of the dialog, showing
that includes one or more parts intended to the sequence of sketches of the screen
be returned with new data or information. each step of the dialog. (storyboarding)
Bills with remittance vouchers Review the storyboard with users
By Natalie Moore Published 31st May, 2015. Sponsored by Readable.com

(NatalieMoore) Last updated 11th May, 2016. Measure your website readability!
www.jchmedia.com/

Business Analysis Cheatsheet

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Business Analysis Cheatsheet

Uploaded by

Copyright:

Available Formats

Business Analysis Cheat Sheet

by Natalie Moore (NatalieMoore) via cheatography.com/19119/cs/9837/

By Natalie Moore Published 16th November, 2016. Sponsored by Readable.com

What is a requir​ement? (cont) What is a requir​ement? (cont) Requir​ement Analysis (cont)

By Natalie Moore Published 16th November, 2016. Sponsored by Readable.com

Elicit​ation (cont) What is a stakeh​older Business Analysis Commun​ication

By Natalie Moore Published 16th November, 2016. Sponsored by Readable.com

By Natalie Moore Published 16th November, 2016. Sponsored by Readable.com

The criteria are presented as parameters - Unclear objectives of the initiative

By Natalie Moore Published 16th November, 2016. Sponsored by Readable.com

By Natalie Moore Published 16th November, 2016. Sponsored by Readable.com

- Evaluate risk Allocate requir​ements to hardware, Purpose:

By Natalie Moore Published 16th November, 2016. Sponsored by Readable.com

By Natalie Moore Published 16th November, 2016. Sponsored by Readable.com

Modelling (cont) Modelling (cont) Tools and Techniques of Facili​tation

By Natalie Moore Published 16th November, 2016. Sponsored by Readable.com

By Natalie Moore Published 16th November, 2016. Sponsored by Readable.com

By Natalie Moore Published 16th November, 2016. Sponsored by Readable.com

By Natalie Moore Published 16th November, 2016. Sponsored by Readable.com

By Natalie Moore Published 16th November, 2016. Sponsored by Readable.com

- A feature is developed into completely Commun​ication and writing skills

By Natalie Moore Published 16th November, 2016. Sponsored by Readable.com

BA necessary skills (cont) BA necessary skills (cont)

- Supporting members of the group in

By Natalie Moore Published 16th November, 2016. Sponsored by Readable.com

By Natalie Moore Published 31st May, 2015. Sponsored by Readable.com

PURPOSE Business Process Analysis

Manage the requir​ements and designs for a

 Specify & Model Requir​eme​nts -

By mmckenzi87 Not published yet. Sponsored by Readability-Score.com

could cause big problems. Elementary Business Processes (EBPs) = involved

By Natalie Moore Published 29th May, 2015. Sponsored by CrosswordCheats.com

UML - Unified Modeling Language

1. Genera​l-p​urpose modeling language in

By Natalie Moore Published 29th May, 2015. Sponsored by CrosswordCheats.com

WBS Delive​rables Key terms and defini​tions

Work Breakdown Structure

Includes internal and external delive​rables

By Natalie Moore Published 13th June, 2014. Sponsored by ApolloPad.com

5. Review the Plan

Is there time for rework after QA?

Finalise Resolve Handle

Call Organise Review

By Natalie Moore Published 13th June, 2014. Sponsored by ApolloPad.com

Prior to planning Gantt Chart Example Activity on node example

Business Case should be set out. Outlines

By Natalie Moore Published 5th November, 2015. Sponsored by CrosswordCheats.com

Work / activity based planning

Very similar to 'Product based planning' but

Product flow diagram (PFD)

Part of the Product approach

Product flow diagram (PFD) - Example

The activity span

Layout of an activity node

By Natalie Moore Published 5th November, 2015. Sponsored by CrosswordCheats.com

Two Levels of Design Components of design (cont) Design Activities (cont)

Enviro​‐ Network and deployment

By Natalie Moore Published 31st May, 2015. Sponsored by ApolloPad.com

Physical design Issues when consid​ering hosting

Design models (primary)

By Natalie Moore Published 31st May, 2015. Sponsored by ApolloPad.com

Gather Interv​iews, questi​onn​aires,

Internal – persons within the organi​zation

Meet with indivi​duals or groups of users

What is a requirement? (cont) What is a requirement? (cont) Requirement Analysis (cont)

Elicitation (cont) What is a stakeholder Business Analysis Communication

- Evaluate risk Allocate requirements to hardware, Purpose:

Modelling (cont) Modelling (cont) Tools and Techniques of Facilitation

- A feature is developed into completely Communication and writing skills

Manage the requirements and designs for a

 Specify & Model Requirements -

1. General-purpose modeling language in

WBS Deliverables Key terms and definitions

Includes internal and external deliverables

Enviro‐ Network and deployment

Physical design Issues when considering hosting

Gather Interviews, questionnaires,

Internal – persons within the organization

Meet with individuals or groups of users

What Are Requirements?

User is the last judge of the quality of a Design for Consistency