Requirements discussion

[sevab]

The transcript of the offline discussion about requirements & the prototype system

[hornets]

Here's a photo of the physical paper we did today.

[sevab]

Following our meeting in forum on Sunday 26th we discussed the Use Case Diagram and came up with the first draft. Since we haven't covered login on the lectures we did a quick research online and adopted one of the approaches to diagram the login procedure. While we were trying to draw the diagram we had problems interpreting the specifications, so as a group we tried to come up with the most logical interpretation. For example, for the scenario where the customer has an option to read movie reviews, watch the trailer or read the synopsis we weren't sure whether we separate it into separate actions for the Customer or do we group all of them as a single case. Vlad proposed that we group all of the 3 actions under View Movie Information action. We agreed from the user experience perspective that grouping all three under a single action is most reasonable. Another item in the specification that we had hard time interpreting was whether or not we should separate Browse Last Weeks Movies and Browse Next Week's Movies into separate case scenarios. Again, from the user experience prospective we decided that the most logical approach would be to have a single Browse Movies use case scenario.

Otherwise the rest of the Use Case Diagram didn't raise any discussions among group members and we just drew it in the most logical way based on the specification.

We agreed that this first draft of the Use Case is not final and we decided to wait until Tuesday lecture to learn whether or not our login part of the diagram needs any amendments. We also agreed to meet on Wednesday to make any amendments to the diagram and write documentation.

[sevab]

From the UML Textbook, chapter on Use Case Diagrams:

More generally, requirements by use cases may encourage developers to think too operationally: users are likely to describe the use case as a very concrete sequence of interactions with the system which is one way, not the only way, of achieving their real goal. For example, users naturally think of the things that have to be done happening in some order, perhaps the order in which they are done at present, even though another order might be just as appropriate. It’s important that developers distinguish between requirements and candidate designs.

So I guess it's ok for us to change the procedure as (from what is described in specification) for it to be more logical. As long as the user is still able to achieve their goals. This is mainly in reference to grouping synopsis, trailer and review under a single View Movie Information use case scenario. I think this can also refer to the argument we had whether or not Browse Last Weeks Movies and Browse Next Week's Movies should be separate use cases or not. As long as the user can achieve their ultimate goal, it is ok for us to group both of them under a single Browse Movies use case in order to simplify maters.

[sevab]

If anyone needs a PDF of the UML book, let me know.

[sevab]

I think you guys must read chapter 8 (just 8 pages) before our meeting on Wednesday. It seems very useful and relevant in explaining how to build a better use case diagram. For those that weren't in class for the first lecture on UML, I also suggest you read chapter 7 which will give you a good introduction to Use Case Diagrams. Click here to download the book in PDF

[sevab]

Following the Tuesday lecture where David said that the bubbles are not to be connected in procedural order (i.e. step-by-step), it looks like we made an error in our diagram. Looking at the wikipedia article, or this page, or this page, or Microsoft's UML guidelines you'll see that the connections between bubbles usually don't extend further than 2, and are primarily connected using <> and <> stereotypes.

[akshay378]

Hey @sevab and team! Thank you for these articles/pages, seem pretty useful. Even after Tuesday's lecture, or even the article I am reading from your list above, it does not seem like its going to be a task to work out the use case diagram; since we already have a rough version with us. Anyway, see you all at 2 at the Forum today!

[akshay378]

As per our meeting in the Forum on the Wednesday 29th, we modified the Use Case Diagram constructed on paper on Sunday the 26th and came up with the final draft.

We made a couple of changes following our understanding of Login from Tuesday's lecture, as well as to utilise 'include' and 'extend' in a more appropriate manner. Firstly, we decided to construct our Use Case Diagram using the login method where the logon is alongside other use cases as it is easy to understand. We initially decided to use the login method where other use cases include logon, however this was disapproved mutually within the team as although it is easy to maintain, but would not be diagrammatically neat and understandable.

Furthermore, according to the specifications provided, we had a detailed discussion with whether to use 'include' or 'extend' is some scenarios. For instance, we had a discussion if to extend 'browse next week movies' and 'browse last week movies' from 'browse movies' use case or to include it. On further discussion and research on the internet for a general definition distinguishing between the two, the team agreed upon extending them from browse movies as the extending use case (browse last week movies and browse next week movies in this case) is dependent on the base case (browse movies).

Also, there was a discussion if to mention the 'Cancel Action and Start Again' in the documentation or as a case itself. With a detailed dialogue amongst the team members, we decided to present it as a separate case since this is a case worth mentioning as it gives the user and option to cancel or start again. This according to the us and the specification seemed like a mandatory option that should be present to the user while operating the machine.

We decided that this is the final draft of the Use Case Diagram for the picture-house. In addition, we decided to meet on Friday along with our divided work i.e writing documentation for the Use Case Diagram, as per the cases we have divided amongst us.

Here is a photo of the modified version of the Use Case Diagram we did today.

[sevab]

I drew the diagram in the digital form now, see pictures below also feel free to download the file itself from the repo, I've just uploaded it. Let me know if there's a typo somewhere. So now just pick the bubbles (aka use cases) you want to be responsible for documenting and let everyone know in the comments.

[sevab]

One thing I was wondering about is that if we have 'Login' shouldn't we also have Logout, so that the next Customer doesn't 'take care' of the previous customer's credit card info?

[hornets]

Seva, I see you have modified the structure compared to what we discussed in the forum today. You went for the 4th form presented in the lectures, that's okay but I don't see much linking to login now, I'm not sure if this clearly depicts that in order to perform any actions the customer / administrator HAVE to login. What does everyone think?

[sevab]

@hornets Vlad, as you remember from the lecture, with the 4th approach you have to specify the requirement to login before proceeding in the documentation of every Use Case that requires login. 4th approach is just as valid as the 2nd approach, but involves less clutter.

[hornets]

Yep, but the thing is that maybe we should ask for a second opinion, that example was very simple, what we're doing is a bit more complex so I think it'd be nice if we'd print this and ask David if we're spot on. Just to make sure.

[sevab]

@hornets checking with David would be great. I'm still convinced that doing Login with the 4th approach is no different than doing it with the 2nd approach. It's just a much cleaner way of doing the same thing. No difference.

[akshay378]

@sevab @hornets both seem to make sense, but I think what @sevab has done there is still ok according to what he spoke about in the lecture and the lecture slides themselves. However, there is no harm in asking David for his opinion at all I guess!

[sevab]

Btw, here's a good example of a scenario description from the UML book:

[armand64]

As we have discussed today in our meeting we decided to split our work this way :

Customer chunk 1: Write review Read review Read synopsis Watch trailer

chunk 2: Login and logout Book ticket (includes select seating and print ticket) Print tickets Read Newsletter

chunk 3- Administrator: Cancel action and start again Create newsletter Change customer details

chunk 4: Change movie details Change movie review Login & logout. Now we have to assign each member a chunk and start working on it!

[hornets]

@sevab we already have that

[akshay378]

Thanks for putting that up @armand64 I am working on chunk 2.

[armand64]

I will take chunk4 if you don't mind

[sevab]

I'll do chunk 1 then!

[hornets]

In this case I'll do the documentation for chunk 3.

[sevab]

Oh, if I forget, could you guys remind me to ask David whether or not we need to include Logout functionality?

[sevab]

For documentation of the 'extend' scenarios you must mention the following (according to the UML book):

• the condition under which the exceptional case applies;
• the point at which the condition is tested and the behaviour may diverge – this is the extension point.

[hornets]

Also, let's ask him tomorrow about the Login as well, we need to make sure that we are doing it the right way.

[akshay378]

@sevab can you please explain the second bullet point a bit more? What i understand from this is that we have an 'assured' (tested) condition and the (user's) behaviour might diverge towards another condition from the extension point?

[sevab]

@akshay378, I'm not exactly sure what you mean. Anyways, the book kind of explains it on page 108 and 109, so have a read (I posted the link above). I will also send you my answer in a bit.

Another question I'd like to ask David is whether the include-arrow from the Browse next week movies to the Book ticket use case should instead come from Read Reviews, Read Synopsis and Watch Trailer use cases.

[sevab]

Also, from the example in the book it seems that we have to describe parent use cases as well. In my case that is Browse Movies, Browse next week movies and Browse next week movies. So whoever does Change customer details must also describe Browse Accounts, and whoever does Change movie details use case, also needs to do Browse movies. Same goes for Browse Movie Reviews and Change movie review. Also, I say we rename Browse Accounts into Browse Customer Accounts.

So here is my chunk. Please give your opinions and make corrections.

Write review

Given a movie that was available from last week and that has just been selected by the Customer (through the use case Browse last week movies) the system should allow a customer to write and submit a review for that movie. Once the customer submits a review, the system should add it to the database and display it along with other reviews for that movie.

Read reviews

Read reviews is a subsidiary use case of two main use cases Browse next week movies and Browse last week movies. The extension point, a point at which Read reviews use case diverges from the Browse next week movies use case, occurs after a Customer decides to Browse next week movies by reading corresponding customer reviews as opposed to watching trailer or reading synopsis (use cases Watch trailer and Read synopsis). Similarly, the extension point, a point at which Read reviews use case diverges from the Browse last week movies use case, occurs after a Customer decides to Browse last week movies by reading customer reviews for those movies.

Read synopsis

Read synopsis is a subsidiary use case of the main use case Browse next week movies. The extension point, a point at which Read synopsis use case diverges from the Browse next week movies use case, occurs after a Customer decides to Browse next week movies by reading movies' synopsises as opposed to watching trailer or reading other customers' reviews (use cases Watch trailer and Read reviews).

Watch trailer

Watch trailer is a subsidiary use case of the main use case Browse next week movies. The extension point, a point at which Watch trailer use case diverges from the Browse next week movies use case, occurs after a Customer decides to Browse next week movies by reading movies' synopsises as opposed to reading movies' synopsises or reading other customers' reviews (use cases Read synopsis and Read reviews).

Browse last week movies

Browse last week movies is a subsidiary use case of the main use case Browse movies. The extension point, a point at which Browse last week movies use case diverges from the Browse movies use case, occurs after a Customer decides that he/she needs to Browse Last week movies as opposed to Browse next week movies. The last decision would in turn occur if a Customer's end goal is to reach either the use case Write Review or Read Reviews.

Browse next week movies

Browse next week movies is a subsidiary use case of the main use case Browse movies. The extension point, a point at which Browse next week movies use case diverges from the Browse movies use case, occurs after a Customer decides that he/she needs to Browse next week movies as opposed to Browse last week movies. The last decision would in turn occur if a Customer's end goal is to reach either the use case Read Reviews, Read Synopsis or Watch Trailer.

Browse Movies

Browse movies is a use case performed by the Customer when his end goal is to reach Browse next week movies, Browse last week movies use cases or other scenarios branching from them. However, before allowing a Customer to perform the Browse movies use case the system should verify that the Customer is authorised to used the system (i.e. logged on the system). If the Customer is not authorised he/she must be redirected to perform the Login use case first.

[akshay378]

That looks good @sevab Also, I saw in the Use Case Diagram that you have written 'Logon' for the Customer as well as Administrator actors. Can we re-name it to 'Login' as per the specification? Also, my chunk involves Logout for the documentation, should I leave that out for now until we ask David for his opinion in tomorrow's workshop?

[akshay378]

Hey Team! Here is the documentation for my chunk (no. 2). Also, instead of writing about the password and card details in the Login use case, I wrote that in the documentation for Create Account as it was not assigned to any of the chunks within the team. Please feel free to leave an opinion and make corrections.

Create Account

Create Account is a main use case that allows a Customer to register themselves with the system if they do not already have Login details. The Customer should register themselves with a customer name that is not already registered with the system and a password that should at least comprise of eight characters, one upper case character and one digit. In addition, the Customer should also register a sixteen-digit credit card number along with the details above that will be used to pay for the cinema ticket.

Login

Login is a primary use case performed by the user in order to gain access to the system. If the Customer (the actor in this use case diagram) does not already have login details, then he/she should Create Account (use case) to utilize the functionalities of the system such as Browse Movies, Book Ticket (use cases within the system) etc.

Book Ticket

Book Ticket is a use case implemented by the Customer when their end goal is to Book Ticket for a movie, Select Seating, Print Tickets or other scenarios branching from them. This use case then further includes two subsidiary use cases – Select Seating and Print Tickets that will follow once the Customer has performed the Browse Next Week Movies use case to select a screening for a movie. However, the Customer should be logged in to the machine before they can perform the Book Ticket use case. Incase the 'Customer' is not logged in to the system, he/she should perform the Login use case first.

Select Seating

Select Seating is a subsidiary use case of the main use case Book Ticket. This is a part of the Book Ticket use case, where a Customer selects a seat for one of the screenings available for a movie. However, the Customer can only select a seat that has not already been taken with an option to Cancel Action and Start Again (use case within the system).

Print Tickets

Print Tickets is a main as well as subsidiary use case, since it allows a Customer to perform the Print Tickets use case on the tickets that have been booked in advance - stored in the database in reference with their Login details, and the ones that have been booked at the cinema from a self-service ticket machine. However, before allowing a Customer to perform the Print Tickets use case, the system should verify that the Customer is authorized to use the system that is logged on the system. If the Customer is not authorized, he/she should be relayed to perform the Login use case first.

Read Newsletter

Read Newsletter is a main use case that is performed by a Customer to read the newsletter. However, the Customer should be logged in to the machine before they can perform the Read Newsletter use case. Incase the Customer is not logged in to the system, he/she should perform the Login use case first.

[armand64]

Hey team, this is the chunk I worked on. Please feel free to add or give any other opinions or make corrections.

‘Browse Movie Review’ is a use case performed by the ‘Administrator’. This use case further includes a subsidiary use case ‘Change Movie Reviews. Before gaining full access over the system, the Administrator should ‘Login’. If access is not granted, he/she is not the ‘Administrator’ and therefore cannot access this specific position.

‘Change Movie Review’ is a subsidiary use case for ‘Browse Movie Review’, which allows the ‘Administrator’ (after performing the ‘Login’ and authenticating him/her) to change and control the reviews written by customers (the ‘Administrator chooses one film review and changes the contents of the review he/she chose). The ‘Administrator’ has the option to cancel and start again.

‘Browse Movies’ is a main use case implemented by the ‘Administrator’ (after full access granted by performing the ‘Login’), which allows him/her to ‘Browse Movies’. The ‘Administrator’ chooses one of the available films and then changes the details of the chosen film through its subsidiary use case ‘Change Movie Details’. The ‘Administrator’ has the option to cancel and start again.

‘Login/Logout’ allows the ‘Administrator’ to have the power over the Reviews and ‘Details’ of each available film. The ‘Administrator’ signs on with his/her name and then introduces the password, in the case that they are not already signed on.

[sevab]

Notes from class:

• No need for Logout on the diagram because it doesn't have much value.

[sevab]

Also, we will need to redesign the diagram. I think our diagram became a bit sequential, so things like Select seating that apparently don't provide that much value to the customer don't really need to be on the diagram and can be hidden in the documentation. Also Login use case, must recognise if a user is already signed. So if the user is already signed in and then selects a step that requires login, the user will not be redirected to the login use case.

[sevab]

Hey guys, So here's the new diagram :trollface:: The reason all the other use cases have been eliminated is that they didn't provide that much value for the customer to be shown on the diagram, and should instead be mentioned in the documentation. Even though we kinda new it, it is only after yesterday's lab that I understood it properly after talking with David. Let me know if you agree with it, or think something should be added/removed. Also, under this new diagram Select Seating is now part of the Book Ticket use case. Browse last week's movies and Browse next week's movies are now part of the Browse Movies use case. Read Reviews, Read Synopsis and Watch Trailer are also part of the Browse Moves , but will be mentioned under Browse next week's movies. For the Admin all the Browse use cases have been sucked in by the Change use cases. So fi you agree with the diagram make your chunk corrections and send them to me for consolidation.

[akshay378]

Yeah, makes more sense now specially with the the Watch Trailer, Read Synopsis and Read Reviews bits being included in the Browse Movies. @sevab my chunk involved Login, Book Ticket, Print Ticket and Read Newsletter. I dont see any effect to my chunk with the new diagram, do you feel the same? Except that I need to include my documentation for Select Seating in Book Ticket.

[armand64]

Here is the corrected chunk. If you feel something is wrong feel free to adjust and make corrections.

Change Movie Review is a main use case that has sucked in the Browse Movie Review use case, which allows the Administrator (after performing the Login and authenticating him/her) to change and control the reviews written by customers (the Administrator chooses one film review and changes the contents of the review he/she chose). The Administrator has the option to cancel and start again.

The Administrator chooses one of the available films and then changes the details of the chosen film through its main use case Change Movie Details. The Administrator has the option to cancel and start again. The Administrator has to perform the Login in order to apply changes to any reviews, contents or details of a film.

Login/Logout allows the Administrator to have the power over the Reviews and Details of each available film. The Administrator signs on with his/her name and then introduces the password, in the case that they are not already signed on.

[sevab]

@akshay378 yeah, apart from Select Seating I don't see anything. Will read your chunk after you correct the Select Seating bit. For the Print Ticket use case mention the fact that the user may have booked the tickets earlier (e.g. through internet) and thus has the option to perform Print Ticket use case directly. In that case Print Ticket will display earlier booked tickets by that user and allow to print them.

[akshay378]

@sevab yeah I mentioned that for the Print Ticket in my previous documentation too :)

[hornets]

Yeah, makes sense now. This is more what I was expecting from the beginning. I kept thinking if Write Review should be extended or included, but I think it's correct as it is now, I think like this it expresses that this functionality is important and should be included whilst extend would mean it's somewhat optional from a developer POV.

[sevab]

The only thing I'm not sure is the Cancel and start again bit. I think we should remove it, since it's not that important to be shown on the diagram. Please vote for/against @akshay378 @hornets @armand64

[akshay378]

Here is my updated chunk as per the new Use Case Diagram.

Create Account

Create Account is a main use case that allows a Customer to register themselves with the system if they do not already have Login details. The Customer should register themselves with a customer name that is not already registered with the system and a password that should at least comprise of eight characters, one upper case character and one digit. In addition, the Customer should also register a sixteen-digit credit card number along with the details above that will be used to pay for the cinema ticket.

Login

Login is a primary use case performed by the user in order to gain access to the system. If the Customer (the actor in this use case diagram) does not already have login details, then he/she should Create Account (use case) to utilize the functionalities of the system such as Browse Movies, Book Ticket (use cases within the system) etc.

Book Ticket

Book Ticket is a use case implemented by the Customer when their end goal is to Book Ticket for a movie, Select Seating, Print Tickets or other scenarios branching from them. This use case then further includes two subsidiary use cases – Select Seating and Print Tickets that will follow once the Customer has performed the Browse Next Week Movies use case to select a screening for a movie. Also, the Customer has to select seat as a part of the Book Ticket use case, where a Customer selects a seat for one of the screenings available for a movie. The Customer can only select a seat that has not already been taken with an option to Cancel Action and Start Again (use case within the system). However, the Customer should be logged in to the machine before they can perform the Book Ticket use case. Incase the Customer is not logged in to the system, he/she should perform the Login use case first.

Print Tickets

Print Tickets is a main as well as subsidiary use case, since it allows a Customer to perform the Print Tickets use case on the tickets that have been booked in advance (e.g. from the Internet) - stored in the database in reference with their login details, and the ones that have been booked at the cinema from a self-service ticket machine. However, before allowing a Customer to perform the Print Tickets use case, the system should verify that the Customer is authorized to use the system that is logged on the system. If the Customer is not authorized, he/she should be relayed to perform the Login use case first.

Read Newsletter

Read Newsletter is a main use case that is performed by a Customer to read the newsletter. However, the Customer should be logged in to the machine before they can perform the Read Newsletter use case. Incase the Customer is not logged in to the system, he/she should perform the Login use case first.

[hornets]

Oh yeah, about that, I agree that it's not worthy of the diagram

[akshay378]

@sevab I think Cancel and Start Again should be removed from the Use Case Diagram as well.

[armand64]

I agree with @akshay378 about the Cancel and start again

[sevab]

Not sure whether Book Ticket must be connected to the Customer, since it can only be accessed by Browsing movies first. I hope I'm not thinking too sequentially. What do you guys think?

[hornets]

Create Newsletter

Create Newsletter is a use case performed by the Administrator when his end goal is distribute a newsletter to all customers using the networked administration machine. In order to perform this case the administrator requires identification, performed through the Login use case. The newsletter to be distributed will be created based on a template provided by the film distributor.

Change Customer Details

Change Customer Details is a use case performed by the Administrator when his end goal is to modify information about a client or to seek information about one. In order to perform this case the administrator requires identification, performed through the Login use case. Once the Administrator has logged into the Administration System he can browse the accounts that have been registered into the system, search through them and if required, modify information about a certain account.

[akshay378]

@sevab I think that will again lead us towards a sequential Use Case Diagram.

[sevab]

I've made the corrections and have consolidated all of the chunks together. I will email you the doc in a sec. Proof read everything (including other's work) to make sure all is right (spelling + logic). Also, send me your bart sheets I will then make one large doc to print out.

[akshay378]

Done with the proof reading, made the corrections necessary. E-mailed you guys the doc now, check through once again to spot anything undone.