REPORT ON NYC MTA SELECT BUS SERVICE METROCARD FARE COLLECTOR ASSESSMENT

INTRODUCTION

The MetroCard is a magnetic stripe card used for fare payment on transportation in the New York City area. It is the primary payment method for the New York City Subway; New York City Transit buses, including routes operated by Academy Bus under contract to the Metropolitan Transportation Authority (MTA) and MTA buses; Nassau Inter-County Express (NICE) systems; the PATH train system; the Roosevelt Island Tramway; AirTrain JFK; and Westchester County’s Bee-Line Bus System.

• Description of setting

NYC MTA Select Bus Service MetroCard Fare Collector Location

Select Bus Service is located in New York City as an innovative bus service designed to reduce travel time and increase the level of comfort for customers.

New York City (NYC), is the most populous city in the United States. With an estimated 2018 population of 8,398,748 distributed over about 302.6 square miles (784 km²), New York is also the most densely populated major city in the United States. Located at the southern tip of the U.S. state of New York, the city is the center of the New York metropolitan area, the largest metropolitan area in the world by urban landmass. With almost 20 million people in its metropolitan statistical area and approximately 23 million in its combined statistical area, it is one of the world’s most populous megacities.

New York City has been described as the cultural, financial, and media capital of the world, significantly influencing commerce, entertainment, research, technology, education, politics, tourism, art, fashion, and sports. Home to the headquarters of the United Nations.

NYC MTA Select Bus Service MetroCard Fare Collector Purpose

1. Select Buses attempt to cover routes in NYC where optimally train service should be available.
2. Make a limited number of stops.
3. To speed up the boarding of the bus tickets are purchased from these machines before boarding select buses.

1. Select Buses try to solve the high demand for buses in New York City due to the introduction of the MetroCard, as well as with an increase in the city’s population which has led to significant growth in bus ridership in recent years.
2. To improve transit’s performance for existing and new customers as well as to foster economic development.

When it is used

NYC MTA Select Bus Service MetroCard Fare Collector is used when paying fare for New York MTA buses as it is the primary payment method for the New York City Subway; New York City Transit buses. When in use, the user follows the following steps:

1. Press Start Button
2. Insert MetroCard
3. Get Proof of Payment / Your Ticket

Features and functionalities of NYC MTA Select Bus Service MetroCard Fare Collector

Figure 1 Diagram of an MTA Fare collector, User interface

Features

1. Display Screen- The screen displays the instructions on how to use the Fare Collector, it shows the progress of the transaction and also the success message in successful transaction and error message if a problem arises.
2. Audio Output- this outputs details of the transaction in sound form.

• The Star Button- this a big that is pushed to initiate a transaction.

1. Card Input Section- this is where the riders insert their MTA cards before the transaction.
2. Ticket collection Area- this is a section where the ticket is ejected when the transaction is successful.
3. Keyboards- allows input of numbers like several riders one is paying for.

• Touch Screen- this displays and accepts riders’ input.

Functionalities

1. How to Pay:
2. Press the start button.
3. Insert your MetroCard, transfer, or ticket face up into the slot.
4. Your ticket will be issued automatically.

1. . Paying for more than one person:

Only a value-based MetroCard can be used to pay the fare for more than one person. Insert the MetroCard into the machine up to four times for a maximum of four people, and SBS paper tickets will be issued for each person.

• Transferring to another SBS bus:

You must obtain a new ticket at the bus stop where you plan to board. At the bus stop, insert the same MetroCard you used to pay for your previous trip and a new ticket will be issued.  Multiple tickets will be issued if a value-based MetroCard was used to pay for more than one person.

1. Paying with coins, exact change.
2. Press the black button to start.
3. Insert exactly $2.75 in coins; if you overpay, no change will be returned.
4. Your ticket will be issued automatically.
5. Reduced-Fare Customers and Half-Fare Student MetroCard users:
6. Press yellow button first
7. Insert exactly $1.35 in coins; if you overpay, no change will be returned.
8. Your ticket will be issued automatically.

1. Transfers:

Use your transfer for other local and limited routes, but to transfer to another SBS bus route, insert your SBS transfer into the MetroCard Fare Collector at the SBS bus stop where you plan to board; a ticket will be issued automatically.

(ii) Elicitation Approach

Using the Observation Technique for Requirements Elicitation

The observation was the only requirement elicitation technique used. There was no other intended verbal or non-verbal communication made with subjects.

Passive/Invisible observation happened where no interaction with the riders was made while the observation was going on, but notes were being taken.

Every observation was guided by clearly stated objectives that were written down. This assisted to know what data was to be collected, how observation would be done, when and where to observe, how the data would be collected, and what the data will be used for after analysis.

Merits of Observation

• The observation technique is an effective means of deciphering how a user does their job by conducting an assessment of their work environment.
• It increases the analyst’s familiarity with the culture and working style of a group of people.
• This technique can also be used to verify requirements and deliver instant requirements worthy of consideration.
• A current process is to be monitored
• The objective is to improve a process
• Processes are highly repeatable
• The data gathered during observation sessions are quite reliable; it is often used to confirm the data extracted using other techniques
• It is relatively inexpensive
• It allows the analyst to perform work measurements of each MetroCard Fare Collector

There are, however, some downsides to using the observation technique that was noted. One is that exceptions are difficult to capture in one session; repeated observation sessions were needed to supplement the facts gathered.

Stakeholders were prone to interruptions during observation sessions and may have responded differently when being studied as demonstrated by the Hawthorne Effect.

Observations made

• Users who appear to be interacting with the vending machine for the first time:
• Touch screen in different ways to turn it on.
• Press buttons improperly to try and get it to work.
• Spend time looking at the machine.
• Users who appear to have experience interacting with the machine:
• Press the start button.
• Remove Proof of Payment.
• Experienced users do not use the machine’s language feature even if they seem to speak another language.
• If users make a mistake they often give up and move to the neighboring vending machine.
• New users do not spend time reading the instructions that are provided.
• Riders use the machine as an excuse to board the bus without paying for the ticket.
• The machine is slow and at times there is not enough time to purchase a ticket and avoid missing the bus.
• Cannot get the machine to work in time to avoid risking to miss the bus.

(iii) Analysis

Flowchart requirement analysis

A flowchart depicts the sequential flow and control logic of a set of activities that are related. Flowcharts are in different formats such as linear, cross-functional, and top-down.  The flowchart can represent system interactions, data flows, etc.

In this case, a cross-functional flowchart used for the requirement analysis.

From the analysis, the following were the outcomes.

1. Ideal situation- the customer – Press the start button then Insert your MetroCard then transfer or buys a ticket then the ticket is issued automatically and then get the card and the ticket and finally stops.
2. Repetitive situation- the customer – Press the start button then Insert your MetroCard then transfer or buys a ticket then the ticket is not issued automatically and then get the card and insert it again and repeat process1 until the ticket is processed and finally stops.
3. Despair situation- the customer – Press the start button then Insert your MetroCard then transfer or buys a ticket then the ticket is not issued automatically and then get the card and stops or try the next machine.

Figure 2 Flowchart diagram of the requirement analysis

Flowchart technique helps in showcasing the critical attributes of a process.

Advantages of Using flowcharts

1. Communication: Flowcharts are a better way of communicating the logic of a system to all concerned or involved.
2. Effective analysis: With the help of the flowchart, the problem can be analyzed more effectively, therefore, reducing cost and wastage of time.

• Proper documentation: Program flowcharts serve as good program documentation, which is needed for various purposes, making things more efficient.

1. Efficient Coding: The flowcharts act as a guide or blueprint during the systems analysis and program development phase.
2. Proper Debugging: The flowchart helps in the debugging process.
3. Efficient Program Maintenance: The maintenance of an operating program becomes easy with the help of the flowchart. It helps the programmer to put efforts more efficiently on that part

• Requirements

1. Functional Requirements (FR) – the user interface to be clear and precise since the customer needs to use the least time with the machine.

-Introduce features to keep track of the customer destination in the bus’s system.

2. Non-Functional Requirements (NFR)- improve Reliability by enhancing the rate at which the machine processes the transactions. Use a better operating system.
3. User requirements- the Select Bus Service MetroCard Fare Collector should have a feature where the users can select their preferred languages.

CONCLUSION

As discussed in this report, it is clear that the MetroCard Collection should be redesigned to improve its usefulness in the community. This redesigning will include all the requirements that have been identified above,

REFERENCES

Ramdhani, Muhammad & Maylawati, Dian & Amin, Abdusy & Aulawi, Hilmi. (2018). Requirements Elicitation in Software Engineering. International Journal of Engineering and Technology(UAE). 7. 772-775. 10.14419/ijet.v7i2.29.14254.

Brannigan, Augustine & Zwerman, William. (2001). The real “Hawthorne effect”. Society. 38. 55-60. 10.1007/s12115-001-1041-6.

WIKIPEDIA, MetroCard, [online], 29^th April 29, 2020, https://en.wikipedia.org/wiki/MetroCard

QUESTION 1, PART B

REQUIREMENT DOCUMENT

Table of Contents

Table of Contents. 1

Introduction. 1

Purpose. 1

Scope. 1

Definitions, acronyms, and abbreviations. 1

References. 1

Overview.. 2

Overall description. 2

Product perspective. 2

Product functions. 2

User characteristics. 2

Constraints. 2

Assumptions and dependencies. 3

Specific requirements. 3

Functional Requirements (FR) –. 3

Nonfunctional requirements. 3

Introduction

Purpose

The MetroCard is a magnetic stripe card technology used for fare payment on transportation in the New York City area. It is the primary payment method for the New York City Subway; New York City Transit buses, including routes operated by Academy Bus under contract to the Metropolitan Transportation Authority (MTA)

Scope

Select Buses attempt to cover routes in NYC where optimally train service should be available. Make a limited number of stops during the trips.

To speed up the boarding of the bus tickets are purchased from these machines before boarding select buses.

Select Buses try to solve the high demand for buses in New York City due to the introduction of the MetroCard, as well as with an increase in the city’s population which has led to significant growth in bus ridership in recent years.

To improve transit’s performance for existing and new customers as well as to foster economic development

Definitions, acronyms, and abbreviations

NYC – New York City

MTA-  Metropolitan Transportation Authority

NICE – Nassau Inter-County Express

References

Ramdhani, Muhammad & Maylawati, Dian & Amin, Abdusy & Aulawi, Hilmi. (2018). Requirements Elicitation in Software Engineering. International Journal of Engineering and Technology(UAE). 7. 772-775. 10.14419/ijet.v7i2.29.14254.

Brannigan, Augustine & Zwerman, William. (2001). The real “Hawthorne effect”. Society. 38. 55-60. 10.1007/s12115-001-1041-6

.

WIKIPIDIA, MetroCard, [online], 29^th April 29, 2020, https://en.wikipedia.org/wiki/MetroCard

Overview

NYC MTA Select Bus Service MetroCard Fare Collector will be an improved update of the current system where a new feature will be implemented into the system to improve its functionality and efficiency.

Overall description

Product perspective

The product is supposed to be a community service development, under the GNU General Public License. It is an embedded system implementing a customer’s request. The NYC MTA Select Bus Service MetroCard Fare Collector System provides a simple mechanism for users to get a quick bus ticket.

Product functions

Accepts user input

Display user instructions

Validate transaction

Counts currency and give out the extra balance.

Display transaction progress

Display error or success messages.

Keep a record of customer

Communicate with part of the system on the bus on customers’ destinations.

Produce bus tickets

User characteristics

The users of The NYC MTA Select Bus Service MetroCard Fare Collector is the general public which consists of all groups of people that are, people with physical abilities or disabilities, intellectual abilities or disabilities, the general attitude toward job and technology, all education linguistic, different skills, all age groups, all gender.

Constraints

Results- The products should have a low production cost.

Time frames- the production time should be minimized.

Resources- the cost resources used should not exceed the stipulated budget

Assumptions and dependencies

Assumptions that are made in this process would be the cost of production and the amount of time required to cover the system.

Project dependencies for this project are based on the fact that the system is state-owned and the approval must be seeking before commencing.

Specific requirements

Functional Requirements (FR)

• The user interfaces to be clear and precise since the customer needs to use the least time with the machine.
• Introduce features to keep track of the customer destination in the bus’s system.

Nonfunctional requirements.

• Adaptability- this may be brought to the customer using the MetroCard Fare Collector whereby changes will be implemented. Covered by using some features labeling of the current system in the new system. Also, the use of customer language will reduce adaptability constraints.
• Reliability- The developer should make the new system work with the confidence that the risk of its failure is minimal.

Therefore, the system should simple and with a clear flow of information and avoiding complex interface.

• Scalability- due to the high demand for the system in New York City, the scalability of the system should adaptable to when high traffic is expected.

The solution for this is to upgrade the current system operating system to the faster version and at the same time accept the firmware currently used.

• Security- this will be implemented to protect the system against malicious attack and other hacker risks so that the software continues to function correctly under such potential risks.

To achieve this proper forms of authentication and verification will be used.

• Usability- the degree to which the system will be used by specified consumers and achieve quantified objectives with effectiveness, efficiency, and satisfaction in a quantified context of use.

The solution for this requirement is observing all the user interface design rules and guidelines. This will make the system usable to the customer.

• Maintainability- the system should be made easy to understood, repaired, or enhanced changes for future development.

This will be achieved by using proper development techniques such as in coding developers to provide well-detailed documentation and commenting on the code.

QUESTION 1, PART C

The Process and Importance of Requirements Elicitation Specification and Documentation

In the world today, people are relying more and more on technology for their everyday needs. Part of this reliance stems from a growing need of on the go service, but what many people don’t realize is that without the software that is designed, none of this would be possible. More and more people are using a broad variety of software types, thus the importance of software elicitation.

A group of requirements always has a structure, and developers should always follow it. The best way that a developer can structure requirements is to organize them into different types. It is suggested that business needs, features, functional software requirements, and non-functional software requirements as the different types used to structure and organize requirements (Heumann, 2004).

The highest category would be the business needs category, which would express a business need without reference to a system. The features category type describes what the system should do. The functional software requirements provide enough detail about what the software’s functionality is that will be written in code. The lasts category, non-functional software requirements, specifies the requirements of the software, such as how fast the system must be. The software requirements need to be elaborated with comments. Comments provide information that will make the requirements more understandable or usable. Developers should try to anticipate what information the development team might need when the process of designing and coding the system begins. Another important fact that the developers need to understand is the language of the written requirements.

Challenges faced during requirement elicitation

1. Hard to quickly record what was happening during periods of heavy use: when the system was in high demand and many customers used it, it was difficult to record what was happening due to the small service time spend at the Bus Service MetroCard Fare Collector
2. Difficult to pick which machine to observe: choosing a machine to observe was a challenge in that one had to be available at the station and also base on the fact that all the machines were used randomly hence the tendency to change choice.

• Difficult to stay near the machine during peak times: during pick times there were many customers at the station and there was limited space and chance to make proper observations and recording.

1. Some exceptions were difficult to capture in one session: many activities were happening at the station and keeping a record of all that was happening was not easy, hence other activities had to be postponed to the next sessions.
2. Repeated observation sessions were needed to supplement the facts gathered however, this was not possible since observation was the only elicitation technique used.
3. Biasing was reflected in the form of seeing what was expect to be seen and what one wanted to see, which affects the results of the observation.

How to improve observation skills as a requirement elicitation technique

1. Know your subject. You’ll notice more if you understand the subject that is under investigation.
2. The use of interview along with the observation may help to clear some facts.

• Try something new. Choose an activity that will engage your senses and heighten your awareness and reduce the chances of losing focus during observation.

1. Improve your concentration by cutting out distractions.
2. Record and consider your observations. Go beyond the things you see.

Requirement Analysis

The requirement analysis phase is the most important and fundamental stage in software engineering. Members of the team can participate in the requirement analysis phase. During this phase, the primary requirements of the end-user will be collected. When the software is developed for an organization, personnel who will be using the software will be asked of their requirements mentioning the intended use of the software.

Analysts will gather information regarding the type of data intended for use, method of data handling by the software, and accessibility of data by the software on installation.

In our system’s requirement analysis, a flowchart technique was used.

Challenges faced during requirement analysis

1. Communication gaps existed between customers hence reflecting the gap during analysis.
2. Ambiguous data- it was discovered that some of the data collected was ambiguous and needed to be sorted.

How to improve requirement analysis

Requirement analysis can be improved in the future study by obtaining enough data during elicitation and selecting the appropriate analysis technique.

References

Beck, Kent. Extreme Programming. 2000.

Cohen, S, D Dori, and U de Haan. “A Software System Development Life Cycle Model for

Tutorial Point. Software Development Life Cycle (SDLC). 2020.