Alexander’s Blog – The Making of LetMeGo

During the past few weeks, I have had several dialogues about user stories and use cases with other people involved in web development (coders, product developers, project managers, etc.) The conversation tends to be controversial as many people adore Agile Development and, as it is, Agile Development promotes user stories over use cases. My argument is that user stories are good for small apps, but use cases are much better for large web apps that will be improved over and over again for years to come. Furthermore, I think that use cases and Agile Development are compatible (see Rrápido Methodology). My objective in this post is not to find who is right or wrong, but just to show you an example of how I write use cases.

So, as I promised to some of you, here is an example of one of the 146 use cases we have for LetMeGo. It was written following the methodologies recommended in the book Writing Effective Use Cases from Alistair Cockburn. If you find it difficult to read, don’t be concerned. It takes time to get used to read use cases and even more time to get used to writing them. I will never go back to user stories, though. For me, use cases are to user stories what object oriented programming is to spaghetti code.

• Use Case ID: 1001
• Use Case Name: Process Email Bounces
• Level: Blue
• Primary Actor: LetMeGo User
• Context of Use: LetMeGo needs to track whether its users are getting their email messages or not. If not, it should try to correct the issue.
• Usage Narrative: Ermenegildo, a LetMeGo user, changes his email account. LetMeGo sends him an email message and gets a bounce (not an autoresponder). LetMeGo sends him another message, from a different email address, asking him to check the issue. Ermenegildo doesn’t get that message either. Ermenegildo then uses LetMeGo the next day. On all screens of LetMeGo he sees a warning message advising him that we got a bounce from one of the emails we sent him. He closes the warning message. He goes ahead and changes his email address. All emails are properly sent thereafter. Two months after, LetMeGo gets two soft bounces because his email quota is full. LetMeGo sends him, right away, an email from another email address asking him to check the issue. He gets the message, acknowledges it, and cleans his inbox. Next day, LetMeGo starts getting soft bounces once again. After the fifth soft bounce, (not taking into account the soft bounces before his acknowledgment) LetMeGo stops sending him messages for one month. After the month LetMeGo tries to send him messages again. After five new bounces LetMeGo blocks his email address once again. The process is then repeated indefinitely even though Ermenegildo never comes back to LetMeGo.
• Stakeholders and Interests
• LetMeGo Users:
• To receive all messages from LetMeGo and be notified whenever it encounters a problem sending a message to them.
• LetMeGo:
• To make sure that the least amount of emails is sent to email address that may not exist or may be full, so that the chances of being flagged as spammers is reduced.
• To comply with some of the white listing requirements given by companies like AOL.
• To maximize the chances of users receiving messages from LetMeGo.
• Minimal Guarantees:
• Email messages are sent if the email address of a user is not marked as “bouncing”.
• Other auto-responders (as vacation messages) should not be treated as bounces ( http://en.wikipedia.org/wiki/Bounce_message ).
• Success Guarantees: Minimal guarantees plus:
• SuD (System under Design) doesn’t send email messages to email addresses that are marked as “bouncing”.
• If a message is sent to multiple users and one or more of them are marked as “bouncing”, all the other users should receive the message anyway.
• Preconditions:
• The user should be a LetMeGo registered user.
• Triggers:
• 0100 – A bounce message is received from an external server to the return-path address.
• 0200 – A bounce message is triggered by the LetMeGo email server to the return-path address.
• Main Scenario:
• 0100 – SuD (System under Design) receives a bounce message.
• 0200 – SuD marks the email address of the user as bouncing and stores the full content of the bouncing message replacing any previous bouncing message for said email address that was stored.
• 0300 – SuD sends a message to the user’s email address notifying him/her of the error. SuD uses a different return-path for the notification to avoid receiving a new bounce from it.
• 0350 – Empty.
• 0400 – The user visits any page of LetMeGo.
• 0500 – SuD displays a message for user notifying him/her of the last bounce received by the system.
• 0600 – User acknowledges the message.
• 0700 – SuD removes the message and resets the bounce count to zero.
• 0750 – Empty.
• Extensions:
• Extension 0350a: If the user is the owner of an active lodging listing:
• 0100 – For each lodging listing {
• 0100.0100 – SuD deactivates the lodging (see use case “Deactivate Lodging”).
• 0100.0200 – SuD sends an email message to all the owners of the lodging listing.
• 0100.0300 – SuD creates a ticket asking an admin to contact the lodging staff.
• }
• 0200 – UC continues at MS 0350.
• Extension 0350e: If a visitor requests to see the details of a user (that the visitor has authorization to view):
• 0100 – SuD displays a warning message informing about the email bouncing issue. UC continues at MS 0350.
• Extension 0500a: If the bounce count reaches five before the user acknowledges the message:
• 0100 – SuD stops the delivery of messages to the email address of the user by marking him/her as “bouncing”. If the user has more than one email addresses, the other address may still continue receiving email messages from LetMeGo.
• 0200 – 30 days later: SuD resets the bounce counter to zero, thus SuD restarts the delivery of email messages to the email address of the user.
• Extension 0750e: If a visitor request to see the details of a user (that the visitor has authorization to view):
• 0100 – SuD doesn’t display the warning message any longer. UC continues at MS 0350.
• Frequency of Occurrence: Anytime
• Open Issues: None