Skip to main content
SpringerLink
Log in

Requirement progression in problem frames: deriving specifications from requirements

  • Original Article
  • Published:
Requirements Engineering Aims and scope Submit manuscript

Abstract

A technique is presented for obtaining a specification from a requirement through a series of incremental steps. The starting point is a Problem Frame description, involving a decomposition of the environment into interconnected domains and a formal requirement on phenomena of those domains. In each step, the requirement is moved towards the machine, leaving behind a trail of “breadcrumbs”—partial domain descriptions representing assumptions about the behaviors of those domains. Eventually, the transformed requirement references only phenomena at the interface of the machine and can therefore serve as a specification. Each step is justified by a mechanically checkable implication, ensuring that, if the machine obeys the derived specification and the domain assumptions are valid, the requirement will hold. The technique is formalized in Alloy and demonstrated on two examples.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Log in via an institution

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Institutional subscriptions

Fig. 1
Fig. 2
Fig. 3
Fig. 4
Fig. 5
Fig. 6
Fig. 7
Fig. 8
Fig. 9
Fig. 10
Fig. 11
Fig. 12
Fig. 13
Fig. 14
Fig. 15
Fig. 16
Fig. 17
Fig. 18

Similar content being viewed by others

Notes

  1. We deviate slightly from the standard problem frames notation when drawing an arc indicating that domain D controls phenomenon p . Rather than labeling the arc D!p , we label it p and place an arrow head pointing away from D . When not all phenomena shared by two domains are controlled by the same domain, separate arcs are used. Most of our diagrams omit indications of control all together, as it is not currently relevant to our approach.

  2. The phenomena mentioned by a breadcrumb might be shared amongst several domains, but there must be a single domain that involves all of them. It is this domain that the breadcrumb touches.

  3. If a requirement mentions a phenomenon that is shared between domains, we consider the diagram to be well formed as long as the requirement touches either of those two domains. It is good style, but not necessary, for the requirement to touch the domain that controls the mentioned phenomenon. A push transformation will violate that good style but leave the diagam well formed. Note that the problem frames notation, as given in the problem frames book [5], is ambiguous about this issue.

  4. For the sake of simplicity, we will ignore the delays between when a light observation is made and when car positions change in response to that change. There is no time allowed for the intersection to clear, and there is no yellow light.

  5. Each execution of the Alloy model was solved instantaneously on a 133MHz G4 PowerMac with 800 Mb of RAM, using the freely available version of Alloy 4 [12].

  6. We use Alloy to formalize problem diagrams and the effect of our transformations on them (Sects. 5, 6) and also to express the constraints in particular examples (Sects. 4, 7). We use the same language only to reduce the number of logics that the reader must keep track of, not to suggest a connection between the two uses. The two kinds of models are not currently put together, and need not be written in the same language. Connecting the two kinds of models is future work (Sect. 10).

  7. A designation is an association between formal terms in some description and informal properties of the real world. This is in contrast to a definition , which relates formal terms to other formal terms [5].

References

  1. Bell TE, Thayer TA (1967) Software requirements: are they really a problem? In: Proceedings of the 2nd international conference on software engineering (ICSE’67), IEEE Society Press, pp 61–68

  2. Greenspan S, Mylopoulos J, Borgida A (1994) On formal requirements modeling languages: RML revisited. In: Proceedings of the 16th international conference on software engineering (ICSE’94), IEEE Computer Society Press, pp 135–147

  3. Leveson NG (1995) Safeware: system safety and computers. Addison–Wesley Longman Publishing Co., Inc., Boston

    Google Scholar 

  4. Jackson M (1995) Software requirements and specifications: a lexicon of practice, principles and prejudice. Addison–Wesley, Reading

    Google Scholar 

  5. Jackson M (2001) Problem frames: analyzing and structuring software development problems. Addison–Wesley Longman Publishing Co., Inc, Boston

    Google Scholar 

  6. Haley CB, Laney RC, Nuseibeh B (2004) Using problem frames and projections to analyze requirements for distributed systems. In: Regnell B, Kamsties E, Gervasi V (eds) Proceedings of the 10th international workshop on requirements engineering: foundation for software quality (REFSQ’04), vol 9. Essener Informatik Beiträge, pp 203–217

  7. Jackson M (1999) Problem analysis using small problem frames. S Afr Comput J 22:47–60

    Google Scholar 

  8. Jackson MA, Hall JG, Rapanotti L (2006) Problem oriented software engineering. Technical Report 2006/10, Department of Computing, The Open University

  9. Laney RC, Barroca L, Jackson M, Nuseibeh B (2004) Composing requirements using problem frames. In: Proceedings of the 12th IEEE international requirements engineering conference (RE’04). IEEE Computer Science Press, pp 121–131

  10. Rapanotti L, Hall JG, Li Z (2006) Deriving specifications from requirements through problem reduction. In: IEE proceedings—software, vol 153: Issue 5, pp 183–198, October 2006. ISSN: 1462-5970

  11. Jackson D (2006) Software abstractions: logic, language, and analysis. MIT Press, Cambridge

    Google Scholar 

  12. Software Design Group (2007) The Alloy Analyzer. website http://www.alloy.mit.edu

  13. Jackson D, Shlyakhter I, Sridharan M (2001) A micromodularity mechanism. In: Proceedings of the 8th European software engineering conference/proceedings of the 9th ACM SIGSOFT sypmosium on the foundations of software engineering (ESEC/FSE’01), September 2001, Vienna, Austria, pp 62–73

  14. Rumbaugh J, Blaha M, Premerlani W, Eddy F, Lorensen W (1991) Object-oriented modeling and design. Prentice-Hall, Inc., Upper Saddle River, NJ

    Google Scholar 

  15. Ricks RC, Berger ME, Holloway EC, Goans RE (2000) REACTS radiation accident registry: update of accidents in the United States. International Radiation Protection Association

  16. Leveson NG, Turner C (1993) An investigation of the Therac-25 accidents. IEEE Comput 7(26):18–41

    Google Scholar 

  17. Food and Drug Administration. FDA statement on radiation overexposures in panama. http://www.fda.gov/cdrh/ocd/panamaradexp.html

  18. Jackson D, Jackson M Rigorous development of complex fault tolerant systems. In: Separating concerns requirements analysis: an example. Springer, New York (to appear)

  19. Air Force, Space Division (1987) System safety handbook for the acquisition manager, January 1987, SDP 127-1

  20. Ozog H (1985) Hazard identification, analysis, and control. Hazard Prevention, pp 11–17

  21. Leveson NG (2003) A new approach to hazard analysis for complex systems. In: International Conference of the System Safety Society, August 2003

  22. Leveson NG (2004) A systems-theoretic approach to safety in software-intensive systems, vol 1, pp 66–86

  23. Eric S.K. Yu. Towards modelling and reasoning support for early phase requirements engineering. In: Proceedings of the 3rd IEEE international symposium on requirements engineering (RE’97), Jan 1997, Washington DC, USA, pp 226–235

  24. Dardenne A, van Lamsweerde A, Stephen F (1993) Goal-directed requirements acquisition. Sci Comput Program 20(1–2):3–50

    Article  MATH  Google Scholar 

  25. Darimont R, van Lamsweerde A (1996) Formal refinement patterns for goal-driven requirements elaboration. In: Proceedings of the 4th international symposium on the foundations of software engineering (FSE’96), Oct 1996, San Francisco, pp 179–190

  26. Letier E, van Lamsweerde A (2002) Deriving operational software specifications from system goals. In: Proceedings of the 10th international symposium on foundations of software engineering (FSE’02), pp 119–128

  27. Parnas DL, Madey J (1991) Functional documentation for computer systems engineering, vol 2. Technical report CRL 237, McMaster University, Hamilton, Ontario

  28. Thompson JM, Heimdahl MPE, Miller SP (1999) Specification based prototyping for embedded systems. In: Proceedings of the 6th European software engineering conference/proceedings of the 7th ACM SIGSOFT symposium on the foundations on software engineering (ESEC/FSE’99), September 1999, number 1687 in LNCS, pp 163–179

  29. Johnson WL (1988) Deriving specifications from requirements. In: Proceedings of the 10th international conference on software engineering (ICSE’88). IEEE Computer Society, pp 428–438

  30. Jackson M, Zave P (1995) Deriving specifications from requirements: an example. In: Proceedings of the 17th international conference on software engineering (ICSE’95), ACM Press, New York, pp 15–24

  31. Rapanotti L, Hall JG, Li Z (2006) Problem reduction: a systematic technique for deriving specifications from requirements. Technical report 2006/02, Department of Computing, The Open University, Feb 2006. ISSN 1744-1986

  32. Li Z, Hall JG, Rapanotti L (2005) A constructive approach to problem frame semantics. Technical report 2004/26, Department of Computing, The Open University

  33. Li Z, Hall JG, Rapanotti L (2006) From requirements to specifications: a formal approach. In: Proceedings of the 2nd international workshop on applications and advances in problem frames (IWAAPF’06), co-located with the 28th international conference on software engineering (ICSE’06), ACM Press, Shanghai, China, p 65

  34. Mannering D, Hall JG, Rapanotti L (2006) Relating safety requirements and system design through problem oriented software engineering. Technical report 2006/11, Department of Computing, The Open University

  35. Mannering D, Hall JG, Rapanotti L (2007) A problem-oriented approach to normal design for safety critical systems. In: Proceedings of fundamental approaches to software engineering (FASE’07). European joint conferences on theory and practice of software (ETAPS’07), 24 March–1 April 2007, Braga, Portugal

  36. Strunk EA, Knight JC (2006) The essential synthesis of problem frames and assurance cases. In: Proceedings of the 2nd international workshop on applications and advances in problem frames (IWAAPF’06), co-located with the 28th international conference on software engineering (ICSE’06), May 2006. ACM Press, Shanghai, China, pp 81–86

  37. Seater R, Jackson D (2006) Requirement progression in problem frames applied to a proton therapy system. In: Proceedings of the 14th IEEE international requirements engineering conference (RE’06), Minneapolis, MN, September 2006

Download references

Acknowledgments

This work is part of an ongoing collaboration between the Software Design Group at MIT and the Burr Proton Therapy Center (BPTC) of the Massachusetts General Hospital. We appreciate the assistance of Jay Flanz and Doug Miller (BPTC), the advice of Michael Jackson and Jon Hall (Open University), and the feedback of the anonymous reviewers. This research was supported by grants 0086154 (“Design Conformant Software”) and 6895566 (“Safety Mechanisms for Medical Software”) from the ITR program of the National Science Foundation, and by the Brazilian Research Agency CNPq. This article extends previous work published at the 2006 Requirement Engineering conference [37].

Author information

Authors and Affiliations

  1. Massachusetts Institute of Technology, Computer Science and Artificial Intelligence Laboratory, Software Design Group, 32 Vassar Street, 32-G707, Cambridge, MA, 02148, USA

    Robert Seater, Daniel Jackson & Rohit Gheyi

  2. Massachusetts Institute of Technology, Universidade Federal de Pernambuco, Cidade Universitaria, Recife PF, CEP: 50670-901, Brasil

    Rohit Gheyi

Authors
  1. Robert Seater
    View author publications

    You can also search for this author in PubMed Google Scholar

  2. Daniel Jackson
    View author publications

    You can also search for this author in PubMed Google Scholar

  3. Rohit Gheyi
    View author publications

    You can also search for this author in PubMed Google Scholar

Corresponding author

Correspondence to Robert Seater.

Appendix: an alloy model of requirement progression

Appendix: an alloy model of requirement progression

This Alloy model is analyzable with the current, freely available, version 4 of the Alloy Analyzer [12].

figure ad
figure ae
figure af
figure ag
figure ah

Rights and permissions

Reprints and permissions

About this article

Cite this article

Seater, R., Jackson, D. & Gheyi, R. Requirement progression in problem frames: deriving specifications from requirements. Requirements Eng 12, 77–102 (2007). https://doi.org/10.1007/s00766-007-0048-y

Download citation

  • Received:

  • Accepted:

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s00766-007-0048-y

Keywords

Search

Navigation