For the purpose of this analysis approach, “Business Events” are anything that occurs that causes your “business” to initiate a business process. Defining all of the Business Events in scope will lead to discovery of the business process in scope.
There are three main types of Business Events:
External: These come from outside of your business and you have little or no control as to when or how often these events occur. Examples are “Customer purchases Product” or “Associate requests time off”.
Temporal: These events happen at regular predetermined intervals. These intervals are required, they are not a business or design decision. Don’t let technology limitations determine the interval. Good Example: “It is time to file quarterly taxes”. Bad Example: “Every two hours the HR system sends employee information to the Financial System”.
Data/SystemState: Occur when the data or system reaches a predetermined condition. These are usually Business Rules or Policy decisions. Example: “Product is re-ordered when the inventory level reaches 5”.
The input arrows on the Context Diagram are the starting point for event discovery. In the next post I will define the elements of the “Event List”.
Note: My Kindle book “Project Management For The Real World”, is available at
The Context Diagram is the place to start when doing your analysis. It should be done in conjunction with the stakeholders that are most knowledgeable about the business processes for the domain under study. The initial list of Business Events will be derived from the Context Diagram.
Start with a circle in the middle of the diagram. This represents the area of the business in the scope of the project. All of the processes within this circle are in scope and are able to be modified or added to as part of the project scope. Think of it as if this business function were outsourced to a service provider and the Executive Sponsor of the project is the CEO of this service provider. What would they need to know to create a business model?
First, you would want to define “who are my Customers?” Your Customers are recipients of your business’s outputs (in most projects, these are flows of information and data). Ask the key stakeholders “who are the current recipients of information your business function?” Draw the Customers as rectangles on the right hand side of the diagram. It is not important at this time that you have the complete list of Customers, only that you have some. We will complete the list of Customers in an iterative process in conjunction with the Event/Response Model.
Next, define the types of information that flow to each Customer. Draw these as arrows from the center circle and connecting to the Customer rectangle. Have a short, high level description of the flow on each arrow.
After that you need to define “who are your Suppliers?” The Suppliers are providers of the business’s information and data. Ask the key stakeholders “who are the current providers of information for your business function?” Draw the Suppliers as rectangles on the left hand side of the diagram. It is not important at this time that you have the complete list of Suppliers, only that you have some. We will complete the list of Suppliers in an iterative process in conjunction with the Event/Response Model.
Next, define the types of information that flows from each Supplier. Draw these as arrows from the Supplier rectangles and connecting to the center circle. Have a short, high level description of the flow on each arrow.
Rules for Suppliers and Customers:
They can be individuals, roles, departments, organizations, systems, vendors, etc. Anything that is a net originator or receiver of data or information from your “business”.
Some entities can be both Suppliers and Customers. so they will have arrows going in both directions.
If you are struggling with whether a Supplier or Customer is inside or outside the circle, the general rule is for entities outside the circle, the project has no control over their processes. The project can only change the nature and content of the information flows to and from these entities.
There are no flows represented that go from entity to entity. They may exist but they are of no concern to the project.
Here is an example of a Context Diagram:
Note: My Kindle book “Project Management For The Real World”, is available at
The Event Model looks at the scope of your project as if this business function is being outsourced to a third party business and your Executive Sponsor is the CEO of that business. This is the new way of thinking about requirements that I referred to in the Overview post.
The Event Model consists of the following elements:
The Context Diagram – shows your business boundary as a circle in the center of the diagram with your suppliers, customers and information flows surrounding the center circle. I will present this in detail in the next post.
The Event/Response Model – this contains the detail of the events that “wake up your business” and requires the business to have a planned response. It is progressively elaborated in conjunction with the Context Diagram. More on this in a future post.
Use Cases – are derived from the Event/Response Model and show the specific steps required for each business response. At the end of the requirements analysis, this becomes (or is the basis for) your “Business Standard Operating Procedures Manual”. Functional Requirements are derived from the Use Cases.
An important thing to remember when creating the Event Model is to keep it independent of technology. It needs to address “what we do” and not “how we do it”. Doing this will help you envision more design alternatives than you would if you locked in a solution at the requirements level.
In the next post I will give you a closer look at how to create a Context Diagram and utilize it to get the requirements discovery rolling.
Note: My Kindle book “Project Management For The Real World”, is available at
If you search this site using the keyword “objectives”, you will see my prior posts on the importance of documenting your Business and Project Objectives, as well as how to properly define them. Those posts framed objectives in the context of the Project Management process. Having the objectives defined is also critical in the requirements analysis process.
Here are some of the key reasons for knowing your Business and Project objectives in advance of your requirements analysis:
Ensure that everyone on the project team understands the project vision. There is a saying in the military that “no plan survives contact with the enemy”. That is also true for projects (where the “enemy” is usually time and resources). However, if everyone understands the commander’s intent (the “objectives”), then it is easier to change and adapt the plan. Conditions may make you unable to execute the original plan, but you are always responsible for achieving the commander’s intent.
The Objectives guide everyone’s decision making. There are many decisions made each day on a project. They are made by everyone on the team, not just the management. Along with empowering people to make decisions, you must give them the tools to make the right decisions. Chief among those tools is making sure they know and understand the Business and Project Objectives.
The Objectives are used to validate the Requirements Model. At the end of the first round of analysis, you will compare the results to the documented Project and Business Objectives. Do your requirements address all the deliverables in the Project Objectives? If not, another round of analysis is needed. Will the requirements achieve the Business Objectives? If not, understand why. Has your analysis revealed additional Project Objectives? If so, these must be addressed in your Change Management process in order to change your Project Charter.
In the next post I will define the Event Model, with subsequent posts addressing each element in detail.
Note: My Kindle book “Project Management For The Real World”, is available at
Getting requirements right is a process. Your business stakeholders will rarely (if ever) be able to give you all of their requirements without some method of generating relevant questions to draw the requirements from them. What I am going to present in this and the following posts on this topic is NOT a new way to document your old thinking. It is a new way to think about requirements.
The deliverables created from this approach are:
Identification of all processes in scope
Documentation of the specific Use Cases for each process
Identification of all of the stakeholders that interact with the business processes
Creation of a framework with which you can generate and execute your test cases
Many analysts start and end their requirements elicitation with “functional requirements” (e.g. “I need to search by Last Name” or “Requests for time off need to be approved by the manager”). In the Event/Response/Use Case approach, functional requirements are derived from the Use Cases at the end of the analysis process.
The analysis sequence is as follows:
Business Objectives
Project Objectives (1st cut)
Event Model
Project Objectives (verified)
Use Cases
Functional Requirements
In the next post, I will discuss how the Business and Project Objectives are defined and used in the Event/Response methodology.
Note: My Kindle book “Project Management For The Real World”, is available at
This is the start of a multi-part series on my favorite requirements elicitation technique: the Business Event/Response Analysis. Early versions of this methodology were developed in the late 1980’s by some of the great system development minds of that era. Since then it has evolved and I have adapted it to meet the needs of whatever organization for which I am working.
There are some that think you can gather requirements by just asking the sponsors and users “what do you want?”. Needless to say, this method will generate incomplete requirements and tends to start and end with functional requirements. In the latter half of the project when large requirements gaps are discovered, the sponsors/users blame the analyst and vice versa.
When I teach on this topic, I tell the analysts it is their responsibility to gather complete requirements. Given this, we need a method that will (1) generate the appropriate questions to ask, (2) ensure that we have the complete set of requirements, and (3) allow us to derive the functional requirements from the model.
The Business Event/Response method meets these desired outcomes. The advantages are:
It helps the Business Analyst create the questions needed to draw the requirements from the Business Owner, even if the Analyst has no knowledge of the business area.
It organizes the requirements in the context of Business Processes and Usage to promote better understanding.
The output serves as a significant starting point for defining the testing scope and scenarios.
In the upcoming posts I will describe this method in detail.
Note: My Kindle book “Project Management For The Real World”, is available at
In the prior posts in this series, I introduced the following requirements elicitation techniques:
Part 1 – Overview
Part 2 – Acceptance Criteria
Part 3 – Benchmarking
Part 4 – Business Rules Analysis
Part 5 – Data Modeling
Part 6 – Document Analysis
Part 7 – Interviews
Part 8 – Non-functional Requirements
Part 9 – Observation
Part 10 – Prototyping
Part 11 – Root Cause Analysis
Part 12 – Surveys and Questionnaires
Part 13 – SWOT Analysis
These are in addition to the Business Event/Response technique which I discussed in detail in a prior post. These techniques can be considered a “toolbox” from which you can select the appropriate tools for the job. You will likely never use all of these in a single project. Based on the type of project you are working on, you will select the techniques that fit the size, background and scope of the project. Every Project Manager should have familiarity with these techniques and be able to apply them. They are core techniques in the Business Analyst’s Body of Knowledge (BABOK).
If you are a Project Manager and don’t currently perform the Business Analyst function, I encourage you to get training in this area. PM’s that can perform this function are immensely valuable to their organizations.
Feel free to leave comments on your own experiences as a Business Analyst. Include what worked well, what didn’t and why.
The acronym SWOT stands for “Strengths, Weaknesses, Opportunities, Threats”. It can be a useful tool to analyze a business process undergoing change. Honest evaluation from all parties is important here. The group undergoing the evaluation must not feel threatened by the analysis. Note that “Opportunities and Threats” are external factors beyond the scope of control of the assessed group.
As with all endeavors in the field of project management, always make sure you have first defined your objectives and expected outcomes of the analysis. This will ensure that proper use is made of the results.
The SWOT evaluation team should be comprised of a cross-section of middle and upper management of the business process owners, as well as those who actually participate in the execution of the business process. The team should be instructed to first identify the Strengths, Weaknesses, Opportunities and Threats independently to avoid group bias. Then the group is brought together to compare notes and agree on the final list.
You then make a matrix with S and W as the rows and O and T as the columns. The cells are filled in by the evaluation team as follows:
SO – How can the groups strengths be leveraged to exploit the potential opportunities?
ST – How can the group use its strengths to ward off potential threats?
WO – Can the group use an opportunity to eliminate or mitigate a weakness?
WT – Can the group restructure itself to avoid a threat?
The answers are analyzed to determine cost of implementing vs. value and from that you can determine which of these the project sponsor wishes to include as part of the business requirements for the project.
For some projects you may need to gather information from many people in a short time. When you have this condition, surveys and questionnaires can be very efficient.
First lets define the terms. A survey encompasses all aspects of the research process (design, construction, sampling method, data collection and response analysis). A questionnaire is a tool used for a survey and is a set of questions with a choice of answers.
Let’s look at the steps to conducting a requirements gathering survey:
Design – You will need the answer to questions such as “What are the objectives?”; “What media will be used?”; “Who will it be sent to?”; “How long will be given to respond?”; “What will you do with non-responders?”; “Who will compile and analyze the data?”
Construction – “Who will determine the questions to ask?”; “How many questions will be asked?”; “Will you allow open-ended responses?”; “Who will create and distribute the questionnaire?”. A tool such as Survey Monkey can be useful.
Sampling Method – You will need to define the target population. If the entire population is sufficiently small, you can include everyone. If the population is large, you will need to use statistical sampling methods. Consult the statistician on your team or company for advice on the various methods.
Data Collection – The method of data collection should have been determined in design. Collect and summarize the data as a prerequisite to response analysis.
Response Analysis – This ties in to the objectives you defined in design. The method and people involved were determined in design. The responses are used to guide the direction of the requirements.
The purpose of root-cause analysis is to determine the underlying source of a problem under study. Doing this will help ensure the requirements attack the real problem and not just the symptoms.
A critical element is to challenge the current business thinking and processes. You want to overcome the “we’ve always done it that way” answer to the question “Why do you do this?”. I recently managed a project where it took interviews with dozens of people to finally get the answer to the question of why the pay week started on a Saturday instead of Sunday where the sales week started.
The steps to root cause analysis are:
Define the problem under study and understand the impact
Analyze the problem to determine the root cause
Agree on solutions to prevent the problem from occurring
One technique to analyze the root cause is the “five whys” to explore the nature and true cause of a problem. This means repeatedly asking “why” after a question is answered until you uncover the real root cause. It may be more or fewer than five, but five is a good rule of thumb.
You can create a visual of your “five whys” analysis using a “Cause Map”. A Cause Map is simply a block on the left that identifies the problem, an arrow labeled “why” going left to right to another block that answers the question, then an arrow labeled “why” going left to right to the next answer and so on until the root cause is identified.
Root Cause Analysis is a good addition to your requirements analysis repertoire. If your project is not addressing the true root causes of the problem definition then you are unlikely to achieve the defined business objectives.
Practical Project Management Tips and Tools 