Re: [Fisterra-devel] Analysis: shop register

[Sergio V. S. <sv...@ig...>]

Here are my comments about the shop register analysis:

First of all, a few lexical issues:
   * I think we should use "barcode" instead of "bar code"
   * "cash withdrawal" not "retired of money"

UC1
===
Refunds: I think there is no need for identifying documents by several
ways. I think the barcode is enough because the whole refunds are
generated with a barcode attached.

Internal code & Provider reference: the same the previous comment. I
think it is impossible for a cashier to remember any item identification
code so items should only be entered with a barcode, read by the shop
register or typed with the keyboard. That is why I would also remove the
window number 4.

I do not understand this piece of text: "By default, the application
shows the given quantity with the calculated total price, if the client
gives other quantity the cashier has to change it."

Talking about the window appearance, what about having a text field
where the application could show messages for the cashier?, for example,
"Remember the customer that there is a complimentary kilogram of
barnacles with these two tins of tomatoes" or "give the customer 100
Fisterra points for each pair of coke bottles".

The application should show a visual item like an icon when we have a
delayed ticket.

I do not understand why the 2nd window is called "Insertion of articles"
when this window is built for client payments. The first phrase is also
wrong because we insert no items in this window. This window must also
consider money outputs. In a client refund the money to return is not
"money given by the client - total price" because it is a negative
quantity. This does not mean that the client can not give us money in a
refund because the client could give us some money in order to allow the
cashier to return him only bills.

Did this analysis take into account the possibility of paying in two
phases, I mean an advance payment? This will affect the previous window
and also the third.

UC3
===
The window 1 of the UC3 need shop chief permissions, so the application
should show an authentication window before showing the use case window.
I think we have to change the name of this UC because we should also be
allowed to add cash to a shop register, not only to withdraw.

UC4
===
The application must check that there is no delayed ticked when trying
to perform a cash audit.

Are the cash additions and withdrawals specified in the "Final balance"?
Is there not need of identifying them? What about the initial amount?

Bye.