Requirements Specifications of the Horizontal Industrial Use Case
Transcript of 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
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
2/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case2 / 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
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
3/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case3 / 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)
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
4/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case4 / 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
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
5/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case5 / 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.
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
6/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case6 / 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
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
7/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case7 / 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/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
8/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case8 / 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.
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
9/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case9 / 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
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
10/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case10 / 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.
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
11/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case11 / 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.
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
12/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case12 / 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.
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
13/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case13 / 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.
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
14/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case14 / 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)
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
15/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case15 / 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
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
16/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case16 / 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
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
17/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case17 / 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.
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
18/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case18 / 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.
Architecture and integration (HLR-2202)
Common vocabulary (HLR-2201)
Semantic lifting & tagging (HLR-2203)
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
19/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case19 / 218
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)
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
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
20/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case20 / 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.
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
21/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case21 / 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
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
22/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case22 / 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
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
23/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case23 / 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.
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
24/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case24 / 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.
Architecture and integration (HLR-2202)
Common vocabulary (HLR-2201)
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)
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
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
25/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case25 / 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
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
26/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case26 / 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.
Figure 8.2 Use case diagram for scenario 2
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.
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
27/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case27 / 218
Figure 8.3 Use case diagram for scenario 3
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.
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
28/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case28 / 218
Figure 8.4 Use case diagram for scenario 4
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.
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
29/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case29 / 218
Figure 8.5 Use case diagram for scenario 5
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.
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
30/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case30 / 218
Figure 8.6 Use case diagram for scenario 6
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).
Figure 8.7 Use case diagram for scenario 7
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
31/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case31 / 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.
Figure 8.8 Use case diagram for scenario 8
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.
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
32/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case32 / 218
Figure 8.9 Use case diagram for scenario 9
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
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
33/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case33 / 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
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
34/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case34 / 218
Scope Service invocation
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
Use Case ID UC-220203 [SC6]
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
Scope Service invocation
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 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 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]
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
35/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case35 / 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
Use Case ID UC-220205 [SC4]
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
Use Case ID UC-220206 [SC5]
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
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
36/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case36 / 218
Goal Send feedback information to an IKS service.
TriggerA feedback request from the CMS.
UC-220207: Receive request
Use Case ID UC-220207 [SC1, SC5]
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.
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
37/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case37 / 218
Action
Figure 8.10 Activity diagram for use case "Receive request"
UC-220227: Manage request by identifier
Use Case ID UC-220227 [SC1]
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.
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
38/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case38 / 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 is ready to receive service requests.
Minimal Postconditions
1. The IKS sends a response back to the CMS.
Success Postconditions
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
Use Case ID UC-220208 [SC5]
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
Use Case ID UC-220209 [SC1]
Description A received IKS request is routed to the specific IKS service which handles therequest and calculates the result.
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
39/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case39 / 218
Parent none
Included by UC-220211
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.
Minimal Postconditions
1. The IKS sends a response back to the CMS.
Success Postconditions
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
Use Case ID UC-220210 [SC5]
Description A received IKS feedback request is routed to the specific IKS service.
Parent none
Included by UC-220208
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-
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
40/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case40 / 218
vice starts its execution.
Parent none
Included by UC-220208
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.
Minimal Postconditions
1. The target IKS service is invoked and some result returns.
Success Postconditions
1. The target service is successfully executed and returns the results.
UC-220212: Send response
Use Case ID UC-220212 [SC1]
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
Included by UC-220211
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
Use Case ID UC-220213 [SC3, SC4, SC6]
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
41/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case41 / 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.
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
42/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case42 / 218
Action
Figure 8.11 Activity diagram for use case "Execute"
UC-220214: Cancel execution when time is up
Use Case ID UC-220214 [SC6]
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
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
43/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case43 / 218
Scope Service execution
Actor(s) IKS Service
Goal Cancel the service execution when time is up.
TriggerThe service was invoked with a maximum execution time.
UC-220228: Send CMS request
Use Case ID UC-220228 [SC2, SC4]
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
Scope Service execution
Actor(s) IKS Service
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.
Minimal Postconditions
1. The CMS sends a response back to the IKS.
Success Postconditions
1. The CMS returns valid results.
UC-220215: Request information from CMS
Use Case ID UC-220215 [SC2]
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
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
44/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case44 / 218
not be included inside the original IKS service request.
Parent UC-220228
Extends UC-220213 (CMS callback)
Scope Service execution
Actor(s) IKS Service
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
Use Case ID UC-220216 [SC3]
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
Scope Service execution
Actor(s) IKS Service
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
Use Case ID UC-220217 [SC4]
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
Scope Service execution
Actor(s) IKS Service
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
45/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case45 / 218
Goal Store data in any system during service execution.
Trigger IKS service needs to store data.
UC-220218: Store data in IKS
Use Case ID UC-220218 [SC4]
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
Scope Service execution
Actor(s) IKS Service
Goal Data is stored inside the IKS.
Trigger IKS service needs to store data inside the IKS.
UC-220219: Store data in CMS
Use Case ID UC-220219 [SC4]
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
Scope Service execution
Actor(s) IKS Service
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
Use Case ID UC-220220 [SC8]
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
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
46/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case46 / 218
specification is mandatory.
Parent none
Included by UC-220221
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
Use Case ID UC-220221 [SC7, SC8, SC9]
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
Actor(s) IKS Customizer
Goal Implement an new IKS service.
TriggerAn IKS customizer wants to create a new semantic service for the IKS.
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
47/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case47 / 218
Action
Figure 8.12 Activity diagram for use case "Create service"
UC-220222: Implement and document service extension points
Use Case ID UC-220222 [SC9]
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
Included by UC-220221
Scope IKS service creation
Actor(s) IKS Customizer
Goal Implement and document the extension points of an IKS service.
TriggerA new IKS service needs to be customizable.
UC-220223: Reuse existing service
Use Case ID UC-220223 [SC7]
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
48/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case48 / 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)
Included by UC-220706
Scope IKS service creation
Actor(s) IKS Customizer
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
Use Case ID UC-220224 [SC8]
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
Scope IKS service creation
Actor(s) IKS Customizer
Goal Make a new service available inside the IKS.
TriggerA new service shall be used inside the IKS.
UC-220225: Create service extension
Use Case ID UC-220225 [SC9]
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
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
49/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case49 / 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
ID Requirement UC-Ref
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
ID Requirement UC-Ref
INR-220201 The IKS shall provide external interfaces to become usable by other systems
like a CMS.
UC-220207
-
8/3/2019 Requirements Specifications of the Horizontal Industrial Use Case
50/218
Deliverable 2.2 Requirements Specification for the Horizontal Industrial Case50 / 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
ID Requirement UC-Ref
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