scispace - formally typeset
Search or ask a question
Proceedings ArticleDOI

Towards modelling and reasoning support for early-phase requirements engineering

Eric Yu1
05 Jan 1997-Requirements Engineering (IEEE Computer Society)-pp 226-235
TL;DR: This paper argues that a different kind of modelling and reasoning support is needed for the early phase of requirements engineering, which aims to model and analyze stakeholder interests and how they might be addressed, or compromised, by various system-and-environment alternatives.
Abstract: Requirements are usually understood as stating what a system is supposed to do, as apposed to how it should do it. However, understanding the organizational context and rationales (the "Whys") that lead up to systems requirements can be just as important for the ongoing success of the system. Requirements modelling techniques can be used to help deal with the knowledge and reasoning needed in this earlier phase of requirements engineering. However most existing requirements techniques are intended more for the later phase of requirements engineering, which focuses on completeness, consistency, and automated verification of requirements. In contrast, the early phase aims to model and analyze stakeholder interests and how they might be addressed, or compromised, by various system-and-environment alternatives. This paper argues, therefore, that a different kind of modelling and reasoning support is needed for the early phase. An outline of the i* framework is given as an example of a step in this direction. Meeting scheduling is used as a domain example.

Content maybe subject to copyright    Report

Citations
More filters
Book ChapterDOI
04 Jul 2009
TL;DR: This chapter reviews the state of the art on the treatment of non-functional requirements (hereafter, NFRs), while providing some prospects for future directions.
Abstract: 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.

2,443 citations


Cites background from "Towards modelling and reasoning sup..."

  • ...The i* family: i* [30], Tropos [31] and GRL(Goal Requirements Language) [32] inherited the concept of softgoal from the NFR Framework, aiming at dealing with softgoals, or non-functionality related attributes, as a first class modeling concept....

    [...]

  • ...In i* [30], the links among softgoals and operations (tasks or resources) are more explicit, since modeling is carried out simultaneously in the context of the Strategic Rationale (SR) diagram....

    [...]

Proceedings ArticleDOI
01 May 2000
TL;DR: An overview of the field of software systems requirements engineering (RE) is presented, describing the main areas of RE practice, and highlights some key open research issues for the future.
Abstract: 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.

2,114 citations


Cites background from "Towards modelling and reasoning sup..."

  • ...This behaviour can be expressed in terms organisational objectives (or goals) and associated tasks and resources [70]....

    [...]

Proceedings ArticleDOI
TL;DR: The paper compares the main approaches to goal modeling, goal specification and goal-based reasoning in the many activities of the requirements engineering process and suggests what a goal-oriented requirements engineering method may look like.
Abstract: 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.

1,729 citations


Cites background or methods from "Towards modelling and reasoning sup..."

  • ...Goal-based specifications can also be acquired by retrieving structurally and semantically analog specifications in a repository of reusable specification components, and then transposing the specifications found according to the structural and semantic matching revealed by the retrieval process [ Mas97 ]....

    [...]

  • ...In the i* framework [Yu93, Yu97 ], various types of agent dependency links are defined to model situations where an agent depends on another for a goal to be achieved, a task to be achieved, or a resource to become available....

    [...]

  • ...In the i* framework [Yu93, Yu97], various types of agent dependency links are defined to model situations where an agent depends on another for a goal to be achieved, a task to be achieved, or a resource to become available....

    [...]

  • ...Goal types and taxonomies are used to define heuristics for goal acquisition, goal refinement, requirements derivation, and semi-formal consistency/completeness checking [Dar93, Sut93, Ant98, Chu00, Ant01], or to retrieve goal specifications in the context of specification reuse [ Mas97 ]....

    [...]

  • ...When should goals be made explicit? It is generally argued that goal models are built during the early phases of the RE process [Dar93, Yu97 , Dub98]....

    [...]

Journal ArticleDOI
D. Moody1
TL;DR: A set of principles for designing cognitively effective visual notations: ones that are optimized for human communication and problem solving are defined, which form a design theory, called the Physics of Notations, which focuses on the physical properties of notations rather than their logical properties.
Abstract: Visual notations form an integral part of the language of software engineering (SE). Yet historically, SE researchers and notation designers have ignored or undervalued issues of visual representation. In evaluating and comparing notations, details of visual syntax are rarely discussed. In designing notations, the majority of effort is spent on semantics, with graphical conventions largely an afterthought. Typically, no design rationale, scientific or otherwise, is provided for visual representation choices. While SE has developed mature methods for evaluating and designing semantics, it lacks equivalent methods for visual syntax. This paper defines a set of principles for designing cognitively effective visual notations: ones that are optimized for human communication and problem solving. Together these form a design theory, called the Physics of Notations as it focuses on the physical (perceptual) properties of notations rather than their logical (semantic) properties. The principles were synthesized from theory and empirical evidence from a wide range of fields and rest on an explicit theory of how visual notations communicate. They can be used to evaluate, compare, and improve existing visual notations as well as to construct new ones. The paper identifies serious design flaws in some of the leading SE notations, together with practical suggestions for improving them. It also showcases some examples of visual notation design excellence from SE and other fields.

1,200 citations


Cites background from "Towards modelling and reasoning sup..."

  • ...i* [150], one of the leading requirements engineering notations, uses labels to differentiate between most of its relationship types [88]....

    [...]

Book ChapterDOI
TL;DR: The goal of this roadmap paper is to summarize the state-of-the-art and to identify critical challenges for the systematic software engineering of self-adaptive systems.
Abstract: The goal of this roadmap paper is to summarize the state-of-the-art and to identify critical challenges for the systematic software engineering of self-adaptive systems. The paper is partitioned into four parts, one for each of the identified essential views of self-adaptation: modelling dimensions, requirements, engineering, and assurances. For each view, we present the state-of-the-art and the challenges that our community must address. This roadmap paper is a result of the Dagstuhl Seminar 08031 on "Software Engineering for Self-Adaptive Systems," which took place in January 2008.

1,133 citations


Cites background from "Towards modelling and reasoning sup..."

  • ...In goal-modelling notations such as KAOS [14] and i! [15], there is no explicit support for uncertainty or adaptivity....

    [...]

References
More filters
Book
01 Jan 1969
TL;DR: A new edition of Simon's classic work on artificial intelligence as mentioned in this paper adds a chapter that sorts out the current themes and tools for analyzing complexity and complex systems, taking into account important advances in cognitive psychology and the science of design while confirming and extending Simon's basic thesis that a physical symbol system has the necessary and sufficient means for intelligent action.
Abstract: Continuing his exploration of the organization of complexity and the science of design, this new edition of Herbert Simon's classic work on artificial intelligence adds a chapter that sorts out the current themes and tools -- chaos, adaptive systems, genetic algorithms -- for analyzing complexity and complex systems. There are updates throughout the book as well. These take into account important advances in cognitive psychology and the science of design while confirming and extending the book's basic thesis: that a physical symbol system has the necessary and sufficient means for intelligent action. The chapter "Economic Reality" has also been revised to reflect a change in emphasis in Simon's thinking about the respective roles of organizations and markets in economic systems.

11,845 citations

Book
01 Jan 1995
TL;DR: In this paper, the authors set aside much of the received wisdom of the last 200 years of industrial management and in its place presented a new set of organizing principles by which managers can rebuild their businesses.
Abstract: "Reengineering the Corporation" sets aside much of the received wisdom of the last 200 years of industrial management and in its place presents a new set of organizing principles by which managers can rebuild their businesses. The book provides numerous examples and in-depth case studies of how leading organizations are achieving significant competitive gains through reengineering: How Ford Motor reduced the size of its North American accounts payable organization by 80% while improving the process; how IBM is leasing subsidiary cut its deal-making process from seven days to four hours; and how Taco Bell used a new set of production and management processes to fuel a six-fold growth in revenue.

5,812 citations


Additional excerpts

  • ..., [22])....

    [...]

Book
01 Jan 1993

2,921 citations


"Towards modelling and reasoning sup..." refers background in this paper

  • ...Instead of automating well-established business processes, systems are now viewed as “enablers” for innovative business solutions (e.g., [ 22 ])....

    [...]

Journal ArticleDOI
TL;DR: A layered behavioral model is used to analyze how three of these problems—the thin spread of application domain knowledge, fluctuating and conflicting requirements, and communication bottlenecks and breakdowns—affected software productivity and quality through their impact on cognitive, social, and organizational processes.
Abstract: The problems of designing large software systems were studied through interviewing personnel from 17 large projects. A layered behavioral model is used to analyze how three of these problems—the thin spread of application domain knowledge, fluctuating and conflicting requirements, and communication bottlenecks and breakdowns—affected software productivity and quality through their impact on cognitive, social, and organizational processes.

2,210 citations


"Towards modelling and reasoning sup..." refers background in this paper

  • ...As discovered in empirical studies (e.g., [ 11 ]), poor understanding of the domain is a primary cause of project failure....

    [...]

Journal ArticleDOI
01 Apr 1993
TL;DR: An approach to requirements acquisition is presented which is driven by higher-level 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.
Abstract: 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

2,092 citations