Learn More
In their seminal paper in the ACM Transactions on Software Engineering and Methodology, Zave and Jackson established a core ontol-ogy for Requirements Engineering (RE) and used it to formulate the " requirements problem " , thereby defining what it means to successfully complete RE. Given that stakeholders of the system-to-be communicate the information(More)
Representation and reasoning about goals of an information system unavoidably involve the transformation of unclear stakeholder requirements into an instance of a goal model. If the requirements engineer does not justify why one clear form of requirements is chosen over others, the subsequent modeling decisions cannot be justified either. If arguments for(More)
In their seminal paper (ACM T. Softw. Eng. Methodol., 6(1) (1997), 1–30), Zave and Jackson established a core ontology for Requirements Engineering (RE) and used it to formulate the " requirements problem " , thereby defining what it means to successfully complete RE. Starting from the premise that the stakeholders of the system-to-be communicate to the(More)
Increasing automation requires open, distributed, service-oriented systems capable of multicriteria-driven, dynamic adaptation for appropriate response to changing operating conditions. We combine a simple architecture with a novel algorithm to enable openness, distribution, and multi-criteria-driven service composition at runtime. The service-oriented(More)
—Techne is an abstract requirements modeling language that lays formal foundations for new modeling languages applicable during early phases of the requirements engineering process. During these phases, the requirements problem for the system-to-be is being structured, its candidate solutions described and compared in terms of how desirable they are to(More)
Regulatory compliance is increasingly viewed as an essential element of requirements engineering. Laws, but also regulations and policies, frame their provisions through complex structures made of conditions, derogations, exceptions , which together generate a high number of alternative compliance solutions. This paper addresses the problem of modeling,(More)
A requirements engineering artifact is valid relative to the stakeholders of the system-to-be if they agree on the content of that artifact. Checking relative validity involves a discussion between the stakeholders and the requirements engineer. This paper proposes (i) a language for the representation of information exchanged in a discussion about the(More)