Skip to main content
Log in

MOQARE: misuse-oriented quality requirements engineering

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

Abstract

This work presents MOQARE (misuse-oriented quality requirements engineering), a method to explore quality requirements. The aim of MOQARE is to support intuitive and systematic identification of quality requirements. It was developed by integrating and adapting concepts from other methods (like Misuse Cases). It provides a general conceptual model of quality requirements, and a checklist-based process for deriving them in a top-down fashion. This derivation starts from business goals and vague quality requirements and delivers detailed requirements. MOQARE applies to requirements on the system to be developed requirements, but also derives requirements on the development process, including administration and maintenance. It considers normal and extreme use. The relationships among these requirements are modeled in a Misuse Tree. MOQARE has shown its merits in several case studies, one of which is presented here.

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

Access this article

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

Instant access to the full article PDF.

Fig. 1
Fig. 2

Similar content being viewed by others

References

  1. Paech B, Kerkow D (2004) Non-functional requirements engineering: quality is essential. In: Regnell B, Kamsties E, Gervasi V (eds) Proceedings of the 10th international workshop on requirements engineering: foundation of software quality—REFSQ 04, Essener Informatik Beiträge Bd 9, Essen, pp 237–250

  2. Sindre G, Opdahl AL (2001) Templates for misuse case description. In: Proceedings of the 7th international workshop on requirements engineering: foundation of software quality—REFSQ 01, Essener Informatik Beiträge Bd.6, Essen, pp 125–136

  3. Sindre G, Firesmith DG, Opdahl AL (2003) A reuse based approach to determining security requirements. In: Proceedings of the 9th international workshop on requirements engineering: foundation of software quality—REFSQ 03, Essener Informatik Beiträge Bd.8, Essen, pp 37–46

  4. Herrmann A, Paech B (2005) Quality misuse. In: Kamsties E, Gervasi V, Sawyer P (eds) Proceedings of the 11th international workshop on requirements engineering: foundation of software quality—REFSQ 05, Essener Informatik Beiträge Bd. 10, Essen, pp 193–199

  5. Kazman R, Klein M, Clements P (2000) ATAM: method for architecture evaluation. CMU/SEI-2000-TR-004, Software Engineering Institution, Carnegie Mellon University

  6. Wiegers KE (2002) Success criteria breed success, The Rational Edge, 2(2)

  7. Firesmith DG (2003) Analyzing and specifying reusable security requirements. Requirements for high assurance systems (RHAS) Workshop

  8. International Standard ISO/IEC 9126. Information technology-Software product evaluation-quality characteristics and guidelines for their use

  9. Chung L, Nixon BA, Yu E, Mylopoulos J (2000) Non-functional requirements in software engineering. Kluwer, Dordrecht

  10. Dörr J, Punter T, Bayer J, Kerkow D, Kolb R, Koenig T, Olsson T, Trendowicz A (2004) Quality models for non-functional requirements. IESE-Report Nr. 010.04/E

  11. Sindre G, Opdahl AL (2000) Eliciting security requirements by misuse cases. Tools Pacific 2000:120–131

    Google Scholar 

  12. Sutcliffe A, Minocha S (1998) Scenario-based analysis of non-functional requirements. In: Dubois E, Opdahl AL, Pohl K (eds) Proceedings of the fourth international workshop on requirements engineering: foundation of software quality—REFSQ 98, Presses universitaires de Namur, Namur, pp 219–234

  13. Firesmith DG (2003) Security use cases. J Object Technol 2(3):53–64

    Google Scholar 

  14. Firesmith DG (2004) Specifying reusable security requirements. J Object Technol 3(1):61–75

    Google Scholar 

  15. Herrmann A, Paech B (2005) Software quality by misuse analysis. Technical report SWEHD-TR-2005-01 (University of Heidelberg). http://www-swe.informatik.uni-heidelberg.de/research/publications/reports.htm

  16. BSI (Bundesamt für Sicherheit in der Informationstechnik = German Ministery for Security in Information Technology) (2004) IT-Grundschutzhandbuch. http://www.bsi.bund.de/gshb/deutsch/g/g01.html

  17. Nakajo T, Kume H (1991) A case history analysis of software error cause-effect relationships. IEEE Trans Softw Eng 17(8):830–838

    Article  Google Scholar 

  18. Lutz RR (1993) Analysing software requirements errors in safety-critical embedded systems. Requirements engineering conference. IEEE Computer Society Press, Silver Spring, pp 126–133

  19. van Lamsweerde A, Brohez S, De Landtsheer R, Janssens D (2003) From system goals to intruder anti-goals: attack generation and resolution for security requirements engineering. RHAS’03 Workshop, pp 49–56

  20. Dörr J, Kerkow D, von Knethen A, Paech B (2003) Eliciting efficiency requirements with use cases. In: Proceedings of the 9th international workshop on requirements engineering: foundation of software quality—REFSQ 03, Essener Informatik Beiträge Bd.8, Essen, pp 37–46

  21. Herrmann A, Rückert J, Paech B (2006) Exploring the interoperability of web services using MOQARE. IS-TSPQ workshop, first international workshop on interoperability solutions to trust, security, policies and QoS for enhanced enterprise systems, 21 March 2006, Bordeaux

  22. Herrmann A (2007) Priorisierung von Qualitätsanforderungen auf der Basis von Risikoabschätzungen. Software & Systems Quality Conferences International 2007, 27 April 2007, Düsseldorf

  23. Herrmann A, Kerkow D, Doerr J (2007) Exploring the characteristics of NFR methods—a dialogue about two approaches. In: Sawyer P, Paech B, Heymans P (eds) Proceedings of the 13th international workshop on requirements engineering: foundation of software quality—REFSQ 07, Springer, pp 320–334

  24. Weiß D, Kaack J, Kirn S, Gilliot M, Lowis L, Müller G, Herrmann A, Binnig C, Illes T, Paech B, Kossmann D (2007) Die SIKOSA-Methodik - Unterstützung der industriellen Softwareproduktion durch methodisch integrierte Softwareentwicklungsprozesse. Wirtschaftsinformatik 49(3):188–198

    Article  Google Scholar 

  25. Alexander I (2002) Initial industrial experience of misuse cases. Requirements engineering conference, pp 61–68

  26. Alexander I (2003) Misuse Cases: Use Cases with hostile intent. IEEE Softw 20(1):58–66

    Article  Google Scholar 

  27. Firesmith DG (2003) Common concepts underlying safety, security, and survivability engineering. Technical note CMU/SEI-2003-TN-033

  28. McDermott J, Fox C (1999) Using abuse case models for security requirements analysis. 15th annual computer security applications conference ACSAC, pp 55–65

  29. Allenby K, Kelly T (2001) Deriving safety requirements using scenarios. requirements engineering conference, pp 228–235

  30. Aagedal JÖ, den Braber F, Dimitrakos T, Gran BA, Raptis D, Stölen K (2002) Model-based risk assessment to improve enterprise security. 5th international EDOC conference, pp 51–62

  31. Moffett JD, Haley CB, Nuseibeh B (2004) Core security requirements artefacts. technical report No 2004/23, Department of Computing, The Open University, UK

  32. Computer security resource center (CSRC). Common Criteria, Version 2.1. http://csrc.nist.gov/cc/

  33. Moore AP, Ellison RJ, Linger RC (2001) Attack modeling for information security and survivability. Technical Note CMU/SEI-2001-TN-001

  34. Lin L, Nuseibeh BA, Ince DC, Jackson M, Moffett JD (2003) Analysing security threats and vulnerabilities using abuse frames. Technical report No: 2003/10, Department of Computing, The Open University, United Kingdom

  35. Liu L, Yu E, Mylopoulos J (2003) Security and privacy requirements analysis with a social setting. Requirements engineering conference, pp 151–161

  36. Object Management Group (2004) UML profile for modeling quality of service and fault tolerance characteristics and mechanisms. http://www.omg.org/docs/ptc/04-09-01.pdf

  37. Blakley B, Heath C, and members of The Open Group Security Forum. Security Design Patterns. http://www.opengroup.org/onlinepubs/9299969899/toc.pdf

  38. Kazman R, Klein M, Barbacci M, Longstaff T, Lipson H, Carriere SJ (1998) The architecture tradeoff analysis method. Software Engineering Institute, Technical report CMU/SEI-98-TR-008

  39. Cysneiros LM, Yu E, Leite JCSP (2003) Cataloguing non-functional requirements as softgoal networks. In: Proceedings of requirements engineering for adaptable architectures, at RE’03, pp 13–20

  40. Mylopoulos J, Chung L, Liao SSY, Wang H, Yu E (2001) Exploring alternatives during requirements analysis. IEEE Softw 18(1):92–96

    Article  Google Scholar 

  41. Liu L, Yu E (2001) From requirements to architectural design—using goals and scenarios. Workshop STRAW, ICSE 2001, http://www.cin.ufpe.br/∼straw01/

  42. Cysneiros LM, Leite JCSP (2001) Driving Non-functional requirements to use cases and scenarios. In: Proceedings of XV Brazilian symposium on software engineering, pp 7–20

  43. Stamatis DH (2003) Failure mode and effect analysis—FMEA from theory to execution. American Society for Quality Press, Milwaukee

    Google Scholar 

  44. BSI (Bundesamt für Sicherheit in der Informationstechnik = German Ministery for Security in Information Technology) (1989) IT security criteria. http://www.bsi.bund.de/zertifiz/itkrit/itgruene.pdf

  45. BSI (Bundesamt für Sicherheit in der Informationstechnik = German Ministery for Security in Information Technology) (1991) Information Technology Security Evaluation Criteria. http://www.bsi.bund.de/zertifiz/itkrit/itsec-en.pdf

  46. Landwehr CE, Bull AR, McDermott JP, Choi WS (1994) A taxonomy of computer program security flaws, with examples. ACM Comput Surv 26(3):211–254

    Article  Google Scholar 

  47. Aslam T (1995) A taxonomy of security faults in the Unix operating system. Master’s thesis, Purdue University

  48. Anton AI, Earp JB, Reese A (2002) Analyzing website privacy requirements using a privacy goal taxonomy. Requirements engineering conference, pp 23–31

  49. Richardson R (2003) 2003 CSI/FBI Computer crime and security survey. Computer Security Institute, http://i.cmpnet.com/gocsi/db_area/pdfs/fbi/FBI2003.pdf

  50. Killourhy KS, Maxion RA, Tan KMC (2004) A Defense-centric taxonomy based on attack manifestations. International conference on dependable systems and networks, pp 102–111

  51. Feigenbaum AV (1961) Total quality control—engineering and management. McGraw-Hill, New York

    Google Scholar 

  52. Herrmann A, Paech B, Plaza D (2006) ICRAD: an integrated process for requirements conflict solution and architectural design. IJSEKE 16(6):1–34

    Google Scholar 

  53. Paech B, Dutoit A, Kerkow D, von Knethen A (2002) Functional requirements, non-functional requirements and architecture specification cannot be separated—a position paper. In: Proceedings of the 8th internationalworkshop on requirements engineering: Foundation of software quality—REFSQ 02, Essener Informatik Beiträge Bd.8, Essen, pp. 102–107

Download references

Acknowledgments

MOQARE is the result of the research project SIKOSA, which was funded by the Ministry of Science, Research and Art of Baden-Württemberg, Germany (Ministerium für Wissenschaft, Forschung und Kunst Baden-Württemberg).

We would like to thank Professor Matthias Becker and Damian Plaza of the Interdisciplinary Uveitis Center Heidelberg for their friendly and dedicated cooperation on the case study. We also thank Maike Gilliot and Lutz Lowis from the University of Freiburg and our colleagues from Heidelberg many constructive discussions.

Author information

Authors and Affiliations

Authors

Corresponding author

Correspondence to Andrea Herrmann.

Rights and permissions

Reprints and permissions

About this article

Cite this article

Herrmann, A., Paech, B. MOQARE: misuse-oriented quality requirements engineering. Requirements Eng 13, 73–86 (2008). https://doi.org/10.1007/s00766-007-0058-9

Download citation

  • Received:

  • Accepted:

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s00766-007-0058-9

Keywords

Navigation