APR: Use Case Briefs

Each of the use cases defined as part of our use case names post is described at a high level of detail here. The goal is to get a broad view of the domain for our project so that we can focus on the most important elements. This is a key step in using use cases in an agile project. We need to understand enough of the big picture in order to determine what is actually the most important. Then we will work on the more important use cases.

Pre-emptive Filtering

After reviewing the use case names, we can pre-emptively filter out several of the use cases for this stage of the analysis. If you feel that any of these should be included in the initial release, please comment in the discussion area of this article, and we will revisit.

• The “Promote An Article” use case – where a blogger promotes their own work for review or publicity will be deferred until after the general sharing of articles has been implemented. The first version of “Suggest An Article” will serve as a means for the blogger to achieve his goals – it will just happen to be suggesting an article that the blogger has written himself. Brian won’t mind, as long as any functionality is retro-active (and that would make sense anyway, if he were to discover that someone else had promoted one of his articles before he did).
• The “Article Mashup” use cases will also be deferred from the inital release. While we think this functionality may provide a differentiating hook and significant value, it make sense to wait. Each mashup will be a mashup of articles that have already been suggested. So we need to have articles being suggested before we can start collecting them into mashups. As of right now, this will probably be the most valuable feature to follow “article scoring” features. We’ll revisit of course – that’s just a hunch.

Use Case Briefs

Excluding those use cases that are filtered per the above. We’re using the use case brief format explained in this sample use case article. The actors are being identified in terms of the personas we identified.

Use Case Name: Browse An Area

Actors: Jill (Primary), Paul & Ellen (Secondary)

The user is exploring an area to see if there is an article that “jumps out” as being interesting. This could be an exploration of a new area – trying to get the lay of the land. It could also be simply browsing an area that the user knows well, to see if something new or interesting has been written lately. The need to “only read something really good” is reduced a little here – the mode of searching is semi-directed, idle investigation. This is the usage mode that is most likely to have people “stumble upon” an article and score it.

Question: Should the “what’s hot right now” mode of browsing be included in this use case? Think about the “watch the front page of digg.com” model – the area is our entire niche, not a section of it – but the idea is the same.

Use Case Name: Search For A Topic

Actors: Jill (Primary), Paul & Ellen (Secondary)

The user is looking for articles on a specific topic, and wants to read the best articles first (or only!). This type of searching would not neccesarily be constrained by topic area – the user may want to actively find cross-posted articles (for example an “agile” article on use cases). They key element is that the user wants to research a specific topic.

Use Case Name: Rate An Article

Actors: Jill (Primary), All (Secondary)

The user has just read an article found by browsing or searching. The user will provide a “recommendation” – should people make sure that they read this or skip it. The user will also optionally identify if they think this article is targetted at beginners or experts (is it an explanation of how parallel activities work in BPMN, or is it a discussion of how you can create deadlock conditions in a BPMN diagram?).

Question: Should rating an article require users to be logged in? Mainstream sites use this approach, which probably prevents the worst gaming of the system, in exchange for the potentially tedious step of logging in.

Question: Should users be able to “recategorize” articles if they feel like something was overlooked, or the article were incorrectly classified (e.g. had nothing to do with use cases, but was tagged “use case”)?

Use Case Name: Broadcast An Article

Actors: Paul (Primary)

The user will want to share a particular article with people who are not part of the community on the site. After optionally rating an article, the user will identify some people to email the article to. Those people are probably coworkers or former colleagues who the user believes will benefit from reading the article.
Email was suggested as the communication method, and we’ll use the term ’email’ as a proxy for “tell non-users about an article” for now. This will be less cumbersome than jumping through hoops to avoid saying ’email.’

Thought: This capability may also be used for other “check this out” goals – we should prioritize the “you should read this” goal when defining requirements / designing this functionality. Other goals may be identified in the future.

Use Case Name: Comment On An Article

Actors: Paul (Primary), All (Secondary)

The user will optionally add a comment or notation to an article after rating it. Comments are great qualitative feedback to help other users decide between articles that they find as part of searching or browsing – but it is “second order” feedback that helps someone refine their search. The “first order” feedback is created via the “Rate An Article” use case.

Thought: A secondary use of this capability could be to ask questions or develop a conversation around an article (eg “This Worked for Us” or “Had anyone actually done this?” Not all articles are published such that their authors encourage on-site conversations like this. Having this facility will help users, and possibly authors.

Thought: Requiring someone to have rated an article prior to commenting will help with spam.

Use Case Name: Suggest An Article

Actors: Paul (Primary), All (Secondary)

Thought: Brian is almost a primary user of this use case, given the filtering of Brian’s use case from the initial release. He would be treated as a supplementary persona for this use case – using functionality designed for Paul without modification.

The user has discovered a great article for our niche and wants to include it in the site for others to read and review. The user will add the article to the site and optionally rate it. The user may also specify the tags/categories for which the article applies, and may classify the article as being for beginners or experts.
Version 1: The first version of this use case will require the user to be logged into the site, and enter the URL of the article directly into a form on the page.

Version 2: The second version of this use case may allow users to use a widget (like stumbleupon, or other widgets created for other sites like digg and delicious) to suggest an article with less interruption to their other browsing.

Version 3: A third version of this use case may allow users to unobtrusively leverage other external activities to automate all or part of the submission process. For example, automatically submitting any del.icio.us articles with a specific tag, or allowing a blogger to “trackback” to the site and initiate a suggestion.

Question: Should users be forced to rate an article when submitting it?

Summary

This overview paints the domain of our project (as defined in the scope and vision article) with a broad brush. It allows us to take the next step of prioritizing the use cases.