The Role of Specification

Part of the Texts in Computer Science book series (TCS)


Software plays a prominent and critical role in large business applications, health care industry, technical endeavors in space missions, and control systems for airlines, railways and telecommunications. In turn, software affects every aspect of human endeavor including the control and delivery of most of the services that we depend on. The World Wide Web (WWW) has introduced new opportunities for business and social networking, while at the same time has raised concerns on security, privacy, and reliability of information content and its use. Software for managing these applications are complex to construct. The source of complexity of a software product lies in the identification of a set of adequate functional and non-functional requirements from domain analysis, specifying system integrity constraints, and gathering the vast amount of knowledge necessary to precisely describe the expected interaction of the software with its environment. When all requirements are not properly understood, recorded, and communicated within the development team, there is a gap between the documented requirements and the requirements actually needed for correct functioning of the system. The inability in mastering the complexity leads to this discrepancy, which is the root cause of software errors. Precise documentation of domain models and system requirements with sufficient detail to cover unexpected worst-case scenarios is a good defense against system errors. Formal methods can provide a foundation for describing complex systems, for reasoning about the behavior of software systems, and can be a complimentary approach to traditional software development methodologies.


Software Development Domain Analysis Software Complexity Software Development Process Behavioral Specification 


  1. 1.
    Alford M (1985) SREM at the age of eight. IEEE Comput 18:4 CrossRefGoogle Scholar
  2. 2.
    Basili VR (1980) Quantitative software complexity models: a panel summary. In: Basili VR (ed) Tutorial on models and methods for software management and engineering. IEEE Computer Society Press, Los Alamitos Google Scholar
  3. 3.
    Brooks FP Jr (1975) The mythical man-month: essays on software engineering. Addison-Wesley, Reading Google Scholar
  4. 4.
    Brooks FP Jr (1987) No silver bullet: essence and accidents of software engineering. IEEE Comput 20(4):10–19 MathSciNetCrossRefGoogle Scholar
  5. 5.
    Brooks RA (1991) Intelligence without reason. MIT AI Lab Technical Report No 1293 Google Scholar
  6. 6.
    Butler RW (1996) An introduction to requirements capture using PVS: specification of a simple autopilot. In: NASA technical memorandum 110255. Langley Research Center, Hampton Google Scholar
  7. 7.
    Carnot M, DaSilva C, Dehbonei B, Meija F (1992) Error-free software development for critical systems using the B-Methodology. In: Third international software symposium on software reliability engineering Google Scholar
  8. 8.
    Cheverst K, Davies N, Mitchell K, Friday A, Efstratiou C (2000) Developing a context-aware electronic tourist guide: some issues and experiences. CHI Lett 2(1):1–6 Google Scholar
  9. 9.
    Chandrasekaran B, Josephson JR, Benjamins VR (1999) What are ontologies and why do we need them? IEEE Intell Syst 14(1):20–26 CrossRefGoogle Scholar
  10. 10.
    Crow J, De Vito BL (1996) Formalizing space shuttle software requirements. In: Proceedings of ACM SIGSOFT workshop on formal methods in software practice, San Diego, CA, January 1996 Google Scholar
  11. 11.
    Curtis B, Sheppard SB, Milliman P, Borst MN, Love T (1979) Measuring the psychological complexity of software maintenance tasks with the Halstead and McCabe metrics. IEEE Trans Softw Eng SE-5(2):96–104 CrossRefGoogle Scholar
  12. 12.
    Evans E (2004) Domain-driven design: tackling complexity in the heart of software. Addison-Wesley, New York Google Scholar
  13. 13.
    Goodenough JB, Gerhart S (1977) Towards a theory of test data selection criteria. In: Yeh RT (ed) Current trends in programming methodology, vol 2. Prentice-Hall, Englewood Cliffs, pp 44–79 Google Scholar
  14. 14.
    Harel D (1992) Biting the silver bullet: toward a brighter future for system development. IEEE Comput 25(1):8–20 CrossRefGoogle Scholar
  15. 15.
    Heninger KL (1989) Specifying software requirements for complex systems: new techniques and their application. IEEE Trans Softw Eng SE-6(1):2–12 CrossRefGoogle Scholar
  16. 16.
    Heninger KL, Kallander JW, Shore JE, Parnas DL (1980) Software requirements for the A-7E aircraft (second printing). NRL Memorandum Report No 3876, Naval Research Laboratories, Washington, DC Google Scholar
  17. 17.
    Jackson D, Thomas M, Millett LI (eds) Committee on Certifiably Dependable Software Systems, National Research Council, Software for dependable systems: sufficient evidence?
  18. 18.
    King T (1994) Formalizing British rail’s signalling rules. In: FME’94: industrial benefit of formal methods. Lecture notes in computer science, vol 873. Springer, Berlin, pp 44–54 Google Scholar
  19. 19.
    Kries B (2007) The future of product development. In: Proceedings of the 17th CIRP design conference. Springer, Berlin Google Scholar
  20. 20.
    Kushilevitz E, Nisan N (1996) Communication complexity. Cambridge University Press, Cambridge CrossRefGoogle Scholar
  21. 21.
    Leveson NG (1991) Software safety in embedded computer systems. Commun ACM 34(2):35–46 CrossRefGoogle Scholar
  22. 22.
    Meyer B (1985) On formalism in specifications. IEEE Softw January:6–26 CrossRefGoogle Scholar
  23. 23.
    Milner R (1993) Elements of interaction. (Turing award lecture). Commun CACM 36(1):78–89 CrossRefGoogle Scholar
  24. 24.
    Naur P (1969) Programming in action clusters. BIT 9(3):250–258 MATHCrossRefGoogle Scholar
  25. 25.
    Neighbors J (1981) Software construction using components. PhD thesis, Department of Computer and Information Science, University of California, Irvine Google Scholar
  26. 26.
    Parnas DL (1986) Can software for the strategic defense initiative ever be error-free? IEEE Comput 19:11 CrossRefGoogle Scholar
  27. 27.
    Parnas DL (1995) Fighting complexity. Invited talk. In: International conference on engineering complex computer systems, ICECCS’95, Fort Lauderdale, Florida, November 1995 Google Scholar
  28. 28.
    Pressman R (2005) Software engineering: a practitioner’s approach. McGraw-Hill, New York Google Scholar
  29. 29.
    Computer Science Technology Board (1990) Scaling up: a research agenda for software engineering. Commun ACM 33(3):281–293 CrossRefGoogle Scholar
  30. 30.
    Smith MK, Welty C, McGuinness DL (2004) Owl web ontology language guide. W3C recommendation, February 2004.
  31. 31.
    Weiser M (1993) Some computer science issues in ubiquitous computing. Commun CACM 36(7):74–84 Google Scholar
  32. 32.
    Wegner P, Goldin D (2003) Computation beyond turing machine. Commun CACM 46(4):100–102 CrossRefGoogle Scholar
  33. 33.
  34. 34.
    Wing J (1995) Hints to specifiers. Manuscript CMU-Cs-95-118R Google Scholar

Copyright information

© Springer-Verlag London Limited 2011

Authors and Affiliations

  1. 1.Dept. Computer Science and Software Eng.Concordia UniversityMontrealCanada
  2. 2.Computer Science DepartmentUniversity of Wisconsin-La CrosseLa CrosseUSA

Personalised recommendations