Jump to: navigation, search

Difference between revisions of "MappingOfUseCasesFeaturesRequirementsAndUserStories"

Line 23: Line 23:
==Mapping of all of these==
==Mapping of all of these==
This section shows which MVP User Stories are implementing the specific Requirements

Revision as of 14:52, 26 November 2018

Mapping of Use Cases, Features, Requirements and User Stories


OpenStack Edge Computing Group (ECG) is a collaboration between several actors and it works on the complex problems of edge computing. As a result of this setup the group uses different places and different terms to describe requirements to he different levels of the edge cloud problem domain. This page collects all the different used levels and makes an attempt to describe a linkage between them.

Requirement types


These are high level features of an edge cloud infrastructure described in a way, that they do not assume any technology details on the implementation. These Features are first developed by the FEMDC SIG and were agreed on and after the Dublin PTG Edge Workshop.


Requirements of edge cloud implementations based on the Features with an attempt to identify the components within the edge cloud instances.

Use Cases

ECG have a Subgroup to define Use Cases. These use cases are high level business driven Use Cases for the whole edge cloud infrastructure. They describe a problem what could be solved using edge cloud infrastructure without providing any solution proposals.

MVP User Stories

During the 2nd Denver PTG we got the feedback that it would be nice to have an architecture description for a Minimum Viable Product (MVP) edge architecture. This is an architecture which implements no more, than the very basic requirements of an edge cloud architecture. We were lucky to have the Oath team in the room who shared their edge cloud design with us. We agreed to use this as the first MVP architecture. This MVP architecture takes the existing OpenStack as a basis and defines some requirements to specific OpenStack projects. These requirements are formulated as User Stories, therefore we call them MVP User Stories.

Relationship of all of these

In an ideal world it would look like this: RequirementTypeRelations.png

(For some reasons I was not able to upload the pptx source of this figure to here, so if anyone would like to make modifications on it I'm (csatari) happy to email it over.)

Mapping of all of these


This section shows which MVP User Stories are implementing the specific Requirements