Requirement is attached
System Models, 30%
This section should include:
• A set of system models using suitable notation. It will not be possible to model the entire system in a 15 page document, so be selective and model a few key functionalities. We suggest that your system models should include: A model showing the context of the system
(business process model or context model).
1) A use case diagram(s).
2) 1-2 sequence diagrams modelling some key functionality in your system. Note: you are not expected to create models for the entire system.
3) A class diagram.
• The System models should include suitable and accurate notations for your choice of modelling, use of suitable abstractions and connection to requirements. A minimal description for each system model should be included. This should describe what is being modeled and explain why it is being modeled.
• The justifications of your system models must include a balanced critique of the aforementioned system models.
2.4 Presentation Report, 10%
The overall quality of your presentation will be graded for professional presentation,
coherence, grammar, punctuation and the quality of your written report
Requirements
Your software engineering team has also conducted requirement elicitation activities and generated the following set of functional and non-functional requirements from interviews with the clients.
However, they have not generated FR4: “The system shall support book loans”.
R#. Requirement description. Functional Requirements FR1 The system shall allow users to register and use an account. FR1.1 Accounts shall require relevant information. FR1.1.1 An account shall have a first name. FR1.1.2 An account shall have a surname.
FR1.1.3 An account shall have an e-mail address. FR1.1.3.1 The system shall check for and not allow duplicate e-mail addresses when registering.
FR1.1.3.2 The system shall display an error message to users if an email address is already in use. FR1.1.3.3 The system should prompt the user to login if attempting to register with an e-mail address that is already in use. FR1.1.4 An account shall have an address.
R.1.1.4.1 An address shall have an address line. FR1.1.4.2 An address shall have a city. FR1.1.4.3 An address shall have a postcode. FR1.1.5 An account shall have a password. FR1.2 Accounts shall be given a unique membership number. FR1.3 The system shall require users to login to use its booking features.
FR1.3.1 The system shall require an e-mail address OR membership number to login. FR1.3.2 The system shall require a password to login. FR1.3.3 The system shall allow users to reset a password by sending an e-mail to their registered e-mail address.
FR2 Users shall be given appropriate roles. FR2.1 Lead Volunteers shall be able to assign roles to users. FR2.1.1 Lead Volunteers shall be able to assign multiple roles to users.
FR2.2 Lead Volunteers shall be able to assign the Volunteer role to a user. FR2.2.1 Lead Volunteers shall inherit the permissions of the Volunteer role. FR2.3 Lead Volunteers shall be able to assign the Facilitator role to a user. FR2.4 Lead Volunteers shall be able to assign the Member role to a user. FR3 The system shall be able to support activity bookings. FR3.1 The system shall allow permitted users to create a booking.
FR3.1.1 Facilitators shall be able to create a booking. FR3.1.2 Volunteers shall be able to create a booking. FR3.1.3 A booking shall require relevant information. FR3.1.3.1 A booking shall have an activity name. FR3.1.3.2 A booking shall have an activity date.
FR3.1.3.3 A booking shall have an activity time. FR3.1.3.4 A booking shall have an activity location. FR3.1.3.5 A booking shall have an activity facilitator. FR3.1.3.6 A booking shall have a list of registered members. FR3.1.3.7 A booking shall have a maximum number of attendees. FR3.1.4 The system shall not allow a booking to be made if the location is in use at the selected time.
FR3.2 The system shall allow permitted users to edit a booking. FR3.2.1 Volunteers shall be able to edit a booking. FR3.3 The system shall allow permitted users to delete a booking. FR3.3.1 Volunteers shall be able to delete a booking. FR3.3.2 Registered members should be e-mailed when a booking is deleted.
FR3.4 Bookings shall only be made for times outside of the library opening hours. FR3.4.1 Bookings that are made for times during the library opening hours shall receive an error message. FR3.5 The system shall allow Members to register for an activity.
FR3.5.1 The system shall display a list of bookings to Members. FR3.5.1.1 The system shall display a list of bookings sorted by date (upcoming listed first) FR3.5.2 The system shall allow a Member to register for a selected activity. FR3.5.2.1 The system should not allow a Member to register for an activity if they are already registered for another activity at the same time.
FR3.5.2.2 A confirmation dialogue should be presented to the Member to confirm registration. FR3.5.2.3 An e-mail should be sent to the Member when registration is complete. FR3.5.2.4 An e-mail should be sent to the Facilitator when registration is complete. FR3.5.2.5 The system should not allow a Member to register for an activity if the there are no more places available. FR4 The system shall support book loans. FR4.1 ….
Non-Functional Requirements
NFR1 User passwords shall be secure.
NFR1.1 Passwords shall contain 6-9 characters. NFR1.2 Passwords shall contain at least one number. NFR1.3 Users shall be required to change password once every 12 months. NFR2 The system should show users an up-to-date list of activities.
NFR2.1 The system should refresh its list of activities at least every 5 minutes. NFR2.2 The system should refresh the number of available spaces on an activity at least every 10 seconds. NFR3 The system should be reliable. NFR3.1 The system should be available at least 23 hours a day.
NFR3.2 Any downtime to the system should be limited to the hours between 00:00 and 06:00 GMT. NFR4 The system should be usable.
NFR4.1 75% of users should be able to register for an activity in under 2 minutes. NFR4.2 Tooltips should be available for every user interface widget.
NFR4.3 Help messages should be available on every page.
NFR5 The system should be portable. NFR5.1 The system should be available on multiple platforms.
NFR5.1.1 The system should be available on Windows versions 7 onwards.
NFR5.1.2 The system should be available on iOS versions 11 onwards.
NFR5.1.3 The system should be available on Android versions 5.0 onwards. NFR5.2 The system should be written in a universally available language.
DescriptionIn this final assignment, the students will demonstrate their ability to apply two ma
Path finding involves finding a path from A to B. Typically we want the path to have certain properties,such as being the shortest or to avoid going t
Develop a program to emulate a purchase transaction at a retail store. Thisprogram will have two classes, a LineItem class and a Transaction class. Th
1 Project 1 Introduction - the SeaPort Project series For this set of projects for the course, we wish to simulate some of the aspects of a number of
1 Project 2 Introduction - the SeaPort Project series For this set of projects for the course, we wish to simulate some of the aspects of a number of
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
30 | 31 | 1 | 2 | 3 | 4 | 5 |
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 1 | 2 | 3 |
