Unit 4 Flashcards
Suggest a business rule that constrains overlapping reservations made by the same person.
Overlapping reservations made by the same person are allowed only if the guest names are different, or at least distinguished from one another.
Write an informal description for the process that cancels a reservation, and draw the corresponding activity diagram.
Your solution may diverge from the one proposed here; this is just a first attempt at detailing the cancellation process.
Cancel reservation
The cancellation process begins when someone calls the hotel chain’s reservation system. The caller will cancel a reservation, giving the reservation number or the dates and name and address of the guest. The existing system looks up the reservation, checks whether the cancellation is being made less than 24 hours from the date of the reservation – in which case it charges the credit card with the amount corresponding to one night’s accommodation – closes the reservation and confirms the cancellation.
In the Volere template in Section 6, we recorded some non-functional requirements. What further work is needed in order to produce the software requirements?
We need to remove any ambiguities and add clear fit criteria. Additionally, we need to identify which functional requirements they constrain; in some instances, they will apply to whole use cases. Often we will need to consult the system stakeholders for further details.
What else needs to be done in terms of non-functional requirements?
We should look at each of the functional software requirements in turn, and consider whether there are any non-functional requirements that apply to them but have been omitted. We should not assume that the stakeholders will supply a complete set of requirements, so cross-checks such as these are essential
Take the non-functional requirements recorded in the Volere template and state appropriate fit criteria, together with the use cases and, where appropriate, specific functional requirements to which they apply. Assume that the stakeholders have been consulted and have supplied appropriate information.
The following non-functional requirements are suggested.
Look-and-feel requirements
LF1: The system shall make use of a small number of bright colours, to conform to the brand image of the hotel chain. On consultation with the stakeholders we arrive at the following. Fit criterion: The system shall be designed with black and white forms with a sky blue title bar and a yellow motif in the bottom right-hand corner copied from the company logo.Applies: All use cases.
LF2: The system shall have uncluttered forms. Fit criterion: Each form shall be limited to a maximum of 8 textual input boxes;each box shall have an accompanying caption of up to 20 characters. Any
preamble text shall be limited to 20 words.Applies: All use cases.
Usability requirements
U1a: The system shall be easy for receptionists to use. Fit criterion: Receptionists shall be able to learn how to use the system in 1 hour. All current receptionists shall be able to complete a reservation, check in or check out form in 2 minutes, assuming the guest has no special
requirements.Applies: UC1, UC2, UC3, UC4.
U2b: The system shall be easy for reservers to use.
Fit criterion: The system shall require no training for its online facilities. At least 90% of reservers shall be able to make a reservation in 1 minute.
Applies: UC1, UC2.
U3c: The system shall be easy for managers and system administrators to use. Fit criterion: Managers and system administrators shall be able to learn how to use the system in 2 hours. All of the current managers shall be able to perform any of the management operations in 1 minute.
Applies: UC5, UC6, UC7, UC8, UC9, UC10.
Performance requirements
P1: The system shall be able to handle a range of large and small hotels.Fit criterion: The system shall be able to handle up to 100 hotels, varying in
size from 10 rooms to 1000 rooms.
Applies: All use cases.
P2: The system shall respond to most user inputs within 1 second. Fit criterion: The system shall be able to respond to more than 50% of user
inputs within 1 second. Applies: All use cases, except UC1. The exceptions in the above fit criterion relate to user requests where we expect the system to have to do a greater amount of processing than we can guarantee in 1 second.
P3: The system shall respond to a complex user request within 10 seconds. Fit criterion: The system shall be able to respond to all complex user requests within 10 seconds. Applies: UC1 (since the system needs to search for availability).
P4: The system shall have high availability.
Fit criterion: The system shall be available 99% of the time for 24 hours a day, 7 days a week, with any period of unavailability lasting 1 hour at most. Applies: All use cases.
Operational requirements
O1: The system shall operate across the hotel chain, with a set of terminals in each hotel and a single central server. Fit criterion: Self-contained. Applies: All use cases.
Maintainability requirements
M1: The system shall be able to add support for several European languages.Fit criterion: Another 2 European languages shall be supported in addition to English. Applies: All use cases.
Security requirements
S1: Only managers and system administrators shall be able to perform
management/administration operations.
Fit criterion: No more than one breach per year shall occur. Applies: UC5, UC6, UC7, UC8, UC9, UC10.
S2: Credit/debit card details shall be securely managed. Fit criterion: A fraud shall occur in no more than one in a million card
transactions. Applies: UC1, UC2, UC3, UC4 specifically, but also to any part of the system where credit card details are accessible. S3: Reservers shall be able only to browse and make or cancel reservations. Fit criterion: No more than one breach per year shall occur. Applies: UC1, UC2. S4: Only receptionists shall be able to check guests in or out. Fit criterion: No more than one breach per year shall occur.Applies: UC3, UC4, but also to any part of the system where relevant details are accessible.
S5: Information on which guests have been checked in and out should not be alterable. Fit criterion: No more than one breach per year shall occur.
Applies: UC3, UC4, but also to any part of the system where relevant details are accessible.
Cultural and political requirements
C1: The system shall reflect the child-friendly policy of the hotel chain.Fit criterion: The system shall distinguish between child and adult guests in
order that children can be treated appropriately.
Applies: UC1, UC2, UC3, UC4.
Legal requirements
L1: The system shall operate in accordance with European and local law. Fit criterion: The system shall pass an audit by the hotel chain’s legal
department. Applies: All use cases.
Consider each of the functional software requirements given above for UC1, and consider whether any of the non-functional requirements can be refined.
Looking at the individual functional requirements for the use cases, it seems clear that only functional software requirements SFR5, SFR5.a.1, SFR7, SFR9, SFR10 and SFR13 can be considered as complex user requests. So it would seem reasonable to refine our performance requirements in two ways. Firstly, we will allow specific times for each of these steps. Secondly, we will allow 1 second for each of the other steps. Now, the relevant performance requirements become as follows. P2: The system shall respond to most user input within 1 second. Fit criterion: The system shall be able to respond to more than 50% of user
inputs within 1 second. Applies: All use cases, except UC1 – SFR5, SFR5.a.1, SFR7, SFR9, SFR10, SFR13. P3: The system shall respond to a complex user request within 10 seconds. Fit criterion: The system shall be able to respond to more than 50% of user inputs within 10 seconds.
Applies: UC1 – SFR5, SFR5.a.1, SFR7, SFR9, SFR10, SFR13. A similar process of refinement of these requirements would be appropriate in
respect of the other use cases, so the information about where the requirements apply will continue to become more specific. You may have found other specific details that require the given non-functional
software requirements to be refined in this way. Alternatively, you may have found some completely new non-functional requirements.
Is it also necessary to check the non-functional software requirements against the original user requirements?
Yes. For example, as well as simply missing explicit non-functional requirements in the template, there might well be non-functional requirements implied under product constraints.
Is it possible that elaborating the functional requirements as above might require us to revise our non-functional requirements? What if we were to add new functional requirements?
Yes, in both cases. There may well be constraints on the added functionality that are not covered by the existing non-functional requirements.
Can elaboration of our software requirements lead to inconsistencies? Give an example.
Yes. For example, if we add sufficient extra functionality, the time taken by the system to carry out the necessary work might mean we are unable to satisfy the time constraint in usability requirement U1.
