1        

1.1     Functional Requirements

 

<< LIST AT LEAST [N x 4] FUNCTIONAL REQUIREMENTS FOR THE SYSTEM. AT LEAST [N X 2] OF THEM MUST BE NEW, PROPOSED BY YOU, AND NOT DERIVED FROM THE EXISTING SYSTEM (MAKE SURE TO MARK THEM AS NEW). YOU NEED TO DISCOVER THE [N] NEW REQUIREMENTS ON YOUR OWN, USING AT LEAST 2 DIFFERENT REQUIREMENTS GATHERING METHODS (SEE SECTION 3).>>

 

The system shall allow passengers to self check-in for the trains or buses.

 

system shall record accident claims. (new)

 

Passengers shall be able to update self-information.

 

The system shall allow the passengers to self check his journey on the application of mobile. (new)

 

The system shall notice the passengers the destination place and what is the next stop to the passengers on the train.

                                                  

The system shall supply some special types of card for the elders and students under 18.

                                                  

The system shall allow passengers to buy the temporary card/ticket when they forget the opal card. (new)

 

The system shall allow passengers to make payment by both cash and credit.

 

The system shall supply special seats for the pregnant, the disable. 

 

The system shall inform the passengers the emergency on the train

 

The system shall be able to make different payments for different travel distance.

 

Passengers shall be able to get help from the staff.

 

The system shall allow the passengers to book ticket online.(new)

 

The passengers shall be able to text feedback to opal system. (new)

 

The passengers shall be able to cancel the journey and repaid from the system. (new)

 

The system shall inform the passengers which exits is to where. (new)

 

The system shall allow the application on mobiles inform the passengers the time  table for different trains.

 

 

 

 

 

 

 

 

1.2     Non-functional Requirements

 

<< LIST OF AT LEAST [N x 3] NON-FUNCTIONAL REQUIREMENTS. NOTE THAT IN REAL-LIFE SITUATIONS, EXTENSIVE REQUIREMENTS GATHERING INVOLVING NUMEROUS STAKEHOLDERS WOULD BE UNDERTAKEN IN ORDER TO ARRIVE AT SUCH A LIST. HERE, THE REQUIREMENTS CAN BE DERIVED FROM THE EXISTING SYSTEM OR FROM YOUR REQUIREMENTS GATHERING METHODS. YOU CAN ALSO MAKE ASSUMPTIONS AS LONG AS THEY ARE REASONABLE.>>

The system shall ensure the safety of passengers’ information.

 

The system shall be available 24 hours.

 

The system shall ensure the notification of next stop is clear and understandable.

 

The system shall be accessible to the visually-impaired.

 

The system shall inform information to the passengers on time.

 

The system shall include muilti-language.

 

The system shall present passengers’account balance clearly.

 

The system shall make the payment efficiently.

 

The system shall present the train timetable understandable.

 

The system shall calculate correctly for the train tickets.

 

The system shall control the audio of notification on the trains suitable.

 

The system shall inform the emergency to passengers in time.

 

 

opal system use case is what i did in this week 

    Agile Software Development Methodology

Most agile methods attempt to minimize risk by developing software in a short-term framework called iteration, which usually lasts for one to four weeks. Each iteration is like a micro-software project, including all the tasks required to release a tiny incremental product. The agile software project is designed to be able to release new software at the end of each iteration. At the end of each iteration, the team re-evaluates the project priorities.

 

At the very least, this includes programmers and people who define the product. Such aileile team is located in the cowshed, including all the people needed to complete the software. As a product manager, business analyst or actual customer. Cowsheds may also include testers, interface designers, technical writers and managers.

 

Agile methods also emphasize that work software is the primary measure of progress. Combined with face-to-face communication preferences, agile methods produce very few translation documents relative to other methods. ( )

 

1.1.1    Advantages

-Provide the software that users need. It will bring the software systems that users really need. Waterfall mode usually draws a straight line between the product's starting point and the final result, and then follows a straight line. However, when the project is completed, users often find that the destination is not their real destination. Agile methods use a small step forward. Each step needs to be adjusted and the next direction is determined until the true end point is reached.

-Higher quality. Agile has strict quality requirements for the output of the iteration cycle. Agile advocates the use of test-driven development, which is to develop test code for this feature before it is officially developed. This provides a reliable quality assurance for the entire development cycle of an agile project.

-Bring products to market faster. Agile advocates avoiding large-scale upfront planning and thinks it is a big waste. Because a lot of pre-planned things will change, large and comprehensive pre-plans are usually in vain. Agile advocates a plan for gradual improvement. Agile teams focus only on the most valuable parts of the development project that are most needed today. This allows for early development, shortening time to market, or enabling software to be delivered earlier.

 

1.1.2    Disadvantage

-Through the distribution of documents between the stages, a rigorous review is conducted at the end of each phase to check that the functional design and implementation meets the requirements of the documents under the previous phase. If they do not meet the requirements, they will return to the previous stage to check and correct them. Until the final stage of the product passes the test and is released during release and operation for maintenance.

-normally harder and more complex than other methodologies in designing

-And once the framework of the software is determined, it will be difficult to change, and it will even lead to the needs of customers who are unable to adapt to the whole body.

-Communication at all stages is through a large number of bloated, complex documents to convey information. Such software development usually makes the function of each piece relatively perfect, and the connection between modules and the time to fully understand the document will be very long.

 

1.1.3    Core Practices

Based on the above comparison, we can draw several advantages of agile development compared to traditional software engineering: the product is more in line with user expectations, the rework possibility is smaller, the rework cost is lower, and the iterative development mode is adopted, which has strong flexibility. However, agile development requires high demands on the team at the same time. It requires face-to-face communication of team members and continuous high-quality delivery, so it is more suitable for elite teams with fewer people. In the face of large-scale projects, you can choose to split it into several sub-projects, and then use agile development.

 

The main goal of XP is to reduce the cost of changing software requirements. Using traditional system development methods, such as the waterfall approach, the requirements of the system are deterministic and are usually "frozen" at the beginning of the development project. Demand costs later in the project - costs that are very common in the real world can be very high.

 

1.1.1    Advantage

-Adopt a simple planning strategy that does not require long-term planning and complex models, and has a short development cycle;

-Iterative incremental development, feedback correction, and iterative testing are used throughout the process to accommodate the changing needs of users.

 

1.1.2    Disadvantage

-Currently applied mainly on small-scale projects and achieved success, but whether it is suitable for medium-sized or large-scale software products requires careful consideration;

-Unable to determine whether the maintenance cost of this model is lower after the delivery of newer products;

-High experience on coding personnel

 

1.1.3    Core practices

Test-driven development

Planning game

Entire team

Pair programming

 

Continuous integration

Design improvement

Small version

 

Simple design

Systematic metaphor

Collective code ownership

Coding standard or coding convention ( )

 

1.2     Rapid application development(RAD)

Save costs by reducing the amount of construction required to build a product. While saving costs during construction, the ability to shorten the construction cycle can also have an impact on the entire project: shorter construction cycles make incremental lifecycles such as evolutionary prototypes Practical. Because RDLs typically lack optimal performance, limit flexibility, and are limited to specific types of problems, they are generally more suitable for developing internal business software and are limited. Distribute custom software instead of system software.

 

1.2.1    Advantages

-The development speed is fast and the quality is guaranteed.

- Particularly effective for information systems.

 

1.2.2    Disadvantages

- For large, scalable projects, RAD requires a lot of human resources to create multiple, relatively independent RAD teams.

- If the developer and user are not prepared to complete the entire system in a short time, the RAD project will fail.

- If a system is not reasonably modular, there are many problems with RAD component building.

- If the system requirements are high performance and you need to improve the performance by adjusting the component interfaces, you cannot use the RAD model.

- In case of high technical risk

 

1.2.3    Scope of application

-Not suitable for development with high technical risk, not suitable for system requirements is high performance, and product development needs to improve performance by adjusting component interfaces.

 

-Applicable to tight schedules, subdivided functions, and suitable components

 

1.3     Systems Development Life Cycle

The SDLC proposes a systematic, sequential approach to software development. The process begins with a specification of user requirements and ultimately provides a complete software and ongoing technical support through the process of planning, modeling, building and deploying.

 

1.3.1    Advantades

- Emphasize the stage of development, each stage has order and dependence

- Emphasize early research and needs analysis, postponing the idea of ​​coding implementation

- Provides a template that allows analysis, design, coding, testing, and support methods to have a common guide under the template.

 

1.3.2    Disadvantages

- Document driven, users can't know the status of the product in time

- Depending on early research and needs analysis, it is difficult to adapt to the uncertainties that must exist at the beginning of many projects.

- The process is single, and the tasks of the previous stage must be completed before the next stage can be carried out. The successful experience in the development process cannot be used for this product.

- The test was introduced later, and significant defects in the system could result in significant losses if not discovered before the executable program review.

- The organization is huge and the staff is idle.