A service requirements engineering method for a digital service ecosystem

Service innovation is already taken into account in the recent research on service ecosystems. In [34], a common underlying architecture is used to connect different pieces of innovation components, and it also considers the value proposition for different participating partners. An open government data portal in [35] is also used as an open innovation platform to attract businesses and citizens to create e-services. An innovation framework introduced in [36] supports the development of new services through integrating customers, suppliers, complementors and competitors. A conceptual framework for web-service ecosystems proposed in [16] emphasises a central platform from which the companies try to extract ideas for service innovation and use these ideas to create new, or improve existing, services. The structure of the value chain affects innovation, requirements engineering performance and software success, such as described in [37]. A method introduced in [38] emphasises socio-technical aspects such as context, environment, and team management in service innovation. In [39], two types of requirement engineering methods are suggested to emerge for IT services: RE for service consumers and RE for service providers. Consumers will focus on identifying the tasks that need support, whereas providers will focus on achieving economies of scale such as offering a new service for multiple customers, or applying a specialised skill to a common problem. In several approaches, such as [29, 40‐43], the identification of business goals and the business processes that support those goals are used as a starting point for the RE of services. Several approaches for the requirements engineering of service users are also suggested, such as [44‐46]. Both these viewpoints are required in ecosystem, since the usage goals of consumers and the business goals of service providers must be fulfilled by the services. The fact is that the current approaches and methods lack of tool support, they do not cover all the phases of RE, or they concentrate only presenting only a technique applicable in a certain RE phase [33].

Although the significance of open innovation has been detected in the context of the ecosystem, there is not much research in the literature on how to go further from ecosystem-based service innovation to service co-creation inside an ecosystem. However, some approaches exist that deal closely with the subject. The Inter-enterprise Service Engineering Framework [47] supports three phases of e-service development in business ecosystems: requirements analysis, service design and service implementation, assigning them to strategic, conceptual, logical and technical abstraction layers. Service requirements are identified in the strategic perspective in the form of a business model. However, the service ideas are innovated, identified and evaluated and their business potential is analysed prior to the development of the strategic perspective, but the approach does not define how this is done. In [48], an RE approach is introduced, which uses guided questionnaires to elicit the requirements coming from the current business situation, and a workshop to define the basic requirements for each Manufacturing Service Ecosystem scenario. The approach enables the relevant ecosystem actors to participate in scenario identification and requirement elicitation, but it does not define the content of RE phases and the impact of other ecosystem elements on RE. In [36], there exists a mapping of information collected in the Innovation Repository accessible to service engineering, but the approach does not describe how this information affects to service realisation.

The interoperability models and rules enable the loosely coupled services to collaborate. In [25], six interoperability levels are defined for smart environments: conceptual, behavioural, dynamic, semantic, communication and connection. In [49], four inter-related metamodels are suggested for ecosystem interoperability: domain ontology, methodology, domain reference, and knowledge management metamodels. In addition to service interoperability, pragmatic interoperability [49] is achieved between ecosystem members when their intentions, business rules and organisational policies are compatible. To detect service interoperability, the service must be specified in an understandable way in the ecosystem’s service registry. Three levels of service specifications can be identified [26]. The importance of interoperability models has been recognised in the context of ecosystems; still there is a lack of application of these models in practise.

The knowledge models are usually described using ontology models, which are guided by knowledge management. The knowledge- and ontology-based requirements engineering has a long history [50]. Even currently, an increasing amount of research has been conducted to utilise ontologies in RE [51]. Different kind of approaches have been suggested, such as for generating a requirements model based on the concepts in the service requirements modeling ontology [52] or establishing a mapping between a requirements specification and ontological elements [53]. A knowledge-based development of intelligent smart spaces is introduced in [27], which support the service innovation and co-creation, exploiting the usage scenario description, the set of use cases that define the specific viewpoint of the usage scenario, and the reusable artefacts, such as ontologies, models, patterns and rules, provided in the knowledge base. In [25, 54], an approach for developing intelligent applications/services for smart spaces is introduced that exploits the ontology models, interoperability models and context models for describing self-adaptable services. The approach is multi-technology and multi-domain oriented, but it still lacks the business (ecosystem) viewpoint.

We can notice that there already exist several methods and approaches that enable some parts of the ecosystem-based RE for services. Several innovation methods exist for services that enable the open innovation among ecosystem members. Several models have been introduced to verify interoperability in ecosystems. Also, support is provided for knowledge-based service engineering that would enable to utilise the existing assets of the ecosystem. However, the interoperability models and knowledge base service engineering have not been present in methods for ecosystem-based service engineering. Service innovation approaches either do not take these into account. Furthermore, the innovation approaches are separated from the further phases of service development. The identified methods and approaches for ecosystem-based service development are loose; they are only concentrating their own viewpoint and not working together. Clearly there still exists a lack of methods how to take the digital service ecosystem elements into account in service engineering, especially when they have a direct effect on RE of services. The diversity of RE approaches and their use in different contexts highlights the importance of the formal definition of terms and the definition of uniform modelling methods and techniques. The identified challenges for service RE [2‐7] and for service RE in ecosystem [8, 9] still remains, meaning that the service RE is not mature enough as such and not especially for digital service ecosystems. There are multiple actors, viewpoints and ecosystem capabilities that affect the service RE in an ecosystem, but at this moment, there is no RE method for digital services that take these account.

The members of the digital service ecosystem can be defined to include service providers, service brokers, service consumers and infrastructure providers. Service consumers use the services and define the usage goals for the services, i.e. tasks that need support. They may also report on problems and failures in the service usage and provide feedback for the service validation. Service providers are independent members that provide digital services to be used by other ecosystem members or consumers. Service brokers promote the services, enable service delivery and match the demand with the best available services. Infrastructure providers provide services that implement the purpose and capabilities of the ecosystem, such as establishing, modifying, monitoring and terminating collaborations, and operations for joining and leaving collaborations. The ecosystem can also include other infrastructure provider roles, such as service market-place providers, tool providers, cloud service providers and interface providers [56]. The ecosystem provider is usually the key organisation, which establishes and maintains the ecosystem, controlling its function, members and services.

The ecosystem capabilities describe the capability model that defines the properties of the ecosystem, and how these are implemented using the ecosystem services that the ecosystem infrastructure provides. The capabilities define the purpose of the ecosystem, its ability to perform actions and the rules of how to operate in the ecosystem. The capabilities define the governance activities and regulation processes for the ecosystem for directing, monitoring and managing the ecosystem. These include, for example, how a trusted collaboration can be established between members, what the interaction rules are, how to join and leave the ecosystem, and how to describe and deliver services. In addition, the ecosystem capabilities define how the knowledge is managed.

Infrastructure implements ecosystem capabilities, supporting the utilisation of core competencies and core assets, flexible business networking, and efficient business decision-making. The infrastructure also includes the taxonomy and shared descriptions of services (categorised by domain, purpose and technology etc.). The infrastructure provides the following models and assets that assist in the RE:

In a digital service ecosystem, digital services are provided by independent ecosystem members, where they provide additional value for both service consumers and other service providers. Service providers do not necessarily provide a complete service for consumers but can just provide part of a composite service [57]. Service level agreements (SLAs) are negotiated between the atomic service providers and the composite service provider, describing the agreed-upon terms with respect to quality of service and other related concerns. The results of the RE process, i.e. service requirements, either result in new digital services, or they are mapped to existing digital services. The requirements can also be identified as new ecosystem support services, or they can cause changes to the existing ones.

The service innovation phase starts the service RE in digital service ecosystem. The main purpose is to identify the ideas for new services, scope and analyse them and transform them into service requirements. The innovation can be divided into two sub-phases: requirements elicitation and the requirements identification of services.

Activities: The elicitation process can be divided into the following steps: Practice: The domain model(s) describes the relevant domain concepts that should be considered in the RE. The knowledge management model provides ontologies, methods, tools, templates and guidelines for requirement elicitation. The Use Case Description Template ensures that all the use cases are described adequately, consistently and with the same accuracy. The use of the template is to make it easier to transform from use cases to identifying services and their relationships. Functional properties can be identified from the use case flow, which is a detailed description of the user actions and system responses during the execution of the use case. All the elements of the use case, i.e. actors, the use case function, actor-use case relations and the use case environment, should also be considered from the non-functional viewpoint, which describes the quality properties of the use case. For example, reliability properties describe the issues affecting the failure free operation of the use case (how the fault prevention, tolerance, removal and recovery from failures are considered in the use case), and availability properties describe the issues ensuring that the use case function is ready for use when required. The Use Case Description Template includes the classification of quality properties and their detailed description to assists users to consider each quality property.

Outcome: The outcome of the phase consists of the following for each use case: General information: the identification, introduction and rationale of the use case,Contextual settings: A description of the context of the use case, including actors, a vision of the infrastructure, the physical resources and required artefacts, Functional and non-functional description: the description of the main functions and the quality properties of the use case, Business properties: a description of business properties or the use case, such as customer segments, value proposition, customer relationships, etc., Constraints: a description of the constraints associated with the elements of the use case, and Threats and exceptions: a description of the threats for the use case, responds to those threats, and description of anticipated exceptions and error conditions.

Practice: The Use Case Analysis template assists ecosystem members in this activity, using as input the information gathered in the previous phase. The template enables to analyse the use cases from business and user points of view and to identify and describe functional and non-functional requirements and constraints. The template also assists and guides in making an initial mapping between the identified requirements and the existing digital services and potential new required ones. Figure 3 describes the mapping with the Microsoft Word smart-art tree diagram provided in the template. The owner of the use case plays a key role in mapping the identified requirements to the support services provided by the use case partners involved in this particular use case. Each functional requirement results in one or more ‘support services’ that implement the requirement. The support service is a new or existing that provides the functionality and quality that is required to implement the use case. If the requirements cannot be mapped to already existing services, totally new services are identified here, which are responsible for implementing the requirements. When candidate services have been identified, non-functional requirements can be mapped to them. This especially concerns the execution qualities, such as performance, availability, reliability and security, but evolution qualities (such as reusability, modifiability and maintainability) are focused on later on in the service modelling phase, where the architectural knowledge guides the design work.

Activities: The identified use cases are collected together in the ecosystem and the members responsible perform the business analysis. Therefore, each use case is analysed by several analysts according to the following criteria (defined in the knowledge management model of the ecosystem) [27]:The given numbers can be weighted to be appropriate for the case. After the business potential analysis, the most relevant use cases from the business viewpoint are identified, and the initial mapping of the identified requirements of these use cases to the responsible services (according to Fig. 3) are verified. At this point, the actors that provide the required support services (see Fig. 3) are identified. Some of the requirements can be implemented by already existing services, when contracts are being made with other service providers, whereas some of the requirements result in identifying new services.

Practice: The knowledge base of the digital service ecosystem contains business knowledge, architectural knowledge, assets and supporting knowledge management tools [27]. Business knowledge also provides information about the earlier ideas that have been evaluated but not realised. The reasons behind the earlier decision are valuable in making feasibility checks while further defining the usage scenario and use cases in hand. The knowledge base also includes documentation about existing assets that resolve their availability, suitability and quality for the service development in hand. The architectural knowledge is used to estimate what artefacts can be used as such, or modified, what is the quality of the artefacts and whether the quality is satisfactory.

The last phase of the service RE includes three sub-phases that are highly interrelated and iterative by nature. The main purpose of the phase is to provide a complete requirement specification of the needed services that is used as input in service architecture modelling.

Activities: Several rotations are required to illustrate domain requirements, business requirements and technical requirements for services. The first round ends with an initial service taxonomy that defines what kind of digital services are needed and clusters them to the groups of services based on their usage or/and technical relations. The last round ends with service specifications that provide a big picture as a set of master use cases that describe the behavioural service architecture. A master use case is made by integrating the related use cases defined by different business actors (see Fig. 3, use case owner). The master use cases give a mutual understanding of the service architecture and how it is used for realising the different use cases by diverse actors. Thus, the service requirements specification includes the activities that transform informal service specifications into semi-formal descriptions to be used as a starting point in the service architecture modelling phase.

Since the service engineering model is iterative (described as double-headed arrow in Fig. 2), it takes into account the requirements evolution caused by new requirements, feedback achieved from the use of the service, and change requests in current requirements. The identified new or changed requirements proceed from the service innovation to the service identification, where the requirements are mapped to the existing digital services and potential new ones. The requirements go normally through the business analysis and requirements analysis, negotiation and specification. It is the responsibility of the modelling phase (out of scope of this paper) to decide how to implement the new and changed requirements.

The Use Case Description Template in the form of Microsoft Word-file was used for collecting input from the ICARE ecosystem members. Thus, the usage of the template did not require special tools. In addition, guidance was provided in the form of instructions for using the templates. The instruction included the definition of the main elements, description of the purpose and goal of the Use Case Description and common instructions for fulfilling the templates. Both business and technical experts were asked to be involved in defining use cases. However, only one contact point was defined by each partner, and it was not visible to other ecosystem members which kind of expertise was used to define the use cases.

All in all 41 use cases were defined. Some of them were variations on a similar theme, the actual number of different use cases being about 30. Filling a use case took about a week by each partner, but it took 3 months to collect all of these use case descriptions because of the participants’ work schedules and the need to iterate the use cases. The activities of the ecosystem members were divided according to work package descriptions of the project; thus, one partner was responsible for collecting and coordinating the use cases. To illustrate the outcome of the Service Innovation phase, the definition of the ‘second-screen voting’ service defined by an ecosystem member is used here as a practical example.

The general information of the use case is represented in Table 2

A context diagram Figure 4 describes the context diagram of the second-screen voting use case.

Actors: The identified use case actors and their responsibilities included the following: End user—uses an interactive TV service via a mobile device application; Advertiser— provides advertisements to the broadcaster to be delivered to the end users; and Broadcaster—provides additional information to show based on the user interaction and provides an interactive service to end user.

Resources: The number of needs of physical resources and locations is more or less an implementation-specific issue. However, some parts of the system, such as software components for a set-top box and HbbTV will be in the home environment running on previously mentioned devices. The notification service and the rating service can run in the same server. Advertisements are most likely provided by third-party actors from their own servers. In addition, a post-production server must be in its own physical environment.

Frequency of use: The frequency of the usage depends on the content and users. Average usage could be 5–8 voting (notifications) during a one-hour programme. If the user base is large, there could be 10–100 thousand simultaneous notification and voting results to be handled.

The Use Case Description template assisted in describing the use case, and the service innovation phase in the case of the ‘second-screen voting’ service resulted in the service description represented in Table 3.

After all use cases were identified and described, each partner identified the functional requirements of the use case, starting from normal flows using Microsoft Word’s smart-art tree-based diagram provided in the Use Case Analysis template. The running ID of each identified requirement and potential support services are also shown in the diagram. In the example diagram in Fig. 5, the use case owner identified two new services to be implemented and also potential for utilising partner-provided or existing technologies to complete the use case. The requirements shown in the diagram were then specified in more detail. The use case number and use case-specific requirement ID was used as the global ID for each requirement. The detailed description is provided in Table 4. The importance (imp) of the requirement ranges from 1 to 5, (\(1= \hbox {not relevant}\)). The template also provided the possibility to define non-functional requirements and constraints, and associate them with functional requirements. For example, two availability requirements were associated with the functional requirements 4.1 and 4.2 (see Table 4). The category (cat) describes the type of the requirement (\(\hbox {F}=\hbox {functional}, \hbox {NF}= \hbox {non-functional}, \hbox {C}=\hbox {constraint}\)). The table was scalable and could be complemented in more detailed afterwards; the ‘Details’ column allowed to insert more information.

Several data resources were also identified: TV programme info, Notification content, Voting results and User profiles. These are specified in the data resource definition template with characteristics of resource name, description, related requirement(s), standards, quantity and size, privacy and details.

The services and service providers identified during service requirement identification and business analysis were collected into a list preserving the link to the original use case. The list of candidate services was checked with partners, and similar services with different naming merged and those with no business potential rejected. At this stage, the service candidates were quite heterogeneous both in scale and conceptual level. A service candidate comprised functionalities from algorithms and functions to sub-systems consisting of several servers. In order to better grasp the overall requirements for the ecosystem, the services were classified into service taxonomy based on their technology position. The services were classified into two dimensions: cloud services vs home network services and infrastructure vs end-user services. A partner interested in providing a service candidate could then check the requirements set to it and similar services tracing their links to the use case descriptions. Based on analysis of the business models presented in the use case descriptions, the shared requirements were also identified (see Table 6).

Several of these requirements could be assigned to individual use cases or service candidates. For example, the cross-distribution platform interoperability could be linked to interactive TV directly supporting different distribution platforms, and also to multi-screen interaction that can cope with emerging technologies helping the user with access to different mobile devices, advanced interaction technologies and multiple screens at home.

The requirements were negotiated in smaller groups of four to five partners with a similar focus and potentially compatible business models. An overall master scenario (i.e. a ‘big picture’) between those partners was drafted and iterated in workshops and details refined through e-mail discussions. The master scenario draft (Fig. 6) shows the technical deployment of services and partner technologies and candidate services. This work resulted in changes in the ideas presented by each partner in the original use cases because of better understanding of the available ecosystem services provided by the other partners. For example, there was no need for sending notification individually to the watcher device. Instead a ‘red button’ indication could be inserted into an interactive TV broadcast stream that a user watching the programme could select either directly on TV remote or based on advanced gesture detection. The work was documented as more or less informal architectural drawings and textual documents shared using e-mail and the master scenario was iterated until each partner was satisfied with their role in the master scenario and the support to be utilised from other partners.

The scope of the master use case was clarified according to the master scenario and details were defined using the use case description template with the exception that now each service provider focused only on the parts (business models and functionalities) relating to their own services. The master use case focused on the services providing interactive TV content related to the use of secondary devices. The rationale was that while use of secondary devices in conjunction with traditional broadcast TV consumption is becoming more popular, there are no methods available for personalised second-screen content that is introduced in line with the traditional content. The master use case was coordinated mainly by two active services—Interactive TV and multi-screen interaction—and consisted of several supporting services integrated with the service registry. The service dependency matrix was added to the template to aid the requirements specification. The matrix included provider services that respond to the services that implement the requirements and the dependent services that set the requirements to the provider services. The related requirements were referred with the ID number of requirements (set by dependent services). The requirements were then grouped for each service and refined as presented in Table 7. The information represented in ‘details’ section in Table 7 depends on the category of requirement; for functional requirements, the inputs and outputs are defined. Each partner then continued the detailed service design from there on.

A total of 67 % of the people that completed the questionnaire were R&D personnel, and the rest were equally divided between business developers and project managers. There were project managers, work package leaders, task leaders, coordinators and developers among the respondents. Five of the respondents felt that their company was a part of a service ecosystem, acting as a service provider, a technology provider, or as a GUI and platform provider. A total of 40 % of the respondents confirmed that their company utilises third-party services/technologies in software development. The target of the requirements engineering was clear enough in the project for almost all of the respondents. According to one respondent, the purpose was not explained clearly enough. One respondent felt that more information was required for focusing the scope of the project.

The definition of the business scenario was considered easy among 80 % of the respondents. The use cases were defined and analysed by architects, business managers and technical experts. The technical experts had the clear majority. Only in one case was the customer of a company involved in requirements identification (through product managers). In one case also the marketing personnel participated in use case definition. The definition of use cases from the scenario was considered easy or very easy among 93 % of the respondents. The use cases were analysed mostly from the viewpoints of business impact and functional requirements. Some also considered the quality requirements, technological viewpoint and implementation complexity viewpoints. The results are illustrated in Fig. 7. 73 % of the respondents considered the requirements easy to define from the use cases.

The service identification was performed mostly by technical experts with the assistance of architects and business managers. In one case, the marketing personnel participated in the service identification phase. 73 % of the respondents considered it easy to define the services that are needed for the defined use cases. A total of 33 % of the respondents exploited existing services in defining a new service. One respondent revealed that they do not exploit existing services because they try to be innovative. The analysis and prioritisation of service requirements was seen as easy by 66 % of the respondents. The respondent companies assumed mostly cloud or platform architectures, when analysing the use cases and identifying services. The mapping of functional requirements to the architecture was considered easy for most of the respondents. Some respondents considered it difficult since the architecture was lacking high-level building blocks. The non-functional requirements were difficult to define and map to the architectural elements due to the following reasons: The vision of architecture was too complex with too many small components (lacking high-level blocks), the target and output of non-functional requirements were not clear enough, and no tool exists to support this. Almost all of the participants were able to exploit the use cases in business, at least to some extent.

According to the respondents, the templates assisted in several phases (see Fig. 8). Also, some shortcomings of the templates were identified:

The completion of the templates by the respondents took from a few hours (15 %), one day (62 %) to several days (23 %). For most of the respondents it was easy to apply the templates in their working practice. It was agreed that for a large European project, documentation is a prerequisite, and the templates were good for that purpose. However, in SME companies, less formalisation and paperwork is done. For a smaller company and for internal usage, the templates are too heavy. Direct communication is preferred; a few overview slides with use case diagrams, and an ROI Excel sheet. One respondent felt that his/her work is technology oriented, but the templates are more business oriented; therefore they did not fit to the working practice. The templates included enough guidance according to most of the respondents. In one case, more guidance for the identification of new services was required. Also, working examples were required in each case that could help shape the structure and content of the proposed implementations. A more specific description of the target and output for non-functional requirements was identified as a development target. Also, more detailed explanations for the data resource titles is required. A total of 80 % of the respondents would recommend the usage of the templates to their colleagues and business partners.