[1/2] Become a Full Stack .NET Developer: Extracting Core Use Cases from Requirements

View fullsize

The requirements document for GigHub.

Following on from the course introduction, the second module gave us the requirements document for the GigHub app.

From here we were given an exercise to derive the use cases that would be required of GigHub. We were warned not to get bogged down at this earlier stage on nitty gritty details (which can often change as a project evolves), but to concern ourselves just with the high level features of what the app should do by extracting a few keywords from the requirements document. The details can come later when we get closer to implementation.

The main use cases that were identified and defined by domain category were:

Authentication Use Cases: Signup, Login, Logout, Change Password, Edit Profile

Gigs Use Cases: Add a Gig, My Upcoming Gigs (for artist), Edit a Gig, Remove a Gig, Remove a Gig, View All Upcoming Gigs, Search, View Gig Details

Gig Calendar Use Cases: Add a Gig to Calendar, Remove a Gig from Calendar, View Gigs I'm Attending

Following Use Cases: Follow an Artist, Unfollow an Artist, Who I'm Following, Gig Feed

Several of the use cases were not explicitly defined in the requirements document but were logical extensions of what was in the document. For example, if a user can signup, then it naturally follows that basic authentication actions (Login, Logout, Change Password etc...) should be present. Similarly if a user can add a gig then it follows that CRUD operations such as being able to delete or edit a gig should be possible even though they weren't specified in the document. 

After identifying our use cases, we proceeded to our Visual Studio Online account (my account is located here), which we are using to plan and manage the use cases of our app. In here we decided upon the dependencies for our use cases, which will help us decide which use cases to implement in order. For example, to follow an artist, you must view one of their gigs first and to unfollow an artist you must first be following an artist.

With this done we decided upon the most essential use cases (generally either the ones that capture information or change the state of the app domain) to program first to capture the essence of the app in its first iteration.

The most essential use cases were identified to be "Add a Gig", "Add a Gig to Calendar" and "Follow an Artist". The only problem with developing only these three use cases in our first iteration is that there is no reporting functionality (i.e. we would not be able to see if gigs were added properly or not from an end user perspective). Therefore we need to include some secondary use cases in our first iteration to provide this necessary feedback. These secondary use cases were identified to be "All Upcoming Gigs", "View Gigs I'm Attending" and "Who I'm Following".

From here with the proper pre-planning done on our project, we could now start sketching out the basic user experience of our app in the next module.