Separating Concerns in Requirements Analysis: An Example

  • Daniel Jackson
  • Michael Jackson
Part of the Lecture Notes in Computer Science book series (LNCS, volume 4157)


Often, a requirements document is structured as a long list of individual ”requirements”, each describing an anticipated function or user interaction. An alternative approach is to identify a collection of subproblems, each representing an aspect of the larger problem, and to describe each subproblem in isolation, deferring their composition to a later stage. This paper illustrates the approach by applying it to the requirements of the positioning functions of a proton therapy installation. It explains how a flaw in the design of the system can be isolated to a single subproblem, which can be formalized and subjected to automatic analysis.


Requirement Analysis Proton Therapy Prefer Position Requirement Document Gantry Angle 
These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.


Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.


  1. 1.
    Ainsworth, M., Cruickshank, A.H., Groves, L.J., Wallis, P.J.L.: Formal Specification via Viewpoints. In: Proc. 13th New Zealand Computer Conference. New Zealand Computer Society, Auckland (1993)Google Scholar
  2. 2.
    The Alloy Language and Analyzer,
  3. 3.
    Beck, K.: Extreme Programming Explained. Addison-Wesley, Reading (1999)Google Scholar
  4. 4.
    Dijkstra, E.: On the role of scientific thought. EWD 447. In: Dijkstra, E.W. (ed.) Selected Writings on Computing: A Personal Perspective, Neuen, The Netherlands, 30th August 1974, pp. 60–66. Springer, Heidelberg (1982), available at: Google Scholar
  5. 5.
    Finkelstein, A., Kramer, J., Nuseibeh, B., Finkelstein, L., Goedicke, M.: Viewpoints: A Framework for Integrating Multiple Perspectives in System Development. In: International Journal on Software Engineering and Knowledge Engineering, vol. 2(1), pp. 31–57. World Scientific Publishing Company, Singapore (1992)Google Scholar
  6. 6.
    Harrison, W., Ossher, H.: Subject-Oriented Programming – A Critique of Pure Objects. In: Proc. 1993 Conference on Object- Oriented Programming Systems, Languages and Applications (September 1993)Google Scholar
  7. 7.
    Jackson, D.: Structuring Z Specifications with Views. ACM Transactions on Software Engineering and Methodology 4(4), 365–389 (1995)CrossRefGoogle Scholar
  8. 8.
    Jackson, D.: Software Abstractions: Logic, Language, and Analysis. MIT Press, Cambridge (2006)Google Scholar
  9. 9.
    Jackson, M.: Problem Frames: Analyzing and Structuring Software Development Problems. Addison Wesley Professional, Boston (2000)Google Scholar
  10. 10.
    Jackson, D., Jackson, M.: Problem Decomposition for Reuse. Software Engineering Journal 11(1), 19–30 (1996)CrossRefGoogle Scholar
  11. 11.
    Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C., Lopes, C.V., Loingtier, J.-M., Irwin, J.: Aspect-oriented programming. In: Aksit, M., Matsuoka, S. (eds.) ECOOP 1997. LNCS, vol. 1241, pp. 220–242. Springer, Heidelberg (1997)CrossRefGoogle Scholar
  12. 12.
    Rae, A., Jackson, D., Ramanan, P., Flanz, J., Leyman, D.: Critical Feature Analysis of a Radiotherapy Machine. In: Reliability Engineering and System Safety. Elsevier Science, Amsterdam (2004)Google Scholar

Copyright information

© Springer-Verlag Berlin Heidelberg 2006

Authors and Affiliations

  • Daniel Jackson
    • 1
  • Michael Jackson
    • 2
  1. 1.Computer Science and Artificial Intelligence Laboratory Massachusetts Institute of TechnologyCambridge
  2. 2.Independent ConsultantLondonEngland

Personalised recommendations