This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
The given scenario is not explain the fully requirements of the ticket issuing system. There are so many services missing to the customer. According that there some omissions have been found from given scenario.
Oyster system is missing: In reality, in the London underground there is a option for Oyster cards and paper tickets. But in the given scenario the option for oyster is omitted. Hence, the user can use only the option of using paper ticket.
A - Z destination and type of ticket: if we consider both the underground and over ground railway system, the selection of the destination should be like A - Z selection. Also the ticket type mean by that customer was child or adult.
Zone selection: when a zone is not selected, the ticket machine would automatically calculate the particular zones from 1-6 and a customer is needed to select a particular zone or they will be charged for extra zones. Therefore the zone selection option must include within the interface.
Travel card selection: in this option the user able to opt for ticket duration but from the given scenario the travel card selection is not included in the system; hence tickets can only be valid for a certain period of time such as day pass, weekly or monthly pass.
Multiple tickets: the customer can buy the multiple tickets for different destinations or same destinations at the same time.
Extension tickets: a customer is valid to extend ticket usage for another period of time with the oyster cards, this functions seems to be missing on the given scenario hence it enforces a customer to make a new ticket purchase.
No change given: In this scenario, the customer will always have to carry the exact amount of money for buying ticket. So when the payments exceed the actual amount then the customer will not receive any change.
No receipt given: it makes sure the payment was made successfully by user. It is like an acknowledgement.
No detail menu displayed when time of selecting in the ticket. Such as the arrival departure time of the train, seat selection, specific train type and rate of the every certain selection of destination.
Resolve the identified ambiguities in some appropriate way.
Interface for the resolve ticketing system
the user will go and able to use the ticketing machine then the interface will appear on the touch screen according to that menu user will able to select their requirement. Then select the popular destination whatever is automatically appear on the screen or select the needed destination from the A-Z selection. Once the destination was selected user asked to select the type of ticket mean by they need a single or return or multiple ticket and first/second/standard sheet and oyster card system.
Once user select the destination and ticket type the system will prompt to asked to pay the payment either cash or card. If the payment is cash then user will insert the coins or note according to their selection, the machine will calculate and deduct require amount and give the balance with ticket. If the payment is card machine will ask to insert the card one the card was validated then ask the pin number. Once user entered the pin then if the pin was validated required amount will detected on your account. Finally user received the ticket.
The purpose of writing a structured approach is easy understanding of the usage of ticketing machine. It will occur in a sequence
"The software must provide a means of representing and accessing external files created by other tool" [Ian sommerville, 2001].
The operation of the system has some Limitation to provide services that can be explained in natural language statements and service diagram types. This can be easily understood by all users even those without technical knowledge.
According to the above scenario the user requirements are the user,
Selecting the destination
Paying the money by cash or card
Receiving the ticket.
User will select the destination according to their requirements. On that interface it has some option like some fixed destinations and manual destinations where users can write down their own by inputting data into that interface.
After completion of the above process user will be asked to pay the required amount of money either by cash or debit/credit card. If the users pay by cash then they need to ensure that they are inserting exact amount of money. If user pays by card then that card will be subjected to validation and after the authentication the user will be issued the ticket.
"The user should be provided with facilities to define the type of external file. Each external file type we have an associated tool which may be applied to the file. Each external file type may be presented as a specific icon on the user's display. Facilities should be provided for the icon representing an external file type to define by user. When a user select an icon representing an external file the effect that selection is to apply the tool associated with the type of external file to the file representing by the selected icon"[Ian sommerville, 2001].
System requirements talk about the services and limitations in details. The documents of the system requirements should be specific. It might work as a deal between the system consumer and software developer.
According to the above scenario the system requirements specifications are,
To show option of destinations.
Request option of payment either card or cash
By card request pin number or by cash put exact money.
Issuing the ticket.
The system will display the list of destination according to the user requirements. Once the destination has been confirmed by the user, the system will automatically calculate and display the amount to be paid for that particular destination. And then option of the payment will be displayed by the system either by cash or card. Once customer selects the type of payment the system will process accordingly if the method is card then it will ask to insert the card and enter the pin number. If the method is cash then user will be asked to put the exact amount of money. After confirmation of payment the user will be issued the desired ticket.
Sequence models will show the progression of object interaction. Normally represent as relationship diagram between every actions take placed by a particular order
In this particular sequence diagram was drawn with some assumptions because this will show only the very basic procedure of the ticketing system. Customers request the ticket and receive the ticket. According to the assumption are
Request of destination - here customer will select the destination according to their requirements then assume this requesting process.
Request of cash/card - this process was done inside the system mean by the process will handle with railway DB and Bank DB. Then assume the process of card or cash requesting.
PIN and card validation request - this process was done behind the bank DB interaction. This also the inside process it will take place in-between railway DB and bank DB. Then assume the validation process.
During the payment user can make some errors such as
Some time put the wrong cards mean by the card sip will corrupted, the magnetic barcode damaged.
User makes a payment with using debit card before they make sure the money in their account. Otherwise the card will not working.
The payment method is cash user must be put the extract money because of the system will not give the change. But some user did not put extract money at that time system getting stuck
Non -functional requirements
"Non-functional requirements are those which are not directly concerned with the specific functions delivered by the system. They may relate to emergent system properties such as reliability, response time and store occupancy. Alternatively, they may define constraints on the system such as the capabilities of I/O devices and the data representations used in system interfaces" [Ian sommerville, 2001].
According to the above scenario the non functional requirements are,
The input interface will get stuck in the case of
Inserting card or putting money
Entering the pin number
Memory scalability, in this case
Cache memory will get stuck
Traffic of the network
Take long refreshing time to start next session.
Output difficulties, in this case
Printing delay (i.e out of paper or ink)
Development of set of User Cases
"User case are a scenario-based technique for requirements elicitation which were first introduced in the objectory method" [Ian sommerville, 2001]
According that statement his is simply explain by models such as
The user cases will identify the internal communication of the each. In this given scenario the set of user case such as
Requirements of validation process
Destination validation: the destination must be valid one. If the customers choose the wrong destination which is not in the database then the destination can not be validated by those particular travel arrangements. The customer will request to select the appropriate path with in the system.
Card validation. Once the customers insert their card it has to be read by the system. If the card is valid then the system will continue with the process. Otherwise the process will terminate and the card will be returned to the customer. According that to avoid the forgery transaction and fin the stolen cards.
Pin validation. The customer will be asked to enter the pin. If the customer put the wrong pin then the customer will be asked to insert the pin again. Therefore, correct pin must be entered for the customer for the validation. When pin is wrong the transaction can not be continue and cannot bee charged that particular account.
Cash validation. The user will able to put the correct amount of money in the system. If they put money by notes, that note must be good money not a duplicate note. Also not damage note because the system will not read the strength of that money. If you put in coins that must be the correct dimension because the system will read the amount of money according to the dimension of coins. Like 5p or 10p or 20p 50p 1pound or 2 pound.
Ticket validation. If the payment is ok before issuing the ticket it will validate by machine in a way of destination are correct, payment correct, date of the travelling and way/time of the ticket. Also make sure the ticket was printed well or well not if it is ok user will able to collect the ticket.
Semantic data model for the above scenario
Semantic data model is the data processed by system in the way of logical type. Sometime its called entity relation attributes modelling. It will explain the relationship between the action and entries. According that identified semantic model for the given scenario is
The impact on cash payment
When the customers pay by cash and they are flexible not to pay the exact amount of money for purchasing tickets, this felicitates the way customers purchase. Because in the current scenario there is no such facility and the customers were always expected to have the exact amount. Therefore, if the facility of money change is implemented, it makes the process of ticket purchasing easier and eventually satisfies the customers.
In such a way if the amount will appear in the screen and than customer will put money in the way of coins or notes. After putting the coins or note into the system then the charged money and balanced money will appear on the screen and finally customer will get the appropriate change and the ticket. Here importance thing is the machine must display the current charge and current charges have to be given to the customer.