Software Design Document
SE 4351 – Requirements Engineering, Section 001
Fall 2013
Name
UTD Email
Keegan Reap
jkr093020@utdallas.edu
Jeffrey Hertzing
jah105020@utdallas.edu
Ken Nakano
kxn099120@utdallas.edu
Rotan Bosson
reb101020@utd.edu
Josh Murphy
jcm052000@utdallas.edu
Michael Bond
mxb105320@utdallas.edu
Branch (Brandt) Jones bwj091020@utdallas.edu
Kylie Kniep
kbk090020@utdallas.edu
Alan Vo
adv090020@utdallas.edu
Chris Kaufman
csk096020@utdallas.edu
Kevin Lin
kxl099220@utdallas.edu
Sami Bouaazzi
smb093020@utdallas.edu
Tej Gidvani
tpg090020@utdallas.edu
Temesxgn Gebrehiwet Thg090020@utdallas.edu
1
Table of Contents
Revision History……………………………………………………………………………………………………………………………………3
1. Introduction………………………………………………….……………………………………………………………………………………4
1.1 Purpose of the System………………………………………………………………………………………………………4
1.2 Design Goals……………………………………………………………………………………………………………………..4
1.3 Definitions, Acronyms, Abbreviations………………………………………………………………………………5
1.4 References…………………………………………………………………………………………………………………………5
1.5 Overview…………………………………………………………………………………………………………………………….5
2. Current Software Architecture…………………………………………………………………………………………………………6
2.1 Software Architecture…..……………………………………………………………………………………………………6
3. Proposed System…………………………………………………………………………………………………………………………….6
3.1 Overview…………………..………………………………………………………………………………………………………..6
3.2 Subsystem Decomposition………………………………………………………………………………………………6
3.3 Hardware/Software Mapping…………………………………………………………………………………………..6
3.4 Persistent Data Management …………………………………………………………………………………………6
3.5 Access Control and Security……………………………………………………………………………………………6
3.6 Global Software Control……………………………………………………………………………………………………6
3.7 Boundary Conditions…………………………………………………………………………………………………………6
4. Subsystem Services…………………………………………………………………………………………………………………………6
4.1 The User Interface (UI) Subsystem…………………………………………………………………………………6
5. Glossary……………………………………………………………………………………………………………………………………………6
2
Revision History
Version
1.0
1.1
Date
09/25/2013
09/30/2013
Comments
Template
Initial draft
3
Author
T. Gebrehiwet
T. Gebrehiwet
1. Introduction
This document describes the overview of the software architecture and design goals
set by the project. This includes subsystem decomposition, data management, control
flow, and other services later detailed in the document.
1.1
Purpose of the system
Remember MEds is an Android application that tracks medical prescriptions, alerts the
user when it is time to take a dose of their medicine, and also make emergency phone
calls. This application is meant for people with memory, disabilities, elderly people, and
the technology illiterate. Taking prescribed medication on time is crucial for one’s
health and safety. Remember MEds allows the users to take their medications on time
even when they forget to take them.
1.2
Design goals
Design goals represent a set of standards that are desired for the system when making
design decisions.
1.2.1 Reliability
1.2.1.1
The application must be 99% correct when processing commands
1.2.1.2
The application must self-reboot if a failure occurs
1.2.2 Response Time
1.2.2.1
The response time to the user should be less than 4 seconds.
1.2.2.2
The application updates should occur when not in use.
1.2.2.3
The application must keep activity logs and prescription logs every
hour.
1.2.2.4
The application must recover within 1 minute if a crash occurs.
4
1.2.3 Workload
1.2.3.1
The application will not make any calculations except for the
addition and subtraction of the pills.
1.2.4 Platform
1.2.4.1
The application will be available on Android phones.
1.2.5 Security
1.2.5.1
The application will have no sensitive data and not make any
internet interactions.
1.3 Definitions, acronyms, and abbreviations
Term
Definition
Cohesion
Degree of interaction within a module.
Coupling
Degree of interaction between two
modules
UML
Unified Modeling Language
1.4
References
 Applying UML and Patterns: An Introduction to Object-Oriented Analysis and
Design and the Unified Process, 2nd ed., C. Larman
 Object-Oriented Software Engineering, 1st ed., S. Schach
1.5
Overview
This document presents and explains the functionality of the system from the
system’s point of view with in-depth UML diagrams for the layers and
interactions of the modules. The decomposition of the system into subsystems
is to be done that minimizes coupling and maximizes cohesion.
5
2. Current software architecture
2.1 Software Architecture
There is no software architecture presently for the application. The system
receives input from the user, processes it, and returns a confirmation to the
user. When a user presses the new button the screen goes to the add medicine
prescription page. The user then enters the necessary information for the
medicine and clicks the add button. Once the user presses the add button a
label confirming that the medication has been added to the list of subscriptions.
The screen goes to the home page after the confirmation label disappears. The
process is done in one layer and everything is stored onto the device running
the application. The lack of having no software architecture could be the
difference between life and death for the patient. The proposed software
architecture will address these issues by creating layers for each component.
3. Proposed software architecture
3.1
Overview
3.2 Subsystem decomposition
3.2.1 User Interface Layer
*Add more
3.3 Hardware/Software mapping
3.4 Persistent data management
3.5 Access control and security
3.6 Global software control
3.7 Boundary conditions
4. Subsystem services
4.1 User Interface Subsystem
* add other subsystems from 3.2
5. Glossary
6
7