Requirements Analysis Using Event/Response And Use Cases – Event Discovery Part 1

Planning

In prior posts I introduced the Context Diagram and the Event List. In this and the upcoming series of posts, I will define some techniques you can use to discover events and complete the Event List and Context Diagram.

The very first place to start defining events is the Context Diagram. Every input arrow on the diagram represents an event to which your “business” must respond. Recall that our definition of your “business” is the boundary of the business area under study. Inside of the business bubble in the Context Diagram, you have control over the business processes and data flows. Outside the boundary, you can negotiate the interfaces with the Suppliers and Customers but have little or no control over their business processes.

Let’s examine an example of how the Context Diagram can provide events. For this example, let us say the Supplier is an Employee and the input arrow is “Travel Expense Details”.

Our first column on the Event List is “When this happens”. In this example, you would state “Travel Expense Report Submitted”.

The second and third columns are “This Source” and “Gives us This”. In this example, the Source is “Employee”, and “Gives us This” is “Travel Expense Details”.

The fourth column is “Then we do this”. These are the labels of the business processes your “business” will execute upon receipt of the “Travel Expense Details”. You might have a list of processes that looks like this:

  • Verify expenses comply with business policy
  • Approve/Reject Expenses

The fifth column is “Which creates this”. These are the outputs of each business process. The outputs of the first process listed above might be “Valid Expenses” and “Invalid Expenses”. The outputs of the second process listed above might be “Approved Expenses” and “Rejected Expenses”.

The sixth column is “… and we give it to …”. These are the recipients of the outputs listed in the fifth column. In this case the recipient of the Valid and Invalid Expenses could be “Employee’s Manager”. The recipient of “Rejected Expenses” would be the Employee while the recipient of “Approved Expenses” could be the Travel Expense Data Repository.

Be sure to keep implementation details out of this analysis. You don’t want solutions to be constrained by using specifics such as “email:, “reports”, “database”, etc.

In the next post, I will continue the discussion of Event Discovery and show how, once you have a few events listed, you can use these events to discover more events and get the complete scope of the project.

Note: My Kindle book “Project Management For The Real World”, is available at

https://www.amazon.com/author/lettera

Requirements Analysis Using Event/Response And Use Cases – The Business Event List

Planning

I recommend setting up the Event List using Excel. Remember, when I refer to your “business” it means the scope of the area under study. Here are the columns you will need along with their descriptions:

  • Event ID – use a numbering system for your Events so they will be easy to track thru design and testing. I use a scheme where the main number puts the event in context and a number after the decimal point is just a sequential number within that context. For example, Event ID 3.1 where “3” represents sales events and “.1” is the first event in that context.
  • “When This Happens” – this is a brief description of the event that causes your “business” to react with a planned response. For example, “Customer initiates check out”.
  • “This Source” – one or two nouns describing the entity responsible for directly providing data/information to your “business”. Examples are “Associate” or “Customer”. This will match your “Suppliers” on the Context Diagram.
  • “Gives Us This” – a brief description of the data/information being provided. Examples are “Time off request” or “Product ID”. This will match the input arrows on your Context Diagram.
  • “Then We Do This” – the name of the business process(es) you will execute to respond to this event. For example “Time off request approved/denied” or “Record Sale”.
  • “Which Creates This” – the permanent output(s) of the business process(es). For example “Time off approval” or “Product Inventory Update”. This will match your output arrows on the Context Diagram.
  • “And Is Given To…” – The recipients of the output(s). These could be systems, departments, roles, or vendors. This will match the “Customers” on your Context Diagram.

Remember to keep the event items free of technical and implementation jargon so that you do not limit your design options. Note my example “Customer Initiates Check Out”. This could be in a store, online or some other means. The “How” will be decided later, in design, and not here.

In the subsequent posts I will show how to do Event Discovery to elicit a complete set of requirements.

Note: My Kindle book “Project Management For The Real World”, is available at

https://www.amazon.com/author/lettera

Requirements Analysis Using Event/Response And Use Cases – Business Events

Planning

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:

  1. 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”.
  2. 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”.
  3. Data/System State: 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

https://www.amazon.com/author/lettera

Requirements Analysis Using Event/Response And Use Cases – The Context Diagram

Planning

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:

Context_Diagram

Note: My Kindle book “Project Management For The Real World”, is available at

https://www.amazon.com/author/lettera

Requirements Analysis Using Event/Response And Use Cases – The Event Model

Planning

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

https://www.amazon.com/author/lettera

Requirements Analysis Using Event/Response And Use Cases – Business/Project Objectives

Planning

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:

  1. 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.
  2. 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.
  3. 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

https://www.amazon.com/author/lettera

Requirements Analysis Using Event/Response and Use Cases – Analysis Sequence

Planning

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

https://www.amazon.com/author/lettera

Requirements Analysis Using Event/Response And Use Cases – Overview

Initiation

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

https://www.amazon.com/author/lettera

Setting Up A Project SharePoint Site Part 7 – Security

Executing Monitoring and Controlling

You can setup your SharePoint site security at a variety of levels. You will need to be the site administrator to do this. Here are some of the key ways you can secure your site:

  • Site Level – Control access to the entire site. You can deny access to individuals or groups. You can also define large groups of people as visitors (read only). You may assign the appropriate individuals the ability to create content or design content. You can also assign others to be site administrators but I advise you to limit this to one backup person.
  • Library/List level – by default all libraries and lists inherit the site level security. If you want different security for some libraries and lists, you need to break the inheritance and custom define the security for that library/list. This is useful for private or sensitive documents such as contracts and individual performance evaluations. If you secure a library/list, it will not appear in the navigation or the site map for those in which access is denied.
  • Document level – by default all documents in a library inherit the document library security. You may break this inheritance for individual documents within the library. This is useful if you have a very small number of documents to secure and don’t want to establish a new library.

You need to pay close attention to how you setup security so the site will be useful to all stakeholders while simultaneously protecting sensitive information. I suggest you consult with your project sponsor and establish a security access process before allowing access to the site.

For more on SharePoint and other Project Management topics, my Kindle book “Project Management For The Real World” is available at

https://www.amazon.com/author/lettera

Setting Up A Project SharePoint Site Part 6 – Project Status Dashboard

Executing Monitoring and Controlling

Assembling a Project Status Dashboard is a powerful way to use the capabilities of SharePoint. Instead of having to create a weekly status report manually, SharePoint can do it for you using information you are already updating on the site. This can be a big time saver. The page is updated in real-time as you update the component parts that are shown on the page so the sponsor or other stakeholders can always see the latest status instead of having to wait for you to send it.

Another advantage of the dashboard is that it acts like “mission control” for the project manager. I would always start my day on the dashboard to help determine on what I need to focus. In one place you have your upcoming milestones, high impact issues and risks, and action items due in the next 7 days. You can drill into the details of each item right from that page. This beats looking for each piece individually in documents on a network drive.

I use the SharePoint “web part page” to set up the Project Status Dashboard. A “web part page” allows you to assemble a page from existing lists, libraries and other SharePoint components you have already built on your project site. I like the 3-column format for fitting all of the important information.

Here is the information I include and how I format it:

First Row, across all 3 columns:

The Project Information Announcement – contains basic project information such as the name, number, description and benefits, sponsor name and project manager name.

Second Row, across all 3 columns:

The Project Status Announcement – contains a few sentences from the Project Manager and Lead Business Analyst on the state of the project. I like to update this weekly or whenever an important milestone is reached.

Third Row:

Column 1: The Project Health Scorecard

Column 2: A view on the Issues list containing only high impact Issues, and under that, a view on the risks list containing only high exposure Risks

Column 3: Upcoming Milestones (current month and next month)

Fourth Row, across all columns:

Time Off Calendar for key project team members and stakeholders

Fifth and Sixth Rows, across all columns:

Action Items Due in the next 7 Days – I use a view over the Action Items List.

Action Items Completed in the last 7 Days – I use a view over the Action Items List.

Seventh Row, across all columns:

Key project documents from the document libraries.

You may need to educate and train your users to come here first for information but it will be well worth your time to do so.

For more on SharePoint and other Project Management topics, my Kindle book “Project Management For The Real World” is available at

https://www.amazon.com/author/lettera