Documenting Your Product – Part 4 – Data Models
This is the third in a series of posts about documenting technology product builds. If you missed the intro, Part 1 – Use Cases, Part 2 – Requirements or Part 3 – Sequence Diagrams go check them out. At the end of this series, I’ll be providing a bunch of templates and resources to make this process more manageable.
For this series, we’re building a product called PetSitPro, which matches pet sitters with pets in need of pet sitting. As a refresher, a Pet Sitter is someone who provides pet care, and a Pet Parent is someone who has a pet to take care of.
In this post, we’re going to talk about how you organize the data in your system. Developers call this a data model. This topic can go as deep as any topic in building software, and there is serious religion amongst us professionals about how you organize data. We’re going to cover the basics here, and even within those basics there will be debate amongst those who have strong opinions. If you’re interested in digging in further on a tangential topic, you can read my post about how data is stored in a database. But do that later. Right now let’s get cranking.
Keep in mind as we go through this that your job as a product owner is to communicate concepts, not solve all of the technical decisions. If you get something
Starting Your Data Model
The first thing you do when starting to build your data model is to list all of the things you want to keep track of. Pretty simple, or so it seems. Let’s look at our app and think about the kinds of data we need to track:
- Users
- Roles (are they a Pet Sitter or a Pet Parent?)
- Pets
- Jobs / Orders
- Calendars
- Payments
- Comments
- … We’ll stop here for now
Now, let’s break a few of these down. We’ll start easy.
Users
For a user, we need to keep track of the following:
- ID
- Name
- Password
- Date of Birth (to make sure we don’t violate labor laws)
- Picture / avatar
- Phone number
- and so on…
These pieces of data we keep track of are called Properties. We’re going to keep using this term so remember it.
Role
- ID
- Name
Here’s where it gets interesting. Because a user of our system could conceivably be both a Pet Parent and a Pet Sitter, the model has to allow for more than one Role per User. There are a number of ways to do this, but for now, we’re just going to add a Property to the User model called Roles. Note that it is a plural, indicating more than one. If we look at our User model again, it looks like:
- ID
- Name
- Password
- Date of Birth (to make sure we don’t violate labor laws)
- Picture / avatar
- Phone number
- Roles
Pretty cool right? You’ve just defined your first One (User) to Many (Roles) relationship.
Pets
- ID
- OwnerID
- Name
- Species (Cat, Dog, Hamster, etc.)
- DateOfBirth
- Special Instructions (Fido has to go out 3 times a day, etc.)
- …
Again, as for relationships, a User can have Many Pets. But you’ll notice that in this model we associate the Pet to the User via the OwnerID Property. This isn’t the only way to do it, but it helps to communicate the concepts. Again, this is your role.
Where To Go From Here
Take the rest of the models we talked about (Orders, Comments, Calendars, etc.) and map them out on a whiteboard. Think through how each of these data models relates to the other and draw arrows between them. Erase, correct, start over.
When you’re done, you will have a fully thought out model that you can share with your developers and start to iterate on. While you may not be great at this the first few times around, it won’t take long to get the hang of it. Remember, the more you understand this process, the more you control.
Next time we’re going to talk about how you share all of this work you’re doing with the rest of your team and gather feedback.