Pamela Zave
Abstract
Research in requirements engineering has produced an extensive body of knowledge, but there are four areas in which the foundation of the discipline seems weak or obscure. This article shines some light in the “four dark corners,” exposing problems and proposing solutions. We show that all descriptions involved in requirements engineering should be descriptions of the environment. We show that certain control information is necessary for sound requirements engineering, and we explain the close association between domain knowledge and refinement of requirements. Together these conclusions explain the precise nature of requirements, specifications, and domain knowledge, as well as the precise nature of the relationships among them. They establish minimum standards for what information should be represented in a requirements language. They also make it possible to determine exactly what it means for requirements and engineering to be successfully completed.
- ABADI, M. AND LAMPORT, L. 1993. Composing specifications. ACM Trans. Program. Lang. Syst. 15, 1 (Jan.), 73-132. Google Scholar
- ALPERN, B. AND SCHNEIDER, F.B. 1987. Recognizing safety and liveness. Distrib. Comput. 2, 117-126.Google Scholar
- ATLEE, J. M. AND GANNON, J. 1993. Analyzing timing requirements. In Proceedings of the 1993 International Symposium on Software Testing and Analysis. Softw. Eng. Notes 18, 3 (July), 117-127. Google Scholar
- BALZER, R. AND GOLDMAN, N. 1979. Principles of good software specification and their implications for specification language. In Proceedings of the Specifications of Reliable Software Conference. IEEE Computer Society, Washington, D.C., 58-67.Google Scholar
- BRACHMAN, R. J., FIKES, R. E., AND LEVESQUE, H.J. 1983. Krypton: A functional approach to knowledge representation. IEEE Comput. 16, 10 (Oct.), 67-73.Google Scholar
- BUBENKO, J. A., JR., Ed. 1983. On concepts and strategies for requirements and information analysis. In Information Modeling. Chartwell-Bratt, Bromley, England, 125-169.Google Scholar
- CURTIS, B., KRASNER, H., AND ISCOE, N. 1988. A field study of the software design process for large systems. Commun. ACM 31, 11 (Nov.), 1268-1287. Google Scholar
- DARDENNE, A., VAN LAMSWEERDE, A., AND FICKAS, S. 1993. Goal-directed requirements acquisition. Sci. Comput. Program. 20, 3-50. Google Scholar
- DOBSON, J. E., BLYTH, A. J. C., CHUDGE, J., AND STRENS, R. 1994. The ORDIT approach to organisational requirements. In Requirements Engineering: Social and Technical Issues, M. Jirotka and J. A. Goguen, Eds. Academic Press, New York, 87-106. Google Scholar
- DUBOIS, E., Du BoIs, PH., AND PETIT, M. 1993. O-O requirements analysis: An agent perspective. In Proceedings of the 7th European Conference on Object-Oriented Programming (ECOOP 93). Lecture Notes in Computer Science, vol. 707. Springer-Verlag, 458-481. Google Scholar
- FEATHER, M.S. 1987. Language support for the specification and development of composite systems. ACM Trans. Program. Lang. Syst. 9, 2 (Apr.), 198-234. Google Scholar
- FEATHER, M. S. 1994. Towards a derivational style of distributed system design--An example. Automated Softw. Eng. 1, 1 (Mar.), 31-59.Google Scholar
- FEATHER, M. S., FICKAS, S., AND HELM, B.R. 1991. Composite system design: The good news and the bad news. In Proceedings of the 6th Annual Knowledge-Based Software Engineering Conference. IEEE Computer Society, Washington, D.C., 16-25.Google Scholar
- GRIES, D. AND SCHNEIDER, F. B. 1993. A Logical Approach to Discrete Math. Springer- Verlag, Berlin. Google Scholar
- HAREL, D. 1987. Statecharts: A visual formalism for complex systems. Sci. Comput. Program. 8, 231-274. Google Scholar
- HEITMEYER, C., BULL, A., GASARCH, C., AND LABAW, B. 1995a. SCR*: A toolset for specifying and analyzing requirements. In Proceedings of the l Oth Annual Conference on Computer Assurance (COMPASS '95). IEEE, New York, 109-122.Google Scholar
- HEITMEYER, C., LABAW, B., AND KISKIS, D. 1995b. Consistency checking of SCR-style requirements specifications. In Proceedings of the 2nd IEEE International Symposium on Requirements Engineering. IEEE Computer Society, Washington, D.C., 56-63. Google Scholar
- HENINGER, K.L. 1980. Specifying software requirements for complex systems: New techniques and their application. IEEE Trans. Softw. Eng. 6, 1 (Jan.), 2-13.Google Scholar
- HOARE, C. A. R. 1985. Communicating Sequential Processes. Prentice-Hall International, Chichester, U.K. Google Scholar
- ISCOE, N., WILLIAMS, G. B., AND ARANGO, G. 1991. Domain modeling for software engineering. In Proceedings of the 13th International Conference on Software Engineering. IEEE Computer Society, Washington, D.C., 340-343. Google Scholar
- JACKSON, D. 1995a. Structuring Z specifications with views. ACM Trans. Softw. Eng. Methodol. 4, 4 (Oct.), 365-389. Google Scholar
- JACKSON, M. 1978. Information systems: Modelling, sequencing, and transformations. In Proceedings of the 3rd International Conference on Software Engineering. IEEE Computer Society Press, Los Alamitos, Calif., 73-81. Google Scholar
- JACKSON, M. 1983. System Development. Prentice-Hall International, Chichester, U.K. Google Scholar
- JACKSON, M. 1995b. Software Requirements and Specifications: A Lexicon of Practice, Principles, and Prejudices. Addison-Wesley, Reading, Mass. Google Scholar
- JACKSON, M. AND ZAVE, P. 1995. Deriving specifications from requirements: An example. In Proceedings of the 17th International Conference on Software Engineering. ACM, New York, 15-24. Google Scholar
- JARKE, M., BUBENKO, J., ROLLAND, C., SUTCLIFFE, A., AND VASSILIOU, Y. 1992. Theories underlying requirements engineering: An overview of NATURE at genesis. In Proceedings of the IEEE International Symposium on Requirements Engineering. IEEE Computer Society, Washington, D.C., 19-31.Google Scholar
- JEREMAES, P., KHOSLA, S., AND MAIBAUM, T. S.E. 1986. A modal (action) logic for requirements specification. In Software Engineering 86, D. Barnes and P. Brown, Eds. Peter Peregrinus, 278-294.Google Scholar
- JOHNSON, W.L. 1988. Deriving specifications from requirements. In Proceedings of the l Oth International Conference on Software Engineering. IEEE Computer Society, Washington, D.C., 428-438. Google Scholar
- JONES, C. B. 1990. Systematic Software Development Using VDM. 2nd ed. Prentice-Hall International, Chichester, U.K. Google Scholar
- KHOSHAFIAN, S. N. AND COPELAND, G. P. 1990. Object identity. In Readings in Object- Oriented Database Systems, Stanley B. Zdonik and David Maier, Eds. Morgan Kaufmann, San Mateo, Calif., 37-46. Google Scholar
- LAMPORT, L. 1989. A simple approach to specifying concurrent systems. Commun. ACM 32, 1 (Jan.), 32-45. Google Scholar
- LEHMAN, M.M. 1980. Programs, life cycles, and laws of software evolution. Proc. IEEE 68, 9 (Sept.), 1060-1076.Google Scholar
- LEVESON, N. G., HEIMDAHL, M. P. E., HILDRETH, H., AND REESE, J.D. 1994. Requirements specification for process-control systems. IEEE Trans. Softw. Eng. 20, 9 (Sept.), 684-707. Google Scholar
- LISKOV, B. H. AND ZILLES, S.N. 1975. Specification techniques for data abstractions. IEEE Trans. Softw. Eng. 1, 1 (Mar.), 7-19.Google Scholar
- MOSTOW, J. 1983. A problem-solver for making advice operational. In Proceedings of the National Conference on Artificial Intelligence (AAAI-83). AAAI, Menlo Park, Calif., 279-283.Google Scholar
- PARNAS, D. L. AND CLEMENTS, P.C. 1986. A rational design process: How and why to fake it. IEEE Trans. Softw. Eng. 12, 2 (Feb.), 251-257. Google Scholar
- PARNAS, D. L. AND MADLY, g. 1995. Functional documentation for computer systems engineering. Sci. Comput. Program. 25, 41-61. Google Scholar
- SPIVEY, J.M. 1990. Specifying a real-time kernel. IEEE Softw. 7, 5 (Sept.), 21-28. Google Scholar
- SPIVEY, J.M. 1992. The Z Notation: A Reference Manual. 2nd ed. Prentice-Hall, Englewood Cliffs, N.J. Google Scholar
- SWARTOUT, W. AND BALZER, R. 1982. On the inevitable intertwining of specification and implementation. Commun. ACM 25, 7 (July), 438-440. Google Scholar
- TURSKI, W.M. 1988. Time considered irrelevant for real-time systems. BIT 28, 473-486. Google Scholar
- VAN SCHOUWEN, A. g., PARNAS, D. L., AND MADLY, g. 1992. Documentation of requirements for computer systems. In Proceedings of the IEEE International Symposium on RequiremeAts Engineering. IEEE Computer Society, Washington, D.C., 198-207.Google Scholar
- WING, J.M. 1990. A specifier's introduction to formal methods. IEEE Comput. 23, 9 (Sept.), 8-24. Google Scholar
- WORDSWORTH, J.B. 1992. Software Development with Z: A Practical Approach to Formal Methods in Software Engineering. Addison-Wesley, Reading, Mass. Google Scholar
- Yu, E., Du BoIs, PH., DUBOIS, E., AND MYLOPOULOS, g. 1995. From organization models to system requirements: A "cooperating agents" approach. In Proceedings of the 3rd International Conference on Cooperative Information Systems. 194-204.Google Scholar
- ZAVE, P. 1982. An operational approach to requirements specification for embedded systems. IEEE Trans. Softw. Eng. 8, 3 (May), 250-269.Google Scholar
- ZAVE, P. AND JACKSON, M. 1993. Conjunction as composition. ACM Trans. Softw. Eng. Methodol. 2, 4 (Oct.), 379-411. Google Scholar
Index Terms
- Four dark corners of requirements engineering
Recommendations
The role of domain knowledge in requirements elicitation via interviews: an exploratory study
Requirements elicitation is the first activity in the requirements engineering process. It includes learning, surfacing, and discovering the requirements of the stakeholders of the developed system. Various elicitation techniques exist to help analysts ...
Knowledge-based approach to requirements engineering using method and domain knowledge
Within information systems development the correct capture of user requirements plays a central role in the construction of effective and flexible systems. This paper views requirements specification as primarily a knowledge intensive activity, and the ...
Enhancing Domain Knowledge for Requirements Elicitation with Web Mining
APSEC '10: Proceedings of the 2010 Asia Pacific Software Engineering ConferenceTo elicit software requirements, we have to have knowledge about a problem domain, e.g., healthcare, shopping or banking where the software is applied. A description of domain knowledge such as a domain ontology helps requirements analysts to elicit ...
Reviews
Gary Russell Gladden
The authors address four areas of requirements engineering that they believe are still obscure or undefined. The four areas described are formal representations (notations should be grounded in reality), implementation bias (there should be none), focus on action (actors include the environment and the machine), and requirements as a support for specifications. The authors view these four areas as representative of the nature of everything that should be included in a requirements specification language. They elaborate on the four approaches. Limited to the formal aspects of requirements engineering, the paper's main purpose is to clarify, improve, and evaluate present and future approaches to requirements development. When the requirements satisfy each of these areas, requirements engineering is complete. Furthermore, the specification derived from the requirements is implementable. Completeness is achieved when the following five criteria are met. First, all requirements have been accepted by the customer. Second, the domain is well known. Third, the specification does not constrain the environment. Fourth, an implementation satisfies the requirements. Fifth, the specification and the domain are consistent. Using the completeness test above, we are assured that if we are given known requirements, and we know the environment and the machine domains, then a specification exists that satisfies the requirements. Of course, this may be true, but the paper does not show us how to describe these requirements. The four (or more) corners remain dark.
Access critical reviews of Computing literature here
Become a reviewer for Computing Reviews.
Comments