Introduction Go through requirements process with the BE Design team Go through requirements process with the BE Design team Write an SRS form, complete.

Slides:



Advertisements
Similar presentations
CAPE COMPUTER SCIENCE UNIT 2
Advertisements

Generalizable Element Namespace Model Element name visibility isSpecification Classifier isRoot Constraint Body Use Cases CS/SWE 421 Introduction to Software.
Project leaders will keep track of team progress using an A3 Report.
Chapter 6: Documenting Accounting Information Systems
 You will be able to: › Explain what is meant by an expert system and describe its components and applications.
ICT and medicine IT & C Department AP - Secretariat.
Case Tools Trisha Cummings. Our Definition of CASE  CASE is the use of computer-based support in the software development process.  A CASE tool is a.
Fitbit accuracy had to be verified Able-bodied test subject wore Fitbit Subject was asked to perform various activities Assistant recorded actual ambulation.
Research Development for Android Coopman Tom. What is Android?  Smartphone operating system  Google  Popular  ‘Easy to develop’  Open-Source  Linux.
Chapter 6 Review Questions
Facility Design Tutorial This tutorial is designed to enhance knowledge of biotechnological/pharmaceutical processes. The topics covered within this tutorial.
Use-case Modeling.
1 Team Skill 4 - Team Skill 5 - Scope Refining the Systems Definition (Chapters of the requirements text) CSSE 371 Software Requirements and Specification.
Actor Specification Actor Name: Designer Abstract: No
Creating Architectural Descriptions. Outline Standardizing architectural descriptions: The IEEE has published, “Recommended Practice for Architectural.
Review Questions List and describe the purpose of the four phases of Systems Analysis. The preliminary investigation phase quickly determines whether or.
Major Exam II Reschedule 5:30 – 7:30 pm in Tue Dec 5 th.
Strabismus Checking System The Team: Lior Barak Omri Mosseri Application Requirements Document.
1 CMPT 275 Software Engineering Requirements Analysis Process Janice Regan,
S R S S ystem R equirements S pecification Specifying the Specifications.
Mr. Beerbower McHenry High School
Prescription & Over-the-Counter Drugs: Get the Facts
BRC Food Safety Quality Management System Training Guide
Marcos Esterman, Associate Professor Industrial and Systems Engineering Department Rochester Institute of Technology Multidisciplinary.
RUP Requirements RUP Artifacts and Deliverables
Project Analysis Course ( ) Week 2 Activities.
Systems Analysis – Analyzing Requirements.  Analyzing requirement stage identifies user information needs and new systems requirements  IS dev team.
® IBM Software Group © 2006 IBM Corporation Rational Software France Object-Oriented Analysis and Design with UML2 and Rational Software Modeler 06. Requirements.
Group 8: Shenanigans Mike Ostrowski Josh Patsey Michelle Boomer Tom Parks Levent Niazi.
Week 5: Business Processes and Process Modeling MIS 2101: Management Information Systems.
Based on D. Galin, and R. Patton.  According to D. Galin  Software quality assurance is:  A systematic, planned set of actions necessary to provide.
Instructore: Tasneem Darwish1 University of Palestine Faculty of Applied Engineering and Urban Planning Software Engineering Department Requirement engineering.
Introducing the Medication Recording System Schedule Ed Castagna Mom & Pop’s Small Business Services.
Feasibility Study.
Chapter 4 – Requirements Engineering Lecture 3 1Chapter 4 Requirements engineering.
10/12/ Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 1. Interviews & questionnaires.
UML The Unified Modeling Language A Practical Introduction Al-Ayham Saleh Aleppo University
The Practical Art of Endpoint Selection: Industry Perspectives A View from the Pharma Industry of the FDA Guidance on PROs Glenn A. Phillips, Ph.D. Director.
Networking and Health Information Exchange Unit 6b EHR Functional Model Standards.
Requirements Documentation CSCI 5801: Software Engineering.
CPSC 372 John D. McGregor Module 2 Session 1 More on requirements and the Investment Decision.
ICT and medicine. Objectives The uses of ICT in medicine The uses of ICT in medicine in patient records, medical equipments, internet devices…etcin patient.
Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 3. Defining the System 4. Managing Scope 5.
A Use Case Primer 1. The Benefits of Use Cases  Compared to traditional methods, use cases are easy to write and to read.  Use cases force the developers.
Yarmouk University Department of Computer Information Systems CIS 499 Yarmouk University Department of Computer Information Systems CIS 499 Yarmouk University.
Shanghai Jiao Tong University 上海交通大学软件工程中心 Object Oriented Analysis and Design Requirements Overview.
Health eDecisions Use Case 2: CDS Guidance Service Strawman of Core Concepts Use Case 2 1.
PMI-Planning Process Group Lecture 08 Ms Saba Sahar.
Requirements Engineering Lesson 2. Terminologies:  Software Acquisition is where requirement engineering significantly meets business strategy.  Software.
This material was developed by Duke University, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information.
Generalizable Element Namespace Model Element name visibility isSpecification Classifier isRoot Constraint Body Use Cases CS/SWE 421 Introduction to Software.
Identifying Needs and Establishing Requirements Presenters: Veronica Gasca Jennifer Rhough.
Using Stem Cells to Treat Ailments of the Nervous System Crista Chavez, Jacqueline Doody, Nina Roxo, Aleksandra Sabov & Zachary Taylor Faculty Mentor:
UML - Development Process 1 Software Development Process Using UML.
Outlines Overview Defining the Vision Through Business Requirements
Ch  ICT is used in many ways in the provision and management of healthcare services:  Hospital administration  Medical training  Maintenance.
The Patient Choice Project Use Case Working Session February 12 th, 2016.
SmartPosition Customer Review and Feedback Presentation.
Use Case Diagrams. Introduction In the previous Lecture, you saw a brief review of the nine UML diagrams. Now that you have the clear, you'll start to.
Requirements. Outline Definition Requirements Process Requirements Documentation Next Steps 1.
A Health and safety law training programme for employers This programme has been set up to guide employers on some of the basic H&S legislation in the.
Staged Electronic Data Deliverable (SEDD): Overview and Implementation Status Dr. Anand R. Mudambi US Environmental Protection Agency (USEPA) November.
Writing the Requirements
PHARMACEUTICAL GUIDELINES: BASIC PRINCIPLES AND STATUTES.
Advanced Higher Computing Science
Medicines and Drugs Chapter 23 Mr. Martin.
Dokumentasi Perubahan Proses: Pengantar BPM
System Design By Kustanto.
Use Case Document Example
Software Engineering System Modeling Chapter 5 (Part 1) Dr.Doaa Sami
Presentation transcript:

Introduction Go through requirements process with the BE Design team Go through requirements process with the BE Design team Write an SRS form, complete with: Write an SRS form, complete with: Work Context Diagram Work Context Diagram Use Cases Use Cases Requirements Requirements Functional Functional Non-Functional Non-Functional Fit Criterion Fit Criterion Constraints Constraints Risks Risks

Device Background Device is to help Parkinson’s patients. Device is to help Parkinson’s patients. Parkinson’s is a disease that effects the brain. Parkinson’s is a disease that effects the brain. Current treatment involves Levodopa. Current treatment involves Levodopa. Levodopa subdues the symptoms. Levodopa subdues the symptoms. Levodopa also destroys the part of the brain that Parkinson’s effects. Levodopa also destroys the part of the brain that Parkinson’s effects.

Project Goals Goal Goal Create a device that accurately measures the Levodopa levels in a patient Create a device that accurately measures the Levodopa levels in a patient Advantage Advantage To have a standard and accurate way of measuring Levodopa levels. To have a standard and accurate way of measuring Levodopa levels. Metric Metric Give a patient a certain amount of Levodopa and use the device to see if it can accurately measure that amount of Levodopa Give a patient a certain amount of Levodopa and use the device to see if it can accurately measure that amount of Levodopa

Goals Goal Goal Use the device to prescribe the least amount of Levodopa to relieve the symptoms of Parkinson's disease. Use the device to prescribe the least amount of Levodopa to relieve the symptoms of Parkinson's disease. Advantage Advantage The lowest and most effective dosage of Levodopa can be given to the patient, decreasing the deteriation of the substantia nigra The lowest and most effective dosage of Levodopa can be given to the patient, decreasing the deteriation of the substantia nigra Metric Metric Take a control group of untreated Parkinson's patients, patients under the current treatment, and patients using the new device. then measure the deterioration of the substantia nigra. Take a control group of untreated Parkinson's patients, patients under the current treatment, and patients using the new device. then measure the deterioration of the substantia nigra.

Goals Goal Goal The device should be portable. The device should be portable. Advantage Advantage With a portable device, the user will easily be able to take the device home with them instead of having to travel to use it. With a portable device, the user will easily be able to take the device home with them instead of having to travel to use it. Metric Metric This goal will be a success if the device requires no third-party assistance in transporting. This goal will be a success if the device requires no third-party assistance in transporting.

Goals Goal Goal The device shall return results of Levodopa levels no longer than five minutes. The device shall return results of Levodopa levels no longer than five minutes. Advantage Advantage A quick response time makes the device convenient for the user to use. A quick response time makes the device convenient for the user to use. Metric Metric Measure the time it takes to input a bodily sample and output the results. If it is less than five minutes, it is a success. Measure the time it takes to input a bodily sample and output the results. If it is less than five minutes, it is a success.

Context Diagram

Use Case Example Use Case Example Use Case Description: This use case describes the "normal" flow of events for the use of the device. Description: This use case describes the "normal" flow of events for the use of the device. Actors: Actors: Marty McFly: Parkinson’s patient on Levodopa treatment for a year. Dr. Benjamin Stone: Mr. McFly’s doctor Pre-Conditions: Marty is already diagnosed as Parkinson’s patient and has been on Levodopa treatment previously. Pre-Conditions: Marty is already diagnosed as Parkinson’s patient and has been on Levodopa treatment previously.

Use Case Basic Flow Basic Flow 1. The device is administered to Marty. 1. The device is administered to Marty. 2. A bodily sample is taken from Marty and processed by the device. 2. A bodily sample is taken from Marty and processed by the device. 3. The device returns raw data to a storage system. 3. The device returns raw data to a storage system. 4. The stored raw data are sent to the analysis system. 4. The stored raw data are sent to the analysis system. 5. There the data is analyzed and Levodopa levels are output for the doctor. 5. There the data is analyzed and Levodopa levels are output for the doctor. 6. Based on the Levodopa levels and patients relief of symptoms, Dr. Stone decides to recommend a lower dosage of Levodopa to maintain treatment at the lowest possible dosage. 6. Based on the Levodopa levels and patients relief of symptoms, Dr. Stone decides to recommend a lower dosage of Levodopa to maintain treatment at the lowest possible dosage.

Use Case Alternate Flows Alternate Flows Based off of the Levodopa levels, Dr. Stone prescribes a greater amount of Levodopa to Marty. Based off of the Levodopa levels, Dr. Stone prescribes a greater amount of Levodopa to Marty. Dr. Stone decides the current prescription is adequate and does not change the prescription. Dr. Stone decides the current prescription is adequate and does not change the prescription. Dr. Stone decides that Levodopa levels are too high and continuation of treatment would be dangerous. Treatment is stopped. Dr. Stone decides that Levodopa levels are too high and continuation of treatment would be dangerous. Treatment is stopped. Post-Condition Post-Condition Decision is made on an updated or sustained prescription Decision is made on an updated or sustained prescription

Requirements Functional Functional The product shall display accurate Levodopa levels. The product shall display accurate Levodopa levels. Fit Criterion: The final analysis presented to the doctor shall be equivalent to the levels of Levodopa in the bodily sample taken from the patient. Fit Criterion: The final analysis presented to the doctor shall be equivalent to the levels of Levodopa in the bodily sample taken from the patient. Source: Goal #1 Source: Goal #1 The product shall require a bodily sample to analyze. The product shall require a bodily sample to analyze. Fit Criterion: The product will not begin analysis until a bodily sample has been provided. Fit Criterion: The product will not begin analysis until a bodily sample has been provided. Source: Goal #1 Source: Goal #1

Requirements The product shall archive the history of Levodopa levels. The product shall archive the history of Levodopa levels. Fit Criterion: After each measurement, collected data shall be stored in a data storage system. Fit Criterion: After each measurement, collected data shall be stored in a data storage system. Source: Goal #1. Archived data is required to create an accurate measurement. Source: Goal #1. Archived data is required to create an accurate measurement.

Requirements Non-Functional Non-Functional The product shall comply with all FDA regulations. The product shall comply with all FDA regulations. Reason: If the product does not comply to FDA regulations, it cannot be sold in the United States. Reason: If the product does not comply to FDA regulations, it cannot be sold in the United States. Source: Stakeholders Source: Stakeholders The product shall not infringe on any existing or pending patents. The product shall not infringe on any existing or pending patents. Reason: Illegal to break patents in the U.S., the device must be patentable to protect the clients interests. Reason: Illegal to break patents in the U.S., the device must be patentable to protect the clients interests. Source: Stakeholders Source: Stakeholders

Requirements The product shall comply with IEEE electronic standards. The product shall comply with IEEE electronic standards. Reason: Aids future maintenance by a third party as the device conforms to pre-existing and widely recognized standards. Reason: Aids future maintenance by a third party as the device conforms to pre-existing and widely recognized standards. Source: Stakeholders Source: Stakeholders

Conclusion Project Purpose Accomplished: Completed the SRS form Project Purpose Accomplished: Completed the SRS form Knowledge Learned: Knowledge Learned: The process for finding requirements The process for finding requirements All information required to write an SRS All information required to write an SRS Handling communication with an outside group Handling communication with an outside group How to build and refine requirements from the ground up, and check them against their intentions How to build and refine requirements from the ground up, and check them against their intentions