Difference between revisions of "Deliciouscake"
From mn/ifi/inf5750
(→Functional requirements:) (Tag: Visual edit) |
(→Summary of requirements) |
||
Line 20: | Line 20: | ||
= Summary of requirements = | = Summary of requirements = | ||
+ | |||
''Functional requirements:'' | ''Functional requirements:'' | ||
− | *The app's main page must contain a form for the submission of commodity orders | + | *A: The app's main page must contain a form for the submission of commodity orders. |
− | **The input fields of the form must accept quantities given by positive integers of the requested commodities. | + | **A1:The input fields of the form must accept quantities given by positive integers of the requested commodities. |
− | **The form must | + | **A2: The form must provide the entire selection of commodities available from the resource "Life Saving Commodities". |
− | + | **A3: There must be a submit button. Upon click, the app must validate the format of the input and the amounts of the ordered commodities before a message may be generated and sent to the DHIS2 messageConversation resource. | |
− | **There must be a submit button. Upon click, the app must validate the format of the input and the amounts of the ordered commodities before | + | ***A3a: The input of each field must be restricted to positive integers or 0. A ceiling input value of 999 (subject to change) must be enforced. |
− | ***The input of each field must be restricted to positive integers | + | ****A summary of the order must be displayed when the submit button is clicked. The summary must contain a list of the commodities, and their respective quantities that have been selected by the user. The summary must prompt the user to review the order before sending. |
− | ****Upon the submission of an order, if any fields do not contain a valid entry, an error message must | + | *****Upon the submission of an order, if any fields do not contain a valid entry, an error message in the summary must provide instructions for the correct format or valid inputs next to the invalidated field(s). No message can be sent in such a case. |
− | ** | + | *****Entirely empty orders are invalid. In case of such a submission, the summary must display an error message prompting the user to review . |
− | ** | + | ****Upon the submission of a valid order, a button labeled "Send order" must be displayed under the summary table. On click, this button must generate and send the message to the appropriate recipients. |
− | *The | + | *****The "appropriate recipients" are defined as those roles that are related to the higher management of the current user's organisation unit. |
− | * | + | **A4: A confirmation message must be sent to the user's message inbox upon sending of an order. |
− | ** | + | ***This message, subject "Commodity Order Confirmation", must state the exact quantities of each ordered commodity. |
− | * | + | *B: The Order message, subject "Commodity Order ", must contain in its body the list of each ordered commodity and the exact quantities that are requested. |
− | **The message must display the | + | **B1: The message must also display the submission date and the name of the sender. |
''Non-functional requirements'' | ''Non-functional requirements'' | ||
− | * | + | * Process requirements: |
− | * | + | ** Client-side HTML5 code will be generated by JavaScript. |
− | * | + | **CSS3 will be used for styling the HTML. |
− | * | + | **Calls to the DHIS2 web API for fetching resources and sending messages will be done with AJAX in jQuery. |
− | + | ** The messages generated and sent by the app will in JSON format. | |
− | + | ** Resources fetched through the DHIS2 api will be in JSON format. | |
− | |||
− | |||
− | |||
− | * | ||
− | |||
− | |||
− | *DHIS2 | ||
= Time schedule = | = Time schedule = | ||
Line 75: | Line 69: | ||
= How we have divided tasks within the group = | = How we have divided tasks within the group = | ||
''Planning phase'' | ''Planning phase'' | ||
− | * Figure out how to implement the app. All questions | + | * Figure out how to implement the app, and determine a rough schedule. All members collaborate. The following questions had to be addressed: |
** How do we implement the submission form? | ** How do we implement the submission form? | ||
*** How do we validate the input fields? | *** How do we validate the input fields? | ||
Line 81: | Line 75: | ||
** How do we generate and send a message based on contents of the form? | ** How do we generate and send a message based on contents of the form? | ||
** How do we implement a storage for commodities, or, what database to pull from? | ** How do we implement a storage for commodities, or, what database to pull from? | ||
− | |||
*** What commodities exist and which should be accessible to each type of user? | *** What commodities exist and which should be accessible to each type of user? | ||
− | *** What types of users exist? | + | *** What types of users/roles exist in the DHIS2 universe? |
− | ** | + | ''Requirements Phase'' |
+ | * Establish requirements. All members collaborated; Thomas documented them. | ||
+ | |||
+ | ''Design Phase'' | ||
+ | * Determine app architecture, and interface layout. All members collaborated. | ||
+ | |||
+ | Implementation phase | ||
+ | * UI layout and design in HTML and CSS (Jørgen). | ||
+ | * Interface to DHIS2 web api (Simen and Thomas). | ||
+ | * Messaging (Everyone). | ||
+ | * Form validation (Simen). | ||
= Screenshots and screen flows = | = Screenshots and screen flows = |
Revision as of 14:06, 9 December 2015
Contents
Project details
Logistics Management Information System (LMIS) Light
The goal for the project is to replace the current paper based system for ordering commodities with a web-based app connected to DHIS2. This will enable users to submit orders to higher managements more efficiently than when using today's system. On one side the app is a simple web-based form where the health workers can fill in orders. On the other side the app is a notification system, where the management can be notified of order requests.
List of group members
Name | |
---|---|
Simen Røste Odden | simenrod@ifi.uio.no |
Thomas Schwitalla | thoschwi@ifi.uio.no |
Jørgen Valen | jorgeval@ifi.uio.no |
Summary of requirements
Functional requirements:
- A: The app's main page must contain a form for the submission of commodity orders.
- A1:The input fields of the form must accept quantities given by positive integers of the requested commodities.
- A2: The form must provide the entire selection of commodities available from the resource "Life Saving Commodities".
- A3: There must be a submit button. Upon click, the app must validate the format of the input and the amounts of the ordered commodities before a message may be generated and sent to the DHIS2 messageConversation resource.
- A3a: The input of each field must be restricted to positive integers or 0. A ceiling input value of 999 (subject to change) must be enforced.
- A summary of the order must be displayed when the submit button is clicked. The summary must contain a list of the commodities, and their respective quantities that have been selected by the user. The summary must prompt the user to review the order before sending.
- Upon the submission of an order, if any fields do not contain a valid entry, an error message in the summary must provide instructions for the correct format or valid inputs next to the invalidated field(s). No message can be sent in such a case.
- Entirely empty orders are invalid. In case of such a submission, the summary must display an error message prompting the user to review .
- Upon the submission of a valid order, a button labeled "Send order" must be displayed under the summary table. On click, this button must generate and send the message to the appropriate recipients.
- The "appropriate recipients" are defined as those roles that are related to the higher management of the current user's organisation unit.
- A summary of the order must be displayed when the submit button is clicked. The summary must contain a list of the commodities, and their respective quantities that have been selected by the user. The summary must prompt the user to review the order before sending.
- A3a: The input of each field must be restricted to positive integers or 0. A ceiling input value of 999 (subject to change) must be enforced.
- A4: A confirmation message must be sent to the user's message inbox upon sending of an order.
- This message, subject "Commodity Order Confirmation", must state the exact quantities of each ordered commodity.
- B: The Order message, subject "Commodity Order ", must contain in its body the list of each ordered commodity and the exact quantities that are requested.
- B1: The message must also display the submission date and the name of the sender.
Non-functional requirements
- Process requirements:
- Client-side HTML5 code will be generated by JavaScript.
- CSS3 will be used for styling the HTML.
- Calls to the DHIS2 web API for fetching resources and sending messages will be done with AJAX in jQuery.
- The messages generated and sent by the app will in JSON format.
- Resources fetched through the DHIS2 api will be in JSON format.
Time schedule
Milestone 1: November 8th
- Document features and architecture on Wiki
- Show understanding of DHIS2 web apps
Milestone 2: November 22th
- First bare-bone version - static HTML
- Uploadable as DHIS2 web app
Milestone 3: December 4th
- Finished, if applicable also with the mobile app
Milestone 4: 11th December
- Final delivery
Documented learning during project
We have:
- Gained a better understanding of DHIS2, and how to use the DHIS2 API.
- Learned how to develop apps for DHIS2. (integrating our own app with open source app)
- Learned to use Git as version control system for the development, enabling synchronization and coordination of source code.
- Gained experience in using HTML5, JavaScript, AJAX, JSON, jQuery and CSS3 to make web apps.
How we have divided tasks within the group
Planning phase
- Figure out how to implement the app, and determine a rough schedule. All members collaborate. The following questions had to be addressed:
- How do we implement the submission form?
- How do we validate the input fields?
- How do we generate a JSON or XML from the form?
- How do we generate and send a message based on contents of the form?
- How do we implement a storage for commodities, or, what database to pull from?
- What commodities exist and which should be accessible to each type of user?
- What types of users/roles exist in the DHIS2 universe?
- How do we implement the submission form?
Requirements Phase
- Establish requirements. All members collaborated; Thomas documented them.
Design Phase
- Determine app architecture, and interface layout. All members collaborated.
Implementation phase
- UI layout and design in HTML and CSS (Jørgen).
- Interface to DHIS2 web api (Simen and Thomas).
- Messaging (Everyone).
- Form validation (Simen).
Screenshots and screen flows