Brown LLC Photo Software Software Requirements

Brown LLC
Photo Software
Software Requirements Specification
Version 1.0
Photo Album Editing Version: 1.0
Software Requirements Specification Date: 05/10/2021
BLLC-001
Confidential ©Brown LLC, 2006, 2019, 2021 Page 2
Revision History
Date Version Description Author
04/05/2006 1.0 Initial document Michael Brown
05/06/2019 1.0.1 Slight modernization Sheldon Linker
05/10/2021 1.1 Modern best practice: No path to an error

case
Sheldon Linker
BLLC-001
Table of Contents
1 Introduction 4
1.1 Purpose 4
1.2 Scope 5
1.3 Definitions, Acronyms and Abbreviations (Glossary) 5
1.4 Risk Analysis 5
1.5 Overview 5
2 Overall Description 5
2.1 Use-Case Model Survey 6
2.2 System Evolution 7
3. Specific Requirements 7
3.1 Use-Case Reports 7
3.1.1 Create Album 7
3.1.2 Delete Album 10
3.1.3 Select Album 12
3.1.4 Create Sub-album 14
3.1.5 Delete Content 17
3.1.6 Import Photo 19
3.1.7 Export Photo 22

3.1.8 Move Album Up 24
3.1.9 Move Album Down 26
3.1.10 Move Content Up 28
3.1.11 Move Content Down 30
3.1.12 Move Down Level 32
3.1.13 Move Up Level 33
3.1.14 Select Content 35
3.1.15 Copy Photo 37
3.1.16 Cut Photo 38
3.1.17 Paste Photo 39
3.1.18 Edit Photo 41
3.1.19 EMail Photo 43
3.1.20 Run Continuous Slideshow 45
3.1.21 Run Slideshow Once 49
3.1.22 Stop Slideshow 50
3.1.23 Search for Photo 51
3.2 Supplementary (Non-functional) Requirements 53
BLLC-001
1. Introduction
Mitropoulos, Inc. is entering the highly completive digital
camera market. Although this
market is saturated with cheap products, Mitropoulos Inc. has
located a third-world country
that has not been tainted with labor laws, human rights and

social programs. With this
advantage Mitropoulos, Inc. can corner the market of low -end
digital cameras. To help
accomplish this goal, Mitropoulos, Inc. needs photo album
editing software to accompany the
cameras.
Mitropoulos, Inc. has contracted with Brown LLC to create
photo album editing software.
Brown LLC specializes in quality software with small feature
sets. They also have an
excellent track record for producing software on schedule,
which is important to Mitropoulos,
Inc.
This document is the Software Requirement Specification (SRS)
for the photo album editing
software. It will outline all of the agreed upon features of the
software.
1.1 Purpose
The purpose of the SRS is to provide a clear, documented model
of the requirements for the
system. This will be used by Brown LLC to construct the
software and provide it by summer
2006.
The software will implement many Use Cases, which are shown
in Section 3. The Use Case
inventory is as follows:
1. Create Album
2. Delete Album
3. Select Album
4. Create Sub-album
5. Delete Content

6. Import Photo
7. Export Photo
8. Move Album Up
9. Move Album Down
10. Move Content Up
11. Move Content Down
12. Move Down Level
13. Move Up Level
14. Select Content
15. Copy Photo
16. Cut Photo
17. Paste Photo
18. Edit Photo
19. Email Photo
20. Run Continuous Slideshow
21. Run Slideshow Once
22. Stop slideshow
23. Search for Photo
BLLC-001
1.2 Scope
The software to be created is photo album editing software. It
will perform basic functions
that will allow the actor to create multiple photo albums.
Within a photo album they will be
able to insert photos. The software also supports sub-albums,
which can be used like

chapters within the software.
1.3 Definitions, Acronyms and Abbreviations (Glossary)
There are a variety of terms used in this SRS relating to the
software being created. Most of
the terms are self-explanatory and are common to physical
photo albums. However, for
completeness, all terms related to the software are provided.
! Album – an album is a selection of content at the highest level
! Content – content can be a photo or a sub-album
! Photo – a digital picture in JPEG or GIF format
! Slideshow – the automatic presentation of photos
! Sub-album – a collection of content within a album or sub-
album
1.4 Risk Analysis
There are a variety of risks to developing this software. As
mentioned before, it is important
that the software be finished by the summer of 2006. This is
the key window to allow
Mitropoulos, Inc. to prepare for holiday shopping season. To
address this risk, Brown LLC
is attempting to finish the software by mid-summer. This will
provide extra time if obstacles
slow down the project.
A secondary risk to this software project is changing
requirements. Mitropoulos, Inc. could
post clarifications to the requirements that might adversely
affect this project. Brown LLC
will attempt to create a very flexible software design that will
allow changes to the software
quickly and easily.
1.5 Overview

The following SRS is organized into two major sections:
Overall Description and Specific
Requirements. The Overall Description describes the
requirements at a high level, while the
Specific Requirements describe all of the relevant requirements
of the system.
2. Overall Description
The photo editing software allows the actor to create virtual
photo albums. The primary
features are to allow the actor to create logical photo albums in
the system. Each photo
album can contain content, which consists of actual photos or
sub-albums. A sub-album is a
logical collection of content. Sub-albums can also contain
content, which is photos or other
sub-albums.
A second set of features allows the actor to change the photo
albums. Order of content and
albums is important in the photo album editing software. A set
of features allows the actor to
move albums or content up or down. Additional features allow
the actor to copy, cut and
paste photos. There is also a search feature that will allow the
actor to search for photos
bases on key words. Actors can change many characteristics of
the pictures like contrast and
brightness.
BLLC-001

The final set of features allows the actor to create slideshows.
A slideshow is an automated
process of showing the photos. The actor can select background
music that can be played.
There are two types of slideshows. One type shows the pictures
only once. A second type
will continuously show the pictures until the actor terminates
the feature.
2.1 Use-Case Model Survey
There are 23 Use Cases that make up the requirements for this
system. The detailed Use
Cases are in section 3.
Use Case Description
1. Create Album Creates an album in the photo album library.
2. Delete Album Deletes an album in the photo album library.
3. Select Album Selects an album in the photo album library.
The system
will display information about the album, like description
and date.
4. Create Sub-album Creates a sub-album in an album or other
sub-album.
5. Delete Content Deletes a sub-album or photo from the
system.
6. Import Photo Puts a photo into an album, possible with a
sub-album in
an album.
7. Export Photo Makes a copy of a selected photo and exports
it from the

system. This photo is saved as a JPG or GIF file.
8. Move Album Up Moves an album up one position in the list
of albums.
9. Move Album Down Moves an album down one position in
the list of albums.
10. Move Content Up Moves a sub-album or photo up one
position in the list of
content.
11. Move Content Down Moves a sub-album or photo down one
position in the list
of content.
12. Move Down Level Displays the content within a sub-album.
13. Move Up Level Displays the content one level above the
current sub-
album.
14. Select Content Select a photo or sub-album. Both
selections show the
description and date of the content. Selecting photo will
also show the photo.
15. Copy Photo Copies a selected photo to the clipboard.
16. Cut Photo Cuts a selected photo to the clipboard.
17. Paste Photo Pastes a selected photo from the clipboard.
18. Edit Photo Permits changes of the photo characteristics.
19. Email Photo Emails a photo as an attachment
20. Run Continuous Slideshow Shows all of the pictures of an
album in a slideshow
format. The actor can set the time interval between
pictures. The actor can also select a music file to be
played. This slideshow will play continuously.

21. Run Slideshow Once Shows all of the pictures of an album
in a slideshow
format. The actor can set the time interval between
pictures. The actor can also select a music file to be
played. This slideshow will play once.
22. Stop Slideshow Terminates the show of a slideshow.
BLLC-001
Use Case Description
23. Search for Photo Retrieves a list of photo whose
descriptions match words
entered by the actor.
The screenshots in the Use Cases are there to present a visual
representation of the screen
will look like. Red circles are used to direct the audience’s
attentions to different areas of the
screen. Do not assume that the actual content on the screens
corresponds to the path of the
Use Case.
2.2 System Evolution
If Mitropoulos, Inc. is successful in carving out a spot in the
digital camera market;

enhancements to this software will be needed. Such
enhancements could include having the
software interact directly with the digital camera and moving
photos from the software to the
digital camera. This would only take place if Mitropoulos Inc.
decides to compete in the
high-end digital camera market.
If Mitropoulos, Inc. sees moderate success in the low -end
camera market; they will maximize
profits by cuttings costs. No new features will be added to the
software. Only bug fixes will
be performed.
3. Specific Requirements
The Specific Requirements section will provide the Use Case
Reports specifying the 23 Use
Cases that make up this system.
BLLC-001
3.1 Use-Case Reports
3.1.1. Use Case Name: Create Album
Summary: The Create Album feature allows the actor of the
software to create a new album in the

album library.
Triggers: The actor selects the Create Album menu item.
Basic course of events (Scenario):
Actor System Screen
1. The actor selects
Create Album.
2. The system requests
the name, description,
and date of the new
album.
3. The actor
completes fields and
selects OK.
BLLC-001
Actor System Screen

4. The Systems adds
that album to the
album area.
Alternative paths:
A. The album created is canceled.
Actor System Screen
3. Actor selects
Cancel.
4. The system removes
the create album
screen.
B. Duplicate album name.
Actor System Screen
4. The system
determines that the
new album name
already exists and
produces error
message.
5. The actor
acknowledges the
error message.

Post conditions:
1. A new album has been created in the album area.
2. The new album is selected.
BLLC-001
3.1.2. Use Case Name: Delete Album
Summary: The Delete Album feature will remove an album
from the system.
Preconditions: An album is selected.
The album is empty.
Triggers: Actor selects the Delete Album menu item.
Actor System Screen
1. The actor initiates
deletion of an album.
2. The system

confirms that delete of
selected album.
3. The actor confirms.
4. The system
removes the selected
album.
BLLC-001
Alternative path:
Actor does not confirm deletion.
Actor System Screen
3. The actor rejects the
album deletion.
4. System removes the
confirmation alert.

Post Conditions: After successful deletion, no album is
selected.
BLLC-001
3.1.3. Use Case Name: Select Album
Summary: This actor changes the selected album
Preconditions: At least one album exists.
Triggers: Actor selects an unselected album.
Actor System Screen
1. The actor select an
unselected album.
2. The system
highlights the selected
album.
3. The system

displays any sub-
albums names and
files names in selected
album.
BLLC-001
Actor System Screen
4. The system
displays album date,
description and the
word album in right
panel.
Post Conditions:
1. An album is selected.
2. Any other content or album information in right-hand panel is
removed.
BLLC-001

3.1.4. Use Case Name: Create Sub-album
Summary: This actor creates a sub-album
Preconditions: At least one album or sub-album is selected
The content area contains no search results.
Triggers: Actor selects the Create Subalbum menu item.
Actor System Screen
Create Subalbum.
2. The system
prompts for sub-
album name, date and
description.
3. The actor enters
information and
confirms.

BLLC-001
Actor System Screen
4. The system creates
sub-album within the
album or sub-album
that is displayed in the
content area.
5. The system
displays content area.
Alternative path:
Actor rejects to create sub-album.
Actor System Screen
3. The actor cancels
creation.
4. System removes
the dialog.

BLLC-001
Post Conditions: On success:
1. A new sub-album exits.
2. The new sub-album is selected.
BLLC-001
3.1.5. Use Case Name: Delete Content
Summary: A selected items in the content area is deleted.
Preconditions: Something in the content area is selected.
Triggers: This actor selects to delete something in the content
area.

Actor System Screen
1. The Actor initiates
deletion of an item in
the content area.
2. The system
confirms that deletion
should take place.
3 The actor confirms
the deletion.
BLLC-001
Actor System Screen
4. The system deletes
the selected content
and redisplays the
content area.

Alternative path:
Actor rejects deletion
Actor System Screen
3. The actor rejects
deletion.
4. The system
removes the
confirmation dialog.
1. Content is deleted.
2. No content is selected.
BLLC-001
3.1.6. Use Case Name: Import Photo
Summary: A photo in gif or jpeg format is put into the photo
album system.

Preconditions: Content area does not contain search results.
Triggers: Actor initiates to import a photo.
Actor System Screen
Insert Photo.
2. The system
prompts for photo
information.
3. The actor enters
photo name, date and
description, then clicks
Select File.
BLLC-001
Actor System Screen

4. The system
prompts to select the
photo.
photo and confirms.
6. The system
removes screen to
select file and shows
original photo
information screen.
7. The actor confirms
file insertion.
8. The system imports
photo and places it in
content area.
BLLC-001

Actor System Screen
9. The system
redisplays content
area putting the photo
name in the content
area.
Alternative paths:
A. The actor rejects addition of the photo.
Actor System Screen
addition of the photo.
4. The system
removes the dialog.
B. The actor cancels the selection of a photo.
5. The actor uses
Cancel.
6. The system does
not add photo.
C. The actor rejects creation of the photo after photo file

selected.
7. The actor uses
Cancel.
8. System does not
add photo.
1. A photo is added to the system.
2. The new added photo is selected.
BLLC-001
3.1.7. Use Case Name: Export Photo
Summary: The actor exports of photo from the photo album.
This does not delete the photo; only
export a copy of it.
Preconditions: A photo is selected in the content area.
Triggers: The actor initiates to export a photo.

Actor System Screen
export of a photo.
2.The system prompts
for actor to select
location and file
name.
3. The actor provides
file name and location
and confirms.
4. System creates
copy of photo under
the provided file name
and location.
BLLC-001

Alternative path:
Actor rejects to export photo.
Actor System Screen
3. The actor cancels.
4. The system
removes the dialog.
Post Conditions: On success, A selected photo is exported from
the system.
BLLC-001
3.1.8. Use Case Name: Move Album Up
Summary: The selected album is moved up in the list of
albums.
Preconditions: Two or more albums exist.
One is selected.
The selected item is not at the top of the list.
Triggers: Actor selected the album move up feature.

Actor System Screen
1. The actor selects the
Move Album Up
feature.
2. The system moves
the selected album up
one position.
BLLC-001
Post Conditions: On success, an album is moved higher in the
list.
BLLC-001

3.1.9. Use Case Name: Move Album Down
Summary: The selected album is moved down in the list of
albums.
Preconditions: Two or more albums exist.
An item is selected.
The selected item is not at the bottom of the list.
Triggers: Actor selected the album move down feature.
Actor System Screen
Move Album Down
feature.
2. The system moves
the selected album
down one position.
BLLC-001

Post Conditions: On success, an album is moved lower in the
list.
BLLC-001
3.1.10. Use Case Name: Move Content Up
Summary: Move the selected content up one position.
Preconditions: Two or more contents are listed.
It is not at the top of the list.
The content area cannot contain search results.
Triggers: Actor triggers the content move up feature.
Actor System Screen
Move Up.

2. The system moves
the content selected
up one position.
BLLC-001
Post Conditions: On success, a content item is moved higher in
the list.
BLLC-001
3.1.11. Use Case Name: Move Content Down
Summary: Move the selected content down one position.

Preconditions: Two or more contents are listed.
It is not at the bottom of the list.
The content area cannot contain search results.
Triggers: Actor triggers the content move down feature.
Actor System Screen
Move Down.
2. The system moves
the content selected
down one position.
BLLC-001
Post Conditions: On success, a content item is moved lower in
the list.

BLLC-001
3.1.12. Use Case Name: Move Down Level
Summary: Move down one level in the hierarchy of the sub-
album structure.
Preconditions: A sub-album exists at current content level and
has been selected.
Triggers: The actor triggers the feature to move down one
level.
Actor System Screen
1. The actor double-
clicks on a content
item.
2. The system
displays the content of
the sub-album.

Post Conditions: On success, content area show content in
selected sub-album.
BLLC-001
3.1.13. Use Case Name: Move Up Level
Summary: Move up one level in the hierarchy of the sub-album
structure.
Preconditions: Content area shows content at lower than the
album level.
Triggers: Actor triggers the feature to move up one level.
Actor System Screen
1. The actor triggers
Up a Level in the sub-
album structure.
2. The system
displays the content
one level up in the

sub-album structure.
BLLC-001
1. No content is selected.
2. Content area shows content one level up.
BLLC-001
3.1.14. Use Case Name: Select Content
Summary: The actor selects content to have the content
information shown.
Preconditions: Content exists in content area.
Triggers: Actor selects content.

Actor System Screen
1. Actor selects
content from the
content area.
BLLC-001
Actor System Screen
2. The system
displays content
description and date.
If content is picture,
the system shows the
picture. If content is
sub-album, shows the
work sub-album.
Post Conditions:
1. Any other content information or album information that was

in the right hand panel is removed.
BLLC-001
3.1.15. Use Case Name: Copy Photo
Summary: The selected photo will be copied to a virtual
clipboard.
Preconditions: Content selected is a photo.
Triggers: The actor selects the Copy feature.
Actor System Screen
1. The actor chooses
the Copy feature.
2. The system copies
photo to virtual
clipboard.

Post Conditions: On success, a photo placed in virtual
clipboard
BLLC-001
3.1.16. Use Case Name: Cut Photo
Summary: The selected photo will be cut to a virtual clipboard.
Preconditions: Content selected is a photo.
Triggers: The actor selects the Cut feature.
Actor System Screen
Cut feature.
2. The system cuts
photo to virtual
clipboard.

Post Conditions: On success, a photo placed in virtual
clipboard
BLLC-001
3.1.17. Use Case Name: Paste Photo
Summary: The photo in the virtual clipboard is placed in the
content area.
Preconditions: Virtual clipboard contains an image.
An album is selected.
Triggers: Actor initiates paste feature.
Actor System Screen
the Paste feature.
2. The system places
the content of the
virtual clipboard into
the content area.

BLLC-001
Actor System Screen
3. The system re-
displays the content
area.
4. If the contents of
the virtual clipboard
were a result of a cut,
the system deletes the
original photo that
was placed into the
clipboard.

BLLC-001
3.1.18 Use Case Name: Edit Photo
Summary: The Edit Photo feature allows the actor to change
the brightness, contract, and RGB of a
photo. They can also convert the photo to black and white.
Preconditions: A photo is selected.
Triggers: The actor selects the Edit Photo feature.
Actor System Screen
Edit Photo feature.
2. The system
displays the Edit
Photo screen.
3. The actor can
modify the Brightness
field, Contrast field,
Red field, Green field,
Blue field and/or
Black/White

checkbox.
BLLC-001
Actor System Screen
changes.
5. The system
changes the selected
photo based on the
modifications from
the actor.
6. The system
redisplays the photo.
Alternative path:
Actor rejects changes to photo.
Actor System Screen

4. Actor rejects
changes to photo.
5. The system
removes the dialog.
Post Conditions: On success, the photo is modified.
BLLC-001
3.1.19 Use Case Name: EMail Photo
Summary: The actor can eMail a selected photo as an
attachment.
Preconditions: A photo is selected.
Triggers: The actor initiates the EMail Photo feature.
Actor System Screen
the EMail Photo
feature.

2. The system
displays the EMail
Photo screen.
EMail server, From
address, To address,
and Subject.
4 System eMails the
photo as attachment
using information
from the actor.
BLLC-001
Alternative path:
Actor rejects to email photo.

3.The actor cancels
sending the photo.
4 The system removes
the dialog.
Post Conditions: On success, the photo is Emailed.
BLLC-001
3.1.20. Use Case Name: Run Continuous Slideshow
Summary: This feature will show all of the photos in an album
in a continuous slideshow format.
Triggers: The actor initiates a continuous slideshow.
Actor System Screen
1. The actor initiates a
continuous slideshow.

2. The system
presents the
Slideshow screen.
3. The actor indicates
number of seconds for
the slideshow
intervals.
music file.
BLLC-001
Actor System Screen
5 The system presents
the File Chooser to
select the music file.

music file and
confirms.
7. The system shows
the Slideshow screen.
the slideshow
information.
9. The system
disables all of other
features.
BLLC-001
Actor System Screen
10. The system
makes visible the Stop
Slideshow button.

11. The system
shows the photos of
the selected album
with the decided
number of seconds
between each photo.
When finished, the
slideshow will repeat.
12. If a music file
was selected, the
system plays the
music.
Alternative paths:
A. Actor rejects slideshow settings.
the slideshow
information.
9. The system
removes the dialog.

BLLC-001
B. Actor rejects the music selection.
music selection.
7. The system returns
to the slideshow
dialog.
1. All other features are disabled.
2. Stop slideshow is enabled.
BLLC-001

3.1.21. Use Case Name: Run Slideshow Once
Summary: This feature will show all of the photos in an album
in a slideshow format.
Triggers: The actor initiates a slideshow.
Actor System Screen
slideshow's Run Once.
Steps 2 through 10 are as shown for §3.1.20.
11. Once all of the
photos in the album
have been presented,
the system terminates
the slideshow and
music.
12. The system
enables all other
features.
Alternative paths: The alternate paths are as shown for §3.1.20

BLLC-001
3.1.22. Use Case Name: Stop Slideshow
Summary: This feature will stop a slideshow that is running. It
can be used for continuous
slideshow or a slideshow that runs only once.
Preconditions: A slideshow is running.
Triggers: The actor clicks Stop Slideshow.
Actor System Screen
1. The actor clicks
Stop Slideshow.
2. The system
terminates the
slideshow.
3. The system enables
all other features.

Post Conditions: All features are enabled, except Stop
Slideshow.
BLLC-001
3.1.23. Use Case Name: Search for Photo
Summary: The Search for Photo feature allows the Actor to
enter words. If any of the words are
within the description or name of a photo they will appear in the
content area.
Triggers: The actor initiates Search for Photo feature.
Actor System Screen
the Search for Photo
feature.
2. The system
prompts for search

words.
3. The actor enters
search words and
confirms search.
BLLC-001
Actor System Screen
4. The system begins
with all of the content
in the content
window. It searches
for any photo that has
a description or name
that contains any of
the search words. It
recursively goes
through all sub-
albums in the content
area.
5. The content area is

cleared.
6. The files that
match are then listed
in the content area.
Alternative paths:
A. Actor rejects search.
Actor System Screen
3. The actor cancels
the Search option.
4. The system
removes search
window.
BLLC-001
3.2 Supplementary (Non-functional) Requirements

• The software shall run on the latest versions of the Windows
operating system, including
Windows 7 through 10.
• Any Menu item or button whose functionality is precluded
because the preconditions to the
function are not met must be disabled when the condition is not
met, and re-enabled when
the conditions are again met.
Uber
Uber Ride
Version: 4.2
Date : 10/06/2021
Document ID: UBER-SRS
Uber
For Uber Ride
Version 4.2
Mahamadou Mahi Diallo
UMGC
SWEN645 9040
Table of Contents
1. Introduction 2
1.1 Purpose 2
1.2 Definitions, Acronyms and Abbreviations 2
1.2.1 Definitions 2
1.2.2 Acronyms 2
1.2.3 Abbreviations 2
1.3 Scope 3

1.4 References 4
1.5 Overview 4
2. Overall Description 4
2.1.1 Application Users’ Roles 8
2.1.2 Assumptions and Dependencies 10
2.2 Specific requirements 11
2.2.1 Use-case reports 11
3. Supplementary Requirements 16
4. Supporting Information 16
Appendix 18
Introduction1.1 Purpose
The purpose of this document is give an overview of Uber
application requirements, its use cases and describing various
techniques used in the designing these use cases. In addition,
this document outlines the requirements of the application in the
form of textural use cases.1.2 Definitions, Acronyms and
Abbreviations
1.2.1 Definitions
· Application – this refers to a computer program that is
designed to accomplish a specific task in the computer system.
· Rider – a user who takes rides using Uber app
· Driver – a person who accepts ride requests from users, picks
and takes them to their destinations.
· Feature – an important component of the application that help
users find what they are looking for.
1.2.2 Acronyms
· GPS – Global Positioning System
1.2.3 Abbreviations

· SRS – Software Requirements Specification
· PCs – Personal Computers
· App – application
· PDAs – Personal Digital Assistants1.3 Scope
The purpose of the Uber application is to make it easy for
customers to get to their destinations by providing them with
information on locations, such as those in Texas or even Silicon
Valley, easy ways of requesting for a ride, estimated time of
arrival, driver-partner information such as type of the vehicle,
first name and license plate number. In addition the application
also calculates the fare automatically for customers when they
arrive at their destinations.
There are various features of the applications that will be
discussed and these features include.
· Real-time tracking of driver
· Allowing others to follow ride in real-time.
· Keeping trip history
· In-app call or chat option
· Saves destinations.
· Preferred driver
· Multiple options of payment
· Booking a ride for now or later
· Adding multiple points of drop-off
· Reviewing and rating of drivers
1.4 References
Space Technologies
· Gives a brief overview of the Uber application.
· Describes various features of the Uber app which can be very
useful to aspiring businesses and those operating only for
millennial audiences.Uber Help: HYPERLINK
"https://help.uber.com/riders/article/how-does-uber-
work?nodeId=738d1ff7-5fe0-4383-b34c-4a2480efd71e"
https://help.uber.com/riders/article/how-does-uber-
work?nodeId=738d1ff7-5fe0-4383-b34c-4a2480efd71e
Alley, J. K. (2016). The impact of Uber Technologies on the
New York city transportation industry.

Grabher, G., & van Tuijl, E. (2020). Uber-production: From
global networks to digital platforms. Environment and Planning
A: Economy and Space, 52(5), 1005-1016.
Mäntymäki, M., Baiyere, A., & Islam, A. N. (2019). Digital
platforms and the changing nature of physical work: Insights
from ride-hailing. International Journal of Information
Management, 49, 452-460.
· It gives a brief description of what Uber app is and how it
works to ensure that customers who request for the rides are
able to get to their destinations.1.5 Overview
This subsection illustrates the software requirements
specification of the Uber application, its features and how the
SRS is organized. The requirements specification for this
application is described further in the use cases.
The features of this application are also described, roles and
responsibilities of the users are explained. The use case model
will also be designed to give more information on the processes
that take place in the Uber application.2. Overall Description
Uber is a technology platform whereby the applications on our
smartphones connect riders and driver-partners. Users is the
cities where Uber is operating are able to use Uber rider
application to request for a ride. In most of parts where Uber
operates, users are allowed to pay their fare in cash, but they
must select this option before requesting for a ride. The
information about the rider is also provided in the app.
In addition, the Uber application has the following features;
i. Book a ride for now or later.
This feature in the Uber application enables users to book
the ride. With the book now or later feature, driver-partners can
easily get rides and travel easily from one place to another. The
book later feature enables users to easily book rides for a trip in
future. This feature is very important for users who are about to
leave their homes, office or even going for a doctor’s
appointment and they want to get there in time.
ii. Multiple options of payment
Not every customer is comfortable paying via card or cash

for their ride. Some of the users do not carry cash while a few
of them do not want to share their card details in the
application. Therefore, including multiple options of payments
in the application has made it easy for the riders whereby they
are able to select from various options that are available in the
app.
iii. Real-time tracking of driver
This feature is included in the application to boost the
satisfaction level of the users and make sure they are not
frustrated when they’re in the unknown regarding the driver.
This is achieved with the help of GPS integration. This feature
helps in tracking the location of drivers and which way they are
traveling.
iv. Preferred driver
Regular Uber riders who take rides for their homes and
offices come across several drivers and after sometime they
start having preferences of drivers based on the experience with
them. The application allows these users to have a choice of
their preferred drivers, and this gives Uber an added advantage.
v. Allow others to follow ride in real-time.
Since safety comes first to everyone, it feels safe when
riders are able to share their details of the ride with some else
who is mostly close to them. This feature allows someone else
to keep an eye on the route that is taken by the driver and also
letting persons know if you they have reached at your their
respective destinations safely or not. Comment by Sheldon
Linker: As mentioned before:
• This type of document should be entirely in the 3rd peson.
This feature is also very useful if the rider is new to a
particular city and are not aware of the route that is being used
by the driver. Therefore, sharing these details helps one to get
an idea of whether or not the route taken is right or wrong and
gives a chance for the person you they’re sharing with to give
insights into the route taken by the Uber driver.
vi. In-app call or call option

This feature is very important when the user wants to
connect with driver mostly to ask them for direction and inquire
on their whereabouts. In some other cases, users would want to
chat directly with the support team for help. In addition, this
feature also helps drivers to avoid the trouble of rider’ s address
when they can just call or chat with riders and get the details
and also get directions.
vii. Driver rating and review
The reviews and ratings of the drivers give you one more
information on them, their behavior, and the kind of experience
they offer to the riders. The riders who have had a trip with the
driver in the past share their feedback and this helps one to
know what they expect. The ratings are reviews are excellent
ways of improving the business of Uber.
viii. Add multiple drop-off points.
ix. Saving of destinations
x. Keeping of trip history2.1 Use-Case Model Survey
Users of the application should be able to retrieve
information of their trip at any time and given an option to
share this with their close relatives and friends.
The following figure is the use case diagram for Uber.
Figure 1: Driver & Rider Summary Use Case Diagram
2.1.1 Application Users’ Roles
This specifies and describes the roles, the associated
responsibilities and all the use cases primarily driven by the
users.
i. Driver
Definition
Driver is the role played by the persons specifically
registered by Uber to accept ride requests from customers and
take them to their destinations.
Responsibilities

The following are the responsibilities of a rider.
· Accepting ride request from the customers and promptly
attending to them.
· Viewing the list of all the available passengers.
· Picking up and dropping of passengers.
· Confirming receipt of payment.
Required capabilities.
The rider requires the following skills to effectively
interact with the Uber app.
· Basic skills required in using a smartphone.
· Ability to use Google Maps.
· Good interpersonal skills.
· Able to locate simple functionalities on smartphone such as
GPS and others.
ii. Rider
Definition
A rider is the role played by the customers of the Uber app
who request for rides using the application.
Responsibilities
The following are the responsibilities of a rider.
· Entering their pick-up location.
· Entering their destination.
· Registering and entering their details into the system.
· Choosing the type of ride, they need.
· Requesting for a ride
Required capabilities.
The rider requires the following skills to effectively
interact with the Uber app;
· Basic skills required in using a smartphone.
· Ability to use Google Maps.
· Able to locate simple functionalities on smartphone such as
GPS and others.
2.1.2 Assumptions and Dependencies
External hardware

· Client hardware
· Employee workstations: these are the personal computers used
by the workers to carry their daily tasks.
· User client: refers to all the devices used in communication,
such as PCs, PDAs and smartphones.
· Client hardware
· Local Area Network: this is the internal local area network
that is used for communication among Ubers employees.
· Internet: the global network applied in communication among
users of the app, employees, drivers, and the Uber platform.
Other assumptions
i. It is assumed that all the riders are requesting for the ride
while at the cities where Uber operates.
ii. Another assumption is that the riders will pay the fare
through option they chose before placing a ride.
iii. It is also assumed that drivers are all-over the city so no
customer will miss their ride.
2.2 Specific requirements
This section outlines the requirements for the Uber
application captured in the use cases and any applicable
supplementary specifications.2.2.1 Use-case reports
This subsection describes the functional and non-requirements
of the application.
A. Use Cases
i. Rider requests a ride.
ii. Rider makes payment.
iii. Rider enters details to the system.
iv. Driver accepts customer rider request.
v. Driver confirms payment.
vi. Driver picks and drops passengers.
vii. Driver views passenger list
1. Use Case: Rider Requests a Ride
a) Use Case Requirement
The app shall enable riders to request for their ride when;
· Drivers are available at their location.

· They are in the cities where Uber operates.
b) Business Justification
· The Uber application ensures that all the users who request for
rides can get them within the shortest time possible.
· The driver waits for these requests so they can attend to them.
c) Use Case Paths
· Normal:
· Rider authentication: users are asked to enter their login
details, that is, usernames and passwords before being granted
access into the system. The system grants access to the user
when correct credentials are entered. Comment by Sheldon
Linker: We're half-way there in this area. You've got the user
actions, but this should be divided up into what the rider does,
what the system does, and what the driver does. The transaction
doesn't stop here. As a part of this transaction, the system
needs to notify the driver of the ride.
Remember that there are 3 components in this area: What the
user(s) do, what the system does, and either a picture or a
description of the interface. Your programming and QA team
can't afford to guess what you have in mind. We need still more
detail.
Within the flows, the steps need to be numbered or lettered,
both for QA purposes, but also for exception purposes.
Exceptions pick up at the first deviation number (or letter).
There are almost always exception cases, such as (1) user
cancels partway through the process or (2) no ride available.
Some of these cases have tables, and some don't. It's hard to
tell where one use case starts and one ends. Reformat like this
to make this clear:
• Number and Title
• Description
• Preconditions (if any)
• Primary flow, as a table

• Any alternate flows, as similar tables
• Post-conditions, if any
Remember that each transaction must be complete.
· Rider enters pick up location: a rider is asked to choose their
location where they can be picked up by the driver. The system
displays information about the riders in the nearest area to the
available drivers whose one of them accept the rider’s request.
· Rider enters destination: a rider is also supposed to input the
address of where they are to be dropped, the system confirms
and sends this information to the driver too who also indicates
it in the application.
· Rider chooses ride type: they should also input the type of ride
they need, for example, UberX. The system then sends this
information to the necessary driver who might choose to accept
the ride if they are in position.
· Exceptional
· None ride available in the area.
· Rider changes their route or cancels ride.
2. Use Case: Driver accepts customer rider request
· Use Case Requirement
The app shall enable drivers to accept ride requests from
customers when:
· Riders request for a ride then the system displays this
information to the available drivers who might accept this ride.
· Riders are in the cities where Uber operates and the system
notifies users of this, this users include the drivers and riders.
· Business Justification
· The Uber drivers accepts requests that are close to them so
they can server customers within the shortest time possible.
This is made possible when the system displays this information
to the drivers after a rider has made a request.
· Use Case Paths
· Normal:
· Rider requests ride, system provides these details to the
drivers available and they are able to view the available rides.
· Driver accepts a rider made by the rider around after being

notified by the system.
· Exceptional
· Driver time out
· Insufficient account balance
i. Normal Path: Rider requests ride
· Path requirement
The app shall enable users to request for their ride and also
cancel when need be;
· Successful rider authentication by the system.
· V System validatesd pickup location specified by the rider..
· Externals
· Rider
· Preconditions
· The Uber application displays the available rides on the screen
to enable the rider to select the ride they need.
· The application also displays details of the driver to the
customers who wish to place rides.
· Interactions
i. The rider sends a request to the application for the ride they
need and the available divers might accept these rides.
ii. The application updates the system with information and
sends them to the available drivers and also riders are provided
with more information the driver.
iii. The driver acknowledges and updates having accepted the
ride, the system notifies the rider of the same.
· Basic course of events
Actor: Rider
System
Screen
i. Authenticates with the application
i. Authenticates the rider
ii. Enter pick up location

ii. Displays available locations
iii. Choose ride type
iii. Displays available ride types
iv. Submit ride request
iv. Accepts rider requests
Actor: Rider
System
Screen
iv. Authenticates with the application
v. Authenticates the rider
Displays more information of the rider
vi. Enter pick up location
v. Gives the rider information on available pickup locations
Displays available locations
vi. Choose ride type
vii. Displays available ride types
· Post-conditions
· The Uber application keeps information about the ride, riders
and drivers have access to this information.
ii. Normal Path: Rider chooses ride type.
· Path requirement
The app shall enable riders to choose the type of ride they
need.
· Successful rider authentication by the system.
· Externals
· Rider
· Preconditions
· The Uber application displays the available rides on the screen
to enable the rider to select the ride they need and drivers are

able to view the available rides.
· Interactions
· The rider sends a request to the application for the ride they
need, which notifies drivers.
· The application updates the system with information and sends
them to the available drivers.
Actor: Driver
System
Screen
i. Views the list of available passengers.
i. Displays the list of available passengers
ii. Accepts the ride request from the rider
iii. Verifies the request of the driver to proceed to pick-up the
rider.
ii. Proceeds to the pick-up location
iii. Notifies drivers when they reach the pick-up location.
Actor: Driver
System
Screen
iv. Views the list of available passengers.
iv. Displays the list of available passengers

v. Accepts the ride request from the rider
vi. Verifies the request of the driver to proceed to pick-up the
rider.
v. Proceeds to the pick-up location
vi. Notifies drivers when they reach the pick-up location.
· Post-conditions
· The Uber application keeps information about the ride and i t is
available to the riders and drivers.3. Supplementary
Requirements
The application has other more requirements and even more
use cases. Riders are also able to cancel ride requests before
they are picked, and this might be due to several reasons such as
to attend to a personal emergency.
The applications are only supported on smartphones, and
this means that both the driver and rider must have one. The
phone should also support GPS to make it easy for the rider and
driver to locate each other.4. Supporting Information
The following is an image for Uber application and other
related information.
Appendix
The Uber application can be downloaded from the Google Play
store.
Guidelines on how to install and use the application can be
found on their official website, that is, www.uber.com.
8
<Project Name>

Version: <1.0>
Date: <dd/mmm/yy>
<document identifier>
<Project Name>Software Requirements SpecificationFor
<Subsystem or Feature>
Version <1.0>
[Note: The following template is provided for use with the
Rational Unified Process. Text enclosed in square brackets and
displayed in blue italics is included to provide guidance to the
author and should be deleted before publishing the document. A
paragraph entered following this style will automatically be set
to normal.]
[To customize automatic fields (which display a gray
background when selected), select File»Properties and replace
the Title, Subject and Company fields with the appropriate
information for this document. After closing the dialog,
automatic fields may be updated throughout the document by
selecting Edit»Select All (or Ctrl-A) and pressing F9, or simply
click on the field and press F9. This must be done separately
for Headers and Footers. Alt-F9 will toggle between displaying
the field names and the field contents. See Word Help for more
information on working with fields.]
[Note: The Software Requirements Specification (SRS) captures
the complete software requirements for the system, or a portion
of the system. Following is a typical SRS outline for a project
using use-case modeling. This artifact consists of a package
containing use cases of the use-case model and applicable
Supplementary Specifications and other supporting information.
For a template of an SRS not using use-case modeling, which
captures all requirements in a single document, with applicable
sections inserted from the Supplementary Specifications (which
would no longer be needed), see rup_srs.dot.]
Many different arrangements of an SRS are possible. Refer to

[IEEE93] for further elaboration of these explanations, as well
as other options for SRS organization.]
<Company Name>
Revision History
Date
Version
Description
Author
<dd/mmm/yy>
<x.x>
<details>
<name>
Table of Contents
1. Introduction 4
1.1 Purpose 4
1.2 Scope 4
1.3 Definitions, Acronyms and Abbreviations 4

1.4 References 4
1.5 Overview 4
2. Overall Description 4
2.2 Assumptions and Dependencies 4
3. Specific Requirements 5
3.1 Use-Case Reports 5
3.2 Supplementary Requirements 5
4. Supporting Information 5
Software Requirements Specification Introduction
[The introduction of the SRS should provide an overview of the
entire SRS. It should include the purpose, scope, definitions,
acronyms, abbreviations, references and overview of the
SRS.]Purpose
[Specify the purpose of this SRS. The SRS should fully describe
the external behavior of the application or subsystem identified.
It also describes nonfunctional requirements, design constraints
and other factors necessary to provide a complete and
comprehensive description of the requirements for the
software.]Scope
[A brief description of the software application that the SRS
applies to; the feature or other subsystem grouping; what Use
Case model(s) it is associated with, and anything else that is
affected or influenced by this document.]Definitions, Acronyms
and Abbreviations
[This subsection should provide the definitions of all terms,
acronyms, and abbreviations required to interpret properly the
SRS. This information may be provided by reference to the
project Glossary.]References
[This subsection should provide a complete list of all documents
referenced elsewhere in the SRS. Each document should be
identified by title, report number (if applicable), date, and
publishing organization. Specify the sources from which the
references can be obtained. This information may be provided
by reference to an appendix or to another document.]Overview
[This subsection should describe what the rest of the SRS

contains and explain how the SRS is organized.]Overall
Description
[This section of the SRS should describe the general factors that
affect the product and its requirements. This section does not
state specific requirements. Instead, it provides a background
for those requirements, which are defined in detail in section 3,
and makes them easier to understand. Include such items as
product perspective, product functions, user characteristics,
constraints, assumptions and dependencies, and requirements
subsets.]Use-Case Model Survey
[If using use-case modeling, this section contains an overview
of the use-case model or the subset of the use-case model that is
applicable for this subsystem or feature. This includes a list of
names and brief descriptions of all use cases and actors, along
with applicable diagrams and relationships. Refer to the use-
case model survey report, which may be used as an enclosure at
this point.]Assumptions and Dependencies
[This section describes any key technical feasibility, subsystem
or component availability, or other project related assumptions
on which the viability of the software described by this SRS
may be based.]Specific Requirements
[This section of the SRS should contain all the software
requirements to a level of detail sufficient to enable designers
to design a system to satisfy those requirements, and testers to
test that the system satisfies those requirements. When using
use-case modeling, these requirements are captured in the use
cases and the applicable supplementary specifications. If use -
case modeling is not used, the outline for supplementary
specifications may be inserted directly into this section.]Use-
Case Reports
[In use-case modeling, the use cases often define the majority of
the functional requirements of the system, along with some non-
functional requirements. For each use case in the above use-
case model, or subset thereof, refer to or enclose the use-case
report in this section. Make sure that each requirement is
clearly labeled.]

Summary: [Give a brief synopsis of the overall purpose and
flow of this functionality. Often, a an implementation priority
is given.]
Preconditions: [List the preconditions, if any, that must be true
for this scenario to start, either as a single item, or as a bulleted
list.]
Triggers: [List the trigger(s) for this function, typically as a
single item, but possibly as a bulleted list.]
Basic course of events (main scenario):
Actor
System
Screen
[Numbered steps here, starting with the triggered as step 1, one
step per table row. You'll almost always be using multiple
rows.]
[Numbered steps here, typically starting with step 2, one step
per row, but often with the response to the Actor's action on the
same row.]
[A picture, drawing, or description of the screen contents for
this step, assuming that there is a screen for this step, and
assuming that we're on step 1, or that the screen contents have
changed for this step. If the picture is too large to fit here,
move it to an appendix, and just have a reference here.]
Alternate courses of events (alternate scenarios)
Actor
System
Screen
[Same rules as above, but omit any steps here that are the same
as the main scenario.]
[Same rules as above, but omit any steps here that are the same
as the main scenario.]
[Same rules as above, but omit any screens here that are the
same as the main scenario.]
Post-conditions: [List the post-conditions, if any, that will have
occurred to permanent state, or to session state, either as a
single item, or as a bulleted list.]

Supplementary Requirements
[Supplementary Specifications capture requirements that are not
included in the use cases. The specific requirements from the
Supplementary Specifications which are applicable to this
subsystem or feature should be included here, refined to the
necessary level of detail to describe this subsystem or feature.
These may be captured directly in this document or refer to
separate Supplementary Specifications, which may be used as
an enclosure at this point. Make sure that each requirement is
clearly labeled.]Supporting Information
[The supporting information makes the SRS easier to use. It
includes: a) Table of contents, b) Index, c) Appendices. These
may include use-case storyboards or user-interface prototypes.
When appendices are included, the SRS should explicitly state
whether or not the appendices are to be considered part of the
requirements.]
Confidential
<Company Name>, <year>
Page 5

Brown LLC Photo Software Software Requirements

Recommended

Recommended

More Related Content

Similar to Brown LLC Photo Software Software Requirements

Similar to Brown LLC Photo Software Software Requirements (20)

More from VannaSchrader3

More from VannaSchrader3 (20)

Recently uploaded

Recently uploaded (20)

Brown LLC Photo Software Software Requirements