Last week I pointed out that most internal IT initiatives probably have something to do with changing an existing business process or creating a new business process. Another thing that almost all internal IT initiatives deal with is collecting or providing data.
As a result, not only do you need to know how to build a shared understanding about the business processes you’re supporting, you also need to understand the data that your product needs and that your product needs to provide.
Most of my career has been working on systems that collect data or provide data organized in a helpful fashion. As a result, I’ve had the chance to learn many different ways to build shared understanding about data.
This week’s Inside Product Ownership shares resources that describe how you can build shared understanding about the data you’re working with. From identifying the key interfaces your product needs to determining what data you need to work with, to knowing which technique to use to remember that information, these resources will help you get a better grasp on the data you need to deal with.
A context diagram is a model that shows how your product interacts with outside people, organizations, and/or systems. The context diagram helps you to identify the interfaces you need to account for, helps you to identify scope, identify potential stakeholders, and build a better understanding of the context in which you are working.
How to discover useful requirements for business intelligence
When you want to understand a stakeholder’s business intelligence needs completely, the following steps often prove very helpful:
- Start with the questions stakeholders want to answer and decisions they want to make
- Focus on value and feasibility to determine what to do next
- Dive into detail only when you need to
Working Backwards on Business Intelligence Projects
Most information systems are intended to accept, process, and provide information to either support a business process, or to provide information that people in the organization use to make decisions or to answer questions.
Business intelligence projects are often started when stakeholders desire to meld information from multiple systems, or arrange data in a way the source systems were not intended to support. The trick to making the most effective use of business intelligence systems is to understand those questions and decisions and focus on the specific pieces of information you need to answer those exact questions or make those particular decisions, and you don’t have to deal with data that you don’t need.
The Seven Information Smells of Domain Modelling
Domain modelling is a powerful technique that you can use to get a better understanding of the data your product needs. Chris Matts and I discussed signals in your domain model that tell you there are more questions to ask. We call these signals “information smells”, and they indicate that you may not have a complete understanding of the information your domain cares about.
When you pay attention to these information smells and address them you can ensure your have an accurate representation of the data you need to know and can help you know when to stop your analysis efforts.
Requirements for Requirements?
Over the course of my career, I’ve found myself in some rather surreal conversations. A conversation I had a while back with a data analyst is probably one of the most twisted. The data analyst suggested that we create a requirement to capture data about data that are requirements…
Once I wrapped my brain around why someone would suggest identifying a requirement to identify requirements, I realized it was worth discussing the concept for a couple of minutes. It gave me an opportunity to discuss how the context in which you record information can be as useful as the content that you record.