This section describes the traceability of our requirements analysis.
The Tracebility matrix describes the dependency of the functional and the non-functional requirements to the domain requirements.
|
DOMAIN REQUIREMENTS
|
|
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
8
|
9
|
10
|
11
|
12
|
13
|
14
|
15
|
16
|
17
|
18
|
19
|
20
|
21
|
22
|
23
|
24
|
FR
|
1
|
x
|
x
|
x
|
x
|
x
|
|
x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x
|
|
FR
|
2
|
x
|
x
|
x
|
|
x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FR
|
3
|
X
|
X
|
X
|
|
x
|
x
|
x
|
x
|
|
x
|
|
|
x
|
|
|
|
|
x
|
|
x
|
|
|
|
|
|
FR
|
4
|
X
|
X
|
X
|
|
|
|
|
|
|
|
|
x
|
|
|
|
|
|
|
|
|
x
|
|
|
|
|
FR
|
5
|
x
|
x
|
x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x
|
x
|
|
|
|
|
FR
|
6
|
x
|
x
|
x
|
|
|
x
|
|
|
|
x
|
x
|
|
x
|
|
x
|
|
|
x
|
x
|
x
|
|
|
|
|
|
FR
|
7
|
X
|
X
|
X
|
|
|
|
|
|
|
|
|
|
|
|
|
x
|
x
|
|
|
|
|
|
|
|
|
FR
|
8
|
X
|
X
|
X
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x
|
x
|
|
|
FR
|
9
|
x
|
x
|
x
|
|
|
|
|
|
x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FR
|
10
|
x
|
x
|
x
|
|
|
|
|
|
|
x
|
|
|
|
|
|
|
|
|
x
|
|
|
|
|
|
|
FR
|
11
|
x
|
x
|
x
|
x
|
|
|
|
|
|
|
|
x
|
|
|
|
|
|
|
|
|
x
|
|
|
|
|
FR
|
12
|
X
|
X
|
X
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x
|
|
|
|
|
X
|
|
FR
|
13
|
X
|
X
|
X
|
|
|
x
|
|
|
|
X
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FR
|
14
|
x
|
x
|
x
|
|
|
|
|
|
|
X
|
x
|
|
|
|
x
|
|
|
|
|
|
|
|
|
|
|
FR
|
15
|
x
|
x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
X
|
x
|
NFR
|
1
|
x
|
x
|
x
|
|
x
|
|
x
|
x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
NFR
|
2
|
X
|
X
|
X
|
|
|
x
|
|
|
|
X
|
x
|
|
x
|
|
x
|
|
|
x
|
x
|
x
|
|
|
|
|
|
NFR
|
3
|
X
|
X
|
X
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
NFR
|
4
|
x
|
x
|
x
|
|
x
|
|
x
|
x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
NFR
|
5
|
x
|
x
|
x
|
|
|
x
|
|
|
|
x
|
x
|
|
x
|
|
x
|
|
|
x
|
x
|
x
|
|
|
|
|
|
NFR
|
6
|
x
|
x
|
x
|
|
|
|
|
|
|
X
|
x
|
|
|
|
X
|
|
|
|
x
|
|
|
|
|
|
|
NFR
|
7
|
X
|
X
|
X
|
|
|
x
|
|
|
|
|
|
|
x
|
|
|
|
|
x
|
|
x
|
|
|
|
|
|
NFR
|
8
|
X
|
X
|
X
|
|
|
x
|
|
|
|
X
|
x
|
|
x
|
|
X
|
|
|
x
|
x
|
x
|
|
|
|
|
|
NFR
|
9
|
x
|
x
|
x
|
|
|
x
|
|
|
|
X
|
x
|
|
x
|
|
X
|
|
|
x
|
x
|
x
|
|
|
|
|
|
NFR
|
10
|
x
|
x
|
x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x
|
|
|
|
|
NFR
|
11
|
X
|
X
|
X
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x
|
x
|
NFR
|
12
|
X
|
X
|
X
|
|
|
|
|
|
|
x
|
x
|
|
|
|
x
|
x
|
x
|
|
|
|
|
|
|
|
|
NFR
|
13
|
x
|
x
|
x
|
|
|
|
|
|
|
x
|
x
|
|
|
|
x
|
x
|
x
|
|
x
|
|
|
|
|
|
|
NFR
|
14
|
x
|
x
|
x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x
|
|
|
|
|
|
NFR
|
15
|
x
|
x
|
x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
NFR
|
16
|
X
|
X
|
X
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x
|
x
|
|
|
NFR
|
17
|
X
|
X
|
X
|
|
|
|
|
|
x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
NFR
|
18
|
x
|
x
|
x
|
|
|
|
|
|
|
|
|
x
|
|
|
|
|
|
|
|
|
x
|
|
|
|
|
NFR
|
19
|
x
|
x
|
x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
X
|
X
|
NFR
|
20
|
X
|
X
|
X
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x
|
x
|
NFR
|
21
|
X
|
X
|
X
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
NFR
|
22
|
x
|
x
|
x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
x
|
|
|
|
|
|
10. References
-
Requirement Engineering –Advanced Requirement Engineering. CS/SE 6361, Section 001, Spring 2012.
http://www.utdallas.edu/~chung/RE/syllabus.htm
-
Software Engineering (8thEdition) – Ian Sommerville
-
Software Engineering, A practitioners approach (7th Edition)– Roger S Pressman
-
http://www.psychpage.com/learning/library/assess/feelings.html
-
Dr. Sundar Raj All India Institute of Speech and Hearing, Mysore, Karnataka, India
-
Dr. Jagadeesh R Malloli, ENT Surgeon, Vikram Hospital, Mysore, Karnataka, India
-
Dr. Suma Harindra, Audiologist, JSS Institute of Speech and Hearing, Mysore, India
Appendix – A
Why we stand out of the crowd?
1. Our system consists of functions that make our project better. Some of them are:
a) PillTracker and MyShelf are useful for old people with memory loss.
b) Sophisticated applications to manage finances cannot be handled by Old people. Hence we have reduced the complexity of the application by just allowing the user to store the bank account details with a secure password which the care-taker can assist with.
d) Every page has the emergency button.
2. Our project aims to attain maximum possible features that could help a person with difficulty, rather than working on a few restricted and highly sophisticated features
3. In our project we are using the spiral model to design the requirements specifications of both phase-1 and phase-2. The actual android application development will follow an agile development process as this is a small project with rapid deliverables.
4. Our application utilizes almost all the basic features of a smartphone for various unique features.
5. The Pareto Principle (also known as the 80/20 rule) the idea is that by doing 20% of the work you can generate 80% of the benefit of doing the whole job.
We have used Pareto 80-20 principle for the measurement of the percentage of the changes in the requirements.
5. All icons are self-explanatory; the icon size is also larger enough to be easily identified.
6. The features and by whole, the application has been designed in a to be very user friendly and would take minimum time to learn and handle.
7. There is more compliance between our prototype and our requirements.
Creeping Rate:
The changes can be easily incorporated in the requirements stage. Once the requirements are finalized and implementation has started, introducing changes during the implementation phase proves expensive.
Project Status (completed stage)
|
Accommodation Percentage
|
Final Phase-1: Final Product Specification. Changes in Product requirements have to freeze
|
15-40%
|
Interim Phase-2: Final Design. Changes in requirement specification have to freeze
|
10-15%
|
Final Phase-2: Final Implementation. Changes in design have to freeze
|
0-10%
|
Feature specific creeping rate is also specified for vulnerable features developed by Team Andromeda.
The features and their corresponding creeping rate threshold at Final Phase-2 stage of project is shown below:
-
Feature
|
Creeping Rate
|
Emergency
|
0-10%
|
Help
|
0-10%
|
PicTalk
|
0-5%
|
MyPage
|
0-15%
|
DietManager
|
0-5%
|
MyShelf
|
0-10%
|
Future Scope of the project:
1. A one-touch text or voice message to contacts in case of an emergency.
2. Transmit the medical report of the user to anybody necessary through e-mail.
3. Use image recognition to recognize a person and retrieve the profile of that person from contacts.
Requirements Prioritization
Out of the total 25 domain requirements, ten main requirements were considered and prioritized as below.
Domain
Requirement
(DR)
|
Functional Requirement
(FR)
|
Priority
|
Reason
|
DR-03
|
FR-01
|
High
|
Emergency Service access.
|
DR-07
|
FR-02
|
Medium
|
--
|
DR-03
|
FR-03
|
Medium
|
--
|
DR-04
|
FR-04
|
Low
|
--
|
DR-05
|
FR-05
|
Medium
|
--
|
DR-19
|
FR-05
|
High
|
Access to drugs.
|
DR-07
|
FR-07
|
Medium
|
--
|
DR-22
|
FR-08
|
High
|
Change in Pressure and Sugar levels should be updated.
|
DR-09
|
FR-09
|
Low
|
--
|
DR-10
|
FR-10
|
Low
|
--
|
APPENDIX B – MINUTES OF MEETING
Date
|
Location & Time
|
Agenda
|
Summary
|
04/18/2012
|
Phase 4 Clubhouse
8:00 PM to 10:00 PM
|
WRS Template, Initial Requirements
|
Finalized the WRS template. Choose the process model & requirements. Distribute modules to the group.
|
04/19/2012
|
EECS 4th Floor
4:00 PM to 6PM
|
Issues related to the requirements
|
Discussed the issues related to the requirements & their possible solutions.
|
04/22/2012
|
Library
4:00 PM to 5:30 PM
|
Improvise on the initial requirements
|
Brainstorming on the initial requirements and improved them to suit the application.
|
04/24/2012
|
ECSS 4th floor
5:00 PM to 8:00 PM
|
Reviewed the rough draft of the documentation,
Prepared a sample SRS Template
|
Reviewed the modules of each team member. Prepared a WRS template based on the team member’s feedback.
|
04/28/2012
|
Library
4:00 PM to 8:00 PM
|
Prepared Presentation & Documentation and finalizing the WRS for Final Phase - 2
|
Finalized the presentation & documentation for
Final Phase - 2
|
04/29/2012
|
Waterview Apt 1531
4:00 PM
|
Document review cycle
|
Reviewed the work of individual team member. Finalized on the SRS template and sent to high end review.
|
05/01/2012
|
Library
12:00 PM to 2:00PM
|
Making changes to the documentation
|
Each team member was given a sub-section of the document to review & make modifications.
|
05/02/2012
|
Open Lab
6:00 PM to 10:00 PM
|
Final review of Final Phase – 2 Documentation
|
The works of team members are reviewed and finalized the WRS document.
|
