Business Analyst Fundamentals

Table of Contents
Section 2 – The Basics ................................................................................................................... 5

8.Types of BA Roles .................................................................................................................. 5
business process analyst.................................................................................................................................5
requirements analyst ......................................................................................................................................5
system analyst - FA..........................................................................................................................................5
data analyst.....................................................................................................................................................6
experience analyst ..........................................................................................................................................6
9. Top BA Skills ......................................................................................................................... 6
communication ...............................................................................................................................................6
Negotiation .....................................................................................................................................................7
problem solving ..............................................................................................................................................7
Facilitation ......................................................................................................................................................7
Organization....................................................................................................................................................7
critical thinking ...............................................................................................................................................7
Section 3 Sofware Development Lifecycles (SDLC) .......................................................................... 8
11. Software Development Lifecycle ......................................................................................... 8
12. Waterfall ............................................................................................................................ 8
Requirements .................................................................................................................................................8
Design .............................................................................................................................................................8
Development ..................................................................................................................................................9
Testing .............................................................................................................................................................9
Deployment ....................................................................................................................................................9
Maintenance ...................................................................................................................................................9
+ & - ................................................................................................................................................................9
When to use....................................................................................................................................................9
13. Incremental (mini waterfall) ............................................................................................. 10
+ & - ..............................................................................................................................................................10
14.Spiral ................................................................................................................................ 10
When ............................................................................................................................................................10
What .............................................................................................................................................................10
15. Scrum (Agile) PART 1 ........................................................................................................ 12
Scrum Model ................................................................................................................................................12
Scrum Model Artifacts ..................................................................................................................................12
16. Scrum (Agile) PART 2 ........................................................................................................ 13
Scrum Model Meetings ................................................................................................................................13
+ & - ..............................................................................................................................................................13
When to use..................................................................................................................................................13
18. Agile -Rapid Application Development (RAD) .................................................................... 14
+ & - ..............................................................................................................................................................14
When ............................................................................................................................................................15
19. Prototyping ...................................................................................................................... 15
+ & - ..............................................................................................................................................................15
When ............................................................................................................................................................15
Section 4: Initiating a Project ...................................................................................................... 16
23. Understanding the Business Objective .............................................................................. 16
1
24. Creating a Business Case ................................................................................................... 16
5 Phases to an Effective Business Case .........................................................................................................16
Initial Analysis ...............................................................................................................................................16
Determine Potential Solutions......................................................................................................................17
Write the Business Case ...............................................................................................................................17
Review Business Case ...................................................................................................................................17
Present the Business Case ............................................................................................................................17
26. What is a Stakeholder and How to Identify Them .............................................................. 18
What is a stakeholder? .................................................................................................................................18
Why identify stakeholders? ..........................................................................................................................18
How to identify stakeholders to my project? ...............................................................................................18
27. Assigning Responsibilities to Stakeholders using a RACI Matrix .......................................... 18
RACI Matrix: Why is it Used ..........................................................................................................................18
Section 5: Requirements Basics ................................................................................................... 19
29.Overview of Requirements ................................................................................................ 19
Categories of Requirements .........................................................................................................................19
Product Constraints ......................................................................................................................................20
Functional Requirements..............................................................................................................................20
Non-Functional Requirements......................................................................................................................20
30. SMART Requirements ....................................................................................................... 21
Specific ..........................................................................................................................................................21
Measurable ...................................................................................................................................................21
Attainable......................................................................................................................................................22
Reasonable ...................................................................................................................................................22
Traceable.......................................................................................................................................................22
31.SMART Requirementrs Clarification ................................................................................... 23
32. Tips for Producing Valid Requirements .............................................................................. 23
Tips for Producing Valid Requirements ........................................................................................................23
Translations for Requirement Verbiage ........................................................................................................23
Terms to Avoid ..............................................................................................................................................23
33. Tips for Producing Valid Requirements .............................................................................. 24
Phases of the Requirements Process............................................................................................................24
34. Business Rules .................................................................................................................. 24
Business Rules vs Business Requirements ....................................................................................................24
Business Rules Best Practices .......................................................................................................................24
Section 6: Requirements Elicitation ............................................................................................. 25
35. Requirement Elicitation Basics .......................................................................................... 25
36. Elicitation Technique: Brainstorming ................................................................................. 25
Brainstorming: Types ....................................................................................................................................25
Brainstorming: Best Practices .......................................................................................................................25
37. Elicitation Technique: Requirement Workshops ................................................................. 26
Requirement Workshop: What is it? ............................................................................................................26
Requirement Workshop: Types ....................................................................................................................26
Requirement Workshop: Best Practices .......................................................................................................27
38. Elicitation Technique: Interviewing – PART 1...................................................................... 27
Interviewing: What is it?...............................................................................................................................27
Interviewing: Types.......................................................................................................................................27
2
Interviewing: Best Practices..........................................................................................................................28
Interviewing: Interview Questions ...............................................................................................................28
Interviewing: Create Interview Document ...................................................................................................28
Interviewing: Sample Interview Questions...................................................................................................29
41. Elicitation Technique: Surveys ........................................................................................... 29
Surveys: Best Practices .................................................................................................................................30
42. Elicitation Technique: Documentation Review ................................................................... 30
Documentation Review: Best Practices ........................................................................................................30
43. Elicitation Technique: Analyzing Interfaces ........................................................................ 30
Analyzing Interfaces: Types ..........................................................................................................................30
Section 7 - Requirement Analysis ................................................................................................ 31
45. Introduction to Requirement Analysis ............................................................................... 31
46. Visual Modeling Concepts ................................................................................................. 31
Benefits of Visual Modeling ..........................................................................................................................31
What Gets Modeled?....................................................................................................................................31
47. Business Models ............................................................................................................... 32
Organizational Chart .....................................................................................................................................32
Competitive Comparison Matrix ..................................................................................................................32
Stakeholder Map ..........................................................................................................................................33
Use Case Diagram .........................................................................................................................................33
Process Flow Diagram ...................................................................................................................................34
User Interface Wireframe .............................................................................................................................34
48. Technical Models .............................................................................................................. 35
System Context Diagram...............................................................................................................................35
Data Flow Diagram .......................................................................................................................................35
CRUD Matrix .................................................................................................................................................36
State Diagram ...............................................................................................................................................36
Entity Relationship Diagram (ERD) ...............................................................................................................37
49. BPMN vs UML .................................................................................................................. 37
BPMN vs UML: Common Parts .....................................................................................................................37
50. Engaging Your Technical Team ........................................................................................... 37
Section 8 - Requirement Specification ......................................................................................... 38
52.Categorize Requirements ................................................................................................... 38
Why ...............................................................................................................................................................38
Categories of Requirements .........................................................................................................................38
53. Deriving Requirements ..................................................................................................... 38
Parsing Requirements ...................................................................................................................................39
Interpreting Requirements example.............................................................................................................39
Focusing Requirements ................................................................................................................................39
Qualifying Requirements ..............................................................................................................................39
54. Deriving Requirements – in other words ........................................................................... 40
55. Assigning Requirement Attributes ..................................................................................... 40
Clarification ...................................................................................................................................................40
Filtering .........................................................................................................................................................41
Validation ......................................................................................................................................................41
55. Assigning Requirement Attributes ..........................................................................................................41
3
56. Prioritizing Requirements ................................................................................................. 41
Prioritization Factors .....................................................................................................................................42
3 Step Prioritization Process .........................................................................................................................42
Requirement Prioritization Best Practices ....................................................................................................42
57. Prioritizing Requirements Example.................................................................................... 42
58. Validating Requirements ................................................................................................... 43
59.Business Requirement Document (BRD) ............................................................................. 43
Section 9 - Requirements Approval ............................................................................................. 44
60. Introduction to Requirements Approval ............................................................................ 44
61. Gaining the Busisness Approval ........................................................................................ 44
Busisness Approval: Schedule (before meeting) ..........................................................................................44
Busisness Approval: Conduct (during meeting)............................................................................................45
62. Gaining the Technical Approval ......................................................................................... 45
Technical Approval: Schedule .......................................................................................................................45
Technical Approval: Conduct (Session 1) ......................................................................................................45
Technical Approval: Conduct (Session 2) ......................................................................................................46
63.Gaining Sponsor or Committee Approval ................................................................................................46
Gaining Sponsor or Committee Approval: Schedule ....................................................................................46
Gaining Sponsor or Committee Approval: Conduct .....................................................................................46
Section 10 – After the Project...................................................................................................... 47
64. Conducting a Project Review ............................................................................................. 47
Project Review ..............................................................................................................................................47
Feedback Survey ...........................................................................................................................................47
Review Meeting ............................................................................................................................................47
Post Review Meeting ....................................................................................................................................47
65. Project Completion Verification ........................................................................................ 47
Section 11 – Miscellaneous Other Topics ..................................................................................... 48
Section 12 – Bonus Section ......................................................................................................... 48
4
Section 2 – The Basics
8.Types of BA Roles
business process analyst
This is usually someone that is using some type of process or workflow software to create process
models that can be simulated, analyzed, and executed directly by the business.
The business process analysts help the business executives in decision making by modeling
and simulating what-if scenarios.
• they model those business processes,

• they take that process and they make it visual
• they identify potential issues or efficiency gains
• they also create the future process flows
• so ultimately, how they want it to work
• and they compare the two
They look at that as-is, or that current process, they look at that to-be process,
and then they conduct a gap analysis to understand what it would take to get from the as-is to the
to-be.
requirements analyst
The requirements analyst is charged with working with project stakeholders and end users
to elicit, understand, analyze, and document the requirements.
Ultimately, they're the ones that are digging out the needs and the wants of the organization of the
users so then that can be completely understood and eventually solved for in that final solution.
This role usually bridges the gap between business and IT, as they're most often using information
technology, or IT solutions, to solve that business problem.
In some organizations, this role can blend into that of a systems analyst and can be involved
in the functional design of the solution.
And when that blend occurs, these are generally referred to as IT requirements analysts
or IT business analysts.
system analyst - FA
This is mostly a system solution-centric role.

Basically, that means that they don't generally participate in the requirements gathering process,
they're not digging into the need, but instead, once the requirements are clearly defined and
documented, they help to design and create a solution by working with the technical team, the
architect, the developers,and help put together all the specifications
of what that solution needs.
Systems analysts are also commonly called systems engineers.
5
data analyst
The data analyst is a professional whose focus of analysis and problem solvingrelates to data, types
of data, and relationships among data elements within a business system or IT system or data
warehouse.
The data analyst role can vary, but commonly involve the following types of things,
including documenting the types and structures of the business data, they also mine the business
data to identify patterns and correlations among various data points, then they're able to map and
trace that data from system to system in order to solve various system
or business problems.
And the data analysts also are usually involved in designing and creating reports or reporting tools to
help business executives and managers in their decision making.
So ultimately, they help to design these reports where it pulls data out of those systems,
delivers it in a way that's intuitive and understanding, and then those executives or managers can use
that to make business decisions.
Data analysts are also often known as data modelers, business intelligence analysts, and data
warehouse analysts.
experience analyst
or also known as the UI analyst or the UX analyst.

This role is very broad and includes those who are involved in interface design or user experience,
often for software applications and websites.
Analysts who are dedicated specifically to this role are concerned with the usability and the user
experience requirements for that given application.
Ultimately, it's what you would see on a screen or on your mobile device as a user
when you're interacting with that certain piece of software.
Once those requirements are well understood, they create the actual user interface designs,
also known as mockups or prototypes or wireframes, which help to show what that design
or what that ultimate interface could look like.
And then they work with the user and they work with executives and stakeholders
to help adjust that design and make it really flow easy and make it as intuitive
for new users to understand as possible.
9. Top BA Skills
• Communication
• negotiation
• problem solving
• facilitation,
• organization
• critical thinking
communication
This is both oral and written communication.

Ultimately, the business analyst is there to be a bridge.
They're bridging the business with the information technology group.
They're bridging the business with the business.
6
They're bridging the management to the users.
They're bridging groups together,and all of that is done through communication.
So obviously that is extremely important.
Negotiation
A business analyst is involved in projects,and ultimately, there's going to be stakeholders and users
that don't agree on how things should be done.
The business analyst is in charge of negotiating between those two people and making sure that the
resolution that's decided on is agreeable by both parties.
problem solving
Some people call the business analysta glorified problem solver.

That's really what a business analyst is doing.
They're going in and solving problems.
It may be organizational problems,
it may be problems with a specific process or system.
They're helping to solve problems and recommend potential solutions.
Because of that, knowing how to solve problems and how to break them down into manageable
components is very important.
Facilitation
As that business analyst is trying to drive that problem towards a resolution,

they need to be able to facilitate meetings.
That means direct the meeting.
It also means to present findings at the meetings, and to ensure that that meeting meets its ultimate
goal.
Organization
A business analyst needs to be organized.

They may be working on a couple different projects.
They're gonna be working with a lot of different people.
They need to be able to take good notes and keep them organized, so it's easy for them to reference
those both during that project, as well as afterwards.
critical thinking
The business analyst needs to be able to analyze findings and come up with some type of solution or
resolution that meets the stakeholder's needs.
7
Section 3 Sofware Development Lifecycles (SDLC)
11. Software Development Lifecycle
General SDLC Steps

1. Gather Requirements
2. Design Solution
3. Development
4. Deploy
5. Maintenance
12. Waterfall
Requirements
• Businessneedsanalysis
• Elicit and document requirements
Design
• Design solution to meet requirements

• Determine hardware and system requirements
• Split design into segments
8
Development
• Develop/code each segment based on design

• Developers unit test each segment
Testing
• System test each segment (QA or BA)

• User acceptance test each segment (Business)
• End-to-end test all segments together as one
Deployment
• Deploy software into production environment or

• Release to market
Maintenance
• Fix bugs with patches/releases

• Enhance the product to meet changing business needs
+&-
+ Clear expectations on schedule, budget, and resourcing needs

+ Extensive documentation helps ensure quality, reliability, and maintainability + Progress is easily
measured
- Inflexible and cumbersome

- Long pole from project start to something tangible
- Problems are discovered at user testing
- Written documentation is never kept up-to-date, loses usefulness
- Promotes gap between the business users and the development team
When to use
• Clear objectives and solution

• Large, complicated, and expensive
• No pressure for immediate return on investment (ROI) from implementation
• Project team is fully knowledgeable about the solution application
• Requirements are stable and will be unchanged through development
• Resource constraints
• Strict requirement for formal approvals at milestones
9
13. Incremental (mini waterfall)
Combo waterfall – linear maar lus erdoor en je kan terug loopen naar begin en er opnieuw door
• Combination of linear and iterative approaches

• Set of concrete steps (“mini waterfalls”) that are worked through in an iterative fashion
• Allows for easier change of requirements
• Focuses on delivering customer value early in the project
+&-
+ Provides early value in the development life cycle

+ Allows for requirement changes between iterations
+ Problems can be detected earlier
+ Can utilize knowledge learned in an earlier iteration
- Heavy documentation, especially around interfaces with other systems

- Can lose track of the overall business problem
- Difficult problems tend to get pushed to future iterations
14.Spiral
When
• Large projects where requirements are not understood

• Working in unfamiliar technical arenas
• Changing requirements due to rapidly changing technology, such as leading-edge applications
• Business user can be moderately to heavily engaged
• Need functional requirements turned into something tangible quickly
What
• Combination of linear and iterative

• Focuses heavily on risk assessment
• Minimized risk by breaking a project into smaller segments
• Each cycle begins with identifying stakeholders and what success looks like
• Each cycle ends with a review and a commitment
10
Check extra info per stap
11
15. Scrum (Agile) PART 1
Agile = main concept -> Scrum is one part of Agile
• Uses iterative approach called sprints

• Flexible and adaptable, great for the unknown
• Values individuals and interactions over processes and tools
• Values working software over comprehensive documentation – uses base requirements
• Values customer collaboration over contract negotiation
• Values responding to change over following a plan
One of many different Agile methods including; (not Scrum)Extreme Programming, Crystal Clear,
Feature Driven, etc.
Scrum Model
Project team completes sprints

Sprint: A short iteration from analysis, development, testing and possibly to deployment of a
product. (14-30 days long)
• product backlog all requirements for a project
• sprint backlog a subset of prioritized requirements for that sprint (part of product backlog)
The project team is made of Product Owner, Scrum Dev Team, and Scrum Master
• Product Owner is responsible for the return on investment (ROI). Focuses on the
requirements, the “what”
• ScrumDevTeam is cross-functional. Collaborates to build the product each sprint, the “how”
• Scrum Master is the team facilitator, but has no power. Removes roadblocks, sets
timeframes, and provides visibility.
Scrum Model Artifacts
Product Backlog
• List of features that the business wants, force ranked by the Product Owner (one #1)
• Anyone can add items, could be user stories or use cases
• Does not contain tasks
Sprint Backlog
• Committed features that will be completed within the current sprint
• Has a deadline to complete
• Tasks are tracked as
o Notstarted
o InProgress
o Completed
12
16. Scrum (Agile) PART 2
Scrum Model Meetings
Sprint Planning – what items from the product backlog can we complete in this sprint
Daily Scrum – Deverybody tells what did you complete yesterday/what today/roadblocks
Sprint Review – Demonstrate product, get feedback once a sprint is done
Sprint Retrospective – Inspect last sprint. Lessons learned
Product Backlog Refinement – Adjust, split, and determine dependencies of backlog items
+&-
+ Flexible and adaptable to changing requirements

+ Gets workable product in-front of the business quicker
+ Promotes collaboration between business and development teams
+ Daily feedback on progress and roadblocks, stops “spinning wheels”
- Leads to scope creep due to no defined end date

- Relies on commitment of all team members
- Challenging to initially adopt and train in an organization
- Changing or leaving team members can have a drastically negative effect
When to use
• The project is unpredictable and will have changing requirements

• Using or creating leading edge technology
• Organization as an experienced Scrum Master
• Business has experienced resource that can dedicate time to the project
• Pressure to produce a tangible product quickly
• Little to no concerns on length of project or budget
• Development team doesn’t have resource constraints
13
18. Agile -Rapid Application Development (RAD)
• Incremental approach
• Components and functions are developed in parallel
• Developments have tight timeframes
• The mini projects are assembled into a working prototype
• Feedback is received and prototype is refined
• Repeated until product fully meets requirements
1,2 and 3 are different teams – they are working at their own project at the same time and they put
all their solutions together to a prototype to present to the customer. After tis they go back to
working apart until they have a working prototype. Then they go to testing and deployment.
+&-
+ Reduced time to develop

+ Increased reusability of components
+ Encourages customer feedback
+ Tackling integration early avoids later issues
- Need strong team to identify business requirements - System must be able to be modularized
- High dependency on modeling skills
- Requires highly skilled developers and designers
14
When
• Need a system that can be modularized and completed in 2-3 months

• High availability of quality designers for modeling
• Large budget
• Resources with high business knowledge are available to dedicate to project
19. Prototyping
No lifecycle or methodology, it is used in iterative methodologies
• Iterative progression
• Used in conjunction with Spiral, Rapid Application Development (RAD), and Incremental
models
• Breaks project into segments and creates small-scale mock-ups of the system, called
prototypes
• Prototypes are iterated until they meet the requirements
• Final prototype usually discarded
• Business user is involved in the full process
+&-
+ Gives business users a visual of their wants and needs + Promotes user participation and
communication
+ Allows progress even when unclear requirements
+ Encourages innovation
- Very loose approval and control process

- Non-functional requirements are tough to identify
- Can lead to poorly designed systems
- False expectations thinking the system is complete from prototype
When
• Project objectives are unclear

• High pressure to implement “something”
• Frequent requirement changes
• Minimal resource constraints
• No strict approval processes needed
• Innovative, flexible designs that need to accommodate future changes
15
Section 4: Initiating a Project
23. Understanding the Business Objective
3 key questions to ask yourself before starting a project
1. What is the purpose of the project?

2. What are the goals and objectives of this project?
3. In the eyes of this project, what is success, and how will it be measured?
24. Creating a Business Case
A business case is a decision-making tool used to determine the effects of a particular decision will
have on profitability.
It’s a document that's presented to decision makers and it's giving them options and telling them,
based on these certain actions, here's the cost benefit ratio, here's the return on investment by
making a decision one way or another.
Business case is used to identify and highlight problems or opportunities that a business can take
and then the different options they have and the recommended solution by the person that's
creating the business case.
It's really used to convince decision makers of a certain course of action.

So a business case is done to identify the problem, lay out potential solutions and their cost and their
benefits.
A business case is done on nearly every action, but not always in a written format.
The business case is created prior to the project being started. This frames up the return on
investment prior to taking the action.
A business case is generally created by a business executive, a business manager, or a business

analyst.
5 Phases to an Effective Business Case
1. Initial Analysis
2. Determine Potential Solutions
3. Write the Business Case
4. Review Business Case
5. Present the Business Case
Initial Analysis
• Thoroughly understand the problem or opportunity

• Determine high level requirements
• Identify data needed to support the business case (ROI)
• Validate with decision makers the high level return is worth the potential investment
• Analyze likelihood project will be approved and if you should continue
16
Determine Potential Solutions
Identify all possible solutions to the problem.

• Benefits
• Costs
• Timetable of project
• Time before a return on investment is realized
• Risks
*One of your solutions should be to do nothing
Write the Business Case
• Executive Summary – write at the end for exec who don’t have time to read all
• Problem Statement
• Analysis
• Solution Options
• Cost-Benefit Analysis
• Recommendation
Review Business Case
• Validate problem statement justifies a call to action

• Ensure all valid solutions are given
• Double check cost benefit analysis calculations
• Objectively dissect your recommendation
• Correct any spelling or grammatical mistakes
• Ask another person to closely review the document
• Get project buy-in of two key stakeholders
Present the Business Case
• Remind yourself, they haven’t seen this before

• Clearly define the problem and business need to act
• Give your recommendation
• Explain the return on investment (ROI)
• Touch on each risk, but unless asked, don’t dive in deep
• Mention your stakeholder backers
• Close the presentation summarizing the benefits and ROI
17
26. What is a Stakeholder and How to Identify Them
What is a stakeholder?
• Project team members

• Customer
• Suppliers
• Employees
• City/Community
• Professional organizations
• Any individual impacted by the project
• Any individual to support the project
Why identify stakeholders?
• It increases the chances for success

• Additional ideas
• Varied perspectives
• Gains buy-in
• Increases credibility
How to identify stakeholders to my project?
• Walk through anticipated scope/process

• Beneficiaries of the effort
• Directly involved with the beneficiaries of the effort
• Jobs that may be affected by project or results
• Government officials
• Influencers
• Interest in outcome
• Get ideas from stakeholders as you identify them
27. Assigning Responsibilities to Stakeholders using a RACI Matrix
RACI Matrix: Why is it Used
Critical tool to understand and align the responsibilities of stakeholders.

Alleviates power struggles
Reduces lack of ownership
Sets clear expectations!
R Responsible – who will be doing this task

A Accountable – who has the authority
C Consulted – who can tell more/who is Subect Matter Expert
I Informed – who’s work depends on this/who needs updates about
18
Section 5: Requirements Basics
29.Overview of Requirements
Something a product must do or a quality it must have
• Guides the design of the eventual solution

• Without correct requirements, you cannot design or build the correct product
60% of project failures originate with the requirements
Categories of Requirements
Functional Requirements
• Things the product must do
• Action the product must take
Non-Functional Requirements
• Properties or qualities the product must have
• How the product will behave
Product Constraints
• Global requirements
• Purpose of the project
• Users of a product
19
Product Constraints
• Purpose of the Product – reason for building the product

• Client, Customer, and Stakeholders – people that interact with the product
• Users of the Product – intended end-users and how they affect product usability
• Requirements Constraints – limitations of the project and restrictions on design
• Naming Conventions and Definitions – vocabulary of the product
• Relevant Facts – outside influences that make a difference to this product
• Assumptions – assumptions developers are making
Examples
• The product budget must not exceed $50,000
• The product shall run on the company’s existing machines
• Implementation of the product cannot interrupt daily business
• The last 5 years of historical data needs to be made available in the product
Functional Requirements
• Scope of the Product – defines the boundaries and connections to other products
• Functional and Data Requirements – Things the product must do and data manipulated by the
functions
Examples
• The product must track recipes down the ingredient and quantity level
• The recipes must be editable by an administrator
• The product must display the orders that need to be completed
• The product must display the recipes to make the orders
• The product must track ingredients including their cost, vendors, and quantity in inventory
• The product must interact with the current Point of Sale system
Non-Functional Requirements
• Look and Feel Requirements – intended appearance

• Usability Requirements – based on the intended users
• Performance Requirements – how fast, big, accurate, safe, reliable, etc.
• Operational Requirements – product’s intended operating environment
• Maintainability and Portability Requirements – how changeable product must be
• Security Requirements – security, confidentiality, and integrity of the product
• Cultural and Political Requirements – human factors
• Legal Requirements – conformance to applicable laws
Examples
• The product shall use the company colors and logos
• The product shall be intuitive, even to first time users
• The product shall only allow bakers and administrators to view recipes
• The product shall be easily upgraded for future business needs
• The product shall be scalable to multiple bakery locations
20
30. SMART Requirements
S Specific
M Measurable
A Attainable
R Reasonable
T Traceable
Specific
Overall
• Clear, no ambiguity
• Consistent, same terminology throughout
• Simple
Guidlines
• Avoid “some”, “several”, “many”
• State pronouns clearly “A calls B, it is updated”
• Specify units all with numbers
• Use pictures to clarify understanding
• Provide explanations for terms like “transmitted”, “sent”, “downloaded”, and “processed”
Questions to Ask
• What?
• Why?
• Who?
• Where
Measurable
Overall
• Measure progress towards goal
• Indicators should be quantifiable
Guidelines
• Ensure measurable during requirement elicitation
• Validate unequivocal success can be proven with that requirement
• Determine tests that will need to be used to verify the requirement was met
Questions to Ask
• How much?
• How many?
• How will I know when it is accomplished?
21
Attainable
Overall
• Validate requirement is feasible
• Within technical expertise
• Within scope of project
• Within budget
Guidelines
• Determine who has responsibility for satisfying the requirement and validate they can deliver
• Ensure sufficient time, resources, and budget
• Reuse pieces from previous projects
Questions to Ask
• Is there a theoretical solution to the problem?
• Has it been done before?
• Are there any known constraints (environmental, physical, etc.)?
Reasonable
Overall
• Validate the effort is worth the requirement
Guidelines
• Run all requirements through a ‘sanity check’
• Ensure the requirement makes sense in context
Questions to Ask
• Is this worthwhile?
• Is the timing right?
• Does this match our other efforts/needs?
Traceable
Overall
• Trace requirement through design, implementation, and testing
Guidelines
• Requirements should include
• Originators
• Assumptions
• Business justifications
• Dependencies on other requirements
• Importance
Questions to Ask
• Can I ensure this requirement has been met in the design solution?
• Can I ensure this requirement has been met in the implementation?
• Can I ensure this requirement has been met during testing?
22
31.SMART Requirementrs Clarification
When you elicit, you want your requirements to be specific and measurable and attainable,
reasonable and traceable as much as possible.
If you can't find a way to do it, write the requirement, write some notes, and when you go back
through in the analysis and the specification stage, you can start to kind of take that and make it into
something that is a SMART requirement.
32. Tips for Producing Valid Requirements
Tips for Producing Valid Requirements
• Should use the word shall (not too much) →only one shall per requirement
• Written in short, simple sentences
• Consistent terminology
• Stated positively
• Accompanied by notes and comments to support and clarify
• Stated imperatively “this shall happen”
• Don’t use will and should
Translations for Requirement Verbiage
• Or – Select one of the options

• Can, should – Expresses desire or suggestion instead of requirement NOT GOOD
• Must – 100% reliability
• Are, is, will – Descriptive part to lead into the requirement
• Support, and/or – Confusing
• But not limited to, etc – Incomplete requirement/thought
• Shall – dictates specification and functional capability
Terms to Avoid
• Adequate • Normally
• Approximately • Optimize
• Better than • Quality product • Quick
• Comparison • Rapid
• Easy • Substantial
• Maintainable • Sufficient
• Maximize • Timely
• Minimize
23
33. Tips for Producing Valid Requirements
Phases of the Requirements Process
1. Requirement Elicitation – Section 6

2. Requirement Analysis – Section 7
3. Requirement Specification – Section 8
4. Requirements Approval – Section 9
34. Business Rules
A business rule is a rule that defines or constrains some aspect of business and always resolves to
either true or false.
Business rules are intended to assert business structure or to control or influence the behavior of
the business.
Examples
• Entered email addresses must appear valid (contain @ and .)

• Each class must have at least one instructor
• Customers must have a valid driver’s license to rent a vehicle
• A quote must be completed prior to an invoice being generated
Business Rules vs Business Requirements
Rule Requirements
• Entered email addresses must appear valid • Capability to enter email address
(contain @, then later .) • Alert agent when the email doesn’t appear to be valid
• Allow for correction of email if invalid email format is
entered
• Customers must have a valid driver’s license • Employee to inspect driver’s license
to rent a vehicle • Ability for employee to validate driver’s license
• A quote must be completed prior to an • Capability to enter a quote

invoice being generated • Details from quote must automatically flow to the
invoice
• Ability to tie the quote and invoices together for
reporting
Business Rules Best Practices
• When documenting business rules, keep it simple

• Business requirements are used to comply with business rules
• Each business rule may need multiple requirements
• Business rules should not be changed
→Changes can cause major constraints down the road
24
Section 6: Requirements Elicitation
35. Requirement Elicitation Basics
Requirement elicitationis getting business requirements through various activities from users and
stakeholders and being able to determine their expectations as well as understand their system
constraints.
So it's really all about getting them communicating with them, asking them questions to pull out
what are their needs of this particular product or system or process and understand what they're
doing today and what they're doing, they need to have it work in the future, et cetera.
What requirement elicitation is not is actually creating a whole bunch of models and going through
and answering how things are gonna be accomplished.
36. Elicitation Technique: Brainstorming
Brainstorming: Types
Individual
• Project team member creates a list of ideas
Open
• Participants call out ideas that are captured by scribe
Structured
• Participants write down their ideas
• Facilitator goes participant to participant to have them share on idea each
• Continue sharing process until all ideas are exhausted
Advantages Disadvantages
Generates multiple ideas quickly Ideas are not discussed/explored
True meaning may be ambiguous or
Involves multiple perspectives
misunderstood
Promotes equal participation
Brainstorming: Best Practices
• Determine type of brainstorming meeting ahead of time

• Publish an agenda prior to the brainstorming session
• Clearly state the objective of the meeting
• Create environment to encourage participation
• Establish ground rules
• Do not discuss ideas during the brainstorming session – only questions to clarify
• Do not dismiss or discount an idea or person
• Do build on others’ suggestions and ideas
• Do have fun
25
• Establish roles
• Timekeeper
• Scribe
• Facilitator
• Create process for combining, categorizing, and summarizing like ideas
• If complex, create multiple meetings to keep meeting fatigue low
• Schedule follow-up meetings
• Prioritize final ideas to plan further analysis
• Allow votes for top ideas
37. Elicitation Technique: Requirement Workshops
Requirement Workshop: What is it?
• Structured meetings that involve

• End-users
• Subject Matter Experts
• Project Manager
• Business
• IT reps
• Generally is used for projects with multiple business units
• Works to define, clarify, and complete requirements
• Starts at broad level and dives into functions and processes as the workshop moves forward
Requirement Workshop: Types
Formal Requirements Workshops

• Highly structured and formal
• Carefully selected group of stakeholders
• Define, create, refine, and reach closure on business requirements
Business Process Improvement Workshops

• Semi-formal
• Analyzes existing business processes
• Identify and agree upon solutions implement process improvements
Agile Requirement Workshops

• Generally more unstructured and informal
• Used generally to document the scope of the requirements
Effective at getting real requirements instead of Difficult to get appropriate stakeholders in
perceived requirements one room at same time
Greater chance of obtaining consensus because issues Increased number of global projects poses
and questions are asked in real-time logistic difficulties and adds complexity
Success of the session is highly dependent
Confirmation of requirement accuracy is immediate
on the expertise of the facilitator
Successfully gather requirements from a large group in
Can be expensive
a short period of time
26
Documentation is completed within hours of the
session and provided quickly back to participants for
review
Requirement Workshop: Best Practices
• Determine the type of requirement workshop ahead of time

• Be clear on what the session will deliver
• Utilize modeling tools to visualize the processes and requirements
• Facilitator should be experienced
• Limit the meeting to the key project participants
• Include end-users, subject matter experts, developers, and senior management
• Remember that you are an analyst, not just a scribe/facilitator
38. Elicitation Technique: Interviewing – PART 1
Interviewing: What is it?
• Systematic discussion to drive out accurate requirements quickly

• Gain understanding of high-level needs, constraints, and assumptions
• Reduces misunderstanding due to cultural differences, lack of openness, and
acronyms/vocabulary
• One on one or with a small group
• Can be formal or informal
• See the process or requirements from interviewee’s perspective
Interviewing: Types
Personal interviews
• Scripted questions – interviewee’s answers are documented
• Exploratory questions to clarify and validate requirements, while removing assumptions
Job shadowing
• Walk through a work day with a user or user group observing them
Customer site visits

• Understand operational environment to discover prerequisites for job success
Task analysis
• Ask end-users to walk through their current jobs
• Show as-is process in order to identify essential and frequent tasks
• Interviewer asks questions to understand what works well and what doesn’t
Promote interactive discussions to explore
Require access and commitment of stakeholders
detailed information
Identify conflicts or discrepancies about Creation of scripted interview questions can be time
stated needs or requirements consuming
27
Encourage participation and build Stakeholders have difficulty describing their future
relationships by establishing rapport with the needs, so the focus is usually focused on what they do
stakeholder currently
Resulting documentation is subject to interpretation of
Enable observations of nonverbal behavior
the interviewer
Allow immediate follow-up to ensure Transcription and analysis of interview data can be
understanding complex and expensive
Interviewing: Best Practices
• Determine the best interview type to accomplish your goals

• Appropriately prepare for the interview
• Schedule interviews ahead of time
• Respect the person by being on time and display interest in the subject
• Match the pace of the interviewee
→ If they are cautious, talk slow. If they are in a hurry, talk quickly
• Check understanding often
• Let interviewee know what will be done with the information
• One person conducts interview while the other documents the answers. If not possible, record
the interview.
• Ask for examples of their issues and document screen shots
• Interview two to three users for each user category you are targeting
• Be sure to interview end-users, not just senior management who think they know how the
process/system is used
• Create thank-you email appreciating their time and how the information will help create quality
requirements – (sent with interview invite)
• Create a follow-up email telling the person how the information will be used and the next steps
for the project – (sent after interview)
• Allow time in the schedule to debrief and finish documentation after each interview
Interviewing: Interview Questions
• Make questions open-ended

• If they could answer the question with a yes or no, reword it
• Avoid questions that may present judgement or a conclusion
• Allow the questions to flow naturally so they can be put into conversation rather than a survey
Interviewing: Create Interview Document
Interview document generally contains:

• Name of interviewee
• Role of person and their primary responsibilities • Open-ended questions
• Space for answers
• Space for interviewers’ insights
• Action item box for flagging key pieces of information
→Requirement, new requirement risk, assumption, or constraint
28
Interviewing: Sample Interview Questions
• What are other ways you accomplish this goal?

• Tell me about your frustrations with this process
• What makes a good day? A bad day?
• If you could wave your magic wand and make it different, what would the process look like?
• What standards or regulations should we be aware of?
• What purpose is accomplished by using the product or process?
• What equipment, tools, templates, and inputs do people need to use it?
• How long should tasks take?
• What people do you share information with?
• What failures cause the organization the most pain?
• What didn’t I ask that I should have?
• If we could only change one thing in the process, what should it be?
41. Elicitation Technique: Surveys
Open-ended questions
• Gives respondents an opportunity to answer in their own words
• Useful, but very time consuming to interpret and catalogue
Closed-ended questions
• Finite set of answers for each question
• Lends itself to statistical analysis
• Tough to create questions that are not leading or need an “Other” answer
Questions can vary

• Ranking from “not very important” to “extremely important”
• Ranking from “strongly disagree” to “strongly agree”
• Rank order a list of items
• Multiple choice question
Require limited stakeholder’s time Relatively low response rate
Effective at reaching geographically dispersed Poorly word questions may provide inaccurate
stakeholders information
Use of open-ended questions requirements
Scalable for large audiences
more analysis by the business analyst
Require both instrument training and problem or
Relatively fast and inexpensive to administer
business domain experience
Supplement more subjective information, such as
Incentives for responding might be expensive
opinions gained through interviews
29
Surveys: Best Practices
• Focus your questions on high-priority risks that have been identified

• Identify user satisfaction levels with existing systems to set a baseline
• Questions should be direct and unambiguous
• Save complex questions for later in the survey
• Save demographic information for last
• Create rewards for participating
• Create the survey with inexpensive online tools
• Notify the participants when the survey is available and continue to remind them to
participate
42. Elicitation Technique: Documentation Review
Review existing documentation

• User guides
• Prior system implementation documentation, including lessons learned • Technical documentation
• Lessons learned after completion of latest project
Formulates context for understanding the scope of the project
Current process documentation provides a
Existing documents may be old and out-of- date
starting point
The reviewer needs domain and technical expertise to
determine if existing
Can be time consuming, and may not provide the
desired payback
Documentation Review: Best Practices
• Know the purpose for reviewing

• Set self-imposed time limits
• Create a glossary of terms from former project documentation
43. Elicitation Technique: Analyzing Interfaces
• Reviewing the system, people, and process linkages

• Determine needs for input, output, and the medium
• Describes manual and automated processes
Analyzing Interfaces: Types
Customer review meetings

• Identify formal requirements to link information, people, and processes
• Drives a robust, complete, and accurate solution
30
Developer review meetings
• Happen early on
• Review high-level requirements and system models
• Identify interfaces, regulations, or technical standards
Discovers missed interfaces and their purposes Not useful as standalone elicitation activity
Determines regulations or interface standards Can begin to focus on many technical details
Provides missed requirements Can be redundant with modeling activities
Uncovers areas of project risk
Section 7 - Requirement Analysis
45. Introduction to Requirement Analysis
And requirements analysis is about stating requirements in multiple ways, to accomplish three
things.
1. you want all stakeholders to understand the requirement.

2. you want the business, the customer to be able to prioritize requirements.So they need to be
able to understand the need of the requirement, and understand what the requirement is
going to do so they can prioritize it.
3. you want your design or developer team to be able to design and implement a solution that
will end up meeting those requirements.
Most of the time, requirements analysis is being done through different modeling techniques.
46. Visual Modeling Concepts
Visual Modeling is a graphical representation using a modeling language that takes something
complex and makes it easier to understand.
Benefits of Visual Modeling
• Easily understand complex information

• Gets all stakeholders involved
• Receive requirements efficiently
• Identify the underlying problem Analyze ‘what if’ scenarios
• Allows remove of irrelevant information
What Gets Modeled?
• Current state, “as-is”

• Future state, “to-be”
• Requirements fill the gap
31
47. Business Models
Organizational Chart
An organizational chart shows the internal structure of an organization or company.
Competitive Comparison Matrix
32
Stakeholder Map
Use Case Diagram
33
Process Flow Diagram
User Interface Wireframe
34
48. Technical Models
System Context Diagram
The Context Diagram shows the system under consideration as a single high-level process and then
shows the relationship that the system has with other external entities.
Data Flow Diagram
35
CRUD Matrix
Create – Read – Update – Delete
State Diagram
Start/End
Status
Transition
36
Entity Relationship Diagram (ERD)
Entity
Primary Key
Attributee
49. BPMN vs UML
BPMN vs UML: Common Parts
Activity - Activity within a process, triggered by an event

Event - Manual or automated action, or delay in time that triggers
Gateway – Split of pathways, where multiple paths can be tajen or decision on a path must be made
per a condition
Flow – direction of the sequence or order of eventd and actions
Swimlanes – visual distinction of who is doing what within a process
50. Engaging Your Technical Team
So, first off, throughout the requirements elicitation phase, you generally are not talking much
to your technical experts.
But once you hit the analysis, requirements analysis and requirements specification, it is important
to get your technical lead and developers engaged to start to understand some of the requirements
that are coming out, especially some of those requirements that are pretty common, pretty standard
that you know are gonna stick and stay pretty true and you wanna get them engaged so they can
start to get a high level design of the solution.
You want them to start thinking about, okay, how would we be able to do this stuff?
And, you know, thinking about the overall objective of the project and looking at some
of those base requirements, they're starting to identify
37
• is this something that we should be making
• or is this something that we should be purchasing
• or buying from a software standpoint?
So they're starting to get an idea of

• how they're gonna frame that,
• how they're gonna design that,
• some high level technical design requirementsor solutions.
At this time, they can also start to pinpoint some requirements that are gonna be extremely difficult
to meet, maybe because of feasibility from a timeline standpoint, feasibility from a cost standpoint,
just straight feasibility, that it's just not possible to be able to do what they're thinking about doing.
And so they can start to pinpoint some of that right away at this analysis specification phase
because what you wanna do is take that information and go back to the business and work with
those stakeholders that brought up those requirements to help shape the requirements in a way that
are gonna be, they're gonna meet their need but also be able to be implemented as efficiently as
possible from a technical standpoint.
Section 8 - Requirement Specification
52.Categorize Requirements
Why
• Aids in documentation
• Helps to prioritize
• Assists in estimating the system cost
• Identifies areas that require further investigation
Categories of Requirements
Functional Non Functional Constraints

Things the product must do Properties or qualities the Global requirements
product must have • purpose of the product
• users of a produst
Actiont the eproduct must take How the procudt will behave
53. Deriving Requirements
1. Parsing Requirements
2. Interpreting Requirements
3. Focusing Requirements
4. Qualifying Requirements
38
Parsing Requirements
Breaking down requirements that are too broad
Original Requirement:
• “User-completed fields on tax forms shall be converted to electronic text documents.”
Parsed Requirements:
• “The system shall be able to convert handwriting to text.”
• “The system shall be able to convert machine print to text.”
• “The system shall be able to electronically correct user-completed fields.”
Removing “and” from requirements → no and splits them up in separate requirements

• Risk is high that only one of the conditions will be tested
• Hard to trace the requirement bug/failure
Interpreting Requirements example
Reduce generalness and ambiguity of stated requirements
• “Each PC shall have state-of-the-art software installed.”
Interpreted Requirement:
• “Each PC shall have Microsoft Office 2013 and Windows 10 installed.”
Parsed Requirements:
• “Each PC shall have Microsoft Office 2013 installed.”
• “Each PC shall have Windows 10 installed.”
Focusing Requirements
Combine overlapping requirements into one focused requirement
Original Requirements:
• “Each PC must have a standard spreadsheet tool installed that runs in Windows.”
Focused Requirement:
• “Each PC on the LAN shall have Microsoft Office Excel 2013.”
Qualifying Requirements
Add a requirement to provide a method of verficiation or compliance
• “The xxx command must peform the following actions...”
Focused Requirement:
• “Each command shall be executed during system testing to demonstrate its functionality.”
39
54. Deriving Requirements – in other words
Parsing Requirements - splitting apart requirements. This is done when requirements are too big or
too broad in scope.
For example, "Allow users with administrator permissions to create and manage user profiles" is a
really big requirement. There would be lots of steps and details needed to complete. This
requirement would be better parsed into multiple requirements that each accomplish a component
of the original.
"Allow users with administrator permissions to create user profiles"
"Allow users with administrator permissions to delete user profiles"
"Allow users with administrator permissions to reset user passwords"
etc.
Fun fact - Parsing a requirement into multiple pieces is referred to as 'slicing' in Agile approaches.
Interpreting Requirements - add clarity or remove ambiguity. Used when requirements are vague or
lack detail.
For example, "Microsoft software will be installed on the user's computer" doesn't provide the
necessary detail needed. We can remove ambiguity and can parse the requirement into :
"Microsoft Excel shall be installed on the user's computer"
"Microsoft Word shall be installed on the user's computer"
"Microsoft PowerPoint shall be installed on the user's computer"
Focusing Requirements - to combine multiple requirements into one. This is often used when two
written requirements are near-duplicates of each other, but there are some small variances.
For example,
"Microsoft Excel shall be installed on the user's computer"
"Microsoft Word shall be installed on the user's computer"
"Microsoft PowerPoint shall be installed on the user's computer"
Maybe it is learned these three Microsoft Office products are all installed at the same time in
something called Microsoft Office Suite, so a more focused requirement could be "Microsoft Office
Suite is installed on the user's computer"
Qualifying Requirements - make the requirement testable. This is done by adding details needed to
validate or make the requirement measurable.
For example, "The system shall start-up efficiently"
A more qualified requirement would be, "The system shall start up within 20 seconds." This is
something that can be measured and determined to be true or false.
55. Assigning Requirement Attributes
Clarification
the attributes give you more details about that requirement, about where that requirement came
from.
Helps you to decide if that requirement is important to the business from an urgency standpoint or a
business needs standpoint.
So, you're able to determine a few extra details about those requirements.
40
Filtering
As you work through projects, especially larger projects, you get a long list of requirements.
So, being able to filter by, by requirement types,being functional or supplemental, non-functional,
constraint requirements, or ones that are high priority, ones that have a certain business need,
you can filter on those and it helps you to break down requirements and helps you find
requirements.
Validation
So, as you're working through and you're,you're working through your projects and you've gone
through and you've designed and, and built the solution, being able to validate that that requirement
is being met and is being achieved for the business is very important.
55. Assigning Requirement Attributes
Unique Identifier (ex:REQ 001)
Acceptance Criteria if you're testing it later on what is the criteria that's gonna be used to validate
that that has been met?
Author who's actually writing the requirement
Complexity scale (low medium high or score 1 to 5,…)
Ownership who is being affected by it
Performance
Urgency how quickly does the business need this

And this one is pretty important. if you're talking about an iterative type of project.
You have a project that's going through multiple phases, Urgency is important becasue you want to
know, should this require maybe be putting the first phase, the second phase, third phase, is it not
that important? (you can use a scale like complexity)
Business Value a quick description of what value does this requirement give to the business.
Status stated- confirmed – developed - tested
Type Functional, non-functional or supplemental, constraint.
Priority scale (low medium high or score 1 to 5,…)
Source who started about this – important if you have questions later
56. Prioritizing Requirements
Generally there are too many functions and features to implement within the project schedule and
budget.
41
Prioritization Factors
• Value to the business

• Value to the customer
• Minimize cost to develop
• Time to implement
• Ease of technical implementation
• Ease of business implementation
• Obligation to some external authority
3 Step Prioritization Process
Step 1 - Define usefulness to business (critical, important, nice to have)

Step 2 - Estimate cost (1-5 scale)
Step 3 - Determine timeframe (1-5 scale)
Requirement Prioritization Best Practices
• Keep it simple
• Business value reigns supreme
• Remove prioritization away from politics
• Prioritize (and re-prioritize) after each project iteration
57. Prioritizing Requirements Example
You are hired by a brick-and-mortar business to help them create and implement an e-commerce
store. Below are two requirements and you are asked which one should be completed first.
What do you think?
(1) A website visitor can save products to their wishlist.

• Usefulness: Nice to have -- They can easily find and purchase those products later. Not
necessary for the e-commerce store to function
• Estimate: 4 -- lots of hidden requirements as they will also need the ability to review the list,
remove from the list, add to cart from list, etc.
• Timeframe: 4 -- will take additional requirement discussions, designing, etc.
(2) A website visitor can change the number (quantity) of products in their cart
• Usefulness: Important -- being able to change the number of items from the cart is
important to a good user experience
• Estimate: 2 -- small scope, only affects the cart and (maybe) the checkout process
• Timeframe: 2 -- implementing should be fairly straightforward after requirements are fully
identified.
As you look at these two requirements, you can see that the ability to change the quantity (2) should
be prioritized above the wishlist item; it is more useful and it will take less time to develop and
implement
(1) A website visitor can save products to their wishlist.

• Usefulness: Nice to have -- They can easily find and purchase those products later. Not
necessary for the e-commerce store to function
42
• Estimate: 4 -- lots of hidden requirements as they will also need the ability to review the list,
remove from the list, add to cart from list, etc.
• Timeframe: 4 -- will take additional requirement discussions, designing, etc.
(2) A website visitor can change the number (quantity) of products in their cart
• Usefulness: Important -- being able to change the number of items from the cart is
important to a good user experience
• Estimate: 2 -- small scope, only affects the cart and (maybe) the checkout process
• Timeframe: 2 -- implementing should be fairly straightforward after requirements are fully
identified.
58. Validating Requirements
Validating requirements is going through and making sure your requirements are valid,
so that's imploring the smart technique (Section 5 – 30. SMART Requirements).
As well as just making sure that your requirements
are clear and concise and don't have ambiguity.
59.Business Requirement Document (BRD)
It's a very important document for business analysts to understand because this is where you're
gonna be putting your final requirements and working it through for approval.
It's a document that houses all of the requirements, the business rules, the use cases, the version
history, stakeholders, basically everything that you're eliciting as part of the requirements of the
project are documented within here.
The most critical use of the Business Requirements Document is to house all of those requirements.
In addition, it also lists and houses the stakeholders that are involved in the project.
And luckily you don't have to really do much other than document it since you've done your
stakeholder identification and mapping as an earlier step as part of your project, but you document
all of tha.
It's also used to mark their approval of the requirements as well, so stakeholders are going to read
the document, make sure they agree with everything that's stated, make sure there isn't anything
missing that they had kind of stated along the way and sign off on the requirements documents,
so it's there to validate the business requirements.
In addition, it's used to help design that eventual solution. To capture what the business needs,
so then the design will meet those needs and that solution that ends up being implemented will end
up meeting the business needs.
And finally, it helps to ensure what you are going to be testing for.
So this sets the groundwork, the foundation of the whole project, and it's extremely important.
This document, you're gonna live in a BRD most of the time as a business analyst, whether you're just
creating one from your elicitation, whether you're editing one, whether you're going back and trying
to gain approval of the requirements, or you're utilizing it to either be part of the design or kind of
move that project into the design phase with your designers.
43
The Business Requirements Document is a key fact or a key feature, key deliverable, as part of this
phase.
So what I like to do is we've talked about the four stages of requirements, you have your elicitation,
then you have your analysis, then your specification, then your validation.
So in the elicitation, that's when you're meeting with everyone, that's when you're doing
all your different elicitation activities, and at that time, I'm not documenting inside of a BRD, I'm
usually documenting in something else,
I'm trying to write good requirements, write smart requirements, 'cause I wantedto rewrite them all
later, but I'm writing them in kind of more note oriented, less organized, and then in the analysis
phase is when I start to put a lot of the details into the BRD,
Also in the specification phase is when I kind of finalize that, and then the validation phase obviously
is going through and getting approval and validation of the BRD.
I start it and start filling it out in the analysis phase. Elicitation, I'm just worried about getting
and making sure that I have the requirements and a good understanding of what the business need
is looking like.
0041_RESOURCE_BusinessRequirementsTemplate lecture 59
Section 9 - Requirements Approval
60. Introduction to Requirements Approval
There's three main steps to gaining approval
• Business Team Approval

• Technical Team Approval
• Project Sponsor / Committee Approval
61. Gaining the Busisness Approval
Busisness Approval: Schedule (before meeting)
• Schedule multiple review sessions

• Separate business units
• Never exceed four hours per session
• Involve Subject Matter Experts (SME)
• Keep it relevant to the audience
• Create meeting agenda (fist we talk about this for 30 min after that we…)
44
Busisness Approval: Conduct (during meeting)
1. Explain the purpose of the meeting and the agenda
2. Review project and objective

remind people who weren’t involved for a while
• what's the objective of the project
• and why are they engaged?
• why is the business doing this?
3. Go over each requirement
Every requirement that's relevant, you're gonna go over one by one by one, list some of the
attributes, explain what it is, and then get approval of that requirement.
4. Address questions and concerns immediately
5. Change and update requirements

In case of questions or concerns it may be needed to update some requirements
6. Table all new requirements unless deemed critical

At this point is not the time that people should be adding new requirements.
So the only reason a requirement gets added once you get into the business approval phase
is if it's absolutely critical, if it was a complete miss on something, then you are gonna have to add
that in
*If critical requirements are determined(in point 6), reschedule the approval meeting
62. Gaining the Technical Approval
Technical Approval: Schedule
Session 1 - Schedule initial high level review
Session 2 - Schedule in-depth follow up review

• Include technical Subject Matter Experts (SMEs)
• Include Technical Lead / Architect
• Create agendas for both meetings
Technical Approval: Conduct (Session 1)

3. Touch on each section of requirements
4. Identify any major technical concerns
5. Answer questions
45
Technical Approval: Conduct (Session 2)

3. Go through each requirement to validate technical feasibility
4. Identify any troublesome requirements
5. Verify enough detail for design phase
6. Make or Buy decision
• Make - Create high level design architecture
• Buy – Determine options (Competitive Comparison Matrix)
7. Update project estimated cost
63.Gaining Sponsor or Committee Approval
Gaining Sponsor or Committee Approval: Schedule
• Create presentation to talk high level about project

• Update project schedule, cost, and risks
• Summarize the business requirements
• Define recommended solution
• Anticipated transition to the solution (training, policies, job aids, etc.)
• Majority of the presentation should be visuals and charts
• Schedule approval meeting with sponsor / committee

• Invite business and technical project leads
• Create meeting agenda
Gaining Sponsor or Committee Approval: Conduct
1. Explain the purpose of the meeting and the agenda 2. Review project and objective (sell it)
3. Give your presentation (stay at a high level)
4. Address questions and concerns immediately
5. Gain official sign-off on the project
46
Section 10 – After the Project
64. Conducting a Project Review
Project Review
Brings the project team and other stakeholders together to discuss both what went well with the
project and what didn’t go as well.
• Can be split into multiple meetings if very large project

• Send a survey ahead of time to collect feedback
• Prepare and send an agenda prior to the meeting
Feedback Survey
A feedback survey should be sent at least one week before the meeting asking about thoughts on
various aspects of the project.
1. Overall, how successful do you think this project was? What went right (list up to 3 things)?
2. What obstacles did you face (list up to 3 things)?
3. What needs improvement/should have been done differently (list up to 3 things)?
4. Do you have any other comments?
Review Meeting
Tend to focus on the negative, so keep it non-confrontational and be sure to ask about what went
right
• Work through each section of the feedback survey and facilitate positive and meaningful discussion
• Take notes both on positive and constructive feedback
Post Review Meeting
Analyze the results from the review meeting and recommend process or procedural changes that
should be made for future projects.
65. Project Completion Verification
Validates project objectives have been met and analyzes if the project adhered to budget, schedule,
and quality requirements.
• Completed by the Project Manager

• Format and level of detail varies per project
• States any open issues or risks
• Outlines high level customer satisfaction on project
47
Section 11 – Miscellaneous Other Topics
See lectures for practical tips.
Section 12 – Bonus Section
• Check out The BA Guide's website & unlock your dashboard by creating an
account
• On The BA Guide website, use coupon code MADEIT at checkout to
enroll in any course for only $11!
48

Business Analyst Fundamentals

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 Analyst Fundamentals

Uploaded by

Copyright:

Available Formats

Table of Contents

Section 2 – The Basics ................................................................................................................... 5

business process analyst

• they model those business processes,

This is mostly a system solution-centric role.

or also known as the UI analyst or the UX analyst.

This is both oral and written communication.

Some people call the business analysta glorified problem solver.

As that business analyst is trying to drive that problem towards a resolution,

A business analyst needs to be organized.

11. Software Development Lifecycle

General SDLC Steps

• Design solution to meet requirements

• Develop/code each segment based on design

• System test each segment (QA or BA)

• Deploy software into production environment or

• Fix bugs with patches/releases

+ Clear expectations on schedule, budget, and resourcing needs

- Inflexible and cumbersome

• Clear objectives and solution

• Combination of linear and iterative approaches

+ Provides early value in the development life cycle

- Heavy documentation, especially around interfaces with other systems

• Large projects where requirements are not understood

• Combination of linear and iterative

Agile = main concept -> Scrum is one part of Agile

• Uses iterative approach called sprints

Project team completes sprints

Scrum Model Artifacts

Scrum Model Meetings

Sprint Review – Demonstrate product, get feedback once a sprint is done

Sprint Retrospective – Inspect last sprint. Lessons learned

+ Flexible and adaptable to changing requirements

- Leads to scope creep due to no defined end date

• The project is unpredictable and will have changing requirements

+ Reduced time to develop

• Need a system that can be modularized and completed in 2-3 months

No lifecycle or methodology, it is used in iterative methodologies

- Very loose approval and control process

• Project objectives are unclear

23. Understanding the Business Objective

3 key questions to ask yourself before starting a project

1. What is the purpose of the project?

24. Creating a Business Case

It's really used to convince decision makers of a certain course of action.

A business case is generally created by a business executive, a business manager, or a business

5 Phases to an Effective Business Case

• Thoroughly understand the problem or opportunity

Identify all possible solutions to the problem.

Write the Business Case

Review Business Case

• Validate problem statement justifies a call to action

Present the Business Case

• Remind yourself, they haven’t seen this before

• Project team members

Why identify stakeholders?

• It increases the chances for success

How to identify stakeholders to my project?

• Walk through anticipated scope/process

27. Assigning Responsibilities to Stakeholders using a RACI Matrix

RACI Matrix: Why is it Used

Critical tool to understand and align the responsibilities of stakeholders.

R Responsible – who will be doing this task

Something a product must do or a quality it must have