The term ‘‘Internet-of-Things’’ is used as an umbrella keyword for covering various aspects related to the extension of the Internet and the Web into the physical realm, by means of the widespread deployment of spatially distributed devices with embedded identification, sensing and/or actuation capabilities. Internet-of-Things envisions a future in which digital and physical entities can be linked, by means of appropriate information and communication technologies, to enable a whole new class of applications and services. In this article, we present a survey of technologies, applications and research challenges for Internetof-Things.

/pdf/internet-of-things-vision-applications-and-research-4xfstaiv80.pdf

Internet of things: Vision, applications and research challenges

Essentially a software system's utility is determined by both its functionality and its non-functional characteristics, such as usability, flexibility, performance, interoperability and security. Nonetheless, there has been a lop-sided emphasis in the functionality of the software, even though the functionality is not useful or usable without the necessary non-functional characteristics. In this chapter, we review the state of the art on the treatment of non-functional requirements (hereafter, NFRs), while providing some prospects for future directions.

/pdf/on-non-functional-requirements-in-software-engineering-3a6a23qlo6.pdf

On Non-Functional Requirements in Software Engineering

The Web is moving from being a collection of pages toward a collection of services that interoperate through the Internet. The first step toward this interoperation is the location of other services that can help toward the solution of a problem. In this paper we claim that location of web services should be based on the semantic match between a declarative description of the service being sought, and a description of the service being offered. Furthermore, we claim that this match is outside the representation capabilities of registries such as UDDI and languages such as WSDL.We propose a solution based on DAML-S, a DAML-based language for service description, and we show how service capabilities are presented in the Profile section of a DAML-S description and how a semantic match between advertisements and requests is performed.

https://www.cmpe.boun.edu.tr/~pyolum/cmpe596/papers/matchmaking.pdf

Semantic Matching of Web Services Capabilities

This paper presents an overview of the field of software systems requirements engineering (RE). It describes the main areas of RE practice, and highlights some key open research issues for the future.

/pdf/requirements-engineering-a-roadmap-3lcu5ikya8.pdf

Requirements engineering: a roadmap

Requirements analysis includes a preliminary acquisition step where a global model for the specification of the system and its environment is elaborated This model, called requirements model, involves concepts that are currently not supported by existing formal specification languages, such as goals to be achieved, agents to be assigned, alternatives to be negotiated, etc The paper presents an approach to requirements acquisition which is driven by such higher-level concepts Requirements models are acquired as instances of a conceptual meta-model The latter can be represented as a graph where each node captures an abstraction such as, eg, goal, action, agent, entity, or event, and where the edges capture semantic links between such abstractions Well-formedness properties on nodes and links constrain their instances-that is, elements of requirements models Requirements acquisition processes then correspond to particular ways of traversing the meta-model graph to acquire appropriate instances of the various nodes and links according to such constraints Acquisition processes are governed by strategies telling which way to follow systematically in that graph; at each node specific tactics can be used to acquire the corresponding instances The paper describes a significant portion of the meta-model related to system goals, and one particular acquisition strategy where the meta-model is traversed backwards from such goals The meta-model and the strategy are illustrated by excerpts of a university library system

Goal-directed requirements acquisition

Goals capture, at different levels of abstraction, the various objectives the system under consideration should achieve. Goal-oriented requirements engineering is concerned with the use of goals for eliciting, elaborating, structuring, specifying, analyzing, negotiating, documenting, and modifying requirements. This area has received increasing attention. The paper reviews various research efforts undertaken along this line of research. The arguments in favor of goal orientation are first briefly discussed. The paper then compares the main approaches to goal modeling, goal specification and goal-based reasoning in the many activities of the requirements engineering process. To make the discussion more concrete, a real case study is used to suggest what a goal-oriented requirements engineering method may look like. Experience, with such approaches and tool support are briefly discussed as well.

/pdf/goal-oriented-requirements-engineering-a-guided-tour-2uwx0ha66r.pdf

Goal-oriented requirements engineering: a guided tour

Requirements engineering is concerned with the elicitation of high-level goals to be achieved by the envisioned system, the refinement of such goals and their operationalization into specifications of services and constraints and the assignment of responsibilities for the resulting requirements to agents such as humans, devices and software. Requirements engineering processes often result in goals, requirements, and assumptions about agent behavior that are too ideal; some of them are likely not to be satisfied from time to time in the running system due to unexpected agent behavior. The lack of anticipation of exceptional behaviors results in unrealistic, unachievable, and/or incomplete requirements. As a consequence, the software developed from those requirements will not be robust enough and will inevitably result in poor performance or failures, sometimes with critical consequences on the environment. This paper presents formal techniques for reasoning about obstacles to the satisfaction of goals, requirements, and assumptions elaborated in the requirements engineering process. The techniques are based on a temporal logic formalization of goals and domain properties; they are integrated into an existing method for goal-oriented requirements elaboration with the aim of deriving more realistic, complete, and robust requirements specifications. A key principle is to handle exceptions at requirements engineering time and at the goal level, so that more freedom is left for resolving them in a satisfactory way. The various techniques proposed are illustrated and assessed in the context of a real safety-critical system.

/pdf/handling-obstacles-in-goal-oriented-requirements-engineering-1qwyi4hyg7.pdf

Handling obstacles in goal-oriented requirements engineering

A wide range of inconsistencies can arise during requirements engineering as goals and requirements are elicited from multiple stakeholders. Resolving such inconsistencies sooner or later in the process is a necessary condition for successful development of the software implementing those requirements. The paper first reviews the main types of inconsistency that can arise during requirements elaboration, defining them in an integrated framework and exploring their interrelationships. It then concentrates on the specific case of conflicting formulations of goals and requirements among different stakeholder viewpoints or within a single viewpoint. A frequent, weaker form of conflict called divergence is introduced and studied in depth. Formal techniques and heuristics are proposed for detecting conflicts and divergences from specifications of goals/requirements and of domain properties. Various techniques are then discussed for resolving conflicts and divergences systematically by the introduction of new goals or by transforming the specifications of goals/objects toward conflict-free versions. Numerous examples are given throughout the paper to illustrate the practical relevance of the concepts and techniques presented. The latter are discussed in the framework of the KAOS methodology for goal-driven requirements engineering.

Managing conflicts in goal-driven requirements engineering

Recently a number of requirements engineering languages and methods have flourished that not only address 'what' questions but also 'why', 'who' and 'when' questions. The objective of the paper is twofold: to assess the strengths and weaknesses of one of these methodologies on a nontrivial benchmark; and to illustrate and discuss a number of challenging issues that need to be addressed for such methodologies to become effective in supporting real, complex requirements engineering tasks. The problem considered here is that of a distributed meeting scheduler system; the methodology considered is the KAOS goal directed language and method. The issues raised from this case study include goal identification, the "deidelization" of unachievable goals, the handling of interfering goals, the impact of early formal reasoning, the merits of early reuse of abstract descriptions and categories, requirements traceability and the need to link requirements to retractable assumptions, and the potential benefits of hybrid acquisition strategies.

/pdf/goal-directed-elaboration-of-requirements-for-a-meeting-37gvvpaqfs.pdf

Goal-directed elaboration of requirements for a meeting scheduler: problems and lessons learnt

Scenarios are increasingly recognized as an effective means for eliciting, validating, and documenting software requirements. The paper focuses on the use of scenarios for requirements elicitation and explores the process of inferring formal specifications of goals and requirements from scenario descriptions. Scenarios are considered as typical examples of system usage; they are provided in terms of sequences of interaction steps between the intended software and its environment. Such scenarios are in general partial, procedural, and leave required properties about the intended system implicit. In the end such properties need to be stated in explicit, declarative terms for consistency/completeness analysis to be carried out. A formal method is proposed for supporting the process of inferring specifications of system goals and requirements inductively from interaction scenarios provided by stakeholders. The method is based on a learning algorithm that takes scenarios as examples/counterexamples and generates a set of goal specifications in temporal logic that covers all positive scenarios while excluding all negative ones. The output language in which goals and requirements are specified is the KAOS goal based specification language. The paper also discusses how the scenario based inference of goal specifications is integrated in the KAOS methodology for goal based requirements engineering. In particular, the benefits of inferring declarative specifications of goals from operational scenarios are demonstrated by examples of formal analysis at the goal level, including conflict analysis, obstacle analysis, the inference of higher level goals, and the derivation of alternative scenarios that better achieve the underlying goals.

/pdf/inferring-declarative-requirements-specifications-from-zsrppulzo2.pdf

A. van Lamsweerde

Papers

Goal-oriented requirements engineering: a guided tour

Handling obstacles in goal-oriented requirements engineering

Managing conflicts in goal-driven requirements engineering

Goal-directed elaboration of requirements for a meeting scheduler: problems and lessons learnt

Inferring declarative requirements specifications from operational scenarios