Write-A-Letter requirements for release 1

Thijs van der Vossen, thijs@fngtps.com, Fingertips.

User stories

id theme As a … I would like to … so that … notes estimate priority planned iteration status
1 Public supporter send a message to the target I can help persuade the target - must have 1 done
2 Public supporter receive notification that my message has been sent I can be sure I have contributed to the campaign - must have 1 done
3 Public supporter provide confirmation of my email address my identity cannot be stolen - should have 1 done
4 Administration administrator login I can access the authenticated pages - must have 1 done
5 Administration administrator logout I can safely use a shared browser - should have 1 done
6 Administration administrator create an appeal supporters can send messages - must have 1 done
7 Administration administrator get an overview of all appeals I can easily find the one I'm looking for Will change, we'll add status filter and search - must have 1 done
8 Administration administrator edit an appeal I can correct mistakes - should have 1 done
9 Administration administrator change the status of an appeal I can control which appeals are available - must have 1 done
10 Administration administrator embed an appeal into an existing web page the appeal can be easily integrated with the current Greenpeace websites - could have 2 done
11 Administration administrator delete an appeal all data related to this appeal is removed from the database - should have 1 done
12 Administration administrator localize or customize the user interface messages of the public interface all user interface elements and error messages use the same language as the appeal - could have 2 done
13 Administration administrator customize the styling of the public interface the look and feel of the appeal matches the look and feel of the campaign - should have 2 done
14 Administration administrator see the number of sucessfully sent emails, the number of bounced emails, and the number of unconfirmed email addresses I can monitor the progress of an appeal - should have 1 done
15 Administration administrator view a change log for an appeal I can find out what changes were done when and by who It's on the edit page right now - could have 1 done
16 Administration administrator export the change log to a spreadsheet I can process the log in any way I want - could have 1 done
17 Email supporter include my email address in the email the target can respond to my message In Reply-To header - should have 1 done
18 Email administrator view a delivery log for an appeal I can get detailled information about delivery problems - should have 1 done
19 Email administrator export the delivery log to a spreadsheet I can process the log in any way I want - could have 1 done
20 Email developer try to get the number of successfully sent and the number of bounced emails I can provide this information to the administrator - should have 1 done
21 Email developer include custom email headers we can try to find out if a given email message was sent by our application - must have 1 done
22 Localization developer support multiple languages and alphabets the application can be used in any language Make sure right-to-left also works - must have 2 done
23 Security developer limit the number outgoing emails the application cannot be used for DOS attacks What are we exactly going to limit? - could have 2 dropped
24 Security developer require the email adress of the message to be unique within a single appeal the target of the appeal will not receive multiple messages from the same email address - could have 1 dropped
25 Non-functional supporter get help I can figure out how to use the application Add some more inline help - could have 2 done
26 Non-functional developer be able to send thousands of emails per hour I can satisfy the demand Depends on MTA - must have done
27 Non-functional developer have valid XHTML and CSS the application is standards compliant - should have done
28 Other developer make sure the application can be embedded into any webpage It can be easily integrated with the current Greenpeace websites We need to choose between iframes or Ajax? Which character sets are used on the current websites? - could have 2 done

Planning

nr. period notes
1 May 8 - 12 Core functionality for creating and running appeals
2 May 15 - 19 Functionality and support for embedding, localizing and customizing the public interface

Definitions

Campaign
A broad course of action organized by Greenpeace to achieve a particular goal. An appeal is a part of a campaign.
Appeal
A web page through which a Greenpeace supporter can send a message in an attempt to persuade a target. An appeal consists of a status (‘active’ or ‘inactive’), a language, a title, a description, a ‘thank you’ message, text for the confirmation email, one or more targets, a default subject line, a default message body, and the url of a privacy policy.
Message
The message sent by the supported to the target as part of the appeal. A message consists of a a status (‘unconfirmed’, ‘pending’, ‘sent’, or ‘failed’), a name, an email address, a subject line, and a message body.
Target
One or more individuals or organizations that Greenpeace is trying to persuade with the help of its supporters. A target consists of a name and an email address.
Confirmation email
An email sent to the supporter containing an url the supporter must visit in order to confirm his or her email adress.

Roles

Supporter
Anyone using the application to participate in an appeal.
Administrator
Any user of the application with full administrative access.
Developer
Anyone working on the development of the application.

Categories

Public
Stories that can be carried out by any member of the general public.
Administration
Stories that can only be carried out by administrators.
Email
Stories that relate to delivering and receiving email.
Localization
Stories that relate to customizations for the native language and alphabet of a particular country or region.
Security
Stories that relate to the prevention of unauthorized use.
Non-functional
Stories that relate to non-functional requirements.
Other
Stories that don’t fit in any other category.

Notes and reminders

Working with user stories

Each user story describes a single requirement as something you would like to do in a given role, preferably with a clear motivation or reason. You can add notes for questions that can be answered later, for issues that need to be discussed, and for additional explanation. User stories are organized in themes which group related requirements.

Writing the initial user stories is the shared responsibility of everyone involved in the project.

Once everyone agrees that the user story list is more-or-less complete, the developer will estimate the amount of time he or she expects it will take to implement each story. At the same time, the client will give each story a priority ranging from ‘must have’, ‘should have’, ‘could have’ to ‘won’t have now’ indicating the value the story contributes to the final goal of the project.

Based on the estimates and priorities, the implementation of the stories will be planned in one-week iterations.

Each story also has a status which is initially set to ‘todo’. Once the story has been implemented it will be set to ‘done’. During development, everything that’s not ‘done’ can still be changed; you can add new stories, move a stories to a different iteration, or set the status of a story to ‘dropped’ if it’s no longer needed.

Below the user story list you’ll find a list of descriptions for all roles and themes and a list of definitions of terms used in the project.