1 / 20

Requirements Engineering in the Year 00: A Research perspective

Requirements Engineering in the Year 00: A Research perspective. By: Abbas Rasoolzadegan. Introduction. Bell & Thayer observed that: The requirements for a system do not arise naturally; instead, they need to be engineered and have continuing review and revision. Introduction (Cont.).

helmick
Télécharger la présentation

Requirements Engineering in the 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. Requirements Engineering in the Year 00: A Research perspective By: Abbas Rasoolzadegan Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  2. Introduction • Bell & Thayer observed that: • The requirements for a system do not arise naturally; instead, they need to be engineered and have continuing review and revision Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  3. Introduction (Cont.) • Boehm estimated that: • The late correction of requirements errors could cost up to 200 times as much as correction during such requirements engineering Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  4. Introduction (Cont.) • Brooks stated that: • The hardest single part of building a software system is deciding precisely what to build … Therefore, the most important function that the software builder performs for the client is the iterative extraction and refinement of the product requirements Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  5. Introduction (Cont.) • Major causes of failure of projects • A survey over 8000 projects undertaken by 350 US companies • The lack of user involvement (13%) • Requirements incompleteness (12%) • Changing requirements (11%) • Unrealistic expectations (6%) • Unclear objectives (5%) • On the European side • Some problems in requirements specification (>50%) • Some problems in requirements management (<50%) Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  6. What is RE? • Ross and Schoman stated that • Requirements definition • is a careful assessment of the needs that a system is to fulfill. • It must say why a system is needed, based on current or foreseen conditions, which may be internal operations or an external market. • It must say what system features will serve and satisfy this context. • It must say how the system is to be constructed Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  7. Why the process of RE is complex? • The scope is fairly broad as it ranges from • a world of human organizations or physical laws to a technical artifact that must be integrated in it • high level objectives to operational prescriptions • Informal to formal Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  8. Why the process of RE is complex? (Cont.) • Non-functional concerns such as • Safety • Security • Usability • Flexibility • Performance • … are often conflicting Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  9. Why the process of RE is complex? (Cont.) • There are multiple parties such as • Customers • Commissioners • Users • Domain experts • Requirements engineers • … involved in the RE process, which have conflicting viewpoints Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  10. Why the process of RE is complex? (Cont.) • Requirement specifications may suffer a great variety of deficiencies such as • errors • inadequacies with respect to the real world • incompletenesses • contradictions • ambiguities • … That may yield undesired consequences such as • waste of time • generation of new errors • noises • forward references • … Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  11. Why the process of RE is complex? (Cont.) • RE covers multiple intertwined activities • Domain analysis • Elicitation • Negotiation and agreement • Specification • Specification analysis • Documentation • Evolution Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  12. Modeling • A core process in RE • The existing system has to be modeled in some way or another • The alternative hypothetical systems have to be modeled as well • On one hand • Models result from • Domain analysis, Elicitation, Specification Analysis, Negotiation • On the other hand • Models guide further • Domain analysis, Elicitation, Specification Analysis, Negotiation • Models provide the basis for documentation and evolution Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  13. Modeling (Cont.) • Yue stated that • 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. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  14. Approaches for solve the conflicts among requirements • Conflicts among requirements often arise from multiple stakeholders viewpoints • Fore sake of adequacy and completeness during requirements elicitation it is essential that • the viewpoints of all parties involved, be captured and eventually integrated in a consistent way • Centralized approach • The viewpoints are translated into some logic-based “assembly” language for global analysis • Viewpoints integration then amounts to some form of conjunction • Distributed approach • Viewpoints have specific consistency rules associated with them • Consistency checking is made by evaluating the corresponding rules on pairs of viewpoints Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  15. Scenario-based techniques • These techniques have been proposed • for elicitation and for validation • To elicit requirements in hypothetical situations • to help identify exceptional cases • to populate more abstract conceptual models • to validate requirements in conjunction with prototyping • for animation • to plan generation tools • To generate acceptance test cases Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  16. Being Pessimistic • First-sketch specifications of goals, requirements and assumptions tend to be too ideal. • If so they are likely to be violated from time to time in the running system due to unexpected behavior of agents • The lack of anticipation of exceptional behaviors may result in unrealistic, unachievable and/or incomplete requirements Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  17. From Requirements to Architecture • A goal-based approach for architecture derivation might be useful and is feasible • The general principle is to: • 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, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  18. More work for future • Efforts should be devoted to bridging the gap between RE research and research in software architecture • Another unexpected transition that should be investigated is the systematic derivation of parameter settings from requirements • The gap between RE research and formal specification research is another important one to bridge • Requirement reengineering • … Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  19. Reference • Axel van Lamsweerde, “Requirements Engineering in the Year 00: A Research perspective”, Invited paper for ICSE’2000 to appear in Proc. 22nd International Conference on Software Engineering, Limerick, June 2000, ACM Press Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

  20. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh

More Related