Requirements Specifications of the Horizontal Industrial Use Case

8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case

1/218

Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case1 / 218

Requirements Specificationof the

Industrial Case

Horizontal

www.iks-projec

t.eu

Interactive Knowledge Stack for SemanticContent Management Systems

Deliverable: 2.2 Requirements Specification for the Horizontal Industrial Case

Delivery Date: 28th Febuary 2010

Author(s): Fabian Christ, Gregor Engels, Stefan Sauer, Gokce B. Laleci, Erdem Alpay,Tuncay Namli, Ali Anil Sinaci, Fulya Tuncer

Filename: iks-d22-reqspec_hor_case-20100301.doc

Publication Level: Public

Web link: http://www.iks-project.eu/iks-story/documentation


2/218


Table of Contents

Document History .................................................................................................................. 3DocumentInformation........................................................................................................... 41 Executive Summary......................................................................................................... 52 IKS in a Nutshell............................................................................................................... 63 Methodology..................................................................................................................... 74 Results overview.............................................................................................................. 85 Document structure and concepts............................................................................... 116 Requirements specification process ........................................................................... 14

6.1 Existing CMS....................................................................................................... 146.2 Statements from industrial partners..................................................................... 186.3 Defining high level requirements ......................................................................... 186.4 The refinement process....................................................................................... 19

7 Actors.............................................................................................................................. 218 High Level Requirements.............................................................................................. 24

8.1 Architecture and integration (HLR-2202)............................................................. 248.2 Common vocabulary (HLR-2201)........................................................................ 518.3 Semantic lifting & tagging (HLR-2203) ................................................................ 678.4 Semantic search & semantic query (HLR-2204) ................................................. 868.5 Reasoning on content items (HLR-2205) .......................................................... 1248.6 Links/relations among content items (HLR-2206) ............................................. 1308.7

Workflows (HLR-2207) ...................................................................................... 149

8.8 Change management, versions and audit (HLR-2208) ..................................... 159

This document contains material, which is the copyright of certain IKS consor-tium parties, and may not be reproduced or copied without permission. Thecommercial use of any information contained in this document may require alicense from the proprietor of that information. Neither the IKS consortium as awhole, nor a certain party of the IKS consortium warrant that the informationcontained in this document is capable of use, nor that use of the information isfree from risk, and accepts no liability for loss or damage suffered by any per-son using this information.

Neither the European Commission, nor any person acting on behalf of theCommission, is responsible for any use which might be made of the informationin this document.

The views expressed in this document are those of the authors and do not ne-cessarily reflect the policies of the European Commission.

IKS is co-funded by the EuropeanUnion and develops technology forintelligent content management

Notice

Copyright


3/218


8.9 Multilingualism (HLR-2209) ............................................................................... 1738.10 Security (HLR-2211).......................................................................................... 181

9 Summary....................................................................................................................... 19210 References.................................................................................................................. 19311 Annex .......................................................................................................................... 194

11.1 Original statements from industrial partners...................................................... 19411.2 Requirements traceability matrix ....................................................................... 195

Document History

Version Name Date Remark

1 Fabian Christ 2009-07-14 Initial version

2 Gokce B. Laleci 2009-07-17 Updates (HLR-1,3,5)

3 Fabian Christ 2009-07-17 Updates (Actors, HLR-2,4)

4 Gokce B. Laleci 2009-08-06 Updates (Actors, HLR-1,3,5)

5 Fabian Christ 2009-08-06 Updates (Actors, HLR-4,6)

6 Fabian Christ 2009-08-14 Updates (HLR-6)

7 Fabian Christ 2009-08-23 Extended scenarios for HLR-4

8 Fabian Christ 2009-09-18 Updated HLR-2 according to comments on mailinglist

9 Fabian Christ 2009-09-23 Update of HLR-4 according to comments andchanges in HLR-2

10 Fulya Tuncer 2009-09-25 Updates HLR-1,3,5

11 Fabian Christ 2009-10-05 Updated actors and HLR-2

12 Fabian Christ 2009-10-09 Added HLR-011

13 Fabian Christ 2009-11-02 Added scenarios and use cases to HLR-011

14 Fabian Christ 2009-11-04 Added HLR-007

15 Fabian Christ 2009-11-09 Updated HLR-2,4,6,7,11

16 Fulya Tuncer 2009-11-09 Updated HLR-1,3,5,8,9,10

17 Fabian Christ 2009-11-20 New TOC structure; Updated actors; UpdatedHLR-4

18 Fabian Christ 2009-11-27 Renamed and updated HLR-2,4,6,7,11 and actors

19 Fabian Christ 2009-11-30 Added activity diagrams, completed use cases forHLR-2,4,6,7,11

20 Fabian Christ 2009-12-01 Edited resulting requirements of HLR-2.4.6.7.11

21 Fulya Tuncer 2009-12-06 Added executive summary, introduction,description of work, requirements traceability ma-trix

22 Fabian Christ 2009-12-07 Finished online document (HTML version)


4/218


23 Fabian Christ 2009-12-11 First draft with results from online document.

24 Fulya TuncerFabian Christ

2009-12-18 Integrated changes from first review

25 Erdem Alpay 2010-02-05 ToDos according to Quality Assurance Feedback

26 Fabian Christ 2010-02-15 Merged ToDos from SRDC and UPB

27 Fulya Tuncer 2010-02-19 Edited use case and activity diagrams

28 Fabian Christ 2010-03-01 Final minor changes

29 Andreas GruberWernher Behrendt

2010-03-04 Final version to be submitted

DocumentInformation

Item Value

Identifier IKS-231527-Deliverable2.2-2009

Author(s): Fabian Christ, Gregor Engels, Stefan Sauer (s-lab, Universityof Paderborn), Gokce B. Laleci, Erdem Alpay, Tuncay Namli,Ali Anil Sinaci, Fulya Tuncer (Software Research, Develop-ment and Consultation Ltd. SRDC Ltd.)

Document title: IKS Deliverable D2.2 Report:Requirements Specification for the Horizontal IndustrialCase

Source Filename: iks-d22-reqspec_hor_case-20100301.doc

Actual Distribution level Public

Document context information

Project (Title/Number) Interactive Knowledge FP7 231527

Work package / Task WP2 / T2.2

Responsible person andproject partner:

Fabian Christ,s-lab - Software Quality Lab, University of Paderborn

Quality Assurance / Review

Name / QA / Release /Comment

Alessandra Bagnato (TXT)Andreas Gruber (SRFG)Gregor Engels (UPB)

Citation information

Official citation Fabian Christ, Gregor Engels, Stefan Sauer, Gokce B. Laleci,Erdem Alpay, Tuncay Namli, Ali Anil Sinaci, Fulya Tuncer,2009: IKS Deliverable. D2.2 Report:Requirements Specification for the Horizontal Industrial Case


5/218


1 Executive Summary

The objective of this deliverable is to provide requirements for the specification for horizontalindustrial use cases. The horizontal industrial use case addresses the set of semantic en-hancements provided by IKS that could be used by any CMS system, i.e. semantic en-hancements that do not address a specific vertical business domain. In order to identifythese requirements, we applied a requirements elicitation methodology that is grounded insoftware engineering processes. We first gathered business scenarios from industrial part-ners of the IKS project to understand their expectations from a semantically enhanced Con-tent Management System. Furthermore, the existing CMSs of Day, Nuxeo, Alkacon and TXTwere analyzed. In addition to these, a "Brainstorming Session on Requirements for SemanticCMS" was conducted in the first IKS Workshop where CMS vendors from outside the IKSconsortium also attended. In this session, the CMS Vendors presented their expectationsfrom a semantically enriched CMS. By consolidating the results of these activities, we cre-

ated the wish list from CMS Developers for a semantically enriched CMS. The items of thewish list were grouped and ten high level requirements were identified. These high level re-quirements are as follows:

Common vocabulary (HLR-2201)

Architecture and integration (HLR-2202)

Semantic lifting & tagging (HLR-2203)

Semantic search & semantic query (HLR-2204)

Reasoning on content items (HLR-2205)

Links/relations among content items (HLR-2206)

Workflows (HLR-2207)

Change management, versions and audit (HLR-2208)

Multilingualism (HLR-2209)

Security (HLR-2211)

The high level requirements are refined into use-cases (Section 0). These use-cases can befurther grouped in to classes according to the dominant actors perspective. This groupingcan also be applied to HLRs, e.g. HLR-2203, HLR-2204, HLR-2206, and HLR-2209, arequalified as use cases with a perspective of the CMS user, while HLR-2201, HLR-2205,HLR-2207, and HLR-2208 are qualified as use cases from a point of view of CMS admin andHLR-2202 is qualified from a point of view of CMS developer. Finally HLR-2211 addresses

the needs of nearly all actors. The various actors of the IKS system and their relations be-tween each other are described in Section 7. In short, the main actor of the system is theCMS user, which is the common super actor for all specialized actors that are CMS users butalso have specialized roles such as a content consumer or a content creator and developer,which can also be specialized such as IKS developer and CMS developer. As a result, in thisdeliverable we suggest requirements for the development and evaluation of the IKS systemfor horizontal use cases from the point of view of different actors that interact with the sys-tem. The resulting high-level requirements are compiled in Section 11.2.

The deliverable is structured as follows. First, we introduce the IKS project and the objectivesof this deliverable. Then, the objectives of the task 2.2 in the project, the requirements gath-ering process, and the concepts of the document are discussed. Afterwards, the details of

concepts used for defining IKS actors and high-level requirements are presented. Finally, weconclude this deliverable with a summary and a requirements traceability matrix.


6/218


2 IKS in a Nutshell

Interactive Knowledge Stack (IKS) is an integrating project targeting small to medium Con-tent Management Systems (CMS) providers in Europe. These firms are providing technology

platforms for content and knowledge management to thousands of end user organizations.Current CMS technology platforms lack the capability for semantic web enabled, intelligentcontent, and therefore lack the capacity for users1 to interact with the content at the usersknowledge level. The objective of IKS is to bring semantic capabilities to current CMSframeworks. IKS puts forward the Semantic CMS Technology Stack which merges the ad-vances in semantic web infrastructure and services with CMS industry needs of coherent ar-chitectures that fit into existing technology landscapes. IKS will provide the specifications andat least one Open Source Reference Implementation of the full IKS Stack.

A rough overview of the stack is shown in Figure 2.1, which identifies the IKS layers thatintroduce semantic capability to CMSs. Hence, the grand vision of future CMSs is to havesemantically enriched content that can interoperate in a flexible and semantically meaningful

way. The vision for gathering requirements for horizontal business cases in this deliverable isto identify where semantic technology will make a difference to knowledge- and contentmanagement systems which can be utilized in generic and horizontal industry applications.

Figure 2.1 Layers of the IKS Stack

IKS will show that the semantically enhanced stack is generic enough to be used in morethan one solution context and domain, with little adaptation. These will be demonstrated inthe "Horizontal Industrial Case" within the scope of IKS project.

1In this document, the term user refers to organisations using CMSs, content consumers, CMS devel-opers, authors or administrators of CMSs


7/218


The aim of this deliverable is to define the domain-independent requirement specificationswhich will apply to all horizontal applications that are based on semantically enhanced CMSvia IKS. The requirement specification from a software engineering perspective across thewhole stack is provided in this deliverable.

The requirement specification document for the horizontal industrial use case is the targetdeliverable of task 2.2. Requirements are a description of how a system should behave andwhat an application is expected to do as well as a description of system properties and at-tributes, thus determining the qualitative and quantitative characteristics of the system fromthe perspective of the CMS developer and user.

The requirements engineering process covers the complex task of eliciting and documentingthe requirements of the customer and all potential users, modelling and analyzing these re-quirements and documenting them as a basis for system design.

Task 2.2 covers both the analysis and the recording of the requirements. And the objective isthen to make sure we have well formed, and well written business and system requirementsthat everyone has agreed to for horizontal use cases design and implementation that will beperformed in task 4.2 (Design and Implementation). Thus the requirements specification iscritical to the entire software development life cycle. It serves not only as the referencedocument for the system design specification but also as the base document for generatingthe validation and acceptance tests.

To achieve this aim, first the needs of horizontal frameworks are elicited from businesscases, which covers the requirements of the different sectors. Then, the specification of thebehavior of the system to be developed is provided with a complete description, which in-cludes a set of use cases that describe all the interactions the users will have with the IKS.Finally the resulting functional and non-functional requirements are identified.

As a result of this task, industrial partners of the IKS project will be able to test the softwareplatforms of NUXEO, DAY and TXT with respect to their relative coverage of the IKS and atthe same time will be able to demonstrate how IKS can be utilized to develop semantically

enhanced horizontal applications.

3 Methodology

The IKS project develops and demonstrates the use of semantically enhanced CMS whichallow new forms of interaction with knowledge rich content. To validate the IKS prototype so-lutions four industrial use cases have been predefined, two more are outlined, and severalothers will be chosen in the later stages of the project.

One of the predefined use cases is has a visionary bias showing how the field of CMS maybe influenced and changed through the vision of ambient intelligence. The second looks at

the requirements in an area where a very rich knowledge domain is combined with CMS ofarbitrary richness in media. The application domain of the second use case is project control-ling, and as a demonstration of this, a knowledge-based "project-controlling system" will beanalysed, designed and built.

One of the outlined use cases looks at requirements from a vertical use case provided byPisano/CIC who are active in the portal market for travel agencies and who are interested incombining their CMS with recommender systems - another example for a CMS providermoving towards added value through "intelligent content". In contrast, the other outlined usecase looks at a horizontal use case from NUXEO and Day Software. These firms are enduser-oriented CMS providers with a "horizontally placed" CMS framework. The use case isnot fixed w.r.t an actual target application, but has a broad range of functionality where theset of generic functions needed in the IKS, at each of the layers can be studied.


8/218


The requirements of all of these use cases will be elaborated within the scope of work pack-age two (WP2). It aims at providing real-world requirements for use cases as witnessed byindustrial partners. This deliverable is the target outcome of task 2.2.

Parallel to the work in this task, the industrial partners use their existing frameworks and ap-

plications to perform the benchmark exercise as part of task 2.1. This exercise is used toanalyse the current level of achievement with respect to semantic capabilities. Additionally,IT executives of CMS provider firms were interviewed in order to capture their requirements.While consolidating these requirements, fifteen in-depth interviews with IT executives of CMSprovider firms where performed and feedback from six industry partners was gathered. Theresult were 131 requirements which can be grouped under eleven major topics as follows:

Interoperability (e.g., CMIS)

Enrichment of Content

Enhanced Search Functionality

Intuitive User interface

Performance

Personalization

Flexible Data Modelling

Flexible Workflow Modelling

Support for Content Creation

Multi-channel Access to Content

Offline Work Support

Most of the above requirements overlap with the high level requirements that we addressed

in this deliverable (see section 0). Since one of the aims of this deliverable is to find out ge-neric requirements of horizontal uses cases, it is a way to validate that the resulting require-ments of the horizontal industrial use cases are a part of the requirements of IT executives ofthe fifteen different CMS provider firms.

4 Results overview

The horizontal industrial use case focuses on the reuse of IKS in several different busi-ness domains. Whether IKS is used to enrich a tourist information CMS with semantic fea-tures or a health care CMS should not make any difference to IKS. The IKS must be awareof being integrated in CMS of such different domains. This horizontal industrial use case de-

scribes the common features which have to be provided by the IKS to ensure impact of thesemantic features for all CMS business domains. To ensure this level of impact we gatheredinput from the industrial partners of the IKS consortium during a requirements workshop.

A first result of the work in task 2.2 was the design and setup of the requirements engineer-ing process which is reflected in the structure of this document. Starting from high level re-quirements (HLR) which were formulated by the industrial partners we set up a systematicapproach to refine these HLR into specific software requirements using scenario and usecase descriptions. This approach ensures the traceability of each software requirement to aHLR which was formulated by the industrial partners. Details of this process are described insection 6.

All requirements are based on use cases which use a common actor's model for CMS. This

actors model, described in section 7, is one important result of task 2.2, because this modelis the basis for the communication inside the consortium about different use cases and whichactors are involved.


9/218


Another major result concerns the requirements for an IKS architecture. An important issuefor all industrial partners was the claim for an easy to use and technology independentmechanism for integrating the IKS into their existing CMS. The industrial partners suggestedto use some kind of RESTful HTTP interfaces to connect CMS and IKS. This requirementwas reflected in section 8.1 of this specification. All IKS features are expressed in terms ofservices which can be accessed by any CMS. These services can be reused to create newhigher-order services, the IKS can be extended by new services for semantic features, andservices can be replaced. This setup allows a modular development of the IKS and enoughflexibility to experiment with different implementations of semantic services. Additionally,each service is required to define further extension points to allow fine grained customizationof all semantic features.

All further requirements are based on or related to, the architectural requirements. These re-quirements form the basis for all semantic features the IKS should provide and thereforemust be considered by all IKS features. The architectural requirements are of such import-ance because all involved industrial partners stress the point of easy interoperability with IKSwith a minimum of technological dependencies. To ensure the impact of IKS on the whole in-

dustry of CMS providers this requirement is essential.Based on the architecture requirements nine HLRs were identified. Each HLR focuses on aspecific aspect, which is of importance for all CMS vendors and therefore relevant for thehorizontal industrial case. Each HLR is refined using the mentioned requirements engineer-ing process, so that each HLR is the root for a set of requirements which should be reflectedin the design of the IKS. This document defines about 200 requirements which result fromthe ten HLRs and their use cases. Implementations of IKS compliant systems will be bench-marked according to these requirements.

At first, we identified the requirement of defining a common vocabulary (HLR-2201, Section8.2) to standardize the terminology inside a CMS. This ensures a common language for allsemantic features of IKS and guarantees that different heterogeneous CMS have the same

understanding of the features.Content without any semantic meta-information must benefit from the semantic features ofthe IKS as new semantically enriched content will. The HLR semantic lifting & tagging (HLR-2203, Section 8.3) focuses on the fact that in each CMS, regardless of its domain, contentwill exist which has to be lifted with semantic information. Tagging is one technique toachieve this but IKS should be able to support further techniques.

The need for new approaches is also present for semantic search & semantic query (HLR-2204, Section 8.4) which is another key requirement for the IKS. Industrial partners of alldomains were focused on the ability to provide better search results for their content assearching is a standard feature in all CMS. This would improve the systems of all industrialpartners and strengthen their capability to manage content und make it more findable.

Another section of requirements addresses the need for combining content automatically.Both reasoning on content items (HLR-2205, Section 8.5) and the automatic creation oflinks/relations among content items (HLR-2206, Section 8.6) treat this aspect and define re-quirements which must be addressed to support such a feature. Again, this functionality is ofimportance for all domains because it offers the capability of generating an added value byre-combining already existent content.

Each CMS provides mechanisms to represent and manage the workflows (HLR-2207, Sec-tion 8.7) of content and to support tasks like change management, versions and audit (HLR-2208, Section 0). These basic features also need to be updated with a semantic view at thecontent because new semantic features which operate on the content require new solutions,e.g. for change management. The handling of content workflows can be redesigned by usingthe semantic information associated with the content. Semantic information can be used e.g.

to determine the current state of a specific content in a given workflow. Even the workflow


10/218


can be expressed in a semantic way which enables the CMS to provide a very flexible wayfor defining them.

Content in large CMS is created in many different languages, so that all IKS semantic featureshould be aware of multilingualism (HLR-2209, Section 8.9) of its users and the content. Ide-

ally, the semantic features are able to operate regardless of the language of the content.Practically, some features will be language based and therefore will not work for all lan-guages. Other features have to be adjusted to the language currently in use. A key require-ment is to detect the current language in a first step and then adjust the semantic features ina second step.

When content is enriched with such new features of the different HLRs the security (HLR-2211, Section 8.10) of accessing the content and its use must be reconsidered. Without theuse of semantic features the access to content was often restricted by flags like "read-only"or "no-deletion". The use of semantic features requires new flags like "reasoning-allowed" or"linkable-with" to define which semantic operation may be performed on the content. Thistopic becomes even more important w.r.t. privacy or copyrights of content.All these HLRs were identified as being of importance for the horizontal industrial case as

they are independent of any domain or technology. The IKS has to address all of these HLRsbut may focus on specific aspects in different releases as the IKS stack is evolving.


11/218


5 Document structure and concepts

This document is structured according to the requirements specification process, which isdescribed in section 6, and the IEEE-830 standard for recommended practice for softwarerequirements specifications [IEEE830].

We will start by describing the process to define the requirements for the horizontal industrialcase, and then go on with the model of actors which will interact with the system. Afterwardswe will proceed with the refinement description of all high level requirements that were identi-fied for the horizontal use case. Each high level refinement description consists of scenariodescriptions, use case descriptions, and the description of the resulting requirements.

A high level refinement description starts with meta-data about the high level requirement.This is done in tabular form using the following fields.

HLR IDA unique identifier that represents the HLR. The pattern for this ID is "HLR-"[TTNN],where TT is the number of the work package task and NN is a sequential number. Ex-ample: HLR-2202 = HLR of task 2.2 with number 02.

NameA name of the HLR

DescriptionA textual description of the main aspects of the HLR

ClassificationA classification of the HLR using the following categories:

o Cross cutting / non-cross cuttingThis category is used to distinguish between HLR that have a cross cutting impacton all other HLR, e.g. security, and HLR that describe a single functionality, e.g.search.

o Horizontal / VerticalThis category is used to distinguish between HLR that are relevant for the horizon-tal industrial case or not. In this specification we used horizontal HLRs only.

Related HLRIf a HLR is related to other HLRs, the IDs of the other HLRs can be listed here.

StatementsLists all related statements from the industrial partners, that have influenced the HLR.

After defining the meta information the refinement process starts by describing user scen-arios. These scenarios reflect the existing needs and are the basis for the definition of moreconcrete use cases that should be implemented. Scenarios are free textual descriptions.

To formalize the content of the described scenarios actors and use cases are extracted. Ac-tors and use cases are modeled using UML use case diagrams [UML]. To express more de-

tails about the activities of an use case we optionally used UML activity diagrams [UML]

additionally. Beside the UML diagrams each use case is described in tabular form. These ta-bles consist of the following information:

Use Case IDA unique ID to identify the use case. The pattern for this ID is "UC-"[HHHHNN], where

HHHH is the four digit number of the HLR and NN is a sequential number. Example:UC-220223 = use case for HLR-2202 with number 23.


12/218


DescriptionA textual description of the use case.

Relationships to other use cases like

o InheritanceThe general use case is referred to as the "parent" use case.

o IncludeDuring the execution of one use case the imported use case is invoked.

o ExtensionA use case invokes its extended use cases when the trigger for the specified ex-tension is true.

ScopeThe abstract scope of the use case to make it easier for a reader understand the contextof this use case. It specifies the parts of IKS system that are involved in the use cases.

Actor(s)The involved actors of the use case.

GoalThe goal that has to be reached by performing the use case.

TriggerThe trigger of the use case to express which action must take place to trigger this usecase.

FrequencyThe frequency in which the use case is triggered.

Beside these information the refinement process offers the opportunity to add more optional

details. These information are optional, because in the early phases of the IKS project manydetails of the requirements, like exact pre- and postconditions are not available. Especiallydetails that require knowledge about the design of the IKS are not available in the phase oftask 2.2. More details and further requirements will be added during the design phase of theIKS. Therefore the following fields are optional fields in the use case descriptions of task 2.2.

ActionAn UML activity diagram that expresses a process of activities that are involved when theuse case is executed. This is often used to clarify the relationship of use cases in a pro-cess view.

PreconditionsPreconditions express a set of conditions that have to be fulfilled before the use case can

be executed. Minimal Postconditions

The minimal postconditions are conditions that at least have to be fulfilled after the usecase was executed. In particular the minimal postconditions have to be fulfilled when theuse case was executed with errors or exceptions.

Success PostconditionsThe success postconditions must be fulfilled when the use case was executed withoutany errors or exceptions. These conditions express the normal case of the use caseexecution.

Main FlowThe main flow describes the process that is performed within the use case. This can be

used to describe the internals of a use case more precisely. This is a narrative based ac-tion step to achieve the goal of the use case.


13/218


ExceptionsExceptions describe situations where the use case execution makes an exception to thenormal behavior that may be described by the main flow.

Open Issues

Open issues can be used to clarify that the use case description leaves out some pointsthat are open or cannot be answered at this stage. The reader gets a hint that thesepoints should be considered in another phase of the development process.

In the end we give a summary of the identified resulting requirements and provide require-ment overviews like a requirements traceability matrix and final listings of all requirements.The resulting requirements are formulated as single testable statements. The formulation iskey word based according to [RFC2119]:

1. MUSTThis word, or the terms "REQUIRED" or "SHALL", mean that the definition is anabsolute requirement of the specification.

2. MUST NOTThis phrase, or the phrase "SHALL NOT", mean that the definition is an absoluteprohibition of the specification.

3. SHOULDThis word, or the adjective "RECOMMENDED", mean that there may exist validreasons in particular circumstances to ignore a particular item, but the full implicationsmust be understood and carefully weighed before choosing a different course.

4. SHOULD NOTThis phrase, or the phrase "NOT RECOMMENDED" mean that there may exist validreasons in particular circumstances when the particular behavior is acceptable oreven useful, but the full implications should be understood and the case carefully

weighed before implementing any behavior described with this label.Requirements are classified in five different categories:

Functional requirementsFunctional requirements are requirements that express required functionality that cannotbe classified as data, interface, or integration requirement.

Data requirementsData requirements are requirements that focus on the transported or handled data andtheir format.

Interface requirementsInterface requirements specify requirements for the provided and requested interfaces ofa system.

Integration requirementsIntegration requirements are requirements that affect the capability of the system (theIKS) to integrate with other systems (CMS).

Non-functional requirementsNon-functional requirements are requirements that affect properties like usability, relia-bility, performance, or supportability.


14/218


6 Requirements specification process

We used two approaches to gather requirements:

Existing CMSWe examined the architectures and features of existing CMS from Alkacon, Day, Nuxeo,and TXT (see section 6.1).

Statements from industrial partnersWe used statements from the industrial partners (see section 6.2) that were collectedduring a workshop where industrial partners were asked to brainstorm about require-ments for the IKS.

After the first phase of gathering requirements we were able to specify a set of high level re-quirements (see section 6.3) that were refined using a defined requirements refinement pro-cess (see section 6.4).

6.1 Existing CMS

Our first step was to examine the existing CMS of our industrial partners, namely Alkacon,Day, Nuxeo, and TXT. The goal was to identify the commons parts that all these CMS have.These common parts are the basis for our work on requirements for the horizontal industrialcase, because the IKS has to support this case by providing features and mechanisms thatallow easy use and integration for existing CMS.

Our input were product descriptions, slides from the industrial partners about their expecta-tions on the IKS with respect to their own product, the product web-sites, and the runningCMS itself. The goal was to identify similarities, common use cases, and needs that all in-

dustrial partners share.In the following sub-section we describe the results of this analysis.

6.1.1 Managed content

At first we investigated the types of content that a CMS should be able to handle. Not eachsystem can handle all of them, some are specialized to some content types, but the IKSshould be prepared that all types of content are supported. The analysis yields the followinglist of content types.

Documents (office)

Web sites / web applications

Multi-Media files (audio, image, video)

Individuals (social networking)

Postings + Comments (blogs, forums)

Short messages (sms, twitter)

Topics (wiki)

Correspondence (e-mail, newsletter)

Feeds (rss)


15/218


6.1.2 Content workflow

The next analysis step was a closer look at the content workflow that all reviewed CMS de-pend on. At first we extracted the common content workflow from content creation to publish-

ing that is depicted in the next figure.

Figure 6.1 From content creation to publishing

The first two phases were not in the focus of the industrial partners, because the main inno-

vations from the IKS are expected to take place in the phases enrichment, storage, andpub-lishing. The result of this analysis was a list of needs grouped by the corresponding contentworkflow phases.

Semantic enrichment needs

o Automatic classification and routing

o Faceted classification

o Use of predefined taxonomies

o Automatic semantic tagging

o Automatic ranking

o Semi-automatic annotations

o Annotation with Microformats

o Ontology extraction

o Concepts, people, places, etc. extraction

o Relationship extraction (isA, partOf)

o Cross-Source correlations

o Document models from ontologies

o Knowledge representation

Persistence needs

o Workflow states

o Relations

o Directories

o Audit

o User preferences

o Converted content

o Synchronization of Content Repository Semantics with Semantic Persistence

Stores

Publishing needs


16/218


o Semantic workflows

o Collaborative content management with semantic and social techniques

o Personalisation of UI

o Knowledge view / administrationAnother workflow that was focused is the search functionality.

Figure 6.2 Search

Search needs

o Pluggable external semantic search

o Ambiguity resolution

o

Similarity searches semantic based and multilingualo Relationship recognition

o Keyword search

o Natural language queries

o Ranked search results

o Faceted Search

6.1.3 Existing content services

After identifying the needs of the industrial partners, we had a closer look at the existing sys-tems. The question was, which component do already exist in such systems. With the know-ledge of existing components we were able to define requirements of the horizontal case withrespect to the existing systems. This aspect was important to ensure that it will be possible tointegrate the IKS and existing CMS. The result is a list of services that are already used inexisting CMS.

Creation / Ingestion

Ingestion Schedules

Transcoding

Indexing

Metadata extraction Storing

Versioning

Audit / Archive

Workflow Management

Publishing

Notification

Search and query

Rendering

User profiles


17/218


Security

Ad service

6.1.4 Architectural view

The last step was an analysis of the architectural styles that the existing CMS use. We exam-ined architecture diagrams and extracted the common aspects that each system was basedon. The result of this analysis is depicted in Figure 6.3.

Figure 6.3: Abstract architectural view on existing CMS

Starting at the bottom each examined CMS consists of a component model that acts as amiddleware for the implementation. All services are created according to the used compo-nent model. A communication bus enables the communication between components and se-curity features are implemented orthogonal to the services. The data is stored in a contentrepository and additional information in a meta-data repository. The repositories are realizedusing some database management system.

At the front end the different CMS support GUI access ranging from web applications that arecontrolled by a browser, over rich client desktop applications to mobile applications, e.g. forsmart phones.

The next question was how new functionality provided by the IKS may be integrated in this

architectural scenario. The idea was to offer a set of semantic services by the IKS, that canbe easily used by a standardized communication protocol. This approach was agreed andsupported by the industrial partners who would like to see simple RESTful [REST] interfacesto these semantic services. The new situation is depicted in Figure 6.4.


18/218


Figure 6.4 Architectural view on existing CMS integrated with IKS semantic services

6.2 Statements from industrial partners

One agenda highlight of the IKS general assembly meeting in Salzburg (May 27-29th, 2009)was a community workshop with a brainstorming session on requirements for semantic CMS.The result of this workshop was a list of statements from the industrial partners that repre-sent their view on a semantic CMS. The industrial partners were asked for features that asemantic CMS should have and that todays CMS system do not provide. The complete list ofthe statements can be found in the annex of this document (see section 11.1).

The resulting list was filtered and used together with the needs from the analysis of existingCMS as the basis for the definition of the high level requirements that are relevant for thehorizontal industrial case. It is valid to use these statements as the basis, because they re-flect the view of the CMS industry and their needs. To gain as much impact as possible in theCMS industry by the implementation of the IKS we have had to focus rather on the industrialneeds than on theoretical thinking.

6.3 Defining high level requirements

The goal of our prior analysis was to have a basis of information that allows us to define a setof high level requirements that can be refined using our requirements refinement process. Ahigh level requirement groups aspects that should be supported by the IKS thematically. Us-ing this grouping strategy we were able to structurize the unstructured wishes and needs ofthe industrial partners and perform a well defined refinement process. This process startsfrom the high level requirements and ends with testable software requirements for the IKS.

Our starting point was a list with 47 statements of our industrial partners plus the compiledneeds from the analysis of existing CMS. The statements and needs were grouped themati-cally and each group made one high level requirement. The result was the following list often high level requirements.





19/218








Security (HLR-2211)

6.4 The refinement process

After defining the ten high level requirements (HLR) each HLR is refined using the followingrefinement process. The process starts with the HLR, produces use cases (UC), and resultsin lists of testable software requirements (R) for the IKS. The following Figure 6.5 depicts therefinement graph as an directed acyclic graph (DAG) that emerges from this process.

Figure 6.5 Refinement DAG, that emerges from the refinement process

The requirements refinement process iterates over all HLRs. For each HLR two refinementsteps are performed. The process is depicted in the next figure.

Figure 6.6 Refinement process from HLRs to resulting requirements

The first refinement is to specify scenarios and to extract and consolidate use cases fromthese scenarios. The result is a set of scenarios and use cases for each HLR. The use case


20/218


consolidation is important to identify relationships between use cases and to keep them con-sistent among each other.

The second refinement step is to extract and consolidate the resulting requirements. Thesoftware requirements result from the use cases, so that each use case relates to one or

more software requirements. A key characteristic of these requirements is their testability.For this the requirements are formulated as simple statements like "The IKS shall be ableto...". This formulation is key word based according to [RFC2119] (see section 4).

The refinement process is implemented as an open participation process that supports con-stant input from the involved industrial partners. The process coordination and consolidationof the input was done by the research partners, who also made proposals for the require-ments based on the input of the industrial partners. To achieve this in a distributed setup ofpartners, the documented results were published online at any time with the opportunity forthe partners to add comments and make further suggestions.


21/218


7 Actors

This section gives an overview of the involved actors. An actor is a role that is associated

with the execution of a use case. Each use case is associated with at least one actor thatdrives the use case. Actors can be human users that interact with the system or technical ac-tors like a service that performs a use case.

Actors can be refined to express that one actor is a specialized role of another actor. For ex-ample, the actorCMS useris the common super actor for all specialized actors that are CMSusers but also have specialized roles like a content consumer or a content creator. Figure 7.1gives an overview of all used actors and their relationships.

Figure 7.1 Actors overview


22/218


Actor Shortname

Description

CMS CMS The CMS actor controls all use cases that are automatically

executed inside the traditional CMS system. From the viewpointof the IKS the CMS actor is technically a consumer that sendsqueries to the IKS and its services.

IKS IKS The IKSactor controls all non user driven use cases that are notpart of traditional CMS systems. As the IKS will be some kind ofservice broker this actor is used for use cases that are not han-dled by a specific service.

IKS Service IKS Service The IKS consists of different services. All use cases that arehandled by a specific service are associated with the IKS ser-vice actor.

CMSUser

CMS User The abstract CMS Useris the parent actor of all specialised us-ers. So each use case that is associated with the abstract CMSUser can be executed by any specialised actor which usesfeatures of either CMS or IKS. It may be one of Consumers,Managers or Creators.

Content con-sumer

Consumer If no specific content consumer is considered we use this moreabstract Consumeractor. The abstract Consumer is the parentactor of all specialised consumers. So each use case that is as-sociated with the abstract Consumer can be executed by anyspecialised consumer actor.

A content consumer does not create content of any kind - aconsumer is rather a read only user of the system. For example,a content consumer can be a web site visitor who reads thecontent published by the CMS or an intranet user who has readaccess to the content of the intranet CMS. Consumers typicallyhave only access to the front end of the CMS with all featuresfor searching, viewing and reading content.

Novice con-tent con-sumer

Novice con-sumer

A novice content consumer is a consumer with little or nodeeper knowledge about underlying technologies or special fea-tures of the system. It is that kind of user that only wants to usethe system quick without a longer learning phase, e.g. first time

consumers. By the time they learn more about the system's fea-tures and use them as advanced consumers.

Advancedcontent con-sumer

Advancedconsumer

An advanced content consumerhas often used the system for alonger period of time and knows all or many of the advancedfeatures that allows him to do his work more efficient. A noviceconsumer in contrast might not be able to do the same task inthe same time and quality as an advanced consumer especiallywhen the task is complex and requires the usage of featuresthat cannot be known by a novice consumer.

Content cre-

ator

Creator When a content consumer is able to create content in some

situations the consumer becomes a content creator for thoseuse cases. By content creation we mean the process of creating


23/218


Actor Shortname

Description

something that is stored in the system and that can be (re)used

by other actors.Typically content creators have access to the back end of theCMS where they have all features for content creation.

Novice con-tent creator

Novice cre-ator

The novice creator is the greenhorn-backend-user of a CMS,who uses only the basic functionality of the CMS backend andneeds often help and advise. On the other hand the novice con-tent creator creates most content elements withouht beeing re-sponsible for the content.

Advancedcontent cre-

ator

Advancedcreator

The advanced creator is the power-backend-user of a CMS,who uses all functionalities of the CMS backend. This actor

manages products, articles, news, and publishes the content.

Contentmanager

Manager The content manageris the super user for content consumptionand creation. The manager knows the CMS in detail and is ableto configure and manage the workflows within the CMS.

Administrator Admin The CMS administratorconfigures and maintains the CMS andthe integrated IKS services. The admin is the power user whoconfigures the used IKS services inside the CMS.

Developer Developer All use cases that handle development or integration tasks areassociacted with some developeractor.

IKS Devel-oper

IKS Devel-oper

The IKS developer is an architect, designer or programmer ofIKS core functionalities.

CMS Devel-oper

CMS De-veloper

A CMS developer is an architect, designer or programmer of aCMS. CMS programmers can customize the IKS as they arespecialized IKS customizers and specialized service customiz-ers.

IKS Custo-mizer

IKS Custo-mizer

The IKS customizeris an architect, designer or programmer thatis able to customize the IKS, e.g. implement a new semanticservice using the IKS infrastructure. The customizer does not

implement or change the core of the IKS.

IKS servicecustomizer

ServiceCustomizer

An IKS service customizer customizes existing IKS services,e.g. by using defined extension points of an IKS service.


24/218


8 High Level Requirements

Based on the wish lists of the industrial partners and the analysis of the existing CMS of Day,Nuxeo, Alkacon and TXT we extracted ten high level requirements (HLR). These HLRs re-flect all relevant requirements for the horizontal industrial use case. Each HLR is doc-umented and refined according to the defined requirements specification and documentationprocess.










Security (HLR-2211)

8.1 Architecture and integration (HLR-2202)

HLR ID HLR-2202

Name Architecture and Integration

Description To allow easy integration of IKS functions into different heterogeneous sys-tem environments all IKS functions should be accessible through RESTfulservice interfaces. So the IKS architecture should be based on a service ap-proach. The implementation should be as technology independent as pos-sible on the one hand and on the other hand provide technology specificaccess to the services to guarantee best performance results. The communi-cation is based on standardized text-based data formats, e.g. XML.

The mantra behind this idea is that everything (data, functions, etc.) insidethe IKS stack can be accessed by an URI.

The IKS has to be customizable and extendible by new services and the im-plementation (e.g. an algorithm) has to be exchangeable. Services can beorchestrated/recomposed to new higher order services which re-use existingservices.IKS services need access to information that are inside the data repository ofthe CMS. Therefore, the IKS defines data access interfaces that must besupported by the CMS that integrates the IKS.

Classification Cross cutting

Horizontal


25/218


Related re-quirements

none

Statements Architecture should be based on services like web services restful

services not on libraries, should be independent Try to leverage existing content, have a semantic layer on top of that,

create a bridge, semantic restful interface between the available con-tent and semantic layer

Examples / Scenarios

Scenario 1

The CMS uses an IKS service by transmitting an URI and input parameters. The IKS routesthe request to the service identified by the URI, invokes the service and sends the response

back to the CMS. The response's content is delivered in an IKS specific format. The CMSmay send several independent requests in parallel.

To identify each request for functions like logging, journalizing, auditing, or for sending re-quests to the CMS in the context of a service execution, the CMS must provide a requestidentifier that uniquely identifies the request inside the CMS. These CMS request identifiersare used inside the IKS to manage all incoming request. The IKS itself will need an algorithmto identify all IKS requests uniquely inside the IKS using the CMS request identifier as input.

Figure 8.1 Use case diagram for scenario 1


26/218


Scenario 2

Same as scenario 1 but in this case the IKS service needs additional information that mustbe provided by the CMS, e.g. the IKS service needs information from the CMS's data reposi-tory. When requesting information from the CMS the IKS service must provide the original

CMS request identifier that allows the CMS to identify the context of this request from theIKS.


Scenario 3

An IKS service needs content as input. In this case the content is delivered by sending a URIor a list of URIs that points to the content. Then the IKS service is able to load content fromthat URIs. The content might reside inside the CMS but might also be stored somewhereelse (Intranet, WWW, etc.). The only demand is that the content is accessible by an URI.


27/218



Scenario 4

Some IKS services will need to persist data. This data can be stored in the IKS's own datarepository or in the CMS's data repository. When data should be stored inside the CMS theCMS must implement the IKS specific data storing interfaces.


28/218



Scenario 5

IKS services will need feedback information from the CMS that tells the IKS service how theCMS user liked the results that were generated by an IKS service in response to a request.This provides IKS services the opportunity to learn from the feedback. Feedback can begiven for each pair of request and response.


29/218



Scenario 6

As it is unclear how the performance of specific semantic IKS services will behave the CMScan provide performance criteria when requesting the service. One criteria will be that the re-sponse must be send in a given period of time by the IKS service - otherwise the results areuseless for the requester. This is useful in situations where you cannot expect a user to waitlonger than a given time before a result is shown. If the result cannot be computed within thistime it is more feasible for the user to continue asynchroniously with his work without the re-sults.

The IKS services must be aware of the time they use to compute the results and must beable to cancel the computation immediately when time is up.


30/218



Scenario 7

IKS services should be reusable to create new services. The requirement is that the IKS pro-vides a mechanism to create higher order services by re-using existing services (aka serviceorchestration).



31/218


Scenario 8

The IKS must provide a framework that allows the easy integration of new services withoutchanging the core of the IKS. Services are plugins or extensions that might be developed bythird parties. The IKS itself is bundled with a set of predefined services but each service can

be unplugged and other services can be plugged in. Each service must be implemented ac-cording to the IKS service specification. This ensures that all services provide the requiredhorizontal features that are needed, e.g. for performance issues or service orchestration.


Scenario 9

To allow the use of different algorithms for a specific service the service implementationshould be exchangeable. Moreover the IKS services can define extension points to allow theextension of a specific service with custom algorithms. The extension point mechanism isstandardized through the IKS service specification.


32/218



8.1.1 Use Case Descriptions

The use cases are ordered by actors:

CMSo UC-220201: Send IKS service requesto UC-220202: Send request with content URIso UC-220203: Send request with execution time constrainto UC-220204: Perform IKS requesto UC-220205: Perform IKS storage requesto UC-220206: Send feedback

IKSo UC-220207: Receive requesto UC-220227: Manage request by identifiero

UC-220208: Receive feedbacko UC-220209: Route to serviceo UC-220210: Route feedback to serviceo UC-220211: Invoke serviceo UC-220212: Send response

IKS Serviceo UC-220213: Executeo UC-220214: Cancel execution when time is upo UC-220228: Send CMS requesto UC-220215: Request information from CMSo UC-220216: Load content from URIso UC-220217: Store data

o UC-220218: Store data in IKSo UC-220219: Store data in CMS


33/218


IKS Customizero UC-220220: Read IKS service specificationo UC-220221: Create serviceo UC-220222: Implement and document service extension pointso UC-220223: Reuse existing serviceo UC-220224: Plug service in IKS

Service Customizero UC-220225: Create service extension

UC-220201: Send IKS service request

Use Case ID UC-220201 [SC1, SC3, SC5, SC6]

Description A CMS sends service requests to a semantic service inside the IKS.

Parent none

Includes

Scope Service invocation

Actor(s) CMS

Goal The specified IKS service is invoked.

TriggerA CMS service request.

Preconditions

1. The IKS is ready to receive service requests.

Minimal Postconditions

1. The IKS sends a response back to the CMS.

Success Postconditions

1. The specified IKS service is invoked and the results are sent back in the response.

UC-220202: Send request with content URIs

Use Case ID UC-220202 [SC3]

Description A CMS sends a service requests that transports a list of URIs. The URIs pointto content that is processed by the semantic service. The IKS service is able toload the content using the protocol and location specified by the URI.

Parent UC-220201

Includes none


34/218



Actor(s) CMS

Goal The specified IKS service is invoked using the list of URIs as input.

TriggerA CMS service request with list of URIs.

UC-220203: Send request with execution time constraint


Description A CMS sends a service request that transports constrains about the maximumexecution time that a service invocation is allowed to consume. If the serviceprocessing takes more time the processing has to be canceled and timeout re-

sult returns.

Parent UC-220201

Includes none


Actor(s) CMS

Goal The specified IKS service is invoked and returns a result without exceeding themaximum execution time.

TriggerA CMS service request with maximum execution time constraint.

Preconditions





1. The specified IKS service is invoked and its execution is canceled when the maxi-mum execution time is reached.

2. If the IKS execution time is reached the service sends a timeout result in response.3. If the IKS service finishes the execution within the given time the results are send

back in response.

UC-220204: Perform IKS request

Use Case ID UC-220204 [SC2, SC4]


35/218


Description The IKS can send requests to the CMS to get additional information from theCMS that is needed for a specific service processing, e.g. load data from theCMS's content repository.

Parent none

Includes none

Scope Request information of CMS

Actor(s) CMS

Goal Perform the request from the IKS.

TriggerAn IKS request.

UC-220205: Perform IKS storage request


Description A special request to the CMS is the request to store data that comes from theIKS. This can be used to store semantically enriched content inside the CMS'scontent repository.

Parent UC-220204

Includes none

Scope Request information of CMS

Actor(s) CMS

Goal Store the data from the request inside the CMS.

TriggerAn IKS storage request.

UC-220206: Send feedback


Description The CMS can send feedback information to the IKS that tells a specific IKSservice how much the user liked the results regarding a specific request.Feedback can be used by the IKS service to tune their semantic calculations.

Parent UC-220201

Includes none

Scope Feedback

Actor(s) CMS


36/218


Goal Send feedback information to an IKS service.

TriggerA feedback request from the CMS.

UC-220207: Receive request


Description The external IKS interfaces should be implemented using standard technolo-gies, e.g. a RESTful HTTP interface, that use the request-response paradigmfor synchronous communication. The IKS may also support asynchronouscommunication for cases where the request triggers some long running pro-cess.The IKS receives requests and routes them to the specific service and invokesthat service with the input parameters from the request. This means that each

IKS service is reachable through the external interface, e.g. by using RESTfulservice request.To ensure a high availability of the external interface the IKS should use a re-quest queue and enqueue each request in a first step to be able to receive fur-ther requests. The external interface must not be blocked by any runningrequest handling.

Parent none

Includes UC-220227, UC-220211

Extensions policies: UC-221103

Scope Request handling.

Actor(s) IKS

Goal Receive the request and invoke the specific IKS service.

TriggerA service request was received.


37/218


Action

Figure 8.10 Activity diagram for use case "Receive request"

UC-220227: Manage request by identifier


Description Each request may contain a CMS specific request identifier that uniquely iden-tifies this request inside the CMS. This CMS specific request identifier must

not be changed by the IKS and must be sent back to the CMS in the response.The IKS must manage all incoming requests using its own request identifierthat makes the request uniquely identifiable inside the IKS. The informationcan be used for functions like logging, auditing, journalizing, and in request re-sponses. The IKS request identifier must also be sent back to the CMS in re-sponse.

Parent none

Included by UC-220207

Scope Request handling.


38/218


Actor(s) IKS

Goal All incoming requests must be managed using a unique request identifier.

TriggerA service request was received and must be managed.

Preconditions





1. The IKS assigns a unique request identifier to the received request.2. The unique request identifier is used within the IKS to identify the request.3. The response contains the unique request identifier.4. The response contains the unmodified CMS specific request identifier which was re-

ceived as part of the request from the CMS.

UC-220208: Receive feedback


Description A special kind of request is the feedback request that is sent by a CMS. Thefeedback request gives an IKS service information about how much the userliked the results regarding a specific service request. The IKS receives thefeedback and routes it to the specific IKS service.

Parent UC-220207

Includes UC-220210

Scope The IKS request handling.

Actor(s) IKS

Goal Receive the request and send the feedback to the specific IKS service.

TriggerA feedback request was received.

UC-220209: Route to service


Description A received IKS request is routed to the specific IKS service which handles therequest and calculates the result.


39/218


Parent none


Scope IKS service invocation

Actor(s) IKS

Goal Identify the specific IKS service and route the request to that service.

TriggerAn IKS service request was received. (UC-220201)

Preconditions

1. The IKS is ready to receive service requests.2. The target IKS service must be specified within the request.




1. The IKS routes the request to the specified target service.2. The target service is invoked and handles the request and calculates a response.3. The response is sent back to the CMS.

UC-220210: Route feedback to service


Description A received IKS feedback request is routed to the specific IKS service.

Parent none


Scope The IKS feedback handling

Actor(s) IKS

Goal Identify the specific IKS service and route the feedback request to that service.

TriggerAn IKS feedback request was received. (UC-220206)

UC-220211: Invoke service

Use Case ID UC-220211 [SC1, SC2, SC3]

Description After receiving a request and routing it to the specific service the service is in-voked using the parameters from the request. By invoking a service the ser-


40/218


vice starts its execution.

Parent none


Includes UC-220209, UC-220212, UC-220215

Scope IKS service invocation.

Actor(s) IKS

Goal Invoke an IKS service to start the service execution.

TriggerA service request is routed to a service and the invoked.

Preconditions

1. The target IKS service is ready for invocation and not blocked by any operation.


1. The target IKS service is invoked and some result returns.


1. The target service is successfully executed and returns the results.

UC-220212: Send response


Description When the service execution has ended the IKS sends the response that wasgenerated by the service back to the CMS. The response sending is part of theservice invocation.

Parent none


Scope IKS service invocation

Actor(s) IKS

Goal Send the response back to the CMS.

TriggerThe service invocation has ended and returned a result.

UC-220213: Execute



41/218


Description When a service is invoked by the IKS it starts its execution. The execution ofan IKS service can have several extensions depending on the required usecases that must be performed during the execution. Each service is able to callback the CMS, load additional content, store data, and must be aware of exist-

ing execution time constraints.

Parent none

Extensions CMS callback: UC-220215 ; load content: UC-220216 ; time constraint: UC-220214; store: UC-220217; policies: UC-221104

Scope Service execution.

Actor(s) IKS Service

Goal Execute the service and compute a result.

TriggerThe service was invoked.


42/218


Action

Figure 8.11 Activity diagram for use case "Execute"

UC-220214: Cancel execution when time is up


Description If the service was invoked with a maximum execution time constraint then theservice has to cancel its execution when time is up and execution has not fin-ished yet regardless the calculated results so far. The execution must end af-ter the maximum execution time and the results must be discarded when theexecution did not end in this period of time.

Parent none

Extends UC-220213


43/218


Scope Service execution


Goal Cancel the service execution when time is up.

TriggerThe service was invoked with a maximum execution time.

UC-220228: Send CMS request


Description When an IKS service needs to interact with the CMS during service executionit can send requests back to the CMS (callback). The request must contain theCMS request identifier that was sent by the CMS as part of the IKS service re-

quest. This information may be needed by the CMS to determine the contextof the request.

Parent none

Includes none



Goal Send a request to the CMS.

TriggerAn IKS service needs to interact with the CMS.

Preconditions

1. The CMS is ready to receive requests.2. The IKS uses the CMS specific request identifier that was received as part of the ori-

ginal request from the CMS within the new request to the CMS.


1. The CMS sends a response back to the IKS.


1. The CMS returns valid results.

UC-220215: Request information from CMS


Description When an IKS service needs additional information from the CMS he can send

a request to the CMS. This is useful for loading additional content that could


44/218


not be included inside the original IKS service request.

Parent UC-220228

Extends UC-220213 (CMS callback)



Goal Request and get additional information from the CMS, e.g. from the contentrepository.

TriggerAn IKS service needs additional information and requests the CMS.

UC-220216: Load content from URIs


Description When an IKS service needs specific content as input this content is not directlyincluded in the IKS service request. The service request just transport pointers(URIs) to the content and the IKS service is able to load that content by usingthe URIs during the service execution.

Parent none

Extends UC-220213



Goal Load content from URIs that are delivered as part of the IKS service request.

TriggerThe IKS service request contains URIs to content.

UC-220217: Store data


Description Storing data is the abstract use case of an IKS service that wants to store datain some system.

Extensions linking: UC-220623

Extends UC-220213




45/218


Goal Store data in any system during service execution.

Trigger IKS service needs to store data.

UC-220218: Store data in IKS


Description An IKS service can store data using the persistence layer of the IKS. The datais stored inside the IKS.

Parent UC-220217

Includes none



Goal Data is stored inside the IKS.

Trigger IKS service needs to store data inside the IKS.

UC-220219: Store data in CMS


Description An IKS service can store data inside the CMS by sending a storage request tothe CMS. The data is stored inside the CMS, e.g. its content repository.

Parent UC-220217, UC-220228

Includes none



Goal Data is stored inside the CMS by sending a storage request to the CMS fromthe IKS service.

Trigger IKS service needs to store data inside the CMS.

UC-220220: Read IKS service specification


Description This use case ensures that there exists an IKS service specification that must

be read by an IKS customizer in order to customize the IKS by implementing anew IKS semantic service. The presents and knowledge of the IKS service


46/218


specification is mandatory.

Parent none


Scope IKS customization

Actor(s) IKS Customizer

Goal Ensure that an IKS customizer is aware of the IKS service specification.

TriggerAn IKS customizer wants to create a new IKS service.

UC-220221: Create service


Description A main IKS customization aspect is that an IKS customizer can create newsemantic services and include it into the existing IKS. This is a plug-in featurefor IKS services offered by the IKS itself.

Extensions reuse: UC-220223

Includes UC-220220, UC-220222,

Scope IKS customization


Goal Implement an new IKS service.

TriggerAn IKS customizer wants to create a new semantic service for the IKS.


47/218


Action

Figure 8.12 Activity diagram for use case "Create service"

UC-220222: Implement and document service extension points


Description Each IKS service can offer its own extension points. This feature allows thecustomization of existing IKS services by using the service's extension points.These extension points are defined and document during the creation processof an IKS service.

Parent none


Scope IKS service creation


Goal Implement and document the extension points of an IKS service.

TriggerA new IKS service needs to be customizable.

UC-220223: Reuse existing service



48/218


Description An IKS customizer can reuse existing IKS services when creating a new IKSservice. This use case is about the orchestration of existing IKS services tocreate new services. The new service can be just a combination of existingservices or a mix of service reuse and implementation of new features.

Extends UC-220221 (reuse)




Goal Reuse existing IKS services when creating a new service.

TriggerA new IKS service want to reuse an existing service.

UC-220224: Plug service in IKS


Description After the creation of a new IKS service the new service must be plugged in theIKS to be used. A binding between IKS and plug-ins makes the plug -ins avail-able inside the IKS. For this the IKS needs a binding mechanism for servicesand the IKS services need to be aware of the mechanism to be compatiblewith the IKS.

Parent none

Inherited by UC-007008



Goal Make a new service available inside the IKS.

TriggerA new service shall be used inside the IKS.

UC-220225: Create service extension


Description The IKS can be customized by new IKS services. Each IKS service can becustomized using the service's extension points. To use an extension point aservice customizer create a new service extension that fits into that extensionpoint.

Parent none

Inherited by UC-007002


49/218


Scope Service customization

Actor(s) Service Customizer

Goal Create an extension for a service extension point.

TriggerA service customizer wants to customize an existing IKS service and imple-ments and extension.

8.1.2 Resulting Requirements Description

Functional Requirements

ID Requirement UC-Ref

FR-220201 The IKS shall support a plug-in mechanism for semantic services. UC-220224

FR-220202 A service execution shall be stoppable at any point of execution. UC-220213

FR-220203 The IKS shall be able to handle feedback information from external systems. UC-220208

FR-220204 The IKS shall manage all requests by using unique request identifiers. UC-220227

FR-220205 The IKS shall route each request to a service and invoke that service tohandle the request.

UC-220209

FR-220206 The IKS shall take the results from a service execution and send it back tothe enquirer.

UC-220212

FR-220207 The IKS shall be able to load content from URIs. UC-220216

FR-220208 The IKS shall be able to store data inside the IKS UC-220218

FR-220209 The IKS shall be able to store data in external systems, e.g. a CMS contentrepository.

UC-220219

Data requirements


DR-220201 IKS shall be able to handle service requests that contain lists of URIs. UC-220202

DR-220202 IKS shall be able to handle service requests that contain execution timeconstraints.

UC-220203

DR-220203 The IKS shall define the format and semantics for feedback information. UC-220206

Integration requirements


INR-220201 The IKS shall provide external interfaces to become usable by other systems

like a CMS.

UC-220207


50/218


INR-220202 The IKS shall be extendible by custom services. UC-220221

INR-220203 The external interfaces should use standardized technologies. UC-220207

INR-220203 Each IKS semantic service shall be reachable by an external interface. UC-220207

INR-220204 The IKS semantic services shall be available as RESTful services. UC-220201

INR-220204 The IKS shall be able to request information from other external systems(e.g. a CMS, the WWW)

UC-220218

INR-220205 The IKS shall be able to access the data repositories of external CMS. UC-220218

INR-220206 Each IKS service shall be customizable using service extension points. UC-220225

INR-220207 Custom services shall be able to reuse existing services. UC-220223

Interface requirements


IR-220201 The external IKS interfaces shall support sychronous communication usingthe request/response paradigm.

UC-220207

IR-220202 The external IKS requests/responses shall use a standard technology (e.g.SOAP over HTTP)

UC-220207

IR-220203 The external IKS interfa

Requirements Specifications of the Horizontal Industrial Use Case

Documents

Transcript of Requirements Specifications of the Horizontal Industrial Use Case