Single Switch Facebook Control

electricianpathInternet και Εφαρμογές Web

13 Δεκ 2013 (πριν από 3 χρόνια και 8 μήνες)

91 εμφανίσεις














Single Switch Facebook Control


CSE 442 ∙ Team 8

Software Requirements Specification



Team 8: Single Switch Facebook Control

Software Requirements Specification

2




SRS

11/14/2012




Table of Contents

Introduction

................................
................................
................................
..........................

3

Assumptions, Constraints and Limitations
................................
................................
..............

3

System Structure and Functionality

................................
................................
.......................

5

List of Drawings

................................
................................
................................
..............................
5

Description of Major Modules

................................
................................
................................
........
6

Model

................................
................................
................................
................................
....................

7

View

................................
................................
................................
................................
......................

7

Controller

................................
................................
................................
................................
..............

8

Description of Minor Modules


Controller and Content Pane Abstractions

................................
.....
9

User Interface Template

................................
................................
................................
.......................

9

Facebook Graph API

................................
................................
................................
............................

10

5.1: Startup Controller

................................
................................
................................
........................

11

5.2: Dynamic Content List Controller

................................
................................
................................
..

12

5.3 Profile Controller

................................
................................
................................
...........................

13

5.4 Single Content Controller

................................
................................
................................
..............

14

5.5 Messaging Controller

................................
................................
................................
....................

15

5.6 Settings Controller

................................
................................
................................
........................

16

5.7 Search Controller

................................
................................
................................
..........................

16

6. Flow of Control Diagram

................................
................................
................................
.................

17

Cross Reference Listing

................................
................................
................................
........

18

Integration Thread

................................
................................
................................
..............

19

Software Change Request Form

................................
................................
...........................

20




Team 8: Single Switch Facebook Control

Software Requirements Specification

3




SRS

11/14/2012




Introduction


This document
specifies the software requirements for the Single Switch Facebook Control
applic
ation to be developed based on the System Specification received on 10/22/2012. The
software modules are presented in detail from the top
-
level abstraction of the system, through
the system design plan and down to the functional module level, which is the
lowest level of
detail contained in this document. The user interface is central to the implementation, so
abstractions of the content areas to be implemented are included for each facet of the UI. The
flow of control between the various interfaces is deta
iled as well. The interaction of the
hardware is described, though the focus of this project is on the actual web application. Various
switches exist which can be used to enter a key press into an
application
1
, which

is assumed
.
Lastly, an integration thre
ad is included, detailing the first
stage of implementation, which will
serve as a proof of concept for the rest of the implementation process. A change request form
can be found at the end of the document, to be used to request modifications to the
implem
entation plan

or specific components
.

Assumptions, Constraints and Limitations


Single Switch Facebook Control will be based on Model View Controller (MVC) design. The
backend will consist

of

a
n external

database
, which

will be accessed through
Facebook’s

public
Application Programming I
nterface (API). The frontend is specified throughout the document; it
follows a series of controllers, which can have several views.


Certain aspects of the hardware have been assumed on behalf of the client. One major
assu
mption is that there are functioning single switches available at an affordable cost to the
users.
Along with the switches themselves,

necessary device drivers

are assumed to exist for
the switches using

common hardware interfaces, such as
the
Universal
Se
rial

Bus (USB).
Moreover, the readily available switches are

assumed to be

configurable to fit the needs of the
user. Various types of input methods are supported to fit a variety

of motor limitations
including

shoulder, chin, cheek muscles, or finger.
Fin
ally
, it is assumed that the switch can
supply the web browser with

input using

a single key press

or mouse click, which will serve as
the input to our application
.


There are a few features and functionalities that will not be a part of this application.
Some

features available within the standard Facebook web interface,
such as uploading



1

Example of existing single switch controller:
http:/
/www.enablemart.com/Catalog/Switch
-
Interfaces/Mini
-
SwitchPort

Team 8: Single Switch Facebook Control

Software Requirements Specification

4




SRS

11/14/2012




pictures/photos, creating

events, groups, accessing inbuilt Facebook applications such as
Twitter, Games Feed etc.

are not planned for this release.

It is also assumed th
at the user has
already created

a

Facebook profile using the aid of another able
-
bodied therapist
, family
member, etc
. Additional Facebook accessibility, such as profile settings, will not be configurable
through this application. User login will not be ha
nd
led by any intermediate service, but rather

it will be directly handled by Facebook’s authorization service. Keychain access may be
supported depending on the device used to run the application.


Aside from the aforementioned assumptions, there are also
some constraints.

The functionality
of Single Switch Facebook Controller is completely dependent on the uptime of Facebook
servers. If Facebook is down for maintenance or otherwise, our application
will not function
.
Also, t
his application can have no more

functionality than is provided by Facebook and their
web services

thus far
.
Furthermore, if Facebook shuts down permanently then this application
will be instantly obsoleted.















Team 8: Single Switch Facebook Control

Software Requirements Specification

5




SRS

11/14/2012




System Structure and Functionality



There are two
main types of m
odules described in the following sections. A
major module

encompasses the overall structure of the application. These major modules outline the most
abstract view of the control and data flow. Each major module will have sets of
minor modules

that can be
interchanged to change how the control and data are more specifically laid out.
Minor modules are classified under major modules depending on certain criteria, such as
similar functionality.

List of
Drawings

1)

Top Level Functional Block Diagram

2)

Major Modules

3)

View Detail

4)

Controller Detail

5)

Minor Modules

6)

Module Flow


These drawings
start at the highest level of abstraction. The first shows the system in its
highest
-
level form; that is, a front
-
end interface that communicates with Facebook using the
Facebook deve
loper API, and which is controlled using the browser via a single switch. Drawing
2 identifies the application from a modular perspective, but still at a high level, showing the
interaction of the Model, View, and Controller in the MVC design, along with t
he place of the
browser and single switch. Drawings 3 and 4 show more detailed perspectives of the View and
Controller. Drawing 5 is an extensive look at each controller and the corresponding views, with
abstractions of the functionality for each controlle
r and of the graphical parts of the UI for each
view. Drawing 6 indicates the flow of control between views from the user’s perspective within
the application.


As per the system specification, the general look and feel of the application will be simple,

including large text and easily recognizable icons. The premise of the application use will be
automatic scrolling through options.
There will also be a settings area in which an able
-
bodied
assistant can set parameters of the application such that the us
er may have a tailored
experience.



Team 8: Single Switch Facebook Control

Software Requirements Specification

6




SRS

11/14/2012




Description of Major Modules



At the highest level, a user interacts with the system using a single switch. As stated, the
hardware interface to the switch is not part of this design, as there are readily available op
tions
for switch
-
based input to computers. The browser loads the application as shown in 1.3 above,
and the switch causes events within the
application, which

may also call the Facebook API.


In drawing 2, the system is broken down into modular components.

The system will be
comprised of the three major modules derived from the well
-
defined Model
-
View
-
Controller
pattern
2
. This scheme provides efficient modularity for various pieces of functionality. Each of
the content types will need their own model, view,

and controller to maintain its data and
visuals. This simple state manipulation allows for a high level of clarity in the design.









2

MVC Design Pattern:
http://msdn.microsoft.com/en
-
us/library/ff649643.aspx
; originally
conceived
Trygve Reenskaug for the Smalltalk platform in the late 1970s


Team 8: Single Switch Facebook Control

Software Requirements Specification

7




SRS

11/14/2012




Model

The m
odel is the major module that can be defined as the
purest

representation of data. Thus,
the model can be in
terpreted as the raw storage of information. This application
will not deploy
a database to maintain state
. Instead, the Facebook
Application Programmer Interface (API)

calls will perform the translation of web service methods to database queries.


Faceboo
k API calls are accomplished through the Facebook Graph API
3
. The Graph API is a low
level HTTP
-
based API, which can be used to accomplish any of the tasks specified within this
document. The model represents an abstraction of this API, essentially packagi
ng the user’s
social graph
, which is the Facebook term for the data that runs the entire user experience on
Facebook. See the Description of Minor Modules section under Drawing 5 for more details.

View



The view is a human
-
readable representation of the
model. It can be thought of as a template
to display information that the controller sends to it. The controller will retrieve the
information from the model and subsequently format it into a representation that the view can
read. The end result is an eleg
ant, legible presentation of the database. While the view contains
data manipulation or
decision
-
making
, it is able to highlight certain attributes and suppress
others. Thus, it has the ability to filter certain

sections based on predetermined

indicators t
hat



3

Facebook Graph API:
http://deve
lopers.facebook.com/docs/reference/api/

Team 8: Single Switch Facebook Control

Software Requirements Specification

8




SRS

11/14/2012




the controller sets after analyzing results from the model.


The visuals that get rendered on the display are comprised of HyperText Markup Language
(HTML), JavaScript, and embedded Ruby. The HTML

provides

templates

for

the layout of the
various aesthe
tics that combine to create a single environment.
JavaScript

is attached

to

the
HTML pages by embedding control functions in the Document Object Model (DOM).
JavaScript

will be invoked in any instance where the user needs to interact with the web page, but

does
not want to change to a new page. This is
accomplished

by using an Asynchronous JavaScript
and XML (AJAX) call to the controller. The embedded Ruby is one of the most powerful features
of this framework. The purpose of this Ruby code is to filter cer
tain pieces of

HTML

based on an
indicator that was decided in the controller. There should never be any complexity inside the
view.

Controller


The controller is the major module that links a user’s actions and input with the system. This
major module dec
ides what should be done when a user causes any event to occur in their web
browser. Moreover, any data

that

is inputted by the user arrives at the controller first where a
logical decision is made. There are two major directions that data can go in once i
t enters the
controller. In the first option, the data is consumed and gets sent to the view so that user’s
display can be updated. Alternatively, the data may get sent to the model for processing. In the
latter case the controller knows which piece of sta
te to update depending on which event was
enacted in the web browser.

Team 8: Single Switch Facebook Control

Software Requirements Specification

9




SRS

11/14/2012




The controller is the essentially the brains for each
piece of
fu
nctionality
being

constructed. A
user provides an input to the controller by initiating a click event with their single s
witch. When
different elements on a page are clicked a specific trigger is fired into the controller. For
example, if the user presses their switch over the ‘a’ button on the keyboard, the browser
simply forwards
the event of

the switch
being

pressed when
the ‘a’ was highlighted. Then, the
controller will append the letter to the variable that is keeping track of the current message
being typed.

Description of Minor Modules



Controller and Content Pane Abstractions

This section describes the minor modules
that comprise the overall MVC model. Each of these
minor modules shows a controller and the views that use it. Each controller has functions
that
can be called by any of it
s views as well as local data and API calls to Facebook. Any individual
controlle
r can be plugged in as the current
one

and represent the entire controller, meaning
that the active controller has all of the currently available function calls. The views shown
display the basic layout/look of the pages included within that view. Views
represent the
content that will be displayed within the content pane of the application at any given time.
Each view has buttons in multiple formats, including simple labeled buttons, statuses or
pictures to view, etc. These buttons are continuously scro
lled through within the view until a
selection is made. Each view will give the user the ability to click a back button to go to the
page he/she came from. In the diagrams below, an asterisk next to any view's name indicates
that the keyboard will be ava
ilable on that page.

User Interface Template



Team 8: Single Switch Facebook Control

Software Requirements Specification

10




SRS

11/14/2012




Drawing 5.A shows the basic layout of each page that will be displayed to the application user.
Within the page, there will be at least two major components. The first component is a top
menu bar that will
be accessible from any page in view. This bar is comprised of numerous
buttons that the user can select via the scrolling technique. The buttons will have available
options such as Newsfeed, Notifications, Messaging, Search, My Profile, and Main Menu. T
he
second component is the content pane, which will display all of the available functionality for
any particular view. All functions will be displayed as
buttons or list elements

which will be
scrolled through. The final component, the keyboard, will be
accessible only on views that may
require it.


As can be seen in 5.B, the keyboard will be on the bottom of the screen and also make use of
the scrolling technique for text input. Since the keyboard is not needed for each of the pages,
not displaying it
will allow more space for the content pane to display useful data. The views
that will make use of the keyboard include login, consume picture, consume post, write status,
conversation, and search. Each of the components
is

scrolled through
,

starting wit
h the top
menu bar
, the content pane, and last
ly,

the keyboard if
present
. If the user does not select an
option, it will begin from the top
menu bar

again. Once the user selects the specific component,
scrolling will then begin within the component's fu
nctionality.


Drawing 5.C shows the approximate look of the keyboard element, which will appear on certain
views as mentioned. The implementation for the functionality of the keyboard will be
functionality available to any controller as multiple controller
s rely on it. The letter placement
within the keyboard is based on English letter frequency
4
, with most frequent letters
requiring
the fewest scrolls to select. Rows are scrolled one at a time, and when a row is a selected, items
within the row are selecte
d. Once letters are entered, four autocomplete options and the
“accept” option are added to the scroll pattern before the rows.
Selecting Accept typically
enters the word into the text area with a space after it.

Facebook Graph API

The following sections
make heavy use of the Facebook API. No data is being permanently
stored within this application, so there is no
need for design of databases
. Instead, all data is
accessed through the Graph API. This is fully documented on Facebook’s site
3
. The basic
mech
anism
fetches a JSON object representing the content of interest, from which the
controller requesting the object will retrieve and render the appropriate data. For example, a
user posting to their wall causes the following HTML POST to be sent:



4

Beker, Henry; Piper, Fred (1982). Cipher Systems: The Protection of Communications.

Wiley
-
Interscience. p. 397


Team 8: Single Switch Facebook Control

Software Requirements Specification

11




SRS

11/14/2012




https://gr
aph.facebook.com/username/feed with the text to post. Similar functionality is used
for all of the API calls and is assumed from this point forward.

5.1: Startup Controller

















Controller 5.1 describes the functionality that is encompassed at

the start of the application.
Within this controller, the credentials of the user will be entered and verified for login. Once
the user is successfully logged in to Facebook, the main menu navigation will begin. The
controller will handle a selection in

the main menu by navigating to a different view within the
application.


View 5.1.1 is the login component which will be seen at the beginning of each application use.
This view will have the keyboard visible for entering text into the username and passw
ord fields.
Each of the options will be scrolled through, allowing the user to select a particular text entry
field. Once the user has successfully entered the credentials, clicking Login will change to the
main menu view.


View 5.1.2 shows the main menu

and is what the user sees directly after logging in to the
application. Throughout the application, the user will have the ability to go directly back to this
view via the top menu bar. The main menu will display all of the available options for browsin
g
Facebook including Newsfeed, My Profile, Search, Notifications, Messaging, and Settings.



Team 8: Single Switch Facebook Control

Software Requirements Specification

12




SRS

11/14/2012




5.2: Dynamic Content List Controller





Controller 5.2 has the functionality that is necessary for displaying any data to the user. To
make viewing large amoun
ts of data simpler, we use basic lists that are dynamically changed as
the user wants to see more. Most of the data displayed can be summed up by describing them
as posts. Within the controller, API calls are made to get list data or update current data
and

posts can be selected to
be shown

on a new page. By changing the page forward or backwards,
the user can display the most recent or previous posts.

View 5.2.1 shows the basic layout of how the Newsfeed will look. Each post, regardless of
original

si
ze, will appear in a predetermined sized box and will display the user's picture, name,
and the content of the post. When clicking on a post, the user will be redirected to a new view
that will allow the user to interact with it, such as like or comment.

View 5.2.2 shows the basic layout for how a list of friends will be displ
ayed. This view can
comprise

the user's friends or someone else's friends. There will be a set number of friends
viewable at any given time and clicking o
n any user will result in o
pening
that user's profile.

Team 8: Single Switch Facebook Control

Software Requirements Specification

13




SRS

11/14/2012




View 5.2.3 shows the basic layout for how photos or albums will be displayed to the user.
When attempting to view photos, the user will first have to select and album to view. Once an
album is selected, the view will display p
hotos that can be clicked on for more interaction.

View 5.2.4 shows how notifications will be displayed to the user. Notifications can be viewed
by clicking on the corresponding button on the top menu bar. This view will show multiple
notifications that

can include but are not limited to comments or likes on
the user’s

posts.
Depending on the event displayed, the user will be sent to a
single item

upon clicking the item.

View 5.2.5 shows how posts within a profile are viewed. When in a profile, the use
r has the
ability to see posts on that profile, or the wall. When this option is chosen, the profile data
view will handle posts by displayi
ng them in a list, the same way the Newsfeed is handled
,

and

based on the type of p
ost, the user will be sent to a
single item
view for interaction.

5.3 Profile Controller












Controller 5.3 takes care of all of the actions required within a user's profile. This controller
gives users the ability to post to a wall, poke someone, view or get content on the wal
l,
navigate photos on the user, and navigate a user's friends.

Both views 5.3.1 and 5.3.2 are very similar and represent the basic look of any user’s profile.
View 5.3.1 specifically shows the active user’s profile while 5.3.2 shows any other user’s pro
file.
When in a profile, the most recent wall post of that user will be displayed on the bottom of the
page. Clicking on this post will take you to the wall associated with that profile. This post is
shown as a way to give the user an idea of profile’s
most recent activity. The simple profile
Team 8: Single Switch Facebook Control

Software Requirements Specification

14




SRS

11/14/2012




views will allow for easy navigation while providing all of the functionality required. Users will
be able to post directly on to the wall of the profile being viewed.

5.4 Single Content Controller






Controll
er 5.4 takes care of the actions available for any single content

item
.
This content,
whether it is

pictures or posts, can be accessed via other views, but all actions will be handled
within this controller. Functionality that will be provided includes L
ike, Comment, View
Comments,
P
ost
New
C
omments

or Change Page.

View 5.4.1 shows the basic layout for viewing a picture. Most of the content pane will be taken
up by the picture itself. The most recent comments will also be viewable and scrolled through.
Cli
cking on a comment will allow
t
he user

to view the comment more in depth and
like/comment. Within the view, a user will be able to like or comment the picture directly.

View 5.4.2 shows the basic layout for viewing a post. This can be any item, other than a p
icture,
and displays the most recent comments. This view will give the user the ability to post a
comment or like the post.



Team 8: Single Switch Facebook Control

Software Requirements Specification

15




SRS

11/14/2012




5.5 Messaging Controller





Controller 5.5 takes care of all of the messaging functionality within the application. Users wil
l
be able to send a new message, open the recent messages, enter text into a message, load a
message, send

a

message, and change the page. The messaging controller handles all actions
available to the messaging home and individual conversations.

View 5.5.
1 shows the messaging home. This is where users will be sent directly when they want
send a message. The most recent messages will be shown and scrolled through, allowing a user
to open the conversation associated with that message. The user can choose
to view the next
or previous messages as well as open a search box to start a new conversation.

View 5.5.2 shows what an active conversation will look like. The user will be able to view
previous messages and send a new message. This will not directly be

associated with the
currently available Facebook chat, but will be similar.



Team 8: Single Switch Facebook Control

Software Requirements Specification

16




SRS

11/14/2012




5.6 Settings Controller

5.7 Search Controller







Controller 5.6 has very simple functionality available, including saving and loading cookies. All
of the settings availab
le in our application will be
s
aved as cookies

and the settings can be
swapped or loaded as needed.


View 5.6.1 shows the only view that will be associated with the settings controller. All of the
settings will be expected to be edited by someone wh
o is able bodied and not necessarily
editable by the user alone. Some settings that will be included are scrolling speed, number of
items to display, and keyboard settings.


Controller 5.7 takes care of all of the search functionality. The controller wil
l simply allow for
search
f
ields

to be entered, search results to be displayed
,

and the ability to
n
avigate results
. It
will simply send out the search to Facebook and display the results on the screen.


View 5.7.1 shows how the search function wil
l be displayed to the user. In the top of the
content pane, there will be a text entry box visible that the user can select to type in. Once a
search is entered,
t
he page will

dynamically display the results below. These results can be
selected and the p
age can be changed. Clicking on a result will take the user to a different view
based on the type of result displayed.

Team 8: Single Switch Facebook Control

Software Requirements Specification

17




SRS

11/14/2012





6. Flow of Control Diagram




The diagram above shows the paths in which a user can reach any part of the application.
Every time the

application is started, the user first sees the login screen. Once credentials are
verified, the main menu will be displayed. This main menu will be accessible throughout the
application via the top menu bar. From the menu, a user will able to navigate

to the settings,
search, newsfeed, notifications, profile, and messaging home. Once in a new view, the
navigation path will change. No matter what view the user is in, he/she will always be able to
go back to the previous page. The search view will all
ow users to select a profile to view. From
the newsfeed, the user will be able to view content such as a picture or post, or choose a profile.
Photos and friends will be accessible from any user’s profile
.

Team 8: Single Switch Facebook Control

Software Requirements Specification

18




SRS

11/14/2012




Cross Reference Listing

T
he following is a list of the requirements as specified in the System Specification, along with the
corresponding modules specified in this document, which implement the functionality. Refer to the
diagrams under drawing
s 1 through

5 in this document and t
he corresponding narratives for more
details on the implementation method.
Flow between modules , as specified in the System Specification,
is captured in drawing 6 and the corresponding narrative.


Requirement
reference

Requirement name

Implement
-
ing mod
ule

reference(s)

Implementing module(s) name(s)

1
-
a

Hardware


卩ng汥⁓睩l捨

1⸲

4

䉲B睳敲e䥮pu琯併瑰u琻⁃ n瑲t汬敲

2
-
愬′
-
b

䅵瑯m慴楣am敮e⁳ ro汬楮g

5⹁.

5⹂

䝥湥牡G⁰慧e⁳ 牵捴畲攠睩th⁡湤
睩瑨wuteybo慲a

2
-
b
-
i

M慩a⁍敮e

5⸱⸲

m慩am敮e

噩ew

2
-
b
-

-
1

N敷猠䙥敤⁃on瑥nt

5⸲⸱

n敷獦V敤⁖楥w

2
-
b
-

-
2

N敷猠䙥敤⁆en捴con慬a瑹

5⸲

Dynam楣ion瑥ntL楳i⁃ n瑲o汬敲

2
-
b
-
楩i
-
1

P牯晩f攠Con瑥nt
m楮攠慮T o瑨敲t)

5⸳⸱,‵.3⸲Ⱐ
5⸲⸵

mypro晩f攠噩敷,瑨敲t牯晩f攠噩敷Ⱐ
p牯晩f敤慴愠噩敷

2
-
b
-
楩i
-
2

P牯晩f攠䙵n捴con慬at
y

5⸳Ⱐ5⸲

P牯晩f攠Con瑲o汬敲Ⱐ
Dynam楣ion瑥ntL楳i⁃ n瑲o汬敲

2
-
b
-
楩i
-
3

PhotoV

5⸴Ⱐ5⸴.1

卩ng汥䍯n瑥nt⁃ nt牯汬e爬r
捯n獵V数e捴畲c⁖楥眠

2
-
b
-
楩i
-
4

䙲楥iTV

5⸲Ⱐ5⸲.2

Dynam楣ion瑥ntL楳i⁃ n瑲o汬敲Ⱐ
晲f敮e猠噩敷

2
-
b
-

Ⱐ2
-
b
-
v

No瑩晩捡瑩onV
Ⱐ剥煵敳eV

5⸲Ⱐ5
⸲.4

Dynam楣ion瑥ntL楳i⁃ n瑲o汬敲Ⱐ
no瑩晩捡瑩on猠v楥w

2
-
b
-

-
1

M敳獡杩ng


卥ST M敳獡ee

5⸵Ⱐ5⸵.2

M敳獡杩ng⁃on瑲o汬敲e⁣onv敲獡瑩on
噩敷

2
-
b
-

-
2

M敳獡杩ng


却慲S⁃桡

5⸵Ⱐ5⸵.1

M敳獡杩ng⁃on瑲o汬敲e
m敳e慧楮ghom攠噩ew

2
-
b
-
v楩

卥慲捨

5⸷Ⱐ5⸷.1

卥S
牣r⁃on瑲t汬敲ⰠV敡牣栠e楥i

2
-
b
-
v楩i

L楫攠慮T 䍯mm敮e⁐慧e

5⸴Ⱐ5⸴.1Ⱐ
5⸴⸲

卩ng汥䍯n瑥nt⁃ nt牯汬e爬r
捯n獵V数e捴畲c⁖楥眬wconVum数e獴V
噩敷

2
-
b
-


呥硴⁅n瑲t


C

䝥湥牡G P慧攠L慹ou琠睩瑨wK敹boa牤

3

卥瑴楮g猠慮V⁃on晩fu牡瑩rn

5⸶Ⱐ5⸶.1

卥瑴楮g猠Von瑲ol
汥爬⁳整瑩tg猠噩敷



Team 8: Single Switch Facebook Control

Software Requirements Specification

19




SRS

11/14/2012




Integration Thread




The inte
gration thread exemplifies
the

power of the
M
odel
V
iew
C
ontroller framework. The
design pattern allows for seamless inte
gration of various
functionalities
. Moreover, the file
structure and nami
ng conventions are
self
-
explanatory
. There is very little onboarding cost
when multiple developers must cooperate. This implementation strategy allows for an
extremely simple integration plan that would allow for imme
nse robustness for future additions.










Team 8: Single Switch Facebook Control

Software Requirements Specification

20




SRS

11/14/2012




COMPUTER SCIECE AND ENGINEERING

|
SOFTWARE ENGINEERING

TEAM 8

SINGLE SWITCH FA
CEBOOK CONTROL

Software Change Request Form

Requirement: #______








Date Submitted: ____/____/20___


CHANGE REQUEST INITIATION


Requestor: ________________________________ Phone#: _____
-
_____
-
_____

System: _____
______________________________

Versi
on :_____


ITEM CHANGE

Configuration:











Hardware
/Single Switch
:










User Interface:












Functionality*:













Documentation:











* Th
is refers to a view/controller or menu options.


CHANGE TYPE

Add





Remove




Modify



View





Controller




Menu



Component Ref # (Please refer to the Block Diagrams):

Change Existing: Menu



View





Controller


Other(s):

Please Specify in detail, the function and/or technical informat
ion. User attachment if necessary (Attachment
Enclosed: YES/NO)






CHANGE REASON

Defect:













Performance:












Business Policy:












Legal:













Comment
s:



CHANGE PRIORITY

Regular:












Urgen
t: (Date by:____/_____/20____)









Emergency:












For Office Use Only

Team 8: Single Switch Facebook Control

Software Requirements Specification

21




SRS

11/14/2012






TECHNICAL EVALUATION

Received by:

Date Received:

Assigned to:


COM
PONENT AFFECTED

Module Name:

Model:

View:

Control:

Web Content:

Device Settings:


DOCUMENTATION E
FFECT

Please Specify in detail the documentation(s) affected (Use attachment if necessary):










TIME ESTIMATES

Estimated:

Actual:


Delivery Da
te: (_____/_____/20____)

Total Hours:


APPROVAL

APPROVED




HOLD





DENIED


Comments:


Signatures

Signature 1

Signature 2

Signature 3

Signature 4