Data Modeling and the Specter of Scope Creep

It's time for one of my favorite steps in the design phase: data modeling.  Much like the UI design exercise in my previous post, this process is a way of realizing the requirements and starting to visualize how things will actually work.

We'll also see how easy it is to fall into the trap of scope creep.

Let's start with that data model.




Attendance Data Model

I used LucidChart to create this model.  LucidChart is basically Microsoft Visio for your browser, and it freed me from my last remaining reason to run Windows.  It also has a pretty solid explanation of entity-relationshp diagrams, which is what I just built for my app:

Full document here

As you can see, it's a pretty simple model.  Each Course has many Roll Calls, and each one of those has many Attendance Records.  Each Attendance Record links to a Student.  Courses and Students have a many-to-many relationship, since students may take multiple courses.

The Problematic Student Entity

If there's anything bothering me here, it's that Student model.  It's a little too specific.  Students are a kind of Person.  Is there really no case where I need to describe a Person who isn't a Student?  How about the implied user of the app, who is an Instructor?

Let's just go ahead and rename that model.  Instead of Person, maybe we'll say User.  After all, some of the non-MVP use cases involved students using the app.  This makes the "classification" attribute (ie freshman, sophomore) a little out of place, but I'll leave it for now.

The Student has become the Master User.

There's also the possibility that an Instructor in one class may be a Student in another.  That's a bit of an edge case, though, and it carries another implication:  person records might be shared across instances of this app, and you may be able to add students from the global pool of users who have registered for this app.

Carry that thinking a little further, and you'll realize that person records would need to be global, unique, and shared.

Record Ownership
 
It gets more complicated.  In the minimum viable product scope, Student records are created and maintained by the user, the instructor.  If user records, including students, are global across all app downloads, we're left with a ton of questions:

• who owns those records?
• must each student record be created by the student themselves?  
• how would we ensure the account creator is, in fact, that person?
• who can edit student records? 
• what if we end up with multiple accounts for the same person?
• can we identify and merge those duplicates?  How?

As if that weren't enough, the biggest question impacts usability: does this mean an instructor can't use the app until every student logs in an creates an account?

Scope Creep

Do you see what just happened?  I started with good intentions, trying to optimize my design for future functionality.  By the time I was done, I had expanded my scope to include user accounts, authentication, and identity management.  That is NOT minimum viable product:  that's serious scope creep.

Scope creep is a danger to any project timeline, but it's an absolute killer in this stage, before implementation has even begun.  If you start getting anxious about the effort involved in what you're about to begin, you might not begin at all.

Getting Back to Safety

As always, we'll use MVP as our guide.  If this app is so wildly successful that I one day need to include more advanced user functionality, well, I'll be happy to meet those technical challenges then.  For now:

• no user accounts
• assume app user is an instructor
• let instructors create and maintain student records
• allow students records to be used for multiple classes

I'll make these two slight concessions to the future:

• refer to "person" instead of "student"
• remove "classification" attribute.  instructors can track this info in the free-form "details" field if desired.

That's enough for this post.  Next time, I've got to decide on my persistence implementation:  should my storage be local, or in the cloud?  Stay tuned!