Requirements Engineering. Traditionally, software engineering divides requirements in two categories: functional requirements (what the system should do) and non-functional requirements (performance, quality of service, etc.). In the areas of adaptive and open-ended systems, both functional and non-functional requirements are better expressed in terms of “goals” [MCY99]. A goal, in most general terms, represent a desirable state of the affairs that an entity, that is a software component or software system, aims to achieve. In ASCENS we propose SOTA for capturing and specifying the requirements of autonomic sys- tems. SOTA is an extension of existing goal-oriented requirements engineering approaches that in- tegrates elements of dynamical systems modeling to account for the general needs of dynamic self- adaptive systems and components. SOTA models the entities of a self-adaptive system as n-dimensional space S, with each dimension representing a specific aspect of the current situation of the entity/ensemble and of its operational environment. As an entity executes, its position in S changes either due to its specific actions of or because of the dynamics of environment. Thus, we can generally see this evolution of the system as a movement in S. 1UML website: xxxx://xxx.xxx.xxx/ 2BPMN website: xxxx://xxx.xxx.xxx/spec/BPMN/2.0/ 3SPEM website: xxxx://xxx.xxx.xxx/spec/SPEM/2.0/ In this context, a goal in SOTA can be expressed in terms of a specific state of the affairs to aim for, that is, a specific point or a specific area in S which the entity or the system as a whole should try to reach, despite the fact that external contingencies can move the trajectory farther from the goal. Along this lines, the activity of requirements engineering for self-adaptive systems in SOTA im- plies: (i) identifying the dimensions of the SOTA space, which means modeling the relevant infor- mation that a system/entity has to collect to become aware of its location in such space, a necessary condition to recognize whether it is correctly behaving and adapt its actions whenever necessary; (ii) identifying the set of goals for each entity and for the system as a whole, which also implies identi- fying when specific goals gets activated and any possible constraint on the trajectory to be followed while trying to achieve such goals. The SOTA modeling approach is very useful to understand and model the functional and adap- tation requirements, and to check the correctness of such specifications (as descr...
Requirements Engineering. Traditionally, software engineering divides requirements in two categories: functional requirements (what the system should do) and non-functional requirements (performance, quality of service, etc.). In the areas of adaptive and open-ended systems, both functional and non-functional requirements are better expressed in terms of “goals” [MCY99]. A goal, in most general terms, represent a desirable state of the affairs that an entity, that is a software component or software system, aims to achieve. In ASCENS we propose SOTA for capturing and specifying the requirements of autonomic sys- tems. SOTA is an extension of existing goal-oriented requirements engineering approaches that in- tegrates elements of dynamical systems modeling to account for the general needs of dynamic self- adaptive systems and components. SOTA, which stands for “state of the affairs”, models the entities of a self-adaptive system as n- dimensional space S, with each dimension representing a specific aspect of the current situation of the entity/ensemble and of its operational environment. As an entity executes, its position in S changes either due to its specific actions of or because of the dynamics of environment. Thus, we can generally see this evolution of the system as a movement in S. In this context, a goal in SOTA can be expressed in terms of a specific state of the affairs to aim for, that is, a specific point or a specific area in S which the entity or the system as a whole should try to reach, despite the fact that external contingencies can move the trajectory farther from the goal. Along this lines, the activity of requirements engineering for self-adaptive systems in SOTA im- plies: (i) identifying the dimensions of the SOTA space, which means modeling the relevant infor- mation that a system/entity has to collect to become aware of its location in such space, a necessary condition to recognize whether it is correctly behaving and adapt its actions whenever necessary; (ii) identifying the set of goals for each entity and for the system as a whole, which also implies identi- fying when specific goals gets activated and any possible constraint on the trajectory to be followed while trying to achieve such goals. The SOTA modeling approach is very useful to understand and model the functional and adap- tation requirements, and to check the correctness of such specifications (as described in [AZ12]). However, when a designer considers the actual design of the system, SOTA ...
Requirements Engineering. The ADVANCE7 project (along with the Deploy project, covered in the next section) is based around the Rodin tool and the Event-B formalism. ADVANCE extended Rodin to allow for FMI co-simulation between Event-B models and arbitrary FMUs. The Rodin tool supports ProR for managing textual requirements including hierarchies and links. The tool is now part of the Eclipse incubator program. The COMPASS8 project developed an approach for the development of Architectural Frameworks (COMPASS Architectural Framework Framework - CAFF). This was used to develop guidelines for SoS requirements modelling 9 called SoS-ACRE. Although the CAFF is agnostic with respect to modelling language, the guidelines were realised in SysML and insight from this fed into the SysML guidance given in Deliverable D3.1a [FGPP15]. The SPEEDS10 project developed a Contract Specification Language (CSL), allowing col- laborating teams to define requirements and promises about the components that their team is developing. This was extended in the DANSE11 project to become the Goal and Contract Specification Language (GCSL), which permits architectural aspects to be captured in OCL12 (Object Constraint Language) notation. DANSE methodology docu- ments13 advocate formalising requirements late in the architectural design workflow. The TOPCASED project included TOPCASED-Req, a solution to manage requirement traceability in model for aviation, following the DO-178B lifecycle. The AGeSys14 Project improved TOPCASED-Req to move away focus on the whole requirements lifecycle as 7xxxx://xxx.xxxxxxx-xxx.xx/ 8xxxx://xxx.xxxxxxx-xxxxxxxx.xx/ 9xxxx://xxx.xxxxxxx-xxxxxxxx.xx/Project/Deliverables/D211.pdf 00xxx.xxxxxx.xx.xxx 11xxxx://xxxxx-xx.xx/ 00xxx.xxx.xxx/xxxx/XXX 13xxxx://xxxxx-xx.xx/home/pdf/danse_d4.3_methodology_v2.pdf 14xxxx://xxx.xxxxxxxxx-xxxxxx.xxx/sites/default/files/encart_html/index.html#1 a new tool called becomes ReqCycle. TOPCASED and ReqCycle now form part of the PolarSys15 open-source tools for embedded systems. The META tool being developed under DARPA AVM (Adaptive Vehicle Make) pro- gramme makes use of the CyPhyML meta language. In terms of requirements they focus on “executable requirements” that are quantifiable tests that can be automatically checked against models or implementations. This has been demonstrated in OpenModelica. The ENOSYS16 project targeted design space exploration for FPGA design, using the XXXXX UML profile for high-level specification. The Modelio tool was used i...
Requirements Engineering. STATE-OF-THE-ART The overall goal of this section is to provide an overview of the state of the art in recommendation and decision technologies for requirements engineering. This overview will be adapted/extended within the scope of the first two years of OpenReq. Thereafter, we plan to transfer our documentation of OpenReq research results and related work into a corresponding journal publication (the concrete journal is not yet decided). In the following subsections we provide an overview of the state-of-the-art research that exists related to recommendation and decision technologies in requirements engineering. In the context of each subsection, we also discuss OpenReq research goals related to the advancement of the existing state-of-the-art.
Requirements Engineering. Requirements Engineering (RE) can be considered as one of the most critical phases in software development processes. Incomplete, low-quality, and suboptimally prioritized requirements can lead to cost explosions and often to the cancellation of a software project [LEF1997]. A major reason is that stakeholders in software projects often take suboptimal decisions. For example, highly relevant requirements are implemented in late releases. Such decisions trigger, for example, opportunity costs since the earlier the software is applicable, the earlier business processes can be supported more efficiently. The reasons for suboptimal decisions are manifold. For example, the relevance of a requirement could have been underestimated simply due to the lack of decision-relevant knowledge of stakeholders who are in charge of prioritizing and release planning. The reason behind this could be a low degree of knowledge exchange between stakeholders. For similar reasons, the quality of individual requirements could have been overestimated. Due to anchoring effects [SFL+2015], the opinion of one stakeholder can have an influence on the opinions of other stakeholders. Polarization effects [ARF2018] can lead to situations where groups take decisions that are riskier compared to the riskiness of decisions taken by individual stakeholders. Such decision biases can be regarded as a major obstacle for high-quality decision making [FBS+2018]. Configuration Technologies & Constraint-based Reasoning Configuration [FHB+2014, FAT2016] is considered as one of the most successful applications of Artificial Intelligence technologies. It is applied in many domains such as financial services [FIS+2007] and telecommunication [FHB+2014]. Configuration environments are typically single-user oriented, i.e., the underlying assumption is that a specific user is in charge of completing the configuration task. However, considering configuration as a single user task can lead to suboptimal decisions [FAT2016]. For example, release planning is a task that typically requires the engagement of a group of stakeholders where the knowledge and preferences of all stakeholders should be taken into account in order to be able to achieve high- quality decisions [DR2009, AFF+2017]. Configuration technologies can be considered as a major technology to support efficient and at the same time personalized and group-oriented prioritization, re-prioritization, release planning, and release re-planning. Thus, conf...
Requirements Engineering. 6.6.2 SLA Negotiation 6.6.3 SLA Agreement 6.6.4 SLA Monitoring 6.6.5 SLA Expiration Description/Summary Service Level Agreement Management is responsible for establishing, reviewing and cancellation of Service Level Agreements (SLAs) with customer. Service Level Agreements are based on Service Design are negotiated and agreed with the customer need the Supply Management Process for the supply of services (agreed in supplier contracts)on service levels (SLAs) from external partners (if needed) need the Supply Management Process for the supply of services (agreed in UCs) on service levels (OLAs) from internal partners (if needed) Service Level Agreement Management in ... ITIL V2: part of Service Delivery ITIL V3: part of Service Design ISO/IEC 20000: part of Service Delivery Processes COBIT: Objectives The purpose of Service Level Agreement Management is to manage Service Level Agreements in a way that customer requirements are reflected and contracts are coordinated and harmonized. Basic requirement is to balance the value and quality for the customer with the costs of service. Service Agreement Management contributes to an integrated Service Management approach by achieving the following goals: Every service provided to a customer is covered by an SLA containing a description of the guaranteed and agreed service level. To achieve the service level targets, OLAs and UCs are established in support of the SLAs by the Supply Management Process. Roles
Requirements Engineering. Service Level Agreement Staff forms together with the CRM Staff a team and decide on who is the requirements engineering agent. This agent gets in contact with the customer and defines customer requirements. This person needs to be an expert concerning the service offered by the company, to match customer requirements with existing services or to define if required services are possible to be delivered in commercial and technical view. A close cooperation with the Service Design Process, CRM and all Operation Processes is necessary. The final regiments need to be written and agreed with the customer. An requirement document is provided. Activity Specific Rules: define requirement with customer check requirement with internal processes if technical deliverable commercial feasible support a business case definition together with CRM process set status on "engineered" SLA Negotiation Requirements are prices and then discussed with the customer. Different options of service delivery are discussed. In addition for each service a service level is defined, proceed and discussed. This pricing of diverse service levels is supported by the Service Level Management Process. A final agreement version is distributed and discussed between all involved parties. Activity Specific Rules: trigger Service Level Management Process for price information on diverse Service level of Service to customer combine all information to offer/ agreement discuss with customer if final version agreed - provide final contract version to all parties for signing set status on "negotiated" SLA Agreement Final version of the contract is checked by all parties including now the check layer. Final version is distributed, signed and documented in the contract/ agreement data base (see CRM Process). Activity Specific Rules: Provide final check of agreement including check by law Sign contract Document contract by providing is to the CRM Process Set status on "agreed" SLA Monitoring Existing agreements need to be monitored: All aspects NOT involving the service quality are monitored by the CRM process All service quality concerning aspects are monitored by Service Level Management Process Activity Specific Rules: monitor quality of service -> trigger Service Level Management Process for monitoring, recive and anlyse information monitor all other contract aspects -> trigger CRM Process, recive and analyse information monitor agreement for end of service (based on date, conditions or customer request...
