Nobody can do everything for themselves, but everyone has some skill to offer. This is the idea behind 'Hour4Hour', a rapidly growing online not for profit venture that links together people who need help and people who can provide it. Hour4Hour (H4H) is somewhat similar to the time banking system described at https://timebanking.com.au/ and, as stated there, the concept is straightforward: "Its as simple as give an hour, receive an hour: by giving one hour of help to another member you earn one hour of time credits, which can be used to receive services that are of personal value" 1 .
H4H has been partly manual for the first few months of its operation, but now needs a new web-based system to facilitate the process of putting together people with needs and people with skills or services to offer. They intend to roll the system out nationally, from their original base in Western Australia. Dylan Clockminder, the developer/manager of H4H, has contacted you for help.
The two sides to the system are, of course, the offers and the needs, exchanged between H4H members for time credits in units of hours. Members can search or browse through all offers of assistance and requests for help posted by other members. If they find an offer or need that is relevant to them, they contact the other member to complete it. When the activity is completed, the member who provided the service records the number of hours it took. The system then records the exchange of time credits between the members.
Membership is free, and anyone over 18 can register to be a member. Members supply their name, address, email and phone number to the system and are provided with an ID, login and password.
Members can log in to the system and submit a need, which is a request for any type of help they might require, such as gardening, ironing, learning to swim, painting, dog walking, or indeed anything at all. They give a brief title and description of their need, their general location, their availability, and a date that the need is active until (after this date the need is removed from the current list of needs that are displayed on the website). The need is listed as from e.g. 'Member from Perth' so that the full name and address are not visible to a casual browser.
If a member browsing H4H believes they have the skills to provide a particular need, they log on to the system and contact the relevant member through H4H's internal messaging system. The members then proceed to negotiate (through personal email or phone) and agree on the details of the activity to be undertaken, including the number of hours it is worth (alternatively, they discover there isnt a good match, and dont pursue it). The recipient creates a record for the activity, including a unique identifier, the provider member ID, the recipient member ID, the need it relates to, and a description of the activity agreed to. The need is then removed from the list of currently displayed needs. When the activity is completed, the member who provided the service logs in to H4H and 'closes the activity by entering the date of completion and the number of hours involved, and the recipient confirms it. The system then removes that number of hours from the recipients total hours, and credits them to the provider.
Members can also post offers of services that they can provide. Again, this can be anything at all, such as IT troubleshooting, language teaching, flat-pack assembly, knitting lessons and so on. They log in to the system and provide a brief title and description of the offer, their general location, their availability and a date that the offer is available for (after this date the offer is removed from the current list of offers that are displayed on the website). The offer is listed as from e.g. 'Member from Fremantle' so that the full name and address are not visible to a casual browser. There is no limit to the number of offers a member can submit, and they can submit several offers at a time.
Members browse the list of offers, and if there is one that they require, they log in to the system and contact the relevant member. (They don't have to have a corresponding need listed in order to take up an offer.) Again, the members negotiate and agree on the details of the activity and an activity record is created, containing the provider member ID, the recipient member ID, the offer it relates to, and a description of the activity agreed to. When the activity is completed, the provider member updates the system with date of completion and number of hours to close the activity, the recipient confirms, and H4H completes the time credit transfer. Offers remain visible on the website throughout this process, as its possible that the same offer of help can be provided to more than one member.
As H4H works on a local community basis, 'Communities' of particular geographical areas can be defined within the website, and each member belongs to a particular community. This ensures that when they log in to their local community pages, they only see offers and needs that are in their area.
H4H is on a completely voluntary basis and there are very few rules, but Dylan would like to encourage people to offer help as well as receive it, and to participate as much as possible. Thus, when new members register, their welcome email suggests that they provide at least one service within the first month, and if they don't, they are sent a reminder email. Similarly, if they dont participate in at least 6 activities in the first six months, they are sent another email encouraging them to join in. To keep the website current and attractive, the home page for each community shows a continually-updated list of both needs and offers (similar to that on https://timebanking.com.au/)
As members can't receive a service that they dont have enough credit hours to 'pay for, there is a built-in incentive to earn credit hours as well as use them, and to maintain sufficient hours for future needs. Members can view the current number of hours they have available, and can also review their time credit history since joining (the list of activity records relating to them).
Dylan is constantly reviewing the performance of H4H, and the system provides him with several summary reports to help with this. The Monthly Activities report lists the total number of activities for the month, the total activities provided, the total activities received, and the total hours exchanged, summarized for each community. The Membership report is run once a year and lists the number of members registered, the percentage of active members (those who have participated in an exchange that year), the percentage of 'provider' members (those who have provided a service) and the percentage of receiver members.
Answer questions 1-10 below. Note the following points:
Q1. List the main stakeholders for the Hour4Hour system (H4H). For each stakeholder, write a brief description of their interest in the system and what aspects of it are of particular relevance to them.
You do not need to categorise the stakeholders. Don't include the systems development team.
Q2. (a) List and briefly describe the main functional requirements for the H4H.
(b) List and briefly describe the main nonfunctional requirements for the H4H.
Q3. (a) Use the User Goal technique to develop a list of use cases for the H4H. Present your list in a table that includes the participating actors, use case name and a brief use case description.
(b) Use the Event Decomposition technique to identify any additional use cases for the H4H. These will probably be temporal and state event types. Present your list in a table that includes the event, type of event, use case name, and brief use case description. You do not need to repeat the use cases you identified in (a) here. (Note that some use cases are already identified in Q6,7,8, below. Include these in your lists.)
Q4. Create a domain model class diagram for the H4H, including all classes, attributes, associations, and multiplicity. Show association classes and generalisation hierarchies where appropriate.
Q5. Create a CRUD matrix to check the consistency between your domain model class diagram and your complete list of use cases. Set this out in the form of a table with classes as the columns and use cases as the rows. If you find discrepancies between the models while you are doing this, you should go back and correct your earlier models as required so that your final set of models is consistent.
Q6. Create a fully-developed use case description for the use case Close Activity. Follow the template provided at the end of this handout.
Q7. Draw an activity diagram to represent the flow of activities for the use case Create Monthly Activities report.
Q8. Draw a system sequence diagram for the use case Submit Offer.
Q9. Draw a state machine diagram to show the possible states and transitions for a NEED object. Label each state with the state name. Label each transition with the appropriate transition name, guard condition (if appropriate) and action expression (if appropriate).
Q10. Develop a user acceptance test plan for a member of the H4H system. Base it on the relevant use cases you have identified. You can follow the example in the textbook (below). Present your test plan in a table including the fields: use case name, test conditions, expected outcomes. You do not need to include test data.