Description
As the TMC, the ODE needs to have the full functionality to manage the deletion and placement of TIMs within an RSU, enabling the RSUs to hold multiple TIM messages at the same time.
CONVERSATION
Result of the following issue: https://github.com/usdot-jpo-ode/jpo-ode/issues/117
Features needed:
- SNMP query of the RSU to view existing TIM index sets
- Updated field in POST TIM message that includes an index on the RSU to place the TIM message (need index range)
- DELETE API call to remove TIM messages at a specific index on an RSU
USER ACCEPTANCE CRITERIA
( ) Query an RSU to view all current TIMs that are active (including the TIM index set on the RSU)
( ) TIM REST call to the ODE to include an index for the TIM.
( ) REST call to the ODE to delete a TIM from an RSU(s).
BUSINESS VALUE
In order to fully manage TIM messages on an RSU, there needs some additional CRUD API Calls to manage the index location of a TIM message and deleting existing messages.
DESCRIPTION
User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:
As a < type of user >, I want < some goal > so that < some reason >.
CONVERSATION
This space is commonly used to provide the team with any additional resources or notes that may help in the development of the story. Oftentimes, we've used this space to highlight and specific technical considerations or features that need to be included with the story.
USER ACCEPTANCE CRITERIA
Acceptance Criteria are a set of statements, each with a clear pass/fail result, that specify both functional (e.g., minimal marketable functionality) and non-functional (e.g., minimal quality) requirements applicable at the current stage of project integration. These requirements represent “conditions of satisfaction.” There is no partial acceptance: either a criterion is met or it is not.
These criteria define the boundaries and parameters of a User Story/feature and determine when a story is completed and working as expected. They add certainty to what the team is building.
Acceptance Criteria must be expressed clearly, in simple language the customer would use, just like the User Story, without ambiguity as to what the expected outcome is: what is acceptable and what is not acceptable. They must be testable: easily translated into one or more manual/automated test cases.
Acceptance Criteria may reference what is in the project’s other User Stories or design documents to provide details, but should not be a re-hash of them. They should be relatively high-level while still providing enough detail to be useful. They should include:
- Functional Criteria: Identify specific user tasks, functions or business processes that must be in place. A functional criterion might be “A user is able to access a list of available reports.” A non-functional criterion might be “Edit buttons and Workflow buttons comply with the Site Button Design.”
- Non-functional Criteria: Identify specific non-functional conditions the implementation must meet, such as design elements. A non-functional criterion might be “Edit buttons and Workflow buttons comply with the Site Button Design.”
- Performance Criteria: If specific performance is critical to the acceptance of a user story, it should be included. This is often measured as a response time, and should be spelled out as a threshold such as “
BUSINESS VALUE
Provide a clear business value description for the feature being developed. This should present a clear value add to the end user and justifies the reason for developing the feature.
DEFINITION OF DONE
( ) User acceptance criteria in the user story has been met; this includes user acceptance testing,
...