Whatever Scopes Your Boat

Before you can build something, you have to know what you're going to build.  This is obvious and hardly bears saying out loud, but it doesn't mean I've never fired up an editor and started coding with only the vaguest semblance of a plan.

For this app, and specially for this blog, I want to be a lot more deliberate.  We're going to follow the software development life cycle, and that means defining our scope by doing some requirements gathering.

These boats appear to be floating.  And come to think of it, probably are.

Methodology

There are plenty of ways to approach requirements gathering.  One popular method right now is to create "user stories," which, as the name indicates, are supposed to present a more detailed, purposeful narrative than dry, detached "use cases."  User stories are the new hotness, he said, invoking a thirteen-year-old, poorly-received Will Smith sequel. User stories have three parts:

As ______,
I want to ______,
so that I can _______.

Here's a laborious example from Wikipedia:  "As a user closing the application, I want to be prompted to save anything that has changed since the last save so that I can preserve useful work and discard erroneous work."  Wow.  Okay, I cringe a bit at something like this, but as with any project methodology, you take what works for you and ditch the rest.

How about this?  As an app developer, I want to finish writing the requirements so that I can get on with writing software.

There are some useful things about this sentence structure.

Clause 1: this part helps us identify the actors that will be using this system and the roles they will play.  Good things to keep in mind.

Clause 2: here's the meat.  It's usually an action, and may translate directly to a feature of the app.  I say "may" because sometimes, a use case can be satisfied in a non-technological way; say, by altering someone's business process.  The most effective software is the software you don't even have to write.

Clause 3: ugh.  I understand the purpose: the "so that" part of a user story is supposed to keep you focused on the user's goals and desires.  The human element, I suppose.  But it's often redundant with clause 2, and beyond that, it just feels awkward to write or say.  I'm ditching it.

My App Requirements

As with most things, I decided to approximate the recipe for user stories.  I ended up with something like this:

--- 
Instructor

As an instructor, I want to...

Class Setup 
Create a new class
Add students to the class
Delete students from a class without losing history
Edit details for a student
---

Etc.  It nods in the general direction of user stories by keeping things oriented around actors and their verbs.  I then divided each statement into sections that group certain categories of functionality.

Sky's the Limit

This is the "blue sky" phase.  Whatever functionality you could possibly conceive as being a part of your app, put it in.  That's what I've done:  the full document is a bit long for this blog, but you can find it all here.  

The full document.  This is as much as I could screencap at once.

Don't get overwhelmed if something seems too big or hard to implement.  There will be time to assess that later.

Paring it Down

Okay, it's later!  I've put a lot of things into that requirements document that could be classified as "nice to have."  That part about letting students request excused absences?  Total frosting.  In fact, I'm not assured that students need to be involved in this app at all.  I think I could sell this to instructors for a couple bucks, but I wouldn't have those instructors ask students to do the same. 

That's far from the only extraneous feature in this document.  I also can't lose sight of my primary meta-requirements.  I need this project to be lean and achievable.

That's where MVP comes in.

Minimum Viable Product

There is perhaps no greater goal in initial requirements gathering than identifying your Minimum Viable Product.  MVP is the set of requirements that absolutely MUST be implemented for your app or business model to function.  MVP means cutting your requirements to the bone to ensure that instead of spending a lot of time building nothing, you actually build something.



For a business, that might mean "the minimum feature set that gets us monetizing users," though actually monetizing seems to be pretty far down on most startups' priority list these days.  For us, it means "the absolute fewest things we can implement and still reasonably claim this app takes class roll."

Take a look at my document now:  requirements with MVP.  I've highlighted the bare minimum of functionality in yellow, with a few items in orange that aren't strictly MVP, but are things I want in this app before I release v1.0.  Looks a lot more management now, doesn't it?

I've gone from two pages full of use cases for both Instructor and Student to this:

Minimum Viable Product

This scope feels right.  There are plenty of things on that original list that I want, but those I can save for later -- as free upgrades, or maybe in-app purchases.  The Minimum Viable Product is both achievable and releasable.

Nothing Stops this Train

Requirements gathering doesn't stop here.  Even MVP scope will shift over time as the project continues, but it gives us a foundation.  We'll also want to keep our "blue sky" list in mind as we design the software, taking care to leave hooks for future functionality.

So we're done for now.  It's on to the next phase:  design!