Omissions In A Ticket Issuing System

The ticket issuing system does not offer many of the services to facilitate the purchase of tickets. A number of ambiguities and omissions have been found from the given scenario.

The scenario given is not clear enough and looks like quite uncertain about the instructions to purchase a ticket. Even the payment procedures do not offer the user to choose the type of payment.

The ambiguities and omissions found in the scenario are as follows:

The system does not allow customers buy more than one ticket for the same destination at a time. It must prompt the user if the ticket can be purchased one at a time. Customer is more likely to input incorrect destinations and the system should allow user to cancel a request and purchase another ticket.

After having input the destination the system will ask the customer to pay and would ask about which type of payment the user prefers. In this case, the system does not indicate as to how to respond if an invalid card is input. It must be able to respond and prompt the user if they try to put their card before selecting a destination.

Do the customer need to press the start button if they wish to buy another ticket to a different destination. Or it allows customers with the choice of selecting other destinations between the stations where the machine is located.

Ticket system is going to allow customers to input their destination through a touch screen or keyboard. The existing system does not allow the user to view the ticket prices. It is vital to publish the ticket prices accordingly, as customers need to know the amount that they will be charged. It does not show the train departure and arrival times, and whether the customer wishes to buy ticket for a specific train. It must allow customers to choose their seats.

Finally, the system should prompt customer to print the receipt which includes the destination details and payment type. A receipt should have been issued to state whether the purchase has been made successfully.

In the first paragraph, the system does not check for validation, such as when the user inserts their card, and the validity needs to be checked as to whether the payment could be made form that particular card.

According to the second paragraph, when the user clicks on the start button, a menu of potential destinations pop up on the screen, along with a message asking the user to select a destination. Once a destination has been selected, users are prompted to input their credit card. However, the credit card’s validity is checked and if the card is good, then user has ed to input a personal identifier as requested by the machine. The ticket is issued when the credit card’s transaction has been validated successfully.

In the second paragraph, the ticket system prompts the user with potential destinations whereas it could have provided with “popular” destinations. In such terminals popular destinations are normally displayed to help the user to select his destination quickly.

• Usually an Underground or an Over ground cover any destinations which can be reached by interchanging and taking number of trains therefore the user should be able to purchase ticket in order to reach any destination.

• It could have also provided the user with a choice to search from a list of A-Z of stations.

• As mentioned before that there should be two types of payment methods

• The validation procedure involves both: validating the card as to whether the card is still valid in terms of not cancelled by the issuer due to fraud lost/stolen reasons. The second type of validity is the PIN validity.

• If both validations are successful then the issuer must authorise the payment in order to purchase the ticket.

2. Solutions identified

To gain a clear and better understanding of the scenario, a more structured approach has been written as follows:

User walks to a ticket machine and presses any button to activate a menu which displays a list of popular destinations accompanied by a message to select a destination. User can select their destination if listed in the popular destination; otherwise they can choose to search for their destination from a list of stations in the A-Z of stations.

As user finds their desired destination they then can choose to have their preferred type of ticket, this can be such as: first/standard class ticket and/or return/single ticket.

Once the destination and the type of ticket is selected the ticket machine prompts the user to make payment. There are two types of payments can be made, likely by card or cash.

If the customer chooses to pay by cash, and it can be inserted into the machine in the form of notes or coins. If the exact amount is paid the ticket will be issued, if more than required is paid then the change will be given along with the ticket. If the customer chooses to pay by card as requested by the system, user can insert the card into the terminal. As the card is being inserted the validity of that card is checked with the issuer. Once the card is validated the user is then required to check the amount and enter the PIN in the terminal. The PIN is validated locally and upon correct entry of the PIN the ticket is issued along with the receipt and the cardholder’s account is charged accordingly with the correct amount.

The aim of writing a structured approach gives a more clear understanding of the scenario and shows the events happen as a sequence.

3. User requirements definitions

The User Requirement Specification specifies the requirements of the user taking the individual aspects into consideration in terms of ; the facility, equipment, and systems in terms of function, throughput, operability, and applicable standards, which are the functions to be carried out, the data on which the system will operate, and the operating environment.

The user requirements for a system should describe the functional and non functional requirements so that they are understandable by system users without any technical knowledge.

When we write the user requirement we should not write with technical forms, table or diagrams. We should write in simple language with simple table, forms and diagrams.

4. System Requirements Specifications

System requirements specification assist potential users to determine if the system specified meets their needs or how the system must be modified to meet their needs. The system requirements help to consider all of the requirements before design begin. Careful reviews of the requirements reveal omissions, misunderstanding and inconsistencies. System requirements specification should be correct, unambiguous, complete, consistent, verifiable, modifiable, and traceable, specify performance, and define detailed functionality of the system.

A specification can be in form of a written document, a set of graphical model, a formal mathematical model, and a collection of usage scenarios, prototype, or any combination of these. However, a standard template should be developed and use for a specification, arguing that this leads to requirements that are presented in a consistent and therefore more understandable manner.

The requirement engineer gives final work product produced which is known as specification. It acts as the foundation for subsequent software engineering activities. It describes all the related functions and the performance of a computer based system and the constrains that will govern its development.

In the given scenario, we would consider all the omissions and ambiguities.

First of all, the system did not provide all the functionality which usually a ticket issuing system should contain. It does not function as it should and does not provide the user with any choice such as to cancel a ticket and buy another one. At times, there are new users who wish to purchase rail ticket from the machine and this system does not guide and provide any kind of help.

Function: Issuing Ticket

Description: Issuing the ticket when the user select their desired tickets and make the correct

money

Inputs: Destination, child or Adult, Pay by card or cash

Output: Their desired ticket to be issued with their payment receipt

Require: Money, form of payment

Pre- Condition: Ticket will be validating between the user current place and the selected destination, otherwise user will have to pay the penalty fare.

5. Actions performed in the ticket-issuing system

6. Non-functional requirements

The non functional requirements define system properties and constrains for an example reliability, response time and storage requirement. Constraints are I/O device capability, system representation, extra. Process requirement may also be specified mandating a particular CASE system, programming language. This non functional requirement may be more critical than function requirements. If these are not met the system is useless and the non functional requirement can be classified as three type of requirement

6.1 Product requirement – these requirement specify that the delivered product must behave in a particular way for example execution speed, and reliability

The user interface for Library system shall be implemented as simple HTML without frames or Java applets

6.2. Organisational requirements – which are a consequence of organisational policies and procedures example for these, process standard used, implementation requirements

The system development process and deliverables defined in XYZCo-SP-Stan-95

6.3. External requirements – these could be from factors which are external to the system and its development process example interoperability requirements, legislative requirements.

The system shall not disclose any personal information about customer apart from their name and reference number to the operator of the system

After we discussed with all above mentioned Non-functional requirements, therefore we considered the product requirements should be determined for especially this scenario which include reliability and response time and should be contrasted with functional requirements that specify specific behavior or functions. And the product requirements have some additional attributes which are

Efficiency – Enable the system to perform under different situation or circumstance

Reliability – This could be very useful for ATM or ticket issuing system

Usability – This would help the user to access the system without any trouble or inconvenience

Performance – This is almost relevant to reliability and check the system is able to work or not in the different environment

Space Requirement – This part of product requirement is very useful for the ticket issuing system when the system is busy or full occupied with user needs. So there it is need to be expanded or stabilized number of machine at the station

8. Requirements Validation

Process requirements validation is an integral part of software engineering. The main activity is to check requirements needed and available to start any particular project. As a consequence of requirements engineering however, the work products produced need to undergo an assessement for quality during a validation sequence. The purpose of requirements validation is to examine the specification to ensure that all software requirements have been stated unambiguously, such as consistencies, omissions, and error detected and corrected and that work products conform to the standards established for the process, the project and the product

The primary requirements validation mechanism is the formal technical review. The review team that validates requirements includes software engineers, customers, user and others stakeholders who examine the specification looking for errors in content or interception, area may be clarification required. The process of requirements needs to check for consistency and completeness. During this process errors and inconsistencies will be identified and reduces future error.

Basically the system should have requirement validation checklist which would help to the system to identify the accurate information which

Are requirement started clearly and Can they be misinterpreted?

Is the source of the requirement identified e.g. a person, a regulation, or a document and the final stamen been examined by the primary source?

Is the requirement bounded by any quantities terms?

What other requirements match to this requirement?

Does the requirement violate any system domain?

Properties of requirements validation are as follows:

• Validity

• Consistency

• Completeness

In order to validate the ticket issuing system requirements all the above properties of the requirements validation must be met. And when the user pay by card the system should validate whether it is valid for making the particular payment and validate the pin no which has accepted or not therefore the validation must work out with final product it could be ticket or receipt

10. The impact on cash payment

After having input the payment type which is cash, in this instance the customer may not have the exact amount to make the payment. If the user is making payment with a note, the machine should prompt the customer to take his change. However, the machine could also have displayed the amount to be charged and change to be given to the customer.