car catalog

8/6/2019 Car Catalog

http://slidepdf.com/reader/full/car-catalog 1/14

Table of Contents

Vision ................................ ................................ ................................ ................................ ............. 2 Scope ................................ ................................ ................................ ................................ .............. 2 Glossary ................................ ................................ ................................ ................................ ......... 3 Detailed Software Requirements ................................ ................................ ................................ ..... 3

Components ................................ ................................ ................................ ............................... 3

Use Case Descriptions ................................ ................................ ................................ ................ 4 Functional Capabilities ................................ ................................ ................................ ............... 7 Business Rules / Validations ................................ ................................ ................................ ...... 8 Security Requirements ................................ ................................ ................................ ............... 8

User Management and Authentication: ................................ ................................ .................. 8 User roles and access control: ................................ ................................ ................................ 8

Non-functional requirements ................................ ................................ ................................ ...... 8 Environment ................................ ................................ ................................ ................................ ... 9

Implementation Ar chitecture ................................ ................................ ................................ ...... 9 Program Structure: ................................ ................................ ................................ ................. 9 Development tool set for code development: ................................ ................................ .......... 9 Other APIs, web services if any: ................................ ................................ ........................... 10 Deployment deliverables and process: ................................ ................................ ..................10

User Interface ................................ ................................ ................................ ............................10 Connectivity requirements ................................ ................................ ................................ .........10 Portability (devices / platforms / browsers to be supported) ................................ ....................... 11 Mobile application characteristics................................ ................................ ..............................11

Design ................................ ................................ ................................ ................................ ...........12 Conceptual Structure ................................ ................................ ................................ .................12 Logical and Physical Structure ................................ ................................ ................................ ..12

Technology Notes ................................ ................................ ................................ .......................... 14



Vision

For the users

Who would like to pur chase a car from the show room,

The Mobile Car Catalog is a best guide

That serves the ultimate purpose of the users to have a look over different models that are availablein the market within his budget

Unlik e the traditional method of going to various show rooms.

Our product would reduce the physical strain in moving from one showroom to the other in sear ch

of a comfortable car to serve his purpose. It also reduces the wastage of time. Our product providesobject mode sear ch as well as Attribute mode sear ch.

Scope

Example:

The students of a college or University can give feedback about a particular course or class. Theapplication will provide a feedback form for the students with some options so that students can

select an option and send it to the server. The consolidated results can be viewed by the lecturer of the class or the college management later. The feedback needs to be anonymous. The application

requires a mechanism to authenticate the student and the teacher.

Requirements List:

Requirement Id Description

R1 The user should be able to provide a Company of his interest and

his Budget.

R2 The user should be able to select among the given f eatures.

R3 He should be able to identif y a car of his choice.

R4 He should be able to navigate through the history.

R5 He should be able to stop the search if satisf ied with a car.

R6 He should be able to f ind the nearest showroom to purchase hiscar of interest.



Glossary

Mobile device Any device that is not stationary i.e. mobile phone, PDA,

Pocket Computer, Tablet PC or Laptop

Mobile user A user that can use a mobile device in any location i.e.

home, office, vehicle or any other location

Web User A user accessing the application using any standard web browser and Internet Connection

Detailed Software Requirements

Components

Actors:

Actor Name Descr iption

Mobile User Will identify a car of his choice

Component Diagram:



U se C ase Descri ptions

<< The detailed descriptions of the use cases in two-column format (user action and system response) with

the following columns: Use Case Id, Use case name, Actors, Goal, Description, Interface Devices,

Operational Flow, Preconditions and Post conditions >>

{

Use Case Definitions:

A way to model how user interacts with a system

A story about some way of using a system to do something useful

Use case defines a goal-oriented set of interactions between external actors and the

system under consideration

A use case is a description of a valuable end-to-end service provided by a system to a

primary actor

T he purpose of a use case is to result in some sort of value to the actor

What are not Use cases:

Use cases are not functional decomposition (e.g. finding the role of a user, finding a

sun sign based on date of birth)

Steps of an end-to-end service are not a use case (e.g. adding an item to a shopping

cart is not a use case; instead, 'Place order' is.

E ach alternative is not a use case (remove an item from shopping cart, changing the

quantity or shipping/ payment info etc.)



What may be Use cases:

Reusable step can be a use case e.g. Catalogue, Payment ( Subsystem-level use case as

opposed to user goal-level)

C RUD

Login

Use case ids can begin with 'UC' and concatenated with a serial number

Use case names should reflect the goal of the primary actor and should start with a verb (e.g.

'View Feedback Report' is preferred to 'Feedback Report').

}

Example:

Use Case Id: UC1

Use case name: Submit Feedback

Actors: Student

Goal: Provide feedback about a course or a specific lecture

Description: Students of a college or University can give feedback about aparticular course or class. The application will provide a feedbackform for the students with some options so that students can selectan option and send it to the server.

Interface devices: Mobile device

Operational Flow:

User starts the feedback applicationon her mobile device.

User identifies herself using the loginform.

User selects a course from the list.

User selects one option.

User completes the responses to thefeedback items and submits.

Login form is shown.

User identity is authenticated.If success, list of courses theuser (student) is enrolled for isdisplayed.

Error: If the user is not valid,application is terminated.

An option to select feedbackabout either the selectedcourse or a particular lecture of that course is given to the user.

The feedback form is shown,one item (question) at a time.

Extension: If the option islecture, then a calendar isshown to select a date beforethe feedback form is shown.

The responses to the feedbackare saved and the user istaken back to course selectionscreen with an option to quit.



Extension: User can submit thefeedback even before all the items inthe feedback form are completed.

Extension: The responses thatare completed so far are savedand the user is given an optionto either continue or selectanother course or quit theapplication.

Preconditions: Student ± course mapping should be in the system.

Post conditions: The student responses are saved.

Use Case Id: UC2

Use case name: View Feedback for self

Actors: Teacher Goal: View feedback about a lecture

Description: The teacher can view the consolidated feedback about a course or a

particular lecture of a course.

Interface devices: Mobile device or web browser

Operational Flow:

User starts the feedback applicationon his mobile device or webbrowser.

User identifies himself using thelogin form.

User selects a course from the list.

User selects one option.


User identity is authenticated. If success, list of courses of the user

(teacher) is displayed.


An option to select feedback abouteither the selected course or aparticular lecture of that course is

given to the user.

The feedback results are shown for all items in a scrollable (as needed)manner. After viewing the completeresults, an option to select another

course or to quit the application isgiven.

Extension: If the option is class, thena calendar is shown to select a datebefore the feedback form is shown.

Preconditions: Teacher ± course mapping should be in the system.

Post conditions: None



Use Case Id: UC3

Use Case name: View Feedback Report

Actors: Management

Goal: View feedback about a course for a teacher or all the courses

Description: The management can view the consolidated feedback about a course for ateacher or all teachers or all courses.

Interface devices: Mobile device or web browser

Operational Flow:

User starts the feedback applicationon his mobile device or webbrowser.

User identifies himself using the

login form.

User selects a course from the list or all courses.

User selects a teacher or allteachers option.


User identity is authenticated. If

success, list of all courses isdisplayed with an option to select acourse or all courses.


The list of teachers for that course isshown with an option to select ateacher or all.

Extension: If all courses is selected,select teacher option is not shown.

The feedback results are shown for all items in a scrollable (as needed)manner. After viewing the complete

results, an option to select another

course or to quit the application isgiven.

Preconditions: Teacher ± course mapping should be in the system.

Post conditions: None

<< Interface mockups for UC1 >><< Interface mockups for UC2 >><< Interface mockups for UC3 >>

Fu nctional C apabi l iti es

<< Generic requirements across multiple needs / features / use cases (e.g. identification of the student

should be anonymous) and / or specific actions (e.g. sending e-mail) or capabilities of the system in given

situations >>

Example:

The feedback providers' identities are anonymous.

E-mail should be sent to HR for any vacation approvals or cancellations.

The leave records should be automatically updated and only after a leave request is



approved.

Bu siness R u les / Val id ations

<< Conditions under which a use case is applicable or generic conditions globally applicable or rules for a

particular data or action to be valid >>

Example:

An employee cannot work in more than one department at the same time. Only the principal can approve vacation over and above the eligibility.

Only the HOD can cancel vacation after it is approved.

S ec u rity Req u ir ements

<< Capabilities that generally refer to the ability to prevent / forbid the access to the unauthorized parties

and control access to the application for authenticated users. Also includes mechanisms to manage the users

of the system (if they are not covered under specific use cases) >>

User Management and Authentication:

Example:

The telephone number of the user should be the identification for the user. The user id should be the same as the network id of the user.

User roles and access control:

Example:

Only authorized payroll personnel will be allowed to access the salary information.

The system has to authenticate a user, determine whether he is a student or teacher or

management.

Different user work with different applications (even though the database is shared), hence

the concept of roles is not needed here.

N on-f u nctional r eq u ir ements

<<

Usability, Reliability, Performance and Supportability requirements, standards

Usability refers to the ease with which the system can be used or learned. Reliability typically refers to availability, mean time between failures, and predictability of

behavior in abnormal conditions.

Performance refers to response time, transaction throughput and capacity / load.

Supportability refers to ability to support or be easily modified or maintained to accommodateusage or change scenarios.

>>

Example:



There should be no text input. (Usability)

The application should support the case of intermittent network connectivity i.e. the student

should be able to submit the feedback form in multiple sessions (one or more responses at a

time). (Reliability and Supportability)

The application should support interruptions for regular mobile device tasks i.e. receiving a

call or a message. (Supportability)

The form should load within 2 seconds. (Performance)

Flexible service based ar chitecture will be highly desirable for future extension(Supportability)

The system should be available 24 X 7. (Reliability/ availability) Downtime should be less than 1%. (Reliability/ availability)

Environment

I mplement ation Archit ect u r e

Program Structure:

<< e.g. 3-tier, servlets, database, database access programs like PL/SQL, web services and architecture

diagram showing different tiers / layers including any web services >>

Example:

The controller which is a servlet/JSP receives the request from the client (the web

browser) and communicates with the application logic and data layers according to therequest. The servlet/JSP retrieves the key areas, quality indicators, themes, questions

from the XML repository using Xalan parser. The parser gives the html output. Theservlet retrieves the ratings for quality indicators, themes, questions from the database.

These ratings are embedded in to the html output generated by the parser using javascript. In situations where the application logic is complex, the servlet hands over

the request to the application layer which generates intermediatory XML from the XMLrepository and this XML will be used by the servlet/JSP.

Development tool set for code development:



<< self ± explanatory >>

Example:

y Symbian / C++

OR

y J2ME, NetBeans 6.5, GlassFish

Other APIs, web services if any:

<< Any third party APIs or web services or pre-developed libraries / servlets etc.>>

Example:

y Y ahoo Astrology, Google weather, Google maps

Deployment deliverables and process:

<< Description of how the final application will be delivered e.g. installer, compressed file, app code plus

database code, etc.) and how it will be expected to be installed >>

{

This is not a detailed installation guide, but a brief notes on what will be the deliverables and on the process

of installing e.g. porting the application from a computer on to a mobile device or installing on a web server

for a web application

}

Example:

U ser I nt erf ac e

<< Guidelines about the characteristics of the user interface depending on the form factor i.e. Web or

mobile or client/server etc. and any additional considerations >>

Example:

y The user interface should be intuitive, clean and efficient and should require minimum

amount of data entry.

y The user interface should be consistent across different screens of a Feedback form and

ac

ross different Feedbac

k forms.y The user interface should be consistent across different device types and multiple platforms.

Connectivity r eq u ir ements

<< Self-explanatory >>

Example:

y GPRS connectivity is needed for authorization and uploading results.

y Wi-Fi / Blootooth connectivity also should be supported if the student is in the campusor very close to the server.



y Moderate speed Internet Connection for web user.

P ort abi l ity ( d evic es / platfor ms / browsers to be su pport ed)

<< Self-explanatory >>

<<

Devices:In case of Symbian application, ....In case of J2ME, ....

Platforms:In case of Symbian, .....In case of J2ME, ....>>

M obi le appl ic ation char act eristics

User Scenario << One or more of tourist / gaming / personal memory /

sales force support / device±to-device / Entertainment /

Information-oriented / General Application / Health care / In-the-field / job performance-related>>

Example:

General application, job performance-related

Device Characteristics <<

Bandwidth ± High / moderate / Low speedBattery -Processing Power -Screen Size -Memory -

>>

Example:

Bandwidth ± Moderate speedBattery - ????Processing Power - ????Screen Size - ????

Memory - ????

User Characteristics <<

Hands-free required? - Yes / NoPatience level : Moderate / Low / very lowText input? - Minimal / Eliminated / No constraint

>>

Example:

Hands-free required? - No



Mobile Number Used as user id (<<is it technicallyfeasible?>>)

Passwd No encryption

User Type Student / Teacher / Management (S /T/M)

Teacher

Column Name Remarks

Id

Name

Department

Other details

Student

Column Name Remarks

Id

Name

Department

Other details

Course

Column Name Remarks

Id

Name

Department

Other details

TeacherCourse

Column Name Remarks

TeacherCourseId

TeacherId

CourseId

Other details

StudentCourse

Column Name Remarks



StudentId

TeacherCourseId

Other details

FeedbackForm

Column Name Remarks

Ser ialNo

Question

FeedbackResultForCourse

Column Name Remarks

TeacherCourseId

QuestionSer ialNo

CumulativeScore

FeedbackResultForLecture

Column Name Remarks

TeacherCourseId

LectureDate

QuestionSer ialNo

CumulativeScore

Technology Notes

<< 10-12 page notes about the technology e.g. Symbian or J2m

E and /or Java / Servlets etc.>>

car catalog

Documents