Reference no: EM133506631
Learning Outcome 1: Understand, critically analyse and choose appropriate methodology for building software based on the business requirements and technical platform using which the software is distributed.
Learning Outcome 2: Reflect on given project conditions to implement component driven development practices taking into consideration customer requirements, platform features and technological constraints.
INSTRUCTION:
In this assessment the students will work in groups assigned to submit a software specification document. The document must contain the following headings:
Title Page
Table of Contents
Introduction
System Description
Selection of SDLC
Requirement Specifications
Functional Requirements
Non-functional Requirements
Others
Assumptions / Constraints
Use Case Diagram
References
Appendecies (if needed)
Contributions/WBA
Each heading should contain the following information:
Title Page
Your report must include a Title Page with the title of the assessment, your group member's name, student ID and the VIT logo.
Table of Contents
A contents page showing page numbers and titles of all major sections of the report.
Introduction
The introduction should describe the purpose of the report in not more than 250 words.
System Description
The part should provide a brief overview of the system. For example, if your team is developing an ATM system, the system description should include relevant details such as withdrawing money etc. This section should not exceed more than 500 words.
Selection of SDLC
This section of the report should provide the reasoning of why the SDLC methodology is selected. For example, if the group selects ‘Scrum' as a methodology, they need to provide a strong justification for that. Simply saying "we will use Scrum" will not give any marks for this section.
Requirement Specifications
The requirement specifications should be written based on the SDLC methodology your team has selected. For example, if they have selected ‘Agile' as a methodology then it should be following the USER STORY format as shown below:
If your team decides to adopt non-agile methodology (such as waterfall etc), then your team will be writing the requirements in the Use Case Casual format as shown in the lecture notes.
The requirements must be divided into functional and non-functional sections.
Assumptions / Constraints
This heading will include any relevant assumptions or constraints your team has considered with respect to the project and the domain.
Use Case
This section provides a complete use case diagram of the system under discussion (i.e., the project). The diagram should include all use cases based on the specifications and relevant relationships that are <<include>>, <<extend>> and generalisation. The diagram must be syntactically correct.
References
All relevant references must be added here. The references should use IEEE format. For more help about IEEE format, refer to the instructions provided under library and learning section of the LMS page for the unit.
Appendices
This is an optional section and usually contains information about any terminologies or abbreviations used. If used that needs to be consistent throughout the document.
CASE STUDY - VIT Ride
VIT has asked your team to develop an application named VIT Ride typically for Users looking for a ride on a budget. The application will allow user to get ride to their destination. There are 3 options for user to travel to their destination. One is to hire a driver and the other option is to share a car with other customer.
Users can be registered as a driver or passenger. The application should allow the following, but not limited to:
user to switch to driver mode or the passenger mode
show available drivers and their vehicles type (passenger mode)
check credit balance (passenger mode)
notify driver for new task (driver mode)
show amount earned (driver mode)
take payment from credit card, paypal, applepay and googlepay (passenger mode)
GPS (driver mode)
promotion (driver and passenger mode)
feedback (passenger mode)
An administrator can manage drivers and accounts. The administrator also monitors customer feedbacks and filter them if needed.
The above description are just some of the requirements outlined by the stakeholder and he is unsure that whether there is any other functionality need to include into the application. Stakeholder will hold a meeting if there is more requirement for the VIT Ride application.