Advertisement
Guest User

Untitled

a guest
May 3rd, 2016
195
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 48.91 KB | None | 0 0
  1. %Copyright 2014 Jean-Philippe Eisenbarth
  2. %This program is free software: you can
  3. %redistribute it and/or modify it under the terms of the GNU General Public
  4. %License as published by the Free Software Foundation, either version 3 of the
  5. %License, or (at your option) any later version.
  6. %This program is distributed in the hope that it will be useful,but WITHOUT ANY
  7. %WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A
  8. %PARTICULAR PURPOSE. See the GNU General Public License for more details.
  9. %You should have received a copy of the GNU General Public License along with
  10. %this program. If not, see <http://www.gnu.org/licenses/>.
  11.  
  12. %Based on the code of Yiannis Lazarides
  13. %http://tex.stackexchange.com/questions/42602/software-requirements-specification-with-latex
  14. %http://tex.stackexchange.com/users/963/yiannis-lazarides
  15. %Also based on the template of Karl E. Wiegers
  16. %http://www.se.rit.edu/~emad/teaching/slides/srs_template_sep14.pdf
  17. %http://karlwiegers.com
  18. %
  19. %Further additions of this sofware have been made by Ryan Zarmbinski
  20. \documentclass{scrreprt}
  21. \usepackage{listings}
  22. \usepackage{ragged2e}
  23. \usepackage{wrapfig}
  24. \usepackage{underscore}
  25. \usepackage{array}
  26. \usepackage{indentfirst}
  27. \usepackage{multirow}
  28. \usepackage{graphicx}
  29. \usepackage{enumitem}
  30. \usepackage{caption}
  31. \usepackage{float}
  32. \floatstyle{boxed}
  33. \restylefloat{figure}
  34. \setlist{nolistsep}
  35. \renewcommand*\rmdefault{ptm}
  36. \DeclareCaptionLabelFormat{blank}{}
  37. \graphicspath{{part1images/}{part1images/sequenceDiagrams/}{part1images/stateDiagrams/}{part1images/screenshots/}}
  38. \usepackage[bookmarks=true]{hyperref}
  39. \renewcommand{\contentsname}{Table of Contents}
  40. \hypersetup{
  41. %bookmarks=false, % show bookmarks bar?
  42. pdftitle={Software Requirement Specification}, % title
  43. pdfauthor={Ryan zarmbinski}, % author
  44. pdfsubject={Rowdy Radio Application}, % subject of the document
  45. pdfkeywords={Software, Rowdy, Radio, App, Application, UTSA, Android, Stream}, % list of keywords
  46. colorlinks=true, % false: boxed links; true: colored links
  47. linkcolor=black, % color of internal links
  48. citecolor=black, % color of links to bibliography
  49. filecolor=black, % color of file links
  50. urlcolor=purple, % color of external links
  51. linktoc=page % only page is linked
  52. }%
  53. \date{}
  54. \author{}
  55. \title{%
  56. \flushright
  57. \rule{\textwidth}{5pt}\vskip0.5cm
  58. \begin{bfseries}
  59. \Huge{SOFTWARE REQUIREMENTS\\ SPECIFICATION}\\
  60. \vspace{1em} %vertical space?
  61. for\\
  62. \vspace{1em}
  63. Rowdy Radio Application\\
  64. \vspace{1em}
  65. Prepared by: {\LARGE Evanilson Braulio,\\
  66. Lymari Montijo,\\
  67. Francisco Platas,\\
  68. Zachary Rodriguez,\\
  69. Ryan Zarmbinski}\\
  70. \vspace{1em}
  71. May 4, 2016
  72. \end{bfseries}
  73. \vskip0.5cm\rule{\textwidth}{5pt}
  74. }
  75. \usepackage{hyperref}
  76. \begin{document}
  77.  
  78. \renewcommand*\listfigurename{Table of figures}
  79. \maketitle
  80. \tableofcontents
  81. \begingroup
  82. \let\clearpage\relax
  83. \endgroup
  84.  
  85. \listoffigures
  86. \listoftables
  87.  
  88. \chapter{Introduction}
  89.  
  90. \section{Purpose}
  91. The purpose of this document is to enumerate all components and functionality of the Rowdy Radio Streaming Application. It will detail the features available for the system and the user interface, and will provide explanations of the usage and constraints of the app.
  92. \par
  93. The intended audience of this document consists of the stakeholders and developers of the system.
  94.  
  95. \section{Software Summary}
  96. The Rowdy Radio Application will be an Android based app that will support UTSA’s Rowdy Radio online services. The main purpose of this software is to allow users to have a seamless mobile experience of the Rowdy radio stream in their Android mobile devices. The target audience for this software is primarily for the UTSA student body, faculty and personnel, but the app is open to anyone that wants to listen. The only requirement is having an account, which is free of charge.
  97.  
  98. The application will be a live Internet-based radio client for the Rowdy Radio stream. In order for the user to access the Radio Stream, he must have an account with UTSA’s Radio services. If the user has an account, he can log in from the app and be granted access to the stream. In the case of first time users, the app allows the user to create an account. Once logged in, the app will take the user to the main screen with the stream, where it will play automatically. The current song information, such as the album artwork, title and artist will be displayed in the main screen. Also the user will have the option of rating the current song using a five star rating system. The app will also feature a news feed which will be part of the main screen where the user can read UTSA and Rowdy Radio’s latest news. Another function of the app will be an alarm feature where the user can create as many alarms as his device will allow, in which the stream will play when the alarm goes off. The application will also gather some user data such as GPS location, song rating information and session log in and log out times to provide the radio services with useful analytics.
  99.  
  100. \clearpage
  101.  
  102. \section{Document Conventions, Acronyms and Abbreviations}
  103. All class, state and sequence diagrams use conventions according to UML. This document also uses the following conventions:
  104. \begin{itemize}
  105. \item \underline{Rowdy Radio Application:} the server-side System, the client-side Application and all interactions thereof.
  106. \item \underline{System:} all architecture that is owned and maintained by developers, owners and Stakeholders in charge of maintenance.
  107. \item \underline{Stakeholder:} any individual that has potential access to the system.
  108. \item \underline{Newsfeed:} a single, regularly updated table that contains a brief description of current events and links to the full articles.
  109. \item \underline{Server:} all application servers and databases that are within the System's scope.
  110. \item \underline{RSS Feed:} \emph{``Rich Site Summary''}, a single news-feed that contains brief descriptions of news articles and a method of reading the full articles online.
  111. \item \underline{Application/App:} the client-side Android application.
  112. \end{itemize}
  113.  
  114. \section{Overview}
  115. Section 2 of the SRS Document will enumerate all requirements for the Rowdy Radio Application. The appendix of this document contains the minutes for the meeting held with the stakeholder.
  116.  
  117. \chapter{Specific Requirements}
  118.  
  119. \section{Functional requirements}
  120. \subsection{System Architecture}
  121. The chosen system architecture for the Rowdy Radio Application will be a combination of the Model-View-Controller (MVC) for the Android Application logic, look and control of operations and a client-server architecture that will communicate with the Rowdy Radio Server to request the live stream, request the latest news feed updates and for the server to collect the user data that it needs.
  122.  
  123. % Make a diagram depicting the system architecture. ?
  124.  
  125.  
  126. \subsection{Use Case Diagram}
  127. \begin{figure}[H]
  128. \centering
  129. \includegraphics[width=\textwidth]{UseCaseDiagramRowdy}
  130. \caption[Use Case Diagram]{Full Diagram of the Use Cases for the Rowdy Radio Application}
  131. \end{figure}
  132. For the Rowdy Radio Application Use Case Diagram, there are a total of 14 use cases and three main actors: The user, the server and the system administrator. The user and server will be in constant communication with each other, the user interacting with the app’s main features and the server will feed the requested data such as the Radio Stream, song info and account validation for logging in or creating an account. A brief description of each use case follows.
  133. \pagebreak
  134. \subsection{Use Case Descriptions}
  135.  
  136. \begin{center}
  137. \begin{table}[!ht]
  138. \centering
  139. \begin{tabular}{|p{11 cm}|}
  140. \hline
  141. \textbf{Use Case: Log In}\\ \hline
  142. ID: UC1\\ \hline
  143. Preconditions: \\
  144. 1. User must have an account with Rowdy radio services \\ \hline
  145. Flow of Events: \\
  146. 1. The user will open the app.\\
  147. 2. The user will enter the username and password.\\
  148. 3. The user will hit the log in button
  149. 4. The server will validate credentials \\ \hline
  150. Postconditions: \\
  151. 1. The user will be logged in and in the main view\\
  152. \hline
  153. \end{tabular}
  154. \caption{Log In Use Case }
  155. \label{tab:testtab1}
  156. \end{table}
  157.  
  158. \begin{table}[!ht]
  159. \centering
  160. \begin{tabular}{|p{11 cm}|}
  161. \hline
  162. \textbf{Use Case: Log Out}\\ \hline
  163. ID: UC2\\ \hline
  164. Preconditions:\\
  165. 1. User must be logged in \\ \hline
  166. Flow of Events: \\
  167. 1. The user will click on the logout button\\
  168. 2. The app will take the user back to the log in screen\\ \hline
  169. Postconditions: \\
  170. 1. The user will be logged out of the app.\\
  171. \hline
  172. \end{tabular}
  173. \caption{Log Out Use Case }
  174. \label{tab:testtab1}
  175. \end{table}
  176.  
  177.  
  178. \begin{table}[!ht]
  179. \centering
  180. \begin{tabular}{|p{11 cm}|}
  181. \hline
  182. \textbf{Use Case: Create Account}\\ \hline
  183. ID: UC3\\ \hline
  184. Actors: User, Server \\ \hline
  185. Preconditions: \\
  186. 1. The user does not have an account \\ \hline
  187. Flow of Events: \\
  188. 1. The user will open the app and will be greeted by the log in screen.\\
  189. 2. User will fill out the Create Account form creating a username and password.\\
  190. 3. Server will validate the new user and create an account within the system.\\ \hline
  191. Postconditions: \\
  192. 1. User will have an account and will be able to log in.\\
  193. \hline
  194. \end{tabular}
  195. \caption{Create Account Use Case }
  196. \label{tab:testtab1}
  197. \end{table}
  198.  
  199. \begin{table}[!ht]
  200. \centering
  201. \begin{tabular}{|p{11 cm}|}
  202. \hline
  203. \textbf{Use Case: Read News feed}\\ \hline
  204. ID: UC4\\ \hline
  205. Actors: User, Server \\ \hline
  206. Preconditions: \\
  207. 1. User is logged into the app and has an Internet connection \\ \hline
  208. Flow of Events: \\
  209. 1. The user will select a news feed headline from the main screen where all the news headlines will be located. \\
  210. 2. App will display the news article in app or redirect to social media. \\
  211. 3. User can refresh the feed by scrolling down with the finger as is common in most apps.\\
  212. 4. Server will receive the latest status and send the newsfeed links that the user doesn't have. \\ \hline
  213. Post-conditions: \\
  214. 1. User will have read the latest headlines.\\
  215. \hline
  216. \end{tabular}
  217. \caption{Read News Feed Use Case }
  218. \label{tab:testtab1}
  219. \end{table}
  220.  
  221.  
  222. \begin{table}[!ht]
  223. \centering
  224. \begin{tabular}{|p{11 cm}|}
  225. \hline
  226. \textbf{Use Case: Update News Feed}\\ \hline
  227. ID: UC5\\ \hline
  228. Actors: System Administrator, Server \\ \hline
  229. Preconditions: N/A \\ \hline
  230. Flow of Events: \\
  231. 1. System Admin will push the latest headlines and news content through the appropriate channels in the UTSA Rowdy Radio Server.
  232. 2. If the user is logged in, the app sends the latest update and the app refreshes. Also the user can refresh by scrolling with the finger. \\ \hline
  233. Postconditions: \\
  234. 1. System Administrator will have updated the app users with the latest news.\\
  235. 2. User will have the latest updates in the app\\
  236. \hline
  237. \end{tabular}
  238. \caption{Update Newsfeed Use Case }
  239. \label{tab:testtab1}
  240. \end{table}
  241.  
  242. \begin{table}[!ht]
  243. \centering
  244. \begin{tabular}{|p{11 cm}|}
  245. \hline
  246. \textbf{Use Case: Rate Song}\\ \hline
  247. ID: UC6\\ \hline
  248. Actors: User, Server \\ \hline
  249. Preconditions: \\
  250. 1. The User is in the play stream view and the album artwork and rating system is visible. \\ \hline
  251. Flow of Events: \\
  252. 1. The user will rate the current song using a five star rating system. \\
  253. 2. The rating given by the user will be stored temporarily in a file. \\
  254. 3. The server will collect user data that will contain the song rating and time of rating. \\ \hline
  255. Postconditions\\
  256. 1.The song will be rated and when the song plays in a different occasion, the song rating will be displayed. \\
  257. \hline
  258. \end{tabular}
  259. \caption[Rate Song Use Case]{}
  260. \label{tab:testtab1}
  261. \end{table}
  262.  
  263. \begin{table}[!ht]
  264. \centering
  265. \begin{tabular}{|p{11 cm}|}
  266. \hline
  267. \textbf{Use Case: Display Song Details}\\ \hline
  268. ID: UC7\\ \hline
  269. Actors: User, Server \\ \hline
  270. Pre-Conditions: \\
  271. 1. The stream will be playing\\ \hline
  272. Flow of Events: \\
  273. 1. The user will play the stream \\
  274. 2. App will request the radio feed from server. \\
  275. 3. Server sends radio feed along with song information \\ \hline
  276. Post-Conditions: \\
  277. 1. Song details will be displayed in the stream \\
  278. \hline
  279. \end{tabular}
  280. \caption{Display Song Details Use Case }
  281. \label{tab:testtab1}
  282. \end{table}
  283.  
  284.  
  285. \begin{table}[!ht]
  286. \centering
  287. \begin{tabular}{|p{11 cm}|}
  288. \hline
  289. \textbf{Use Case: Create Alarm} \\ \hline
  290. ID: UC8\\ \hline
  291. Actors: User \\ \hline
  292. Preconditions: N/A \\ \hline
  293. Flow of Events: \\
  294. 1. User will click on the alarms button. \\
  295. 2. The app will take the user to the alarms view.\\
  296. 3. The user will choose "add new alarm". \\
  297. 4. User will select alarm date, time, repeat and snooze options. \\ \hline
  298. Postconditions: \\
  299. 1. Alarm will be set up. \\
  300. \hline
  301. \end{tabular}
  302. \caption{Create Alarm Use Case }
  303. \label{tab:testtab1}
  304. \end{table}
  305.  
  306. \begin{table}[!ht]
  307. \centering
  308. \begin{tabular}{|p{11 cm}|}
  309. \hline
  310. \textbf{Use Case: Modify Alarm} \\ \hline
  311. ID: UC9\\ \hline
  312. Actors: User \\ \hline
  313. Preconditions: At least an alarm exists \\ \hline
  314. Flow of Events: \\
  315. 1. User will navigate to the alarms view, where each alarm has an option to be modified or deleted. \\
  316. 2. User will select "modify alarm". \\
  317. 3. User will change the desired alarm parameters.\\
  318. 4. User will save changes. \\ \hline
  319. Post-Conditions: \\
  320. 1. Existing alarm will be modified.\\
  321. \hline
  322. \end{tabular}
  323. \caption{Modify Alarm }
  324. \label{tab:testtab1}
  325. \end{table}
  326.  
  327.  
  328. \begin{table}[!ht]
  329. \centering
  330. \begin{tabular}{|p{11 cm}|}
  331. \hline
  332. \textbf{Use Case: Delete Alarm} \\ \hline
  333. ID: UC10\\ \hline
  334. Actors: User \\ \hline
  335. Preconditions:\\
  336. 1. At least an alarm exists \\ \hline
  337. Flow of Events: \\
  338. 1. User will navigate to the alarms view, where each alarm has an option to be modified or deleted. \\
  339. 2. User will select "delete alarm". \\ \hline
  340. Postconditions: \\
  341. 1. Alarm will be deleted and not exist. \\
  342. \hline
  343. \end{tabular}
  344. \caption{Delete Alarm}
  345. \label{tab:testtab1}
  346. \end{table}
  347.  
  348. \begin{table}[!ht]
  349. \centering
  350. \begin{tabular}{|p{11 cm}|}
  351. \hline
  352. Use Case: Play Stream \\ \hline
  353. ID: UC11\\ \hline
  354. Actors: User \\ \hline
  355. Preconditions: \\
  356. 1. The user is logged in and there is an Internet connection \\ \hline
  357. Flow of Events: \\
  358. 1. User will log in to the app.\\
  359. 2. Server validates user and establishes a connection to get the radio feed. \\ \hline
  360. Post-Conditions: \\
  361. 1. Stream is playing in the app. \\
  362. \hline
  363. \end{tabular}
  364. \caption{Play Stream }
  365. \label{tab:testtab1}
  366. \end{table}
  367.  
  368. \begin{table}[!ht]
  369. \centering
  370. \begin{tabular}{|p{11 cm}|}
  371. \hline
  372. \textbf{Use Case: Control Volume} \\ \hline
  373. ID: UC12\\ \hline
  374. Actors: User \\ \hline
  375. Preconditions: The stream is playing \\ \hline
  376. Flow of Events: \\
  377. 1. The user will scroll up or down for the volume or press the mute button. \\
  378. 2. The volume will go up, down or be muted accordingly. \\ \hline
  379. Postconditions: \\
  380. 1. The volume will be modified. \\
  381. \hline
  382. \end{tabular}
  383. \caption{Control Volume }
  384. \label{tab:testtab1}
  385. \end{table}
  386.  
  387. \begin{table}[!ht]
  388. \centering
  389. \begin{tabular}{|p{11 cm}|}
  390. \hline
  391. \textbf{Use Case: Pause Stream} \\ \hline
  392. ID: UC13\\ \hline
  393. Actors: User \\ \hline
  394. Preconditions: The stream is playing. \\ \hline
  395. Flow of Events: \\
  396. 1. The user will press the pause button.\\
  397. 2. The stream will pause. \\
  398. 3. When the user presses play again, the stream will play like in UC 11 - Play Stream. \\ \hline
  399. Postconditions: \\
  400. 1. The stream will stop. \\
  401. \hline
  402. \end{tabular}
  403. \caption{Pause Stream }
  404. \label{tab:testtab1}
  405. \end{table}
  406.  
  407. \begin{table}[!ht]
  408. \centering
  409. \begin{tabular}{|p{11 cm}|}
  410. \hline
  411. \textbf{Use Case: Collect User Data} \\ \hline
  412. ID: UC14\\ \hline
  413. Actors: User, Server \\ \hline
  414. Preconditions: The User has been logged into the app and listening to the stream for a determined amount of time.\\ \hline
  415. Flow of Events: \\
  416. 1. The user will log into the app and play the stream. \\
  417. 2. After some time, the server will collect the information such as song rating, gps location and session connect times. \\ \hline
  418. Post-Conditions: \\
  419. 1. Servers will have user information for their analytics. \\
  420. \hline
  421. \end{tabular}
  422. \caption{Collect User Data }
  423. \label{tab:testtab1}
  424. \end{table}
  425.  
  426. \end{center}
  427.  
  428.  
  429. \clearpage
  430.  
  431. \subsection{Use Case Story Backlog}
  432. \begin{enumerate}
  433. \item Create Account
  434. \begin{enumerate}
  435. \item As a new user, I want to be able to create an account to be able to login to the app.
  436. \begin{enumerate}
  437. \item (10 pts) Create UI form for user to be able to enter in account info
  438. \item (12 pts) Setup backend for account info to be stored
  439. \end{enumerate}
  440. \end{enumerate}
  441. \item Log In
  442. \begin{enumerate}
  443. \item As a user, I want to be able to login to the app using the information I gave when I created my account.
  444. \begin{enumerate}
  445. \item (10 pts) Create UI form for entering username \& password
  446. \item (12 pts) Setup backend to validate information
  447. \item (6 pts) Direct user to stream page upon successful login
  448. \item (3 pts) Display error message upon unsuccessful login attempt
  449. \end{enumerate}
  450. \end{enumerate}
  451. \item Log Out
  452. \begin{enumerate}
  453. \item As a user, I want to logout of the app once I am done using it.
  454. \begin{enumerate}
  455. \item (3 pts) Add logout button/option to UI
  456. \item (4 pts) Stop stream/data once logged off
  457. \item (5 pts) Return user to login page if logout is successful
  458. \end{enumerate}
  459. \end{enumerate}
  460. \item Play Stream
  461. \begin{enumerate}
  462. \item As a user, I want to be able to hear the rowdy radio stream after I log in to the app.
  463. \begin{enumerate}
  464. \item (10 pts) Add Stream/Main page UI to the app
  465. \item (15 pts) Implement streaming functionality/backend
  466. \end{enumerate}
  467. \end{enumerate}
  468. \item Pause Stream
  469. \begin{enumerate}
  470. \item As a user, I want to be able to pause the stream, so that it no longer consumes data or outputs sound.
  471. \begin{enumerate}
  472. \item (3 pts) Add pause button to streaming screen
  473. \item (5 pts) Implement ability to stop gathering stream data upon pause click
  474. \end{enumerate}
  475. \end{enumerate}
  476. \item Display Song Details
  477. \begin{enumerate}
  478. \item As a user, I want to see information about the song that is currently playing on the radio stream
  479. \begin{enumerate}
  480. \item (8 pts) Retrieve track information if a valid song is playing in stream
  481. \item (8 pts) Display song info on main page of playing stream
  482. \end{enumerate}
  483. \end{enumerate}
  484. \item Create Alarm
  485. \begin{enumerate}
  486. \item As a user, I want to be able to create an alarm from within the app after logging in. I should be able to specify a date/time and volume for the created alarm and well as setup a repeating schedule.
  487. \begin{enumerate}
  488. \item (4 pts) Add alarm button on main screen
  489. \item (8 pts) Create alarm add page
  490. \item (10 pts) Create alarm listing page
  491. \item (10 pts) Setup location to store alarm data
  492. \item (12 pts) Implement alarm scheduling
  493. \end{enumerate}
  494. \end{enumerate}
  495.  
  496. \clearpage
  497. \item Modify/Delete Alarm
  498. \begin{enumerate}
  499. \item As a user, I want to be able to modify or delete any alarm(s) that I have previously created.
  500. \begin{enumerate}
  501. \item (9 pts) Create Edit alarm page
  502. \item (6 pts) Add delete button next to each alarm in the alarm list
  503. \item (6 pts) Add delete button to edit alarm page
  504. \end{enumerate}
  505. \end{enumerate}
  506. \item Read News Stream
  507. \begin{enumerate}
  508. \item As a user, I want to keep up with the latest news about rowdy radio. A news stream should be visible once I login to the app.
  509. \begin{enumerate}
  510. \item (8 pts) Add news stream UI to main screen
  511. \item (9 pts) Pull news stream data from source
  512. \item (10 pts) Populate news stream with gathered data
  513. \end{enumerate}
  514. \end{enumerate}
  515. \item Update News Feed
  516. \begin{enumerate}
  517. \item As a user, I want the news feed that I see to be updated periodically with the latest news.
  518. \begin{enumerate}
  519. \item (7 pts) Implement update/refresh news functionality
  520. \item (4 pts) Add manual refresh button to news stream
  521. \end{enumerate}
  522. \end{enumerate}
  523. \item Control Volume
  524. \begin{enumerate}
  525. \item As a user, I want to control the volume of the radio stream from within the app itself.
  526. \begin{enumerate}
  527. \item (5 pts) Add volume bar to main page
  528. \item (5 pts) Tie volume bar to system volume
  529. \end{enumerate}
  530. \end{enumerate}
  531. \item Rate Song
  532. \begin{enumerate}
  533. \item As a user, I want to rate each song that I hear on the radio stream as a way to give feedback to the app.
  534. \begin{enumerate}
  535. \item (4 pts) Add stars/rating UI to main screen under song info
  536. \item (8 pts) Create enable/disable functionality for the rating system depending on if a song is playing
  537. \item (9 pts) Connect rating to currently playing song/user and send data back to server
  538. \item (8 pts) Populate rating if song has been previously rated by user
  539. \end{enumerate}
  540. \end{enumerate}
  541. \item Collect User Data
  542. \begin{enumerate}
  543. \item As an admin, I want to be able to know information about who is using my app
  544. \begin{enumerate}
  545. \item (10 pts) Track user logins
  546. \item (10 pts) Obtain GPS location
  547. \end{enumerate}
  548. \end{enumerate}
  549. \end{enumerate}
  550.  
  551.  
  552. \begin{center}
  553. \subsection{Class Diagram}
  554. \begin{figure}[H]
  555. \centering
  556. \includegraphics[width=\textwidth]{ClassDiagram}
  557. \caption[Class Diagram]{Full Class Diagram of the Rowdy Radio Application}%Ryan Zarmbinski
  558. \end{figure} %evanilson
  559. \justify
  560. The Class Diagram for the system is composed of 8 classes and they all allow the listener to interact with the app. The UserAccount class represents the user of the app, with a unique username and password. It has methods for logging in and out of the account and it also allows for the creation of an account in app. This class is also responsible for storing and facilitating the required user data that the server will collect. The Stream Class is an abstract class and it pertains to the main screen of the app where the stream can be both seen and heard. The methods \texttt{Play()} and \texttt{Pause()} will affect the sound and the \texttt{DisplayInfo()} method will interact with any of the three subclasses, Song, Podcast or Commercial to change the look of the screen. The Song class will also have a method that will store the user rating of the song. The Volume class will have the methods to control the volume up, down or completely mute the sound. The Newsfeed Class will receive information and updates from the rowdy radio server which will feed updates which will be displayed in the top of the screen. The method \texttt{read()} will let the user select a news headline and take the user to the appropriate link or social media site. The Alarm class will store the user designated alarm, which can be zero, one or more, as in most android devices. The class will have methods to setup a new alarm, modify or delete an existing one and to sound off the alarm. The interactions between the Stream class and Song, Podcast and Commercial classes is a generalization. The relationship between the Stream and Volume classes is a composition and the rest of the relationship between classes is an association. %Lymari
  561.  
  562. \end{center}
  563.  
  564. \subsection{State Diagrams}
  565. \begin{figure}[H]
  566. \centering
  567. \includegraphics[width=\textwidth]{StreamStateDiagram}
  568. \caption[Stream State Diagram]{State Diagram for the Live Audio Stream}%Ryan
  569. \end{figure}%Francisco
  570. The Stream State Diagram displays 2 main states those being Playing and Paused. The Stream is in the Playing state when the user logs in or plays the stream. The stream changes to the paused state when the pause button is pressed or when the user logs out.%Francisco
  571.  
  572. \begin{figure}[H]
  573. \centering
  574. \includegraphics[width=\textwidth]{AlarmStateDiagram}
  575. \caption[Alarm State Diagram]{State Diagram for the Alarm Clocks}%Ryan
  576. \end{figure}%Francisco
  577. The Alarm State Diagram displays 3 main states those being Active, Inactive, Going Off and a final state when the alarm is removed. When an alarm is created it is active unless it is modified later on to be inactive. When the time is equal to the specified hour and minute for the alarm then it goes into the going off where the stream is started up, unless there is no network connection and instead a default alarm sound is played at a pre-specified volume. After the alarm goes off it goes into either the active state if it is set to repeat or the inactive state if it is not set to repeat. An alarm can be disabled to put it in an inactive state and reactivated to put it in the active state. If an alarm is removed it goes into an end state and is deleted.%Francisco
  578.  
  579. \subsection{Sequence Diagrams}
  580.  
  581. \begin{figure}[H]
  582. \centering
  583. \includegraphics[width=\textwidth]{login}
  584. \caption[Log-in Sequence Diagram]{Sequence Diagram for the User Log-in}%Ryan
  585. \end{figure}%Lymari
  586. \begin{figure}[H]
  587. \centering
  588. \includegraphics[width=\textwidth]{logout}
  589. \caption[Log-out Sequence Diagram]{Sequence Diagram for the User Log-out}%Ryan
  590. \end{figure}%Lymari
  591. \begin{figure}[H]
  592. \centering
  593. \includegraphics[width=\textwidth]{CreateAccount}
  594. \caption[Create Account Sequence Diagram]{Sequence Diagram for Creating a New Account with Rowdy Radio}%Ryan
  595. \end{figure}%Lymari
  596. \begin{figure}[H]
  597. \centering
  598. \includegraphics[width=\textwidth]{ReadNewsFeed}
  599. \caption[Read News Feed Sequence Diagram]{Sequence Diagram for Reading the News Feed}%Ryan
  600. \end{figure}%Lymari
  601. \begin{figure}[H]
  602. \centering
  603. \includegraphics[width=\textwidth]{RateSong}
  604. \caption[Rate Song Sequence Diagram]{Sequence Diagram for Rating the Current Song}%Ryan
  605. \end{figure}%Lymari
  606. \begin{figure}[H]
  607. \centering
  608. \includegraphics[width=\textwidth]{DisplaySongDetail}
  609. \caption[Display Song Detail Sequence Diagram]{Sequence Diagram for Displaying the Details of the Current Song}%Ryan
  610. \end{figure}%Lymari
  611. \begin{figure}[H]
  612. \centering
  613. \includegraphics[width=\textwidth]{CreateAlarm}
  614. \caption[Create Alarm Sequence Diagram]{Sequence Diagram for Creating a New Alarm Clock}%Ryan
  615. \end{figure}%Lymari
  616.  
  617.  
  618. \begin{figure}[H]
  619. \centering
  620. \includegraphics[width=\textwidth]{ModifyAlarm}
  621. \caption[Modify Alarm Sequence Diagram]{Sequence Diagram for Modifying an Existing Alarm Clock}%Ryan
  622. \end{figure}%Lymari
  623.  
  624. \begin{figure}[H]
  625. \centering
  626. \includegraphics[width=\textwidth]{DeleteAlarm}
  627. \caption[Delete Alarm Sequence Diagram]{Sequence Diagram for deleting an Existing Alarm Clock}%Ryan
  628. \end{figure}%Lymari
  629.  
  630.  
  631. \begin{figure}[H]
  632. \centering
  633. \includegraphics[width=\textwidth]{PlayStream}
  634. \caption[Play Stream Sequence Diagram]{Sequence Diagram for Starting the App's Reception of the Live Stream}%Ryan
  635. \end{figure}%Lymari
  636. \begin{figure}[H]
  637. \centering
  638. \includegraphics[width=\textwidth]{ControlVolume}
  639. \caption[Control Volume Sequence Diagram]{Sequence Diagram for Controlling the Volume of the Stream}%Ryan
  640. \end{figure}%Lymari
  641. \begin{figure}[H]
  642. \centering
  643. \includegraphics[width=\textwidth]{PauseStream}
  644. \caption[Pause Stream Sequence Diagram]{Sequence Diagram for Pausing the App's Reception of the Live Stream}%Ryan
  645. \end{figure}%Lymari
  646. \begin{figure}[H]
  647. \centering
  648. \includegraphics[width=\textwidth]{CollectUserData}
  649. \caption[Collect User Data Sequence Diagram]{Sequence Diagram for Collecting User Data Through the App}%Ryan
  650. \end{figure}%Lymari
  651. \begin{figure}[H]
  652. \centering
  653. \includegraphics[width=\textwidth]{UpdateNewsFeed}
  654. \caption[Update News Feed Sequence Diagram]{Sequence Diagram for Updating the News Feed Items}%Ryan
  655. \end{figure}%Lymari
  656.  
  657. \section{User Interface Requirements}
  658.  
  659. \floatstyle{plain}
  660. \restylefloat{figure}
  661. \begin{figure}[H]
  662. \centering
  663. \includegraphics[width=0.4\textwidth]{LoginView}
  664. \caption[Log-in View]{The Main Screen for Logging Into the App or Creating a New Account}
  665. \label{fig:login}
  666. \end{figure}
  667. When a new or returning User opens up the App and he/she is not still logged in, the main landing screen shall be the Login View. (\textit{see Figure \ref{fig:login}}) This screen provides the User with the ability to log into their account or create a new account. Additionally, this screen contains a button that will allow the user to change a forgotten password. The top half of this View contains the following elements:\par
  668. \vspace{0.5em}
  669. \begin{itemize}
  670. \item Username: a text field for the User’s username
  671. \item Password: a text field for the User’s password
  672. \item Forgot Password: a button that will allow the user to reset a forgotten login credential through the main website
  673. \item Log In: a button that will submit the login form for validation
  674. \end{itemize}
  675. \vspace{0.5em}
  676. The User may enter his/her username and password in the corresponding fields and press enter, or the Forgot Password button may be selected which will forward the user to www.rowdyradio.org in order to reset his/her login credentials. If Forgot Password is selected, the remainder of the interactions will take place on the Rowdy Radio website. If the Log In button is selected, the entered information will be sent to the Server for validation. If the entered credentials match those on record, the App will transition to the Stream View. (\textit{see Figure \ref{fig:stream}})\par
  677. \noindent The bottom half of this View contains the following elements:\par
  678. \vspace{0.5em}
  679. \begin{itemize}
  680. \item Username: a text field for the User’s new username
  681. \item Password: a text field for the User’s new password
  682. \item Re-enter Password: a text field to verify the User’s new password
  683. \item Create Account: a button that will submit the new login credentials for storage
  684. \end{itemize}
  685. \vspace{0.5em}
  686. The User may enter a new username and password along with a verification of the same password and press Create Account. This will verify that the two aforementioned password fields match, then the App will send the new login credentials to the Server for storage. Once a new account is created, the App automatically logs in the User and the App changes to the Stream View.\par
  687. \begin{figure}[H]
  688. \centering
  689. \includegraphics[width=0.4\textwidth]{StreamView}
  690. \caption[Stream View]{The Main Landing Screen After the User Has Logged Into Their Account}
  691. \label{fig:stream}
  692. \end{figure}
  693. The main dashboard for the App shall be the Stream View. (\textit{see Figure \ref{fig:stream}}) This screen will allow the user to view and interact with currently-streaming audio and the most up-to-date news from the Rowdy Radio RSS Feed. Additionally, this screen features two navigation buttons to change the current View. This View contains the following elements:\par
  694. \vspace{0.5em}
  695. \begin{itemize}
  696. \item Alarms (button on top left with the clock icon): a button that will navigate the user to the Display Alarms View
  697. \item Logout (button on top right with the right arrow): a button that will log the user out of the App and navigate to the Log In View
  698. \item Rowdy Radio News: an embedded RSS Feed
  699. \item Stream window: a window that contains the information and album artwork of the song that is currently playing
  700. \item Pause Button: a button that will pause the App’s reception of the Live Stream
  701. \item Rate Song: a row of stars that can be used to rate the song that is currently playing
  702. \item Volume Controls: a menu that allows the user to mute or adjust the volume of the Stream (this is available on any screen of the app)
  703. \end{itemize}
  704. \vspace{0.5em}
  705. The User may scroll and select a news item from the RSS Feed which will forward the User to the full article in their web browser. The User may pause and continue the Live stream by interacting with the Pause button. \par
  706. \begin{figure}[H]
  707. \centering
  708. \includegraphics[width=0.4\textwidth]{VolumeControlsView}
  709. \caption[Volume Controls View]{The Menu That Allows the User to Adjust the Volume of the Live Stream}
  710. \label{fig:volume}
  711. \end{figure}
  712. The User may tap one of the stars visible below the song details in order to rate the song. If the User wishes to adjust the volume, the Volume Controls menu (\textit{see Figure \ref{fig:volume}}) may be opened from this or any other View, or the User may simply use the device’s volume control side buttons. \par
  713. \begin{figure}[H]
  714. \centering
  715. \includegraphics[width=0.4\textwidth]{ViewAlarmsView}
  716. \caption[Display Alarms View]{The Screen That Displays All Saved Alarms}
  717. \label{fig:dispAlarm}
  718. \end{figure}
  719. Additionally, the User may select the Logout button which will log the user out of their account and navigate back to the Log In View (\textit{see Figure \ref{fig:login}}), or the User may select the Alarms button to navigate to the Display Alarms View. (\textit{see Figure \ref{fig:dispAlarm}})\par
  720. After the User has selected the Alarms button, the App shall redirect to the Display Alarms View. This screen shows a list of currently saved alarms along with brief information about each alarm. This View contains the following elements:\par
  721. \vspace{0.5em}
  722. \begin{itemize}
  723. \item Alarms: a table that contains all of the saved alarms. Each row contains the following elements:
  724. \begin{itemize}
  725. \item Delete (button with a trash can icon): a button that will delete the alarm
  726. \item Edit (button with a pencil icon): a button that will edit the alarm
  727. \end{itemize}
  728. \item Add Alarm (button on bottom right with a plus sign): a button that will add a new alarm
  729. \item Exit (button on the top right with an ‘X’): a button that will navigate the User back to the Stream View
  730. \end{itemize}
  731. \vspace{0.5em}
  732. The User may select the Add Alarm button in order to add a new alarm. Doing this will navigate the User to the New Alarm View. (\textit{see Figure \ref{fig:newAlarm}}) If the User wishes to Edit a saved alarm, the Edit button may be selected which will navigate the User to the Edit Alarm View. (\textit{see Figure \ref{fig:editAlarm}}) \par
  733. \begin{figure}[H]
  734. \centering
  735. \includegraphics[width=0.4\textwidth]{DeleteAlarmView}
  736. \caption[Delete Alarm Warning box]{The Warning That Will Pop Up if the User Selects the Delete Button}
  737. \label{fig:delAlarm}
  738. \end{figure}
  739. Additionally, the User may select the Delete button which will cause the App to warn the User about deleting the selected alarm. (\textit{see Figure \ref{fig:delAlarm}}) If the User selects “no,” the App will resume the normal Display Alarms View. Otherwise, the App will delete the selected alarm. Finally, the User may navigate back to the main Stream View (\textit{see Figure \ref{fig:stream}}) by selecting the Exit button.\par
  740.  
  741. \begin{figure}[H]
  742. \centering
  743. \includegraphics[width=0.4\textwidth]{EditAlarmView}
  744. \caption[Edit Alarm View]{The Screen That Allows the User to Edit a Saved Alarm}
  745. \label{fig:editAlarm}
  746. \end{figure}
  747. After the User has selected the Edit button from the Display Alarms View, the App shall display the Edit Alarm View. (\textit{see Figure \ref{fig:editAlarm}}) This screen will allow the user to view and edit the properties of a previously-saved alarm. This View contains the following elements:\par
  748. \vspace{0.5em}
  749. \begin{itemize}
  750. \item Hours, Minutes and Period (spinners at the top of the screen): 3 spinners that will allow the user to view and change the hour, minute and the 12-hour period (AM or PM) for the alarm
  751. \item Repeat: an element of the property table that will allow the user to select which days the alarm will repeat.
  752. \item Type: an element of the property table that will allow the user to select an alarm mode. The available options are “Sound,” “Vibrate”or “Sound and Vibrate.”
  753. \item Alarm Volume: a slider bar that will allow the User to view and edit the desired volume of the Alarm
  754. \item Snooze: a switch that will allow the User to activate or de-activate the snooze function of the alarm
  755. \item Alarm Name: a text field that will allow the User to view and edit the name of the alarm
  756. \item Save (button on top right with a floppy-disk icon): a button that will allow the user to save changes made to the alarm
  757. \item Exit (button on top right with an ‘X’): a button that will allow the user to exit the Edit Alarm View without saving the changes to the Alarm
  758. \end{itemize}
  759. \vspace{0.5em}
  760. The User may view and edit any of the aforementioned fields by either incrementing or decrementing the spinners, sliding the volume bar, typing the alarm name, or by tapping the Repeat and Type elements in order to specify the days for the alarm to repeat or the type of the alarm respectively. The last two interactions will forward the User to another View within the Edit Alarm View either to select the days (\textit{see Figure \ref{fig:days}}) or the type of the alarm. \par
  761. \begin{figure}
  762. \centering
  763. \includegraphics[width=0.4\textwidth]{SelectDaysView}
  764. \caption[Select Days Menu]{The Screen That Allows the User to Select the Days For the Alarm to Go Off}
  765. \label{fig:days}
  766. \end{figure}
  767. Finally, the User may select the Save button to save the changes made for the alarm, or the User may select the Exit button to proceed without saving. Both of these interactions will navigate the User back to the Display Alarms View. (\textit{see Figure \ref{fig:dispAlarm}})\par
  768. \begin{figure}[H]
  769. \centering
  770. \includegraphics[width=0.4\textwidth]{NewAlarmView}
  771. \caption[New Alarm View]{The Screen That Allows the User to Create a New Alarm}
  772. \label{fig:newAlarm}
  773. \end{figure}
  774. After the User has selected the Add button from the Display Alarms View, the App shall navigate the User to the New Alarm View. (\textit{see Figure \ref{fig:newAlarm}}) This screen will be identical to the Edit Alarm View with two exceptions:\par
  775. \vspace{0.5em}
  776. \begin{enumerate}
  777. \item The title displayed at the top of the screen will read ``Add New Alarm'' instead of ``Edit Alarm''
  778. \item The property table and time spinners will be prepopulated with default values instead of those from a previously saved alarm.
  779. \end{enumerate}
  780. \vspace{0.5em}
  781. The User may interact with this View in an identical manner as the Edit Alarm View. If the User selects the Save button, the App will save the newly created alarm on the User’s device. If the User selects the Exit button, the new alarm will be discarded. As in the Edit Alarm View, both of these interactions will navigate the User back to the Display Alarms View. (\textit{see Figure \ref{fig:dispAlarm}})
  782.  
  783. \clearpage
  784. \section{Non-Functional Requirements}
  785.  
  786. \centering
  787. \begin{table}[!ht]
  788. \begin{tabular}{|l|l||p{5 cm}|p{2 cm}|p{2 cm}|}
  789. \hline
  790. NF-ID & Name & Description & Precondition & Postcondition \\ \hline
  791. NF-1 & Performance & XXX & XXX & XXX \\ \hline
  792. NF-2 & Security & The System will require a password with a minimum length of – letters and -- numbers & XXX & XXX \\ \hline
  793. NF-3 & Platform & The system is an Android Application & XX & XX \\ \hline
  794. NF-4 & Memory & The app would use – space on the device, the app will not store any songs device. Only thing stored on the device is the information the App gathers in the case that there is no internet connection. & XX & XX \\ \hline
  795. NF-5 & Interface & The System would need to interact with the Rowdy Radio Server to receive the Stream, as well as the Newsfeed & XX & XX \\ \hline
  796. NF-6 & Documentation & The System will have detailed Installation, and Testing documentation. & XX & XX \\ \hline
  797. NF-7 & Accessibility & The App is able to read in the stream, and news feed at any time. & XX & XX \\ \hline
  798. NF-8 & Operational & Technical /System administrators will handle and operate the system. & xx & xx \\ \hline
  799. NF-9 & Maintainability & XX & XX & XX \\ \hline
  800. NF-10 & Packaging & Any user can follow the installation instructions to install the app on their android device. & XX & XX \\ \hline
  801. NF-11 & Usability & The app has an easy to understand interface. & XX & XX \\ \hline
  802. NF-12 & Scalability & The System should be scalable to support 1000 active concurrent users. & XX & XX \\ \hline
  803. NF-13 & Backup \& Recovery & XX & XX & XX \\
  804. \hline
  805. \end{tabular}
  806. \caption{Non-Functional Requirements}
  807. \label{tab:testtab1}
  808. \end{table}
  809.  
  810.  
  811. \chapter{Appendix}
  812.  
  813. \section{Stakeholder Meeting Minutes}
  814. Meeting was held on Monday March 21, 2016 at 12:00 and lasted 24 minutes.
  815. All group members were present for the Stakeholder meeting.\par
  816. \vspace{0.5em}
  817. \noindent Stakeholder - John Heaps
  818.  
  819.  
  820. \subsection*{Question 1.}
  821. Pertaining to the stream, is the app sort of like (A) Pandora, where there radio stations are created and music plays according to what is available on the Pandora catalog, or is it like (B), Spotify, where the user can search for music and create playlists, listen to new albums or © is it just for listening to the UTSA radio.\par
  822. \vspace{1em}
  823. John - We are just going to assume it will be an app streaming one channel only, which will be the rowdy station.\par
  824. \vspace{1.5em}
  825.  
  826. \subsection*{Question 2.}
  827. For the app news feed, the specifications say that the news feed will have 3 major topics: music related topics, information about the organization and info about local concerts and giveaways. The question is, does the customer want an assorted news feed where all three topics are intertwined, or can the user can browse the three different topics within the news feed screen?\par
  828. \vspace{1em}
  829. John - RSS feed. We can embed it into the app. The choice of the newsfeed implementation can be up to us.\par
  830. \vspace{1.5em}
  831.  
  832. \subsection*{Question 3:}
  833. Will the user have control over which song to hear? Can the user choose a genre, skip a song, create a playlist?\par
  834. \vspace{1em}
  835. John - No skipping. It’s just the stream.\par
  836. \vspace{1.5em}
  837.  
  838. \subsection*{Question 4:}
  839. Will there be multiple stations within the rowdy radio station? Will the user be able to pick a station? If there is only one general channel, (a station), will the user only be able to mute-unmute it? Can the user access past podcasts or past radio programs? Or will it all be live?\par
  840. \vspace{1em}
  841. John - “One channel. Mock backend. Don’t worry about integrating them right now.”\par
  842. \vspace{1.5em}
  843.  
  844. \subsection*{Question 5:}
  845. What components of the functionality of the system are already implemented? Which components need improvement and which functions need to be completely implemented?\par
  846. \vspace{1em}
  847. Securenet systems.\par
  848. \vspace{1.5em}
  849.  
  850. \subsection*{Question 6.}
  851. If a user gives a bad rating for a song, will the radio automatically play another song? Does this action play part in the radio’s algorithm? It's just for analytics. For the backend only. \par
  852. \vspace{1em}
  853. John - The app will not do this because it’s only one stream, but rating the song helps the personnel decide not to play a song that no one likes. For example if a song gets a bad rating throughout the whole week, then the radio station might decide not to play it as much, if at all.\par
  854. \vspace{1em}
  855. You can have the option of rating the song once, and then the app will remove the option of not rating that song again, or you can design the app such that you can always rate the song, just in case you change your mind of the song has grown on you.\par
  856. \vspace{1.5em}
  857.  
  858. \subsection*{Question 7.}
  859. The app requires an internet connection to be used. Just to be clear, this only refers to be able to access and listen to live radio. It also says that the system must store user information, such as GPS location, date and time, device id and send it to the system’s servers. It also states that when there is no connection, the information must be stored somehow. If the user has no connection, he/she won’t be able to listen to the stream. So even when there is no connection, rowdy app wants the previously mentioned information?\par
  860. \vspace{1em}
  861. John - Data to attempt to connect. The time that they opened the app, the device id, GPS? Store it somehow. JSON file, or some other place.\par
  862. \vspace{1.5em}
  863.  
  864. \subsection*{Question 8.}
  865. Alluding to the previous question, storing date and time, GPS location and device id are important. But what about the song they were listening to? What about the user rating of the song? Should that be stored as well? Will having the date and time from the user be enough information to determine what the user was listening to?\par
  866. \vspace{1em}
  867. John - The back end would know, so it's not necessary to the song, but the rating would be the most important data to upload for UTSA radio.\par
  868. \vspace{1.5em}
  869.  
  870. \subsection*{Question 9.}
  871. Will the app allow users to store music files for offline use? What about saving podcasts of the different radio shows? In general, what can be some of the allowed features of the offline mode of the app? \par
  872. \vspace{1em}
  873. John - It would be cool, to implement the past week’s 5 podcasts. Or link the soundcloud with the podcasts.\par
  874. \vspace{1em}
  875. Alarm would be one of them. Maybe store a temporary song, or commercial, in case there user is offline, but the app can still wake them up.\par
  876. \vspace{1.5em}
  877.  
  878. \subsection*{Question 10.}
  879. For the news feed, how will the information be sent. Will someone post links on the news feed? Will the news feed be composed of tweets? Will the user be redirected to a rowdy radio website or blog. Basically, how will the news feed be updated, so that we may know how all the users can receive it at the same time?\par
  880. \vspace{1em}
  881. John - Social media? Low level social media. Admin would push that. The rowdy radio has its own RSS feed. We can take advantage of that.\par
  882.  
  883. \section{Daily Stand up Meetings}
  884. \subsection {Monday, April 25, 5:00 pm}
  885.  
  886. \begin{flushleft}
  887. In Attendance: Ryan Z., Zach R., Lymari M. \& Francisco P.
  888. Topics Discussed:
  889. \begin{itemize}
  890. \item Work distribution for the Software Engineering Project 2 prototype.
  891. \item SRS Document
  892. \item Program Source code.
  893. \item Who is the APO and Scrum Master
  894. \end{itemize}
  895.  
  896. Distribution of Responsibilities: \\
  897. \begin{itemize}
  898. \item Lymari - Putting together the SRS Document, preparing to present as the Scrum Master.
  899. \item Zach - will work on the Android Source Code. Specifically implementing the alarm views.
  900. \item Francisco - Will work on putting the Live Demo Presentation slides and \\ the Non-functional requirements.
  901. \item Ryan - Will work on setting up Android Studio and working on getting the Server up and running.
  902. \end{itemize}
  903. \end{flushleft}
  904.  
  905. \subsection{Friday, April 29, 5:00 pm}
  906. \begin{flushleft}
  907. In Attendance: Ryan Z., Zach R., Lymari M. \& Francisco P.
  908. Topics Discussed:
  909. \begin{itemize}
  910. \item We discussed each other's progress and roadblocks.
  911. \item Things still left to do: Set up the server for the log in.
  912. \item Finish the non-functional requirements list
  913. \item Finish the alarm feature for the prototype.
  914. \item Finish the log in interface.
  915. \item Ryan was working on a service interface for calling the web services for the radio stream.
  916. \end{itemize}
  917. \end{flushleft}
  918.  
  919. \subsection{Sunday, May 1, 5:00 pm}
  920. \begin{flushleft}
  921. In Attendance: Ryan Z., Zach R., Lymari M. \& Francisco P.
  922. Topics Discussed:
  923. \begin{itemize}
  924. \item Deciding the architecture of the software prototype.
  925. \item MVC and Client Server architecture was decided upon
  926. \item Ryan is still working on setting up web services.
  927. \item Zach is working on the alarms view and functionality.
  928. \item Francisco added more things to the presentation slides and finished the non-functional requirements.
  929. \end{itemize}
  930.  
  931. \end{flushleft}
  932.  
  933. \subsection{Monday, May 2, 5:00 pm}
  934. \begin{flushleft}
  935. In Attendance: Ryan Z., Zach R., Lymari M. \& Francisco P.
  936. Topics Discussed:
  937. \begin{itemize}
  938. \item First Item
  939. \end{itemize}
  940.  
  941. \end{flushleft}
  942.  
  943.  
  944.  
  945. \end{document}
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement