There is a simple condition, called “fitness improvement” that triggers (i.e., is both necessary and sufficient for) the change of a requirements model. The problem with it is that it is simple to define, but expensive to check when it verifies in practice. What is that condition, and why is checking it expensive? In discussing…
What could it mean that a “requirement evolves”? Is it the same to say that a requirement evolves and that it changes? How are requirements evolution and change related to updates of sets of requirements? The term “evolution” has rigorous definitions in biology. A textbook one is as follows (it is carried over from [1],…
In a functional organizational structure, each team is responsible for a set of something called functions. An essential property of a functional team is homogeneity of knowledge within the team: people in it usually share similar educational background, similar expertise, similar career development paths. A clear benefit of functional organization is that it allows a…
What determines the distribution of knowledge and information flow between teams in a firm? Why are some bigger than others? Why do some teams collaborate more with others? Many small choices made by different people, inside and outside a team, accumulate to hard-to-reverse distribution of expertise, decision authority, and resources, that is, into the set…
Requirements Engineering (RE) focuses on eliciting, modelling, and analyzing the requirements and environment of a system-to-be in order to design its specification. The design of the specification, usually called the Requirements Problem (RP), is a complex problem solving task, as it involves, for each new system-to-be, the discovery and exploration of, and decision making in,…
Innovative companies need an agile approach towards product and service requirements, to rapidly respond to and exploit changing conditions. The agile approach to requirements must nonetheless be systematic, especially with respect to accommodating legal and non-functional requirements. This paper examines how to support lightweight, agile requirements processes which can still be systematically modeled, analyzed and…
Changing requirements are widely regarded as one of the most significant risks for software systems development. However, in today’s business landscape, these changing requirements also represent opportunities to exploit new and evolving business conditions. In consonance with other agile methods, we advocate requirements engineering techniques that embrace and accommodate requirements change. This agile approach to…
Requirements Engineering (RE) focuses on eliciting, modeling, and analyzing the requirements and environment of a system-to-be in order to design its specification. The design of the specification, known as the Requirements Problem (RP), is a complex problem-solving task because it involves, for each new system, the discovery and exploration of, and decision making in a…
When implementing (semi-)automatic business processes with services, engineers are facing two sources of variability. One source of variability are alternative refinements and decompositions of requirements. The other source of variability is that various (combinations of) services can be used to satisfy the same requirements. We suggest a method based on the use of a goal…
This paper investigates aspects of the problem of software evolution resulting from top-level requirements change. In particular, while most research on design for software focuses on finding some correct solution, this ignores that such a solution is often only correct in a particular, and often short-lived, context. Using a logic-based goal-oriented requirements modeling language, the…
The vision for self-adaptive systems (SAS) is that they should continuously adapt their behavior at runtime in response to changing user’s requirements, operating contexts, and resource availability. Realizing this vision requires that we understand precisely how the various steps in the engineering of SAS depart from the established body of knowledge in information systems engineering….
The requirements roadmap concept is introduced as a solution to the problem of the requirements engineering of adaptive systems. The concept requires a new general definition of the requirements problem which allows for quantitative (numeric) variables, together with qualitative (binary boolean) propositional variables, and distinguishes monitored from controlled variables for use in control loops. We…
Service Level Agreements (SLAs) are used in Service-Oriented Computing to define the obligations of the parties involved in a transaction. SLAs define the service users’ Quality of Service (QoS) requirements that the service provider should satisfy. Requirements defined once may not be satisfiable when the context of the web services changes (e.g., when requirements or…
A pluripotent information system is an open and distributed information system that (i) automatically adapts at runtime to changing operating conditions, and (ii) satisfies both the requirements anticipated at development time, and those unanticipated before but relevant at runtime. Engineering pluripotency into an information system therefore responds to two recurring critical issues: (i) the need…
Open service-oriented systems which autonomously and continually satisfy users’ service requests to optimal levels are an appropriate response to the need for increased automation of information systems. Given a service request, an open service-oriented system interprets the functional and nonfunctional requirements laid out in the request and identifies the optimal selection of services-that is, identifies…
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 architecture involves mediator Web services coordinating other Web services into compositions necessary to fulfill user…
It is not feasible to engineer requirements for adaptable and open service-oriented systems (AOSS) by specifying stakeholders’ expectations in detail during system development. Openness and adaptability allow new services to appear at runtime so that ways in, and degrees to which the initial functional and nonfunctional requirements will be satisfied may vary at runtime. To…