Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh 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: 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 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: Boehm estimated that: The late correction of requirements errors could cost up to 200 times as much as correction during such requirements engineering 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: 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 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 Major causes of failure of projects A survey over 8000 projects undertaken by 350 US companies A survey over 8000 projects undertaken by 350 US companies The lack of user involvement (13%) The lack of user involvement (13%) Requirements incompleteness (12%) Requirements incompleteness (12%) Changing requirements (11%) Changing requirements (11%) Unrealistic expectations (6%) Unrealistic expectations (6%) Unclear objectives (5%) Unclear objectives (5%) On the European side On the European side Some problems in requirements specification (>50%) Some problems in requirements specification (>50%) Some problems in requirements management (<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 Ross and Schoman stated that Requirements definition Requirements definition is a careful assessment of the needs that a system is to fulfill. 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 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 what system features will serve and satisfy this context. It must say how the system is to be constructed 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? 1. 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 a world of human organizations or physical laws to a technical artifact that must be integrated in it high level objectives to operational prescriptions high level objectives to operational prescriptions Informal to formal 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.) 2. Non-functional concerns such as Safety Safety Security Security Usability Usability Flexibility Flexibility Performance Performance … are often conflicting 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.) 3. There are multiple parties such as Customers Customers Commissioners Commissioners Users Users Domain experts Domain experts Requirements engineers Requirements engineers … involved in the RE process, which have conflicting viewpoints 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.) 4. Requirement specifications may suffer a great variety of deficiencies such as errors errors inadequacies with respect to the real world inadequacies with respect to the real world incompletenesses incompletenesses contradictions contradictions ambiguities ambiguities … That may yield undesired consequences such as That may yield undesired consequences such as waste of time waste of time generation of new errors generation of new errors noises noises forward references 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.) 5. RE covers multiple intertwined activities Domain analysis Domain analysis Elicitation Elicitation Negotiation and agreement Negotiation and agreement Specification Specification Specification analysis Specification analysis Documentation Documentation Evolution Evolution

Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh 12 Modeling A core process in RE A core process in RE The existing system has to be modeled in some way or another The existing system has to be modeled in some way or another The alternative hypothetical systems have to be modeled as well The alternative hypothetical systems have to be modeled as well On one hand On one hand Models result from Models result from Domain analysis, Elicitation, Specification Analysis, Negotiation Domain analysis, Elicitation, Specification Analysis, Negotiation On the other hand On the other hand Models guide further Models guide further Domain analysis, Elicitation, Specification Analysis, Negotiation Domain analysis, Elicitation, Specification Analysis, Negotiation Models provide the basis for documentation and evolution 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 Yue stated that The integration of explicit goal representations in requirements models provides a criterion for requirements completeness 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 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. 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 Conflicts among requirements often arise from multiple stakeholders viewpoints Fore sake of adequacy and completeness during requirements elicitation it is essential that 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 the viewpoints of all parties involved, be captured and eventually integrated in a consistent way Centralized approach Centralized approach The viewpoints are translated into some logic-based “assembly” language for global analysis The viewpoints are translated into some logic-based “assembly” language for global analysis Viewpoints integration then amounts to some form of conjunction Viewpoints integration then amounts to some form of conjunction Distributed approach Distributed approach Viewpoints have specific consistency rules associated with them Viewpoints have specific consistency rules associated with them Consistency checking is made by evaluating the corresponding rules on pairs of viewpoints 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 These techniques have been proposed for elicitation and for validation for elicitation and for validation To elicit requirements in hypothetical situations To elicit requirements in hypothetical situations to help identify exceptional cases to help identify exceptional cases to populate more abstract conceptual models to populate more abstract conceptual models to validate requirements in conjunction with prototyping to validate requirements in conjunction with prototyping for animation for animation to plan generation tools to plan generation tools To generate acceptance test cases 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. 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 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 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 A goal-based approach for architecture derivation might be useful and is feasible The general principle is to: The general principle is to: Use functional goals assigned to software agents to derive a first abstract dataflow architecture Use functional goals assigned to software agents to derive a first abstract dataflow architecture Use non-functional goals to refine dataflow connectors 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 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 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 The gap between RE research and formal specification research is another important one to bridge Requirement reengineering 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. 22 nd International Conference on Software Engineering, Limerick, June 2000, ACM Press Axel van Lamsweerde, “Requirements Engineering in the Year 00: A Research perspective”, Invited paper for ICSE’2000 to appear in Proc. 22 nd 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