Scheduler Feedback
- Wes Brown
- Aare Laponin
Feedback Template
Source ID/Section | Comment | Feedback Type | Jira Issue |
|---|---|---|---|
6.1 - Functional Requirements / Event management | It is stipulated that changes in event cannot be done after event is over, which implies that changes can be done when event is already started - it may be problematic, if some important attributes of event (e.g. venue) are changed once event is started and not yet over. | Next | Create issue only once comment has been reviewed |
6.2 - Functional Requirements / Resource management | While it stated in the section 4 Out of scope that evaluation of other then time criteria is out of scope, still, in the context of one resource affiliation permission rule to different host entities, seems to be problematic if one Resource will be affiliated to two different entities in such way that it is impossible to arrive from one entity to another during the time between two tie slots. For example, if one doctor has working hours on Monday from 10am till noon in hospital A and from noon till 4pm in hospital B and distance between two hospitals is 10 km, it is obviously problematic. Same obviously problematic situation will be to plan continuous usage of a shared car without planning refuelling etc. I suggest to have at least some constraint policies for different type of resources. | Next |
|
6.3 - Functional Requirements / Subscriber management | In the first rule here Scheduler can assign subscriber to an event without any consent from subscriber. That seems to be inappropriate, at least from terminology point of view. Subscriber is normal an active actor, who is willingly express wish to subscribe to certain event. Here the term Subscriber is used like a Subject. It is confusing, despite the fact, that I kinda guess the motivation for doing so. I suggest, to use Subscriber only when person or system can actually willingly and actively subscribe to certain event and Subject should be used, when person or system is assigned to certain event. Also, there is a rule, that Subscriber may be affiliated with subsequent non-overlapping events. Like in case with Resource, there should be some constraint policies, checking that such affiliation is feasible. For example, patient should be able physically to reach subsequent event from the previous event, if they are in different venues etc. | Next |
|
6.4 - Functional Requirements / Alert management | There used undefined term “token number“. It is unclear what it is (I assume, it is not a token, which is, for example, used in JWT standard). Some explanation should be provided or better (less abstract) term should be used. | Next |
|
6.5 - Functional Requirements / Logging and Reporting | The title of the section is confusing as far as the content is more like about monitoring not about logging per se. Also, logging requirements were described in the section “Alert management“ (bullet #3). | Now | |
6. - Functional Requirements | I recommend to add Policy for Entity and Resource to define basic constraints of relations and planning. | Next |
|
7 - Scheduler Building Block Data Model | I assume that diagram is done using Entity Relationship Diagram notation. Incorrect diagram: it is shown that one record in Alert_ScheduleList is connected to many records in the Event_List. That means that there may be several records in Event_List referring to one record in Alert_Schedule_List. That means that several different Event_Id-s may refer to one Alert_schedule_id. However, in tables description it is mentioned that Event_id in the Alert_schedule_List is an ID of Event, which is bound to the schedule. That is contradicting. Same problem is the attributes:
Also, not all relations are shown. For example, attribute Entity_id in Log implies relation to Entity_list but it is not shown. One should be consistent: whether you show all relation or you do not show foreign keys if you do not want to show relations. | Next |
|
8 - Service API | Documentation should be provided in standard way as it is done for all other BB-s Also, API operations are documented not in a standard way. For example, for operation POST https://<domain>/entity/ | Complete |
|
9.2 - | The workflow is too generic. I believe, it is not feasible to assign for Event of type “Dentist Doctor appointment“ gynaecologist (Resource) and a person (Subject), who has just delivered baby and requires some new-born baby related assistance. Also, workflows 2 and 3 should be combined. In general, I would recommend to use so-called use case or user story methodology for workflows i.e., each workflow should achieve meaningful business objective. Current workflows are more like technical internal stuff. | Next |
|