1
HOPE (Helping Our People Easily)
Mobile Phone Application System
Final Phase
SE 4351
Section 001
Team Name: Team Awesome
Member’s Name
Email Address
David Pederson
[email protected]
Weston Wofford
[email protected]
Eric Ly
[email protected]
Aakash Patel
[email protected]
Saad Ahmed
[email protected]
Angela Neff
[email protected]
Amanda Lim
[email protected]
Team Website: https://sites.google.com/site/utdhope001/
2
Table of Contents
Introduction ………………….………………………………………………………… 3
1. Purpose
2. Scope
3. Stakeholders
4. Definitions and Glossary
5. References
2. Organizational Structure
…….……………………………………………..……… 4
1. Visions and Goals
2. Team Roles
3. Workflow
3. Process Specification …………………………………………………………………… 6
1. Requirements Engineering Model
2. Requirements Elicitation
3. Requirements Analysis and Negotiation
4. Requirements Specification
5. Requirements Validation
4. Project Organization ……….………………..………………………………………… 8
1. Project Phases
2. Interim Phase I
3. Final Phase I
4. Interim Phase II
5. Traceability
1.
3
1. Introduction
1.1. Purpose
The purpose of this document is to describe the process that Team Awesome used to develop
the HOPE System, in order to help the elderly people overcome their physical disabilities and
communicate effectively with the people around them in an easy and cost effective way.
1.2 Scope
This Process Specification document applies to the HOPE System which will be developed by
Team Awesome as an Android application for mobile phones. The HOPE System provides a
sentence generator, alarm system, and emergency contact features. The system supports
phones that use the Android platform.
1.3 Definitions, Acronyms, and Abbreviations
Android: a mobile phone platform
Assistive person: caretaker or assistant who helps the elderly
Elderly: elderly people who might use the HOPE System to aid with memory and
communication needs
HOPE: Help Our People Easily
1.4 References
1. Requirement Engineering –Advanced Requirement Engineering. CS/SE 4351, Section 001,
Fall 2011. http://www.utdallas.edu/~chung/CS4351/syllabus.htm
2. final+process+specification-12-02-10-00-47.doc http://www.utdallas.edu/~chung/RE/
Presentations10F/supernova/
3. 3 - Process Specification - Final.pdf http://www.utdallas.edu/~chung/RE/
Presentations10F/Team-hope/
4
2. Organization Structure
2.1 Vision and Goals
Vision
Our vision is to organize the team and develop rapport between team members so that we may
work well together. This will yield a superior final product and satisfy the customer’s needs.
Goals
1.
2.
3.
4.
Meet our deadlines.
Prepare well-made deliverables that fit the requirements.
Distribute work evenly among team members.
Create a product within the scope of our team’s small size that still satisfies our client’s
needs.
5. Share and communicate openly between team members.
2.2 Team Roles
All members performed various roles throughout the project, which can be loosely defined as
follows.
Team Leader
The team leader must lead the team and overlook all group operations. He or she is also
responsible for taking the initiative in conducting group meetings, scheduling, and resolving
conflicts. Most importantly, the team leader ensures that the final outcome of the project is high
quality and completed on time.
Android Developer
The Android Developer must create the final product of the project, the HOPE application for the
Android system. After the requirements have been decided, the developer is responsible for
translating those requirements and implementing the code.
Technical Writer
The technical writer must complete the deliverables which require technical writing. This
includes the vision document, process specification, WRS, and user manual. The writer is
required to adhere to the given outline of the documents and the technical writing style
appropriate for such documentation.
Reviewer
The reviewer must examine and potentially change the deliverables created by the team before
the deliverables can be submitted. The reviewer checks for grammar, style, adherence to
requirements, and adherence to applicable standards. If unable to implement the changes
necessary for any deliverable, the reviewer must resubmit it to the team so they can implement
the changes.
2.3 Workflow
For each phase, the Team Leader outlines everything to be accomplished for that phase. Then
work is split up and assigned to individuals to complete before a given deadline (prior to the
phase deadline). Every document is uploaded to Google Documents so that members may read
or edit simultaneously. Before the final due date, the Team Leader reviews everything and the
team has a group meeting to discuss any problems or changes that need to be made.
5
3. Process Specification
3.1 Requirements Engineering Model
Our process specification followed the spiral model. A diagram is given below.
3.2 Requirements Elicitation
Requirements are given by Professor Chung as part of the class assignment. Further
requirements are created by the team after analyzing the initial problem.
3.3 Requirements Analysis and Negotiation
Upon first receiving the initial requirements for the HOPE system, Team Awesome listed the
initial functional and nonfunctional requirements for the system. Each phase introduced issues
with the initial requirements, so they were refined and changed as necessary. The team
checked requirements for unambiguousness, inconsistency, and completeness.
3.4 Requirements Specification
Requirements are divided into functional and nonfunctional in order to allow proper and efficient
maintenance.
3.5 Requirements Validation
To insure that the requirements comply with the customer’s expectations, a prototype has been
created to show the initial functionality of the system. A prototype allows the team to show the
customer how the system will function, and the customer can give feedback as to any missing
components, confusing services, or miscommunication that has occurred between them and the
team.
6
7
4. Project Organization
4.1 Project Phases
The project was divided into two phases, with two sub-phases each. The following is a brief
overview of each phase.
Phase I
Part I: The focus was on preparing the basis for all functional and non-functional
requirements, and trying to elicit the domain and stakeholders, as well as trying to focus in on
key issues.
Part II: The final part of Phase I was to further expand the requirements, domain,
stakeholders, and to develop our WRS (World, Requirement, Specification) including an attempt
to improve understanding of all key areas. A prototype was also developed and user manual
created, and traceability established.
Phase II
Part I: The focus on this part was to begin working on the actual system, as well as
further refining our goals with a Vision Document, and accompany our documents with models
and diagrams detailing processes and use cases.
Part II: This final part of the last phase will focus on completing the system to the
satisfaction of our team, as well as matching all final definitions of requirements.
4.2 Interim Phase I
Stakeholders
The following were the stakeholders for Interim Phase I
● Team Awesome
● The elderly who would use the HOPE system
● The assistants who aid the elderly
Goals
The following were the goals for Interim Phase I.
● Establish what the stakeholder needs
● Decide which features to include in the HOPE system
● Refine the list of requirements
● Create a presentation for Interim Phase I
Inputs
The following were the inputs for Interim Phase I.
● Preliminary Project Plan
Processes
The following is a description of the team’s process for Interim Phase I.
● Determine the best time for team meetings
● Elect phase leader
● Identify key issues
● Identify the deliverables for the phase
● Assign work to individuals
● Review and discuss all work
● Submit deliverables on time
8
Activities
The following describes the main activities for Interim Phase I.
● Create and revise deliverables
● Create and revise presentation slides
● Rehearse the presentation
● Live meetings
● Daily email communication
Outputs
The following were the outputs for Interim Phase I.
● Issues
● WRS
● Mock-up
● User Manual
● Powerpoint Presentation
Roles and Responsibilities
The following were the roles for each team member for Interim Phase I.
Team Lead: Weston Wofford
Issues and WRS: everyone
Prototype: Weston Wofford
User Manual: David Pederson, Amanda Lim
Powerpoint Presentation: everyone
4.3 Final Phase I
Stakeholders
The following were the stakeholders for Final Phase I
● Team Awesome
● The elderly who would use the HOPE system
● The assistants who aid the elderly
Goals
The following were the goals for Final Phase I.
● Revise the WRS and issues.
● Develop improved understanding.
● Consider and implement criticism received in class.
● Update the prototype and manual.
Inputs
The following were the inputs for Final Phase I.
● Preliminary Project Plan
● Issues
● WRS
● Mock-up
● User Manual
Processes
The following is a description of the team’s process for Final Phase I.
● Elect phase leader
● Identify ideas to use from other team’s presentations
● Identify positive criticism from class to implement
9
●
●
●
●
Identify the deliverables for the phase
Assign work to individuals
Review and discuss all work
Submit deliverables on time
Activities
The following describes the main activities for Final Phase I.
● Create and revise deliverables
● Live meetings
● Daily email communication
Outputs
The following were the outputs for Final Phase I.
● Revised Issues
● Revised WRS
● Revised Mock-up
● Revised User Manual
Roles and Responsibilities
The following were the roles for each team member for Final Phase I.
Team Lead: David Pederson
Revised Issues: everyone
Revised WRS: everyone
Revised Prototype: Weston Wofford
Revised User Manual: David Pederson, Amanda Lim
4.2 Interim Phase II
Stakeholders
The following were the stakeholders for Interim Phase II
● Team Awesome
● The elderly who would use the HOPE system
● The assistants who aid the elderly
Goals
The following were the goals for Interim Phase II.
● Document the process specifications
● Identify further issues and correct them
● Identify vision and goals
● Use semi-formal notation to describe project
● Begin implementation of the system
● Implement the critiques received from the TA in class
Inputs
The following were the inputs for Interim Phase II.
● Preliminary Project Plan
● WRS Document
● Mock-up
● User Manual
● Project Presentation
Processes
10
The following is a description of the team’s process for Interim Phase II.
● Elect phase leader
● Identify the deliverables for the phase
● Begin programming of the Android application prototype
● Create the Vision Document
● Create the Process Specification Document
● Assign work to individuals
● Review and discuss all work
● Submit deliverables on time
Activities
The following describes the main activities for Interim Phase II.
● Create and revise deliverables
● Live meetings
● Daily email communication
Outputs
The following were the outputs for Interim Phase II.
Revised WRS and Issues Document
Process Specification
Prototype
Vision Document
Roles and Responsibilities
The following were the roles for each team member for Interim Phase II.
Team Lead: Amanda Lim
Vision Document: everyone
Prototype: Saad Ahmed
Process Specification: Amanda Lim
4.5 Traceability
Interim Phase I vs. Final Phase I
Interim Phase I deliverable
Preliminary Project Plan
Issues and WRS Document
Mock-up
User Manual
Interim Phase I Presentation
Final Phase I deliverable
Project Plan
Revised WRS Document and Process
Specification
Revised Mock-up
Revised User Manual
Interim Phase I Presentation (no change)
Final Phase I vs. Interim Phase II
Final Phase I deliverable
Project Plan
Revised WRS Document and Process
Specification
Interim Phase II deliverable
Project Plan
Revised WRS Document, Process
Specification, and Vision Document
11
Revised Mock-up
Revised User Manual
Interim Phase I Presentation
Prototype
Revised User Manual
Interim Phase II Presentation