As a product manager, I have a large bag of tools at my disposal for my various projects. Recently, I’ve started to focus more on Enterprise Content Management (ECM) projects. I’ve noticed that there are a set of requirement models that I tend to use often.
For those unfamiliar with requirement models, I use a set of visual models that I use that helps me with the analysis process. These models help me organize large groups of information to understand the ultimate solution. They also help me look for gaps in my understanding to ensure that the requirements are as complete as possible.
The requirement models that I have found very useful with ECM projects are:
- Business Objectives Model
- Ecosystem Map
- Business Data Diagram
- Process Flows
Let’s look at each one of these models.
Business Objective Model
The Business Objectives Model helps me understand the organization’s problems and what solving that problem looks like once solved. At the highest level, it’s why we are doing this project. Understanding the business objectives helps me ensure that the solution will meet those objectives. I also use this model to help us with scope control. The model looks something like the template below. We’ll notice several different problems and objectives, and they often show up in layers. We do this to reflect our reality; our life is rarely as simple as “I have a problem, I have an objective, and I have a solution.” If you would like to learn more about this model, take a look at this blog post.
Ecosystem Map
An Ecosystem Map shows all the systems related to the environment and the high-level data objects that flow between those systems. An Ecosystem Map helps us understand the integrations required for the solution and any impacts on existing integrations. We look for any logical system to consider and identify the high-level data object that flows between the systems. From a requirements perspective, I use this model to help me analyze the integration; what data needs to flow, what is the frequency, is it automated or not, etc. Without this model, I risk missing an integration as part of my overall requirements effort. Especially for an ECM project, this model can help identify where the content is coming from and help analyze how that content will get into our ECM system. The model looks like this:
Business Data Diagram
A Business Data Diagram (BDD) looks at how the business thinks of its data, the relationships between data objects, and the cardinality relationship. A BDD may look similar to an Entity Relationship Diagram (ERD), but it does have a different purpose. A BDD focuses on the business; how they think of their data, where an ERD focuses on the actual implementation of the data objects in a database schema. Use a BDD to identify these data objects, which will lead to the data fields for the solution, and think through how these data objects are created, edited, deleted, etc. For an ECM project, these data objects may be the beginnings of the metadata that needs to be attached to our content.
Process Flows
I can’t think of a project that I have worked on where I didn’t create a process flow. Process flows have become a core requirement model for me, helping me understand how the business will use the ECM system and help to model out a workflow that may be required. Identifying if or how the business will change its processes for the new tool is essential, not only from the perspective of configuring the application but also from a change management and training perspective. I love to derive requirements from process flows. Methodically look at each step and ask, “What does the system need to do here?” The step may be a manual one, and thus there are no requirements. That’s ok; the important thing is considering the step before moving on to the next step in the process flow. This blog post can provide you even more information about process flows.
These four requirement models give me a good overall perspective of the project, and from here, I can derive many of the needed requirements for the solution. However, additional requirements will be required. For example, we will still need to identify all the metadata desired (although the BDD above is a start to that process) and then will need to map content types to various metadata. Other requirements may be necessary, but I’m off to a great start!
