How Software Architecture can Frame, Constrain and Inspire System Requirements

  • Eoin WoodsEmail author
  • Nick Rozanski


Historically a system’s requirements and its architectural design have been viewed as having a simple relationship where the requirements drove the architecture and the architecture was designed in order to meet the requirements. In contrast, our experience is that a much more dynamic relationship can be achieved between these key activities within the system design lifecycle, that allows the architecture to constrain the requirements to an achievable set of possibilities, frame the requirements making their implications clearer, and inspire new requirements from the capabilities of the system’s architecture. In this article, we describe this relationship, illustrate it with a case study drawn from our experience and present some lessons learned that we believe will be valuable for other software architects.


  1. 1.
    Barbacci M, Ellison R, Lattanze A, Stafford J, Weinstock C, Wood W (2003) Quality attribute workshops (QAWs) 3rd edn. Technical report, CMU/SEI-2003-TR-016, Software Engineering Institute, Carnegie Mellon UniversityGoogle Scholar
  2. 2.
    Bass L, Clements P, Kazman R (2003) Software architecture in practice, 2nd edn. Prentice Hall, Englewood CliffsGoogle Scholar
  3. 3.
    Boehm B (1986) A spiral model of software development and enhancement. ACM SIGSOFT Softw Eng Notes 21(5):61–72Google Scholar
  4. 4.
    Clements P, Bachmann F, Bass L, Garlan D, Ivers J, Little R, Nord R, Stafford J (2002) Documenting software architectures: views and beyond. Addison Wesley, BostonGoogle Scholar
  5. 5.
    Garlan D (1994) The role of software architecture in requirements engineering. In: Proceedings of the second international conference on requirements engineering. University of York, UK, 18–21 April 1994Google Scholar
  6. 6.
    Hull E, Jackson K, Dick J (2010) Requirements engineering. Springer Verlag, BerlinGoogle Scholar
  7. 7.
    Institution of Electrical and Electronic Engineers (1990) IEEE standard glossary of software engineering terminology. IEEE Standard 610.12-1990Google Scholar
  8. 8.
    International Standards Organisation (2007) Systems and software engineering – recommended practice for architectural description of software-intensive systems. ISO/IEC Standard 42010:2007Google Scholar
  9. 9.
    Jackson M (2001) Problem Frames. Addison Wesley, WokinghamGoogle Scholar
  10. 10.
    Kazman R, Klein M, Clements P (2000) ATAM: a method for architecture evaluation. Technical report, CMU/SEI-2000-TR-004, Software Engineering Institute, Carnegie Mellon University, PittsburghGoogle Scholar
  11. 11.
    Kruchten P (1995) The 4 + 1 view model of software architecture. IEEE Softw 12(6):42–50CrossRefGoogle Scholar
  12. 12.
    Kruchten P (2003) The rational unified process: an introduction, 3rd edn. Addison-Wesley, BostonGoogle Scholar
  13. 13.
    van Lamsweerde A, Letier E (2002) From object orientation to goal orientation: a paradigm shift for requirements engineering. In: Proceedings of the radical innovations of software and systems engineering, Venice, Italy, 7–11 October 2002. Lecture notes in computer science, vol 2941. Springer, Heidelberg, pp 325–340Google Scholar
  14. 14.
    Larman C (2004) Agile and iterative development: a manager’s guide. Addison-Wesley, ReadingGoogle Scholar
  15. 15.
    Nuseibeh B (2001) Weaving together requirements and architectures. IEEE Comput 34(3):115–119CrossRefGoogle Scholar
  16. 16.
    Nord R, Soni D (2003) Experience with global analysis: a practical method for analyzing factors that influence software architectures. In: Proceedings of the second international software requirements to architectures workshop (STRAW). Portland, Oregon, 9 May 2003Google Scholar
  17. 17.
    Robertson S, Robertson J (2006) Mastering the requirements process, 2nd edn. Addison Wesley, ReadingGoogle Scholar
  18. 18.
    Royce W (1970) Managing the development of large software systems. In: Proceedings of IEEE WESCON, vol 26. Los Alamitos, pp 1–9Google Scholar
  19. 19.
    Rozanski N, Woods E (2005) Software systems architecture: working with stakeholders using viewpoints and perspectives. Addison Wesley, BostonGoogle Scholar

Copyright information

© Springer-Verlag Berlin Heidelberg 2011

Authors and Affiliations

  1. 1.ArtechraHerfordshireUK
  2. 2.Software Architect for a UK Investment BankLondonUK

Personalised recommendations