Requirements Elicitation Techniques Part 5 – Data Modeling

Planning

Data modeling is a complex topic. Becoming a professional data modeler takes months or years of education plus practical experience. It is not my intent to teach data modeling in this brief post, but to show how it related to requirements elicitation.

I introduced some of the concepts of data modeling in Part 4 of this series, “Business Rules Analysis”. The relationships between entities are the business rules and they are fixed in the structure of the data. Examples of these rules are “A Customer lives at one or more Addresses” and “An Address may contain one or more Customers”.

Entities can be found in the nouns in your requirements. They are people, places and things about which the organization wishes to store data. In the example above, “Customer” and “Address” are entities and are therefore capitalized in the rules statements.

Attributes are the elemental pieces of data that are associated with each Entity. In the logical data model, each attribute must be stored with one and only one Entity. The logical data model represents the business Entities, Attributes and Relationships without regard to physical implementation.

The physical data model represents how the logical data model will be implemented in a relational database. Here are two examples of the differences between the logical and physical data models:

  • In the logical model, you can have “many to many” relationships as in the Customer / Address example above. In the physical model you cannot implement many-to-many relationships, so there would need to be an additional table to store each Customer / Address combination.
  • In the logical model,  Attributes belong to one and only one entity. In the physical model, attributes can be included in multiple entities due to inclusion on table keys or for performance reasons.

The data is an important part of requirements gathering. It is an important tool in Event Discovery, as you will ask data related questions such as “What does having this data allow you to do?” and “If I took this data away, what would it prevent you from doing?” Other Event Discovery questions are “What events cause this attribute to be added (or changed, or deleted)?”

I would recommend all Project Managers at least be able to read and understand an Entity-Relationship diagram.

Advertisements

Requirements Elicitation Techniques Part 3 – Benchmarking

Planning

The technique of “Benchmarking” is sometimes used in the Requirements gathering process. You compare your company’s processes and performance metrics to industry best practices from other companies. The knowledge uncovered in these investigations can be used in process improvement initiatives or to solve thorny problems you encounter on your project. I have managed many projects where a typical question in a meeting is “What does Company X do in this case?”. “Company X” is typically the main competition for your company and is usually recognized as an industry leader in the area under study. You may or may not get “Company X” to speak with you on a particular topic, depending on the relationship and the level of competition.

Benchmarking can save a lot of time on a project by avoiding the “let’s reinvent the wheel” syndrome. If someone else has figured it out, why waste your own time? Now you may find their solution cannot be completely adapted to your specific situation but there are usually as least some pieces that can be used and be very valuable.

Benchmarking is a supplementary requirements technique. It will never be the only technique you use but can add important additional information to the requirements process. On every project you should at least ask yourself if Benchmarking can add value to the requirements process.

Requirements Elicitation Techniques Part 2 – Acceptance Criteria

Planning

If you search the Internet for “Acceptance Criteria” you will see definitions like this: “Acceptance Criteria are the conditions that a software product must satisfy to be accepted by a user, customer or external system.” There are no shades of grey, the condition either satisfies the criteria or not. There are no “90% satisfies”.

Acceptance Criteria should be established before development begins. The reason for this is that the criteria needs to guide the development. If you write them during or after the development, you will just be verifying what was built and not the customer intent.

Like all good business requirements, the criteria should be “what” not “how”. For example, you might state “Upon submission of the completed application a notification is sent to the Director”. You don’t want to state “Upon clicking ‘Submit’ an email is sent to the Director”. Avoiding implementation specifics opens up new possibilities for a design solution.

In many ways, the “Event/Response method” (see my prior posts on this topic) and “Acceptance Criteria” are very similar. With Event/Response, we document a triggering event, the data sent and who sends it, what we do with it, the outputs and who receives them. With Acceptance Criteria, many use the format “Given some precondition, when I do some action, I expect some result”. These are essentially the same things although Acceptance Criteria can be at a lower level (the Use Case and Functional Requirements level).

You do not approach your user or customer and ask “What are your acceptance criteria?”. This will mostly elicit blank stares. You will want to use other elicitation methods such as Event/Response and Use Cases, and the derive the Acceptance Criteria from there. You can do this by prioritizing your requirements (e.g. “priority 1 = must have or cannot go live, priority 2 = can go live without it but must have within 1 month of go live, priority 3 = nice to have if it fits within the budget and schedule”). In this case, priority 1 requirements are the acceptance criteria for go live and priority 2 requirements are the acceptance criteria for project completion.

Some examples of Acceptance Criteria:

  • If I am a System Administrator, I can add, update or delete accounts.
  • I can search for users by last name and can enter a partial string and receive the results of all that qualify
  • I can filter my staff by availability for a given shift

Requirements Elicitation Techniques Part 1 – Overview

Planning

In the previous series of posts I introduced my favorite requirements elicitation technique, “Business Event/Response”. Of course there are many other techniques which can act either as complementary to or in place of “Business Event/Response”. The techniques you choose depend on many factors including the type of project, knowledge depth of the Subject Matter Experts (SME), the availability of documentation, time constraints, etc.

A skilled Project Manager that is also a seasoned Business Analyst is a very valuable commodity. I encourage all PM’s to increase their BA ability by reading books, attending webinars and seminars, and putting their new knowledge to practice. There is no substitute for actual work experience in this realm.

Here are the topics I will address in the series:

  • 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
  • Part 14 – Summary

Requirements Analysis Using Event / Response and Use Cases: Final Summary

Planning

In the preceding posts, I gave you some guidance on how to execute the Event/Response methodology for scope and requirements analysis. In this last of the series of posts on this topic, I will take the 5,000 foot view and put it all together in a summary of steps.

  • Step 1 – Define the Business Objectives (the measurable benefits realized after implementation). These will be used to verify the scope and requirements.
  • Step 2 – Define the Project Objectives (the products, services and/or results delivered at project implementation). These will also be used to verify scope and requirements.
  • Step 3 – The Context Diagram. Look at the area under study as an outsourced business, with Suppliers (of data) and Customers (recipients of data/information/results).
  • Step 4 – The Event List. This represents your “business model”. You define all of the events that “wake up” your business and require a planned response. In the prior posts, I presented a variety of techniques for fleshing out these events. Included in the Event List are your business processes and stakeholders.
  • Step 5 – Validate the Event Model. Compare your event scope with the Business and Project Objectives and verify with the Project Sponsor that all objectives are covered by this scope.
  • Step 6 – Construct Use Cases. Use the defined business processes in the Event Model as the starting point for creating Use Cases.
  • Step 7 – Test Planning and Execution. The Event Model is a wonderful framework in which to define your test scenarios and cases. Take advantage of all the work you did in the requirements phase to make your test planning and execution easier.

That’s it for this topic. I hope you found it informative and useful. I have used this technique successfully in many real-world projects.

Requirements Analysis Using Event/Response and Use Cases: Test Planning & Execution

Planning

In addition to being a great way to elicit the complete scope of a project, the Event/Response methodology delivers a comprehensive framework for test planning and execution. When using this methodology, what many call “User Acceptance Testing” can be replaced by the term “Event Testing”.

In my prior posts on this topic, I identified the primary deliverables of the Event/Response methodology as:

  1. The Event List (containing the event that triggers the response, the origin and data content of the information flow into your “business”, the named processes, the outputs of the processes and the destinations of the outputs), and
  2. The Use Cases. You can plan to test by simulating the actual Events, creating the data flows, executing the processes and examining the outputs. The Use Cases give you a good start on creating the data and usage variations for each Event. Doing this yields a direct mapping of the scope and requirements to the test cases and execution.

Note that since the Event List also contains the roles of the actors initiating the events and processes, as well as the roles receiving the outputs, security testing can also be built into this framework.

Another major plus of planning and executing the tests this way is that you are testing the system as it will actually be used in context, as opposed to functional testing which tests bits of functionality in isolation.

A recent project of mine used this methodology and yielded 180 Events and over 1,600 test cases. Because of this comprehensive approach, the system was very well tested and only experienced minor problems after implementation.

Requirements Analysis Using Event-Response / 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