This Article 
 Bibliographic References 
 Add to: 
Handling Obstacles in Goal-Oriented Requirements Engineering
October 2000 (vol. 26 no. 10)
pp. 978-1005

Abstract—Requirements engineering is concerned with the elicitation of high-level goals to be achieved by the envisioned system, the refinement of such goals and their operationalization into specifications of services and constraints and the assignment of responsibilities for the resulting requirements to agents such as humans, devices, and software. Requirements engineering processes often result in goals, requirements, and assumptions about agent behavior that are too ideal; some of them are likely not to be satisfied from time to time in the running system due to unexpected agent behavior. The lack of anticipation of exceptional behaviors results in unrealistic, unachievable, and/or incomplete requirements. As a consequence, the software developed from those requirements will not be robust enough and will inevitably result in poor performance or failures, sometimes with critical consequences on the environment. This paper presents formal techniques for reasoning about obstacles to the satisfaction of goals, requirements, and assumptions elaborated in the requirements engineering process. A first set of techniques allows obstacles to be generated systematically from goal formulations and domain properties. A second set of techniques allows resolutions to be generated once the obstacles have been identified thereby. Our techniques are based on a temporal logic formalization of goals and domain properties; they are integrated into an existing method for goal-oriented requirements elaboration with the aim of deriving more realistic, complete, and robust requirements specifications. A key principle in this paper is to handle exceptions at requirements engineering time and at the goal level, so that more freedom is left for resolving them in a satisfactory way. The various techniques proposed are illustrated and assessed in the context of a real safety-critical system.

[1] E.J. Amoroso, Fundamentals of Computer Security. Prentice Hall, 1994.
[2] T. Anderson and P.A. Lee, Fault Tolerance: Principles and Practice. Prentice Hall, 1981.
[3] A.I. Anton, W.M. McCracken, and C. Potts, "Goal Decomposition and Scenario Analysis in Business Process Reengineering," Proc. CAISE'94, Sixth Conf. Advanced Information Systems Eng., pp. 94-104, Lecture Notes in Computer Science 811, Springer-Verlag, 1994.
[4] J.S. Anderson and S. Fickas, "A Proposed Perspective Shift: Viewing Specification Design as a Planning Problem," Proc. IWSSD-5, Fifth Int'l Workshop Software Specification and Design, pp. 177-184, IEEE, 1989.
[5] T. Anderson, R. de Lemos, and A. Saeed, “Analysis of Safety Requirements for Process Control Systems,” Predictably Dependable Computing Systems, B. Randell, J.C. Laprie, B. Littlewood, and H. Kopetz, eds., Springer-Verlag, 1995.
[6] A. Arora and M.G. Gouda, “Closure and Convergence: A Foundation of Fault-Tolerant Computing,” IEEE Trans. Software Eng., vol. 19, no. 11, pp. 1,015–1,027, 1993.
[7] A. Arora and S. Kulkarni, “Component-Based Design of Multitolerant Systems,” IEEE Trans. Software Eng., vol. 24, no. 1, pp. 63–78, Jan. 1998.
[8] D.M. Berry, “The Safety Requirements Engineering Dilemma,” Proc. Ninth Int'l Workshop Software Specification and Design, Apr. 1998.
[9] A. Borgida, “Language Features for Flexible Handling of Exceptions in Information Systems,” ACM Trans. Database Systems, vol. 10, no. 4, pp. 565–603, Dec. 1985.
[10] Readings in Knowledge Representation, R.J. Brachman and H.J. Levesque eds., Morgan Kaufmann, 1985.
[11] R.W. Butler, S.P. Miller, J.N. Potts, and V.A. Carreno, “A Formal Methods Approach to the Analysis of Mode Confusion,” Proc. 17th Digital Avionics Systems Conference, Nov. 1998, .
[12] E.C. Coffman, M.J. Elphick, and J. Shoshani, “System Deadlocks,” ACM Computing Surveys, vol. 3, no. 2, pp. 67–68, June 1971.
[13] F. Cristian, "Understanding Fault-Tolerant Distributed Systems," Comm. ACM, vol. 34, no. 2, Feb. 1991.
[14] F. Cristian, “Exception Handling,” Software Fault Tolerance, M.R. Lyu ed., 1995.
[15] A. Dardenne, S. Fickas, and A. van Lamsweerde, “Goal-Directed Concept Acquisition in Requirements Elicitation,” Proc. Sixth Int'l Workshop Software Specification and Design, pp. 14–21, 1991.
[16] A. Dardenne, A. van Lamsweerde, and S. Fickas, "Goal-Directed Requirements Acquisition," Science of Computer Programming, pp. 3-50, vol. 20, Apr. 1993.
[17] R. Darimont and A. van Lamsweerde, "Formal Refinement Patterns for Goal-Driven Requirements Elaboration," Proc. FSE'4—Fourth ACM SIGSOFT Symp. Foundations of Software Eng., pp. 179-190,San Francisco, Oct. 1996.
[18] R. Darimont, E. Delor, P. Massonet, and A. van Lamsweerde, “GRAIL/KAOS: An Environment for Goal-Driven Requirements Engineering,” Proc. 20th Int'l Conf. Software Eng. (ICSE '98), vol. 2, pp. 58–62, Apr. 1998.
[19] E.W. Dijkstra, “Hierarchical Ordering of Sequential Processes,” Acta Informatica, vol. 1, pp. 115–138, 1971.
[20] M.B. Dwyer, G.S. Avrunin, and J.C. Corbett, “Patterns in Property Specifications for Finite-State Verification,” Proc. 21st Int'l Conf. Software Eng., pp. 411–420, May 1999.
[21] S. Easterbrook, “Resolving Requirements Conflicts with Computer-Supported Negotiation,” M. Jirotka and J. Goguen eds., pp. 41–65, Academic Press, 1994.
[22] M. Feather, "Language Support for the Specification and Development of Composite Systems," ACM Trans. Programming Languages and Systems, vol. 9, no. 2, pp. 198-234, Apr. 1987.
[23] M. Feather, “Cardinality Evolution in Specifications,” Proc. Eighth Conf. Knowledge-Based Software Eng. (KBSE '93), Sept. 1993.
[24] M. Feather, “Towards a Derivational Style of Distributed System Design,” Automated Software Eng., vol. 1, no. 1, pp. 31-60, 1995.
[25] M.S. Feather et al., "Requirements and Specification Exemplars," Automated Software Eng., Vol. 4, No. 4, Oct. 1997, pp. 419-438.
[26] M. Feather, S. Fickas, A. van Lamsweerde, and C. Ponsard, "Reconciling System Requirements and Runtime Behaviour," Proc. IWSSD'98—Ninth Int'l Workshop Software Specification and Design,Isobe, IEEE CS Press, Apr. 1998.
[27] S. Fickas and R. Helm, "Knowledge Representation and Reasoning in the Design of Composite Systems," IEEE Trans. Software Eng., pp. 470-482, vol. 18, June 1992.
[28] A. Finkelstein, “The London Ambulance System Case Study,” Succ. Eighth Int'l Workshop Software Specification and Design (IWSSD 8), Sept. 1996.
[29] F.C. Gartner, “Fundamentals of Fault-Tolerant Distributed Computing in Asynchronous Environment,” ACM Computing Surveys, vol. 31, no. 1, pp. 1–26, Mar. 1999.
[30] D. Gries, The Science of Programming.New York, Heidelberg, Berlin: Springer-Verlag, 1981.
[31] R.J. Hall, "Explanation-Based Scenario Generation for Reactive System Models," Proc. ASE'98,Hawaii, Oct. 1998.
[32] M.P. Heimdahl and N.G. Leveson, "Completeness and Consistency in Hierarchical State-Based Requirements," IEEE Trans. Software Eng., pp. 363-377, vol. 22, June 1996.
[33] C.L. Heitmeyer, R.D. Jeffords, and B.G. Labaw, "Automated Consistency Checking of Requirements Specifications," ACM Trans. Software Eng. and Methodology, pp. 231-261, vol. 5, July 1996.
[34] G.J. Holzmann, “The Model Checker SPIN,” IEEE Trans. Software Eng., vol. 23, May 1997.
[35] M.A. Jackson, System Development. Prentice Hall, 1983.
[36] M. Jackson and P. Zave, "Domain Descriptions," Proc. RE'93—First Int'l IEEE Symp. Requirements Eng., pp. 56-64, Jan. 1993.
[37] M. Jackson, Software Requirements and Specifications, Addison-Wesley, Reading, Mass., 1995.
[38] D. Jackson, "Elements of Style: Analyzing a Software Design Feature with a Counterexample Detector," Proc. ACM ISSTA'96, pp. 239-249,San Diego, 1996.
[39] M.S. Jaffe, N.G. Leveson, M.P.E. Heimdahl, and B. Melhart, "Software Requirements Analysis for Real-Time Process-Control Systems," IEEE Trans. Software Engineering, vol. 17, no. 3, pp. 241-258, Mar. 1991.
[40] P. Jalote, Fault Tolerance in Distributed Systems. Prentice Hall, 1994.
[41] Real-Time Systems: Specification, Verification and Analysis, M. Joseph ed., Prentice Hall, 1995.
[42] D.O. Keck and P.J. Kuehn, “The Feature and Service Interaction Problem in Telecommunication Systems: A Survey,” IEEE Trans. Software. Eng., vol. 24, no. 10, pp. 779–796, Oct. 1998.
[43] S.E. Keller, L.G. Kahn, and R.B. Panara, “Specifying Software Quality Requirements with Metrics,” System and Software Requirements Eng., R.H. Thayer and M. Dorfman, eds., pp. 145–163, 1990.
[44] S.J.H. Kent, T.S.E. Maibaum, and W.J. Quirk, “Formally Specifying Temporal Constraints and Error Recovery,” Proc. First Int'l Symp. Requirements Eng. (RE '93), pp. 208–215, Jan. 1996.
[45] R. Koymans, Specifying Message Passing and Time-Critical Systems with Temporal Logic, Lecture Notes in Computer Science 651, Springer-Verlag, 1992.
[46] A. van Lamsweerde, "Learning Machine Learning," Introducing a Logic Based Approach to Artificial Intelligence, A. Thayse, ed., vol. 3, pp. 263-356, John Wiley&Sons, 1991.
[47] A. van Lamsweerde, R. Darimont, and P. Massonet, "Goal-Directed Elaboration of Requirements for a Meeting Scheduler: Problems and Lessons Learned," Proc. RE'95—Second Int'l Symp. on Requirements Eng.,York, IEEE, 1995.
[48] A. van Lamsweerde and E. Letier, "Integrating Obstacles in Goal-Driven Requirements Engineering," Proc. ICSE-98: 20th Int'l Conf. Software Eng.,Kyoto, Apr. 1998.
[49] A. van Lamsweerde, R. Darimont, and E. Letier, "Managing Conflicts in Goal-Driven Requirements Engineering," IEEE Trans. Sofware. Eng., special issue on Inconsistency Management in Software Development, Nov. 1998.
[50] A. van Lamsweerde and L. Willemet, “Inferring Declarative Requirements Specifications from Operational Scenarios,” IEEE Trans. Software. Eng., vol. 24, no. 12, pp. 1,089–1,114, Dec. 1998.
[51] “Inquiry Into the London Ambulance Service,” Technical Report, ISBN 0-905133-70-6, The Communications Directorate, South West Thames Regional Authority, Feb. 1993, service/organisation/featursinfo.html .
[52] R. de Lemos, B. Fields, and A. Saeed, “Analysis of Safety Requirements in the Context of System Faults and Human Errors,” Proc. IEEE Int'l Symp. and Workshop Systems Eng. of Computer Based Systems, pp. 374–381, Mar. 1995.
[53] N. Leveson, “Safety Analysis Using Petri Nets,” IEEE Trans. Software Eng., vol. 13, no. 3, Mar. 1987.
[54] N.G. Leveson, Safeware: System Safety and Computers. Addison-Wesley, 1995.
[55] R. Lutz, "Analyzing Software Requirements Errors in Safety-Critical, Embedded Systems," Proc. IEEE Int'l Symp. Requirements Eng., RE '93, pp. 126-133,San Diego, Calif., Jan. 1993.
[56] T. Maibaum, “Temporal Reasoning over Deontic Specifications,” Deontic Logic in Computer Science—Normative System Specification, J. Ch. Meyer and R.J. Wieringa eds., Wiley, 1993.
[57] Z. Manna and A. Pnueli, The Temporal Logic of Reactive and Concurrent Systems. Springer-Verlag, 1991.
[58] Z. Manna and the STep Group, "STeP: Deductive-Algorithmic Verification of Reactive and Real-Time Systems," Proc. CAV'96—Eighth Int'l Conf. Computer-Aided Verification, pp. 415-418, Lecture Notes in Computer Science 1102. Springer-Verlag, July 1996.
[59] P. Massonet and A. van Lamsweerde, "Analogical Reuse of Requirements Frameworks," Proc. IEEE 3rd Int'l Conf. Requirements Eng., IEEE CS Press, 1997, pp. 26–37.
[60] K.L. McMillan, Symbolic Model Checking. Kluwer Academic, 1993.
[61] B. Meyer, “On Formalism in Specifications,” IEEE Software, vol. 2, no. 1, pp. 6–26, Jan. 1985.
[62] Deontic Logic in Computer Science—Normative System Specification, J.Ch. Meyer and R.J. Wieringa eds.,Wiley, 1993.
[63] F. Modugno, N.G. Leveson, J.D. Reese, K. Partridge, and S.D. Sandys, “Integrated Safety Analysis of Requirements Specifications,” Proc. Third Int'l Symp. Requirements Eng. (RE '97), 1997.
[64] J. Mylopoulos, L. Chung, and B. Nixon, "Representing and Using Nonfunctional Requirements: A Process-Oriented Approach," IEEE Trans. Software Eng., pp. 483-497, vol. 18, June 1992.
[65] J. Mylopoulos, L. Chung, and E. Yu, "From Object-Oriented to Goal-Oriented Requirements Analysis," Comm. ACM, vol. 42, no. 1, Jan. 1999, pp. 31-37.
[66] N.J. Nilsson, Problem Solving Methods in Artificial Intelligence. McGraw-Hill, 1971.
[67] B. Nuseibeh, "To Be and Not to Be: On Managing Inconsistency in Software Development," Proc. Eighth Int'l Workshop on Software Specification and Design, IEEE CS Press, Los Alamitos, Calif., 1996, pp. 164-169.
[68] S. Owre, J. Rushby, N. Shankar, and F. von Henke, "Formal Verification for Fault-Tolerant Architectures: Prolegomena to the Design of PVS," IEEE Trans. Software Eng., vol. 21, pp. 107-125, Feb. 1995.
[69] D.L. Parnas and J. Madey, “Functional Documentation for Computer Systems,” Science of Computer Programming, vol. 25, no. 1, pp. 41–61, Oct. 1995.
[70] D.E. Perry, "The Inscape Environment," Int'l Conf. Software Eng. 1989.
[71] C. Potts, "Using Schematic Scenarios to Understand User Needs," Proc. DIS'95—ACM Symp. Designing Interactive Systems: Processes, Practices and Techniques, Univ. of Michigan, Aug. 1995.
[72] B. Potter, J. Sinclair, and D. Till, An Introduction to Formal Specification and Z, second edition. Prentice Hall, 1996.
[73] B. Randel and J. Xu, “The evolution of the recovery block concept,” Software Fault Tolerance, M.R. Lyu, ed., Wiley, 1995.
[74] V. Ratan, K. Partridge, J.D. Reese, and N.G. Leveson, “Safety Analysis Tools for Requirements Specifications,” Proc. Compass 96, June 1996.
[75] J.D. Reese and N. Leveson, “Software Deviation Analysis,” Proc. 19th Int'l Conf. Software Eng. (ICSE '97), pp. 250–260, May 1997.
[76] W.N. Robinson, "Integrating Multiple Specifications Using Domain Goals," Proc. IWSSD-5—Fifth Int'l Workshop Software Specification and Design, pp. 219-225, IEEE, 1989.
[77] W.N. Robinson and S. Volkov, “A Meta-Model for Restructuring Stakeholder Requirements,” Proc. 19th Int'l Conf. Software Eng. (ICSE 19), pp. 140–149, May 1997.
[78] D.T. Ross and K.E. Schoman, “Structured Analysis for Requirements Definition,” IEEE Trans. Software Eng., vol. 3, no. 1, pp. 6–15, 1977.
[79] D.S. Rosenblum, “Towards a Method of Programming with Assertions,” Proc., 14th Int'l Conf. Software Eng. (ICSE 14), pp. 92–104, 1992.
[80] K.S. Rubin and J. Goldberg, "Object Behaviour Analysis," Comm. ACM, vol. 35, no. 9, pp. 48-62, Sept. 1992.
[81] K. Ryan and S. Greenspan, “Requirements Engineering Group Report,” Succeedings Eighth Int'l Workshop Software Specification and Design (IWSSD 8), pp. 22–25, Sept. 1996.
[82] A. Saed, R. de Lemos, and T. Anderson, “Robust Requirements Specifications for Safety-Critical Systems,” Proc. 12th Int'l Conf. Safety, Reliability, and Security (SAFECOMP '93), 1993.
[83] I. Sommerville and P. Sawyer, Requirements Engineering: A Good Practice Guide, John Wiley&Sons, New York, 1998.
[84] A.G. Sutcliffe, N.A. Maiden, S. Minocha, and D. Manuel, “Supporting Scenario-Based Requirements Engineering,” IEEE Trans. Software Eng., vol. 24, no. 12, pp. 1,072–1,088, Dec. 1998.
[85] R. Waldinger, “Achieving Several Goals Simultaneously,” Machine Intelligence, E. Elcock and D. Michie, eds., vol. 8, 1977.
[86] K. Yue, “What Does It Mean to Say That a Specification is Complete?,” Proc. Fourth Int'l Workshop Software Specification and Design (IWSSD 4), 1987.
[87] P. Zave, “Classification of Research Efforts in Requirements Engineering,” ACM Computing Surveys, vol. 29, no. 4, pp. 315–321, 1997.
[88] P. Zave and M. Jackson, “Four Dark Corners of Requirements Engineering,” ACM Trans. Software Eng. and Methodology, vol. 6, no. 1, pp. 1–30, Jan. 1997.

Index Terms:
Goal-oriented requirements engineering, high-level exception handling, obstacle-based requirements transformation, defensive requirements specification, specification refinement, lightweight formal methods.
Axel van Lamsweerde, Emmanuel Letier, "Handling Obstacles in Goal-Oriented Requirements Engineering," IEEE Transactions on Software Engineering, vol. 26, no. 10, pp. 978-1005, Oct. 2000, doi:10.1109/32.879820
Usage of this product signifies your acceptance of the Terms of Use.