RFID application use case model + domain model

Problem statement

The problem context of requirements analysis for an asset tracking system using RFID technology. The system will track important assets and entities in the hospital (pharmaceuticals, supplies, durable medical equipment, patients, doctors, nurses, etc.) and provide specific user interfaces that are tailored for particular kinds of asset tracking.

1) Supply Tracker (search inventory, display inventory, order supplies, update inventory) - primarily used by an individual playing the role of Purchaser
2) People Tracker (admit patient, register visitor, discharge patient, register staff, query person location, monitor visitors, monitor ward) - primarily used by Nurses, Administrative Staff and Security Personnel

Approach
Through this project approach can be summarized as following :

1) Construct questionnaires for various stakeholders

2) Make a list of use cases (brief format) and initial prioritization

3) Develop fully-dressed use cases for high-priority use cases

4) Describe UML use case model for fully-dressed use cases

5) Describe UML system sequence diagram for each fully-dressed use case

6) Describe UML domain model

Use Case Model
1) Supply Tracker Application

2) People Tracker Application

The business value of the system is driven by several current issues which are of concern :
- Unauthorized visitor access (e.g. risk of drug theft or infant abduction)
- More effective inventory management
- More effective shared use of high-demand capital equipment (e.g. sonogram machines)

Domain Model
In this problem context, key concerns are RFID tag , People Registration /Asset Registration and Location Event. The others are duplicated information from HR, e-Records and e-Logistics system which is originally managed patient’s medical information, employee’s detail information and asset’s information. By applying “separation of concerns” concept, key abstraction can shows this domain characteristics concisely, however, with other entity can describe well enough to understand this domain as well. Key abstraction (yellow) will be designed first in design stage and others will be designed later and be consistent with existing environment.
E-records is the master domain of patient’s medical information. HR is the master domain of employee’s information such as department, special occupation, and position. E-Logistics is the master domain of asset’s information such as asset category (disposable supplies, expensive equipment, etc) and earned date , earned price, and etc. These entity should be consistent with original master entity in HR, e-Records, and e-Logistics. To meet consistency, in design stage, these entities should be designed to meet their original domain’s design specification such as database schema, interface specification and etc.