Table of Contents

Vision...................................................................................................................................................2
Scope....................................................................................................................................................2
Glossary................................................................................................................................................3
Detailed Software Requirements..........................................................................................................3
Components.....................................................................................................................................3
Use Case Descriptions.....................................................................................................................4
Functional Capabilities....................................................................................................................8
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 Architecture...........................................................................................................9
Program Structure:......................................................................................................................9
Development tool set for code development:...........................................................................10
Other APIs, web services if any:...............................................................................................10
Deployment deliverables and process:......................................................................................10
User Interface.................................................................................................................................11
Connectivity requirements.............................................................................................................11
Portability (devices / platforms / browsers to be supported).........................................................11
Mobile application characteristics.................................................................................................11
Design.................................................................................................................................................12
Conceptual Structure......................................................................................................................12
Logical and Physical Structure......................................................................................................13
Technology Notes...............................................................................................................................15
Vision

For the users

Who would like to purchase 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 available
in the market within his budget
Unlike 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 search
of a comfortable car to serve his purpose. It also reduces the wastage of time. Our product provides
object mode search as well as Attribute mode search.

Scope

Example:
The students of a college or University can give feedback about a particular course or class. The
application 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 features.
R3 He should be able to identify 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 satisfied with a car.

R6 He should be able to find the nearest showroom to purchase his

car 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 Description

Mobile User Will identify a car of his choice

Component Diagram:
Use Case Descriptions
<< 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
 The 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.
 Each 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)
 CRUD
 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 a
particular course or class. The application will provide a feedback
form for the students with some options so that students can select
 an option and send it to the server.
Interface devices: Mobile device
Operational Flow:
User starts the feedback application Login form is shown.
on her mobile device.

User identifies herself using the login User identity is authenticated.

form. If success, list of courses the
user (student) is enrolled for is
displayed.

Error: If the user is not valid,

application is terminated.

User selects a course from the list. An option to select feedback

about either the selected
course or a particular lecture of
that course is given to the user.

User selects one option. The feedback form is shown,

one item (question) at a time.

Extension: If the option is

lecture, then a calendar is
shown to select a date before
the feedback form is shown.

User completes the responses to the The responses to the feedback

feedback items and submits. are saved and the user is
taken back to course selection
screen with an option to quit.

Extension: User can submit the Extension: The responses that

feedback even before all the items in are completed so far are saved
the feedback form are completed. and the user is given an option
to either continue or select
another course or quit the
application.

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 application Login form is shown.
on his mobile device or web
browser.

User identifies himself using the User identity is authenticated. If

login form. success, list of courses of the user
(teacher) is displayed.

Error: If the user is not valid,

application is terminated.

User selects a course from the list. An option to select feedback about
either the selected course or a
particular lecture of that course is
given to the user.

User selects one option.
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 is
given.

Extension: If the option is class, then

a calendar is shown to select a date
before 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 a
teacher or all teachers or all courses.
Interface devices: Mobile device or web browser
Operational Flow:
User starts the feedback application Login form is shown.
on his mobile device or web
browser.

User identifies himself using the User identity is authenticated. If

login form. success, list of all courses is
displayed with an option to select a
course or all courses.

Error: If the user is not valid,

application is terminated.

User selects a course from the list or The list of teachers for that course is
all courses. shown with an option to select a
teacher or all.

Extension: If all courses is selected,

 select teacher option is not shown.

User selects a teacher or all
teachers option.
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 is
given.

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

Post conditions: None

<< Interface mockups for UC1 >>

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

Functional Capabilities
<< 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.

Business Rules / Validations

<< 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.

Security Requirements
<< 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.

Non-functional requirements
<<
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 accommodate
usage 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 architecture 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
Implementation Architecture
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 the
 request. The servlet/JSP retrieves the key areas, quality indicators, themes, questions
from the XML repository using Xalan parser. The parser gives the html output. The
servlet 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 XML
repository and this XML will be used by the servlet/JSP.

Development tool set for code development:

<< self – explanatory >>

Example:

 Symbian / C++

OR
 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:
 Yahoo 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:

User Interface

<< 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:

 The user interface should be intuitive, clean and efficient and should require minimum
amount of data entry.
 The user interface should be consistent across different screens of a Feedback form and
across different Feedback forms.
 The user interface should be consistent across different device types and multiple platforms.

Connectivity requirements
<< Self-explanatory >>
Example:
 GPRS connectivity is needed for authorization and uploading results.
 Wi-Fi / Blootooth connectivity also should be supported if the student is in the campus
or very close to the server.
 Moderate speed Internet Connection for web user.

Portability (devices / platforms / browsers to be supported)

<< Self-explanatory >>
<<
Devices:
In case of Symbian application, ....
In case of J2ME, ....

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

Mobile application characteristics

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 speed

Battery -
Processing Power -
Screen Size -
Memory -

>>

Example:
Bandwidth – Moderate speed
Battery - ????
Processing Power - ????
Screen Size - ????
Memory - ????

User Characteristics <<

Hands-free required? - Yes / No

Patience level : Moderate / Low / very low
Text input? - Minimal / Eliminated / No constraint

>>

Example:
Hands-free required? - No
Patience level : Low to very low
Text input? - Should be eliminated

Testing << Is the application required to be tested on actual

Considerations device, should it be tested for large amount of data, should
it be tested on different platforms, should it be tested with
different connectivity modes (GPRS, Blue tooth) etc. >>

Example:
Application needs to be tested on the actual device.

Design

Conceptual Structure
<< A digram showing the functional / technical components (including third party components / services
and their relationships and where each component resides (i.e. installed) in the final deployed application
>>
 Authentication
Module

Results
Store

SERVER

Feedback
Form

Logical and Physical Structure

<< Class diagrams and data dictionary, XML Schema Definitions (XSD), any other file formats and where
they are stored (absolute / relative paths) etc. >>

<<Class diagram:>>

Data Dictionary:

User:
Column Name Remarks
Mobile Number Used as user id (<<is it technically
feasible?>>)
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
SerialNo
Question

FeedbackResultForCourse
Column Name Remarks
TeacherCourseId
QuestionSerialNo
CumulativeScore
 FeedbackResultForLecture
Column Name Remarks
TeacherCourseId
LectureDate
QuestionSerialNo
CumulativeScore

Technology Notes
<< 10-12 page notes about the technology e.g. Symbian or J2ME and /or Java / Servlets etc.>>