# Agile Service Engineering in the Industrial Internet of Things
## 3 SERVUS Methodology
### D1: Analysis and Design Artefacts
#### Relations between the SERVUS Meta-Model Elements  
There are the relations between the SERVUS meta-model element types: user stories (US), use cases (UC) are linked to actors, to other use cases, to test cases (TC), to requirements (REQ), and information resources (IR). These relations are illustrated in Figure 3 and are explained below.  
* US to Actor
* tells (inverse relation: is told by): a US is told from the viewpoint of an actor.
* US to UC
* motivates (inverse relation: is motivated by): a US motivates the description of functional requirements in the form of use cases (UC).
* UC to Actor
* performs (inverse relation: is performed by): a UC is initiated and performed by an actor.
* UC to UC
* includes (inverse relation: is included in): one UC is included in another UC, i.e., one UC is included as a whole in the main success scenario, extension, or alternate path of another UC.
* refines (inverse relation: abstracted from): one UC is a refinement of another UC, e.g., it provides more details in its main success scenario, adds an extension or interprets a more abstract UC in the context of a thematic domain.
* UC to TC
* is tested by (inverse relation: tests): one UC may be tested by one or more test cases. One test case may also be linked to several use cases (which are then included in each other).
* UC to REQ
* maps to (inverse relation: is derived from): a UC is mapped to one or more requirements. This means that the system under design should provide function (may be in terms of a Web service) that fulfills each requirement.
* related to (bijective relation): one REQ is related to another REQ, i.e., there is some relationship between the requirements. This relation has to be qualified in the comments. It could be a unilateral or bilateral dependency but also some similarity in terms of concepts, design pattern or technology.
* REQ to CAP
* implemented by (inverse relation: implements): one REQ is implemented by one or more CAPs. This relation has to be better qualified in the future. It could be a unilateral or bilateral dependency but also some similarity in terms of concepts, design pattern, or technology.
* UC to IR
* requests (inverse relation: is requested by): a UC requests an information resource in a defined access mode (create, read, update, delete).
* CAP to TECH
* realized by (inverse relation: realizes): a capability is realized by a combination of technologies whereby the combination may be specified by simple Boolean expression.
* TECH to TECH
* belongs to (inverse relation: comprises): a technology/product may belong to another technology/products. This relationship allows the user to express structured technologies/products.
* IR to IR
* refines (inverse relation: abstracted from): an information resource is a refinement of another information resource (in the sense of inheriting all properties of the more abstract information resource).
* related to (bijective relation): an information resource is related to another information resource. The meaning of the relation may be defined during the information modelling design step.  
Figure 3: Relations between the major SERVUS meta-model elements.  
An important aspect of the requirements and system analysis phase is the agreement upon the terms that are being used by both the end users and the software architects. Very often, these terms are being captured during the analysis phase in a glossary. The SERVUS methodology foresees linking the terms being used in the SERVUS elements to concepts described in a glossary, or formally defined in an ontology. The linkage is also called semantic annotation.