1 / 26

Requirement Engineering in year 00: A Research Perspective

Requirement Engineering in year 00: A Research Perspective. Axel van Lamsweerde June 2000. Abstract. The paper presents a brief history of the main concepts and techniques developed to date to support the RE task, a number of current

mitchellcoleman
Télécharger la présentation

Requirement Engineering in year 00: A Research Perspective

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Requirement Engineering in year 00: A Research Perspective Axel van Lamsweerde June 2000 AmirKabir University of Technology, Department of Computer Engineering & Information Technology, Intelligent Systems Laboratory, http://ceit.aut.ac.ir/islab Requirements Engineering Course Fall 2007

  2. Abstract The paper presents a brief history of the main concepts and techniques developed to date to support the RE task, a number of current New research trends in RE-specific areas such as goal-oriented requirements elaboration, conflict management, and the handling of abnormal agent behaviors are examined. AmirKabir University of Technology, Department of Computer Engineering & Information Technology, Intelligent Systems Laboratory, http://ceit.aut.ac.ir/islab Requirements Engineering Course Fall 2007

  3. Introduction • Software requirements have been repeatedly recognized during the past 25 years to be a real problem. • Famous saying: • “the requirements for a system do not arise naturally; instead, they need to be engineered and have continuing review and revision”. [Bel76] • “The hardest single part of building a software system is deciding precisely what to build”. [Boe81] AmirKabir University of Technology, Department of Computer Engineering & Information Technology, Intelligent Systems Laboratory, http://ceit.aut.ac.ir/islab Requirements Engineering Course Fall 2007

  4. Introduction (cont.) • System failure because of the lack of requirement engineering is obvious. • An old definition: Requirement engineering must say: • Why a system in needed • What system features will serve & satisfy this context • How the system is to be constructed. AmirKabir University of Technology, Department of Computer Engineering & Information Technology, Intelligent Systems Laboratory, http://ceit.aut.ac.ir/islab Requirements Engineering Course Fall 2007

  5. Introduction (cont.) • requirements engineering must address: • The contextual goals why a software is needed • The functionalities the software has to accomplish to achieve those goals • The constraints restricting how the software accomplishing those functions is to be designed and implemented. • Non-functional concerns are often conflicting. • Most often parties have conflicting viewpoints AmirKabir University of Technology, Department of Computer Engineering & Information Technology, Intelligent Systems Laboratory, http://ceit.aut.ac.ir/islab Requirements Engineering Course Fall 2007

  6. Introduction (cont.) • Requirements engineering covers multiple intertwined activities: • Domain analysis • Elicitation • Negotiation & Agreement • Specification • Specification Analysis • Documentation • Evolution AmirKabir University of Technology, Department of Computer Engineering & Information Technology, Intelligent Systems Laboratory, http://ceit.aut.ac.ir/islab Requirements Engineering Course Fall 2007

  7. The First 25 years: A few research milestones • Modeling appears to be the core process in requirement engineering. • The existing system has to be modeled and the hypothetical system has to be modeled. Therefore, the most of the research to date has been devoted to techniques for modeling and specification. • The early days: • SADT • ERD for modeling the data • Structured analysis for the stepwise modeling of operation • State transition diagram for the modeling of user interaction AmirKabir University of Technology, Department of Computer Engineering & Information Technology, Intelligent Systems Laboratory, http://ceit.aut.ac.ir/islab Requirements Engineering Course Fall 2007

  8. Current issues • Agent-based reasoning • Goal-based reasoning • Viewpoints, facets, conflicts • Scenario-based elicitation & validation AmirKabir University of Technology, Department of Computer Engineering & Information Technology, Intelligent Systems Laboratory, http://ceit.aut.ac.ir/islab Requirements Engineering Course Fall 2007

  9. Agent-based reasoning • A next step was made by realizing that the software-to-be and its environment are both made of active components. Such components may restrict their behavior to ensure the constraints they are assigned to. • Agent-based reasoning is central to requirements engineering since the assignment of responsibilities for goals and constraints among agents in the software-to-be and in the environment is a main outcome of the RE process. • Agents on both sides of the software-environment boundary interact through interfaces that may be visualized through context diagrams AmirKabir University of Technology, Department of Computer Engineering & Information Technology, Intelligent Systems Laboratory, http://ceit.aut.ac.ir/islab Requirements Engineering Course Fall 2007

  10. Goal-based reasoning • The research efforts so far were in the what-how range of requirements engineering. • The integration of explicit goal representations in requirements models provides a criterion for requirements completeness - the requirements are complete if they are sufficient to establish the goal they are refining • A goal corresponds to an objective the system should achieve through cooperation of agents in the software-to-be and in the environment. • Two complementary frameworks arose for integrating goals and goal refinements in requirements models: a formal framework and a qualitative framework. AmirKabir University of Technology, Department of Computer Engineering & Information Technology, Intelligent Systems Laboratory, http://ceit.aut.ac.ir/islab Requirements Engineering Course Fall 2007

  11. Formal Framework • goal refinements are captured through AND/OR graph structures borrowed from problem reduction techniques in artificial intelligence • AND-refinement: satisfying all subgoals in the refinement is a sufficient condition for satisfying the goal • OR-refinement: satisfying one of the refinements is a sufficient condition for satisfying the goal • a conflict link between goals is introduced when the satisfaction of one of them may preclude the satisfaction of the others. • Operationalization links are also introduced to relate goals to requirements on operations and objects. AmirKabir University of Technology, Department of Computer Engineering & Information Technology, Intelligent Systems Laboratory, http://ceit.aut.ac.ir/islab Requirements Engineering Course Fall 2007

  12. Qualitative framework • Weaker versions of such link types are introduced to relate “soft” goals. • The idea is that such goals can rarely be said to be satisfied in a clear-cut sense. Instead of goal satisfaction, goal satisfying is introduced to express that lower-level goals or requirements are expected to achieve the goal within acceptable limits, rather than absolutely • If a goal is AND-decomposed into subgoals and all subgoals are satisficed, then the goal is satisficeable; but if a subgoal is denied then the goal is deniable. If a goal contributes negatively to another goal and the former is satisficed, then the latter is deniable. AmirKabir University of Technology, Department of Computer Engineering & Information Technology, Intelligent Systems Laboratory, http://ceit.aut.ac.ir/islab Requirements Engineering Course Fall 2007

  13. Viewpoints, facets, conflicts • New studies has emphasized the need for handling conflicts at the goal level. • Bohem [Boe95] propose a method for identifying conflicts at the requirements level and characterizing them as differences at goal level; such differences are resolved (e.g., through negotiation) and then down propagated to the requirements level. AmirKabir University of Technology, Department of Computer Engineering & Information Technology, Intelligent Systems Laboratory, http://ceit.aut.ac.ir/islab Requirements Engineering Course Fall 2007

  14. Conflicts • an iterative process model was proposed in which: • all stakeholders involved are identified together with their goals (called win conditions); • conflicts between these goals are captured together with their associated risks and uncertainties; • goals are reconciled through negotiation to reach a mutually agreed set of goals, constraints, and alternatives for the next iteration. AmirKabir University of Technology, Department of Computer Engineering & Information Technology, Intelligent Systems Laboratory, http://ceit.aut.ac.ir/islab Requirements Engineering Course Fall 2007

  15. Scenario-based elicitation & validation • Even though goal-based reasoning is highly appropriate for requirements engineering, goals are sometimes hard to elicit. • Operational scenarios of using the hypothetical system are sometimes easier than finding goals. • A scenario is a temporal sequence of interaction events between the software-to-be and its environment in the restricted context of achieving some implicit purpose(s). • Shortcomings of this method: • The problem with scenarios is that they are inherently partial • Scenarios are generally procedural, thus introducing risks of overspecification. • scenarios leave required properties about the intended system implicit, in the same way as safety/liveness properties are implicit in a program trace AmirKabir University of Technology, Department of Computer Engineering & Information Technology, Intelligent Systems Laboratory, http://ceit.aut.ac.ir/islab Requirements Engineering Course Fall 2007

  16. Back to groundwork • There is a distinction between domain properties (called indicative) and requirements (called optative) • Another important distinction: • System requirements: • are formulated in terms of objects in the real world, in a vocabulary accessible to stakeholders • Software specifications: • Are formulated in terms of objects manipulated by the software in a vocabulary accessible to programmers. AmirKabir University of Technology, Department of Computer Engineering & Information Technology, Intelligent Systems Laboratory, http://ceit.aut.ac.ir/islab Requirements Engineering Course Fall 2007

  17. Requirement Reuse • Requirements refer to specific domains and to specific tasks. • Requirements within similar domains and/or for similar tasks are more likely to be similar than the software components implementing them. AmirKabir University of Technology, Department of Computer Engineering & Information Technology, Intelligent Systems Laboratory, http://ceit.aut.ac.ir/islab Requirements Engineering Course Fall 2007

  18. Eliciting new goals through WHY questions • Why question AmirKabir University of Technology, Department of Computer Engineering & Information Technology, Intelligent Systems Laboratory, http://ceit.aut.ac.ir/islab Requirements Engineering Course Fall 2007

  19. Eliciting new goals through How questions • How question AmirKabir University of Technology, Department of Computer Engineering & Information Technology, Intelligent Systems Laboratory, http://ceit.aut.ac.ir/islab Requirements Engineering Course Fall 2007

  20. Advantages of goal-oriented requirement engineering • Object models and requirements are derived systematically from goals • Goals provide the rationale for requirements • The goal refinement structure provides a comprehensible structure for the requirements document • Alternative goal refinements and agent assignments allow alternative system proposals to be explored • Goal formalization allows refinements to be proved correct and complete. AmirKabir University of Technology, Department of Computer Engineering & Information Technology, Intelligent Systems Laboratory, http://ceit.aut.ac.ir/islab Requirements Engineering Course Fall 2007

  21. Being Pessimistic • The lack of anticipation of exceptional behaviors may result in unrealistic, unachievable and/or incomplete requirements. • Goals also provide a basis for early generation of high-level exceptions which, if handled properly at requirements engineering time, may generate new requirements for more robust systems. • The goal Achieve[CmdMsgSentInTime] may be obstructed by conditions such as: • CommandNotSent, • CommandSentLate, • CommandSentToWrongTrain • Such obstructing conditions are called obstacles. AmirKabir University of Technology, Department of Computer Engineering & Information Technology, Intelligent Systems Laboratory, http://ceit.aut.ac.ir/islab Requirements Engineering Course Fall 2007

  22. Obstacles • Obstacles can be produced for each goal by constructing a goal-anchored fault-tree, that is, a refinement tree whose root is the goal negation. • Formal and heuristic techniques are available for generating obstacles systematically from goal specifications and domain properties • Alternative resolution strategies may then be applied to the generated obstacles in order to produce new or alternative requirements. • Strategies: • Goal substitution Strategy • Agent substitution Strategy AmirKabir University of Technology, Department of Computer Engineering & Information Technology, Intelligent Systems Laboratory, http://ceit.aut.ac.ir/islab Requirements Engineering Course Fall 2007

  23. From Requirements to Architecture • Little work has been devoted to date to techniques for systematically deriving architectural descriptions from requirements specifications. • The general principles of a goal-based approach: • Use functional goals assigned to software agents to derive a first abstract dataflow architecture • Use non-functional goals to refine dataflow connectors. AmirKabir University of Technology, Department of Computer Engineering & Information Technology, Intelligent Systems Laboratory, http://ceit.aut.ac.ir/islab Requirements Engineering Course Fall 2007

  24. More work for the next 25 years! • Efforts should thus be devoted to bridging the gap between RE research and research in software architecture. • things get much more complicated for software evolution. For example, the conflict between requirements volatility and architectural stability is a difficult one to handle. • The gap between RE research and formal specification research is another important one to bridge. • Another area of investigation is requirements reengineering. AmirKabir University of Technology, Department of Computer Engineering & Information Technology, Intelligent Systems Laboratory, http://ceit.aut.ac.ir/islab Requirements Engineering Course Fall 2007

  25. Conclusion • During the last 25 years, a lot of effort has gone into improving the process of requirement engineering • We reviewed a number of important milestones in requirement engineering • We tried to convince the reader that goal-based reasoning is central to requirements engineering • We also tried to suggest that much remains to be done. AmirKabir University of Technology, Department of Computer Engineering & Information Technology, Intelligent Systems Laboratory, http://ceit.aut.ac.ir/islab Requirements Engineering Course Fall 2007

  26. Q&A AmirKabir University of Technology, Department of Computer Engineering & Information Technology, Intelligent Systems Laboratory, http://ceit.aut.ac.ir/islab Requirements Engineering Course Fall 2007

More Related