TM354 Unit 4 - Case Study Part 1

Question 1

The rules of the existing business that have been identified by talking to domain experts so far are the following.

• a guest who cancels a reservation within 24 hours of the check in date will be charged for one night’s accommodation – a ‘no show’ leads to the same charge
• if a guest has reserved with a credit card, final payments with that credit card can be processed automatically.

Suggest a business rule that constrains overlapping reservations made by the same person.

Answer 1

Overlapping reservations made by the same person are allowed only if the guests for each reservation are different.

Question 2

What are the main differences between a use case and a user story?

Answer 2

A use case describes a business process or a self-contained task within a process. It is as complete as possible lasts as a document is agreed (by customers and developers) and is used to generate requirements. A user story is small enough to be implemented in a single iteration represents an instance from a user perspective is not complete does not last and instead is used as a reminder for a conversation.

Question 3

Consider the required characteristics of a user story as described in Unit 2: independent , negotiable, valuable to users and customers , estimable , small, testable. Give an example of another valid user story for this case study and of a user story that would not satisfy these criteria.

Answer 3

Another valid user story could be: . as a manager I can remove a room from the bookable rooms in a hotel when the room is being refurbished. An example of a user story that does not satisfy the criteria is: . as a guest I must find the interface friendly – this is not a good example as it is not a testable story.

Question 4

(a) 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?

Answer 4

(a) 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.

Question 5

(b) What else needs to be done in terms of non-functional requirements?

Answer 5

(b) We should look at each use case and see whether we identify other non-functional requirements based on the use case steps. We can do this by looking at the functional software requirements in turn (each corresponding to a use case step) and considering 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 this are essential.

Question 6

(a) Is it also necessary to check the non-functional software requirements against the original user requirements?

Answer 6

(a) Yes. For example as well as the possibility of simply missing explicit non-functional requirements in the template there might well be non-functional requirements implied under product constraints.

Question 7

(b) 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?

Answer 7

(b) Yes in both cases. There may well be constraints on the added functionality that are not covered by the existing non-functional requirements.

Question 8

(c) Can elaboration of our software requirements lead to inconsistencies? Give an example.

Answer 8

(c) Yes. For example if we add sufficient extra functionality the time taken by the system to carry out the necessary work might mean that we are unable to satisfy the time constraint in usability requirement U1.