1 / 54

Non-Functional Requirements in Software Development Projects: A Systematic Review

Non-Functional Requirements in Software Development Projects: A Systematic Review. Dewi Mairiza Dewi.Mairiza@uts.edu.au http://www- staff.it.uts.edu.au /~ mairiza / Faculty of Engineering and Information Technology University of Technology Sydney. Introduction Motivation The Study

adolph
Download Presentation

Non-Functional Requirements in Software Development Projects: A Systematic Review

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Non-Functional Requirements in Software Development Projects: A Systematic Review Dewi Mairiza Dewi.Mairiza@uts.edu.au http://www-staff.it.uts.edu.au/~mairiza/ Faculty of Engineering and Information Technology University of Technology Sydney

  2. Introduction • Motivation • The Study • Objective • Questions • Methodology • Findings • Conclusion • Publications Outline 2

  3. Introduction 3

  4. Software Projects 4

  5. … Software Projects 5

  6. … To develop a software system based on stakeholder’s requirements, on budget and schedule Software Projects 6

  7. … • People or organizations who will be affected by the system and who have a direct or indirect influence on the system requirements (and those who will be involved in developing • the system). • Users • Decision-makers • Legislators • Developers Software Projects 7

  8. A software system that suits the specified requirements … Software Projects 8

  9. A software system that suitsthe specified requirements … • People or organizations who will be affected by the system and who have a direct or indirect influence on the system requirements (and those who will be involved in developing • the system). • Users • Decision-makers • Legislators • Developers To develop a software system based on stakeholder’s requirements, on budget and schedule ? Software Projects 9

  10. Software Requirements 10

  11. Software Requirements 11

  12. Software Requirements 12

  13. Motivation 13

  14. Non-Functional Requirements 14

  15.  the requirements that specify the desired quality attributes of the system 1,2,3 Non-Functional Requirements 15 1Chung et al., 2000, 2Alexander & Maiden, 2004; 3Robertson & Robertson, 2006

  16. Characteristic • Subjective • Relative • Interacting • Unlike FRs, NFRs are more abstract in nature • Not uniform in nature Non-Functional Requirements 16

  17. “The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements….. No other part of the works so cripples the resulting system is done wrong. No other part is more difficult to rectify later”1 • A critical factor to the success of software projects • address the important issue of quality of the system • perform as constraints or qualifications of operations • often more critical than individual FR in determination of system’s perceived success or failure Why NFRs? 17 1Brooks 1987

  18. Capturing, specifying, and managing NFRs are still difficult to perform • NFRs Characteristic • Inadequate knowledge about NFRs • Little help is available in the literature • NFRs are often neglected, poorly understood and less considered • Not elicited at the same time and the same level of detail • Poorly articulated in the requirements document What happened in practice? 18

  19. The Study 19

  20. to systematically investigate the notion of NFRs in the software engineering literature. Objective 20

  21. Q1. What is the typology of NFRs? Q2. Which types of NFRs are commonly considered or often discussed in the literature? Q3. Which types of NFRs are of concern in various types of systems? Q4. Which types of NFRs are of concern in various application domains? Q5. With respect to NFRs relative characteristic: • Q5a. Can we develop a catalogue of conflicts among NFRs? • Q5b. How can we create a conceptual model of the conflicts among NFRs? • Q5c. Can software developers use this model to perform tradeoffs decision? Questions 21

  22. Q1. What is the typology of NFRs? Q2. Which types of NFRs are commonly considered or often discussed in the literature? Q3. Which types of NFRs are of concern in various types of systems? Q4. Which types of NFRs are of concern in various application domains? Q5. With respect to NFRs relative characteristic: • Q5a. Can we develop a catalogue of conflicts among NFRs? • Q5b. How can we create a conceptual model of the conflicts among NFRs? • Q5c. Can software developers use this model to perform tradeoffs decision? Questions 22

  23. Extensive systematic literature review • Articles • 182 articles • Software engineering field • Published over the last three decades • Academic resources and documents from software development industry • Cover various issues of NFRs and conflicts among them Methodology 23

  24. Methodology 24

  25. Technique • Content analysis technique • method for summarizing any form of content by counting various aspects of the content • It enables researchers to identify trends and patterns in the literature through the frequency of key words, coding and categorizing the data into a group of words with similar meaning or connotations • It is applicable to all domain contexts • The starting point for selection of the papers to be reviewed was the study conducted by Chung et al 2000. Methodology 25

  26. Research Framework: • Creating a comprehensive catalogue of NFRs, their definition and attributes characterization • Identifying the interdependencies among NFRs • Performing the normalization process to the initial NFRs conflicts catalogue Methodology 26

  27. Findings 27

  28. 252 types of NFRs • 114 types correspond to the NFRs definitions that have been discussed specifically in relation to “the quality” Types 28

  29. Types 29

  30. Types 30

  31. Types 31

  32. Top five of the most frequent types of NFRs listed in the NFRs catalogue: • performance (88.68%) • reliability (67.92%) • usability (62.26%) • security (60.38%) • maintainability (54.72%) Most Frequent NFRs 32

  33. Most Frequent NFRs 33

  34. NFRs VS Type of Systems 34

  35. NFRs VS Type of System 35

  36. Performance, security, usability •  the most common NFRs in each software being developed NFRs VS Type of System 36

  37. Digital Industry Taxonomy NFRs VS Application Domain 37

  38. Type of System and Application Doman • Performance and Usability • Security NFRs VS Application Domain 38

  39. NFRs Conflicts Catalogue 39

  40. The relativity of conflicts is characterized: • Absolute conflict All pairs of NFRs that are always in conflict. Labeled as ‘X’ • Relative conflict All pairs of NFRs that are claimed to be in conflict in the certain cases but they are also claimed as not being in conflict in the other cases. Labeled as ‘*’ • Never conflict All pairs of NFRs that have never been declared as being in conflict with each other. They may contribute either positively or indifferent to one another. Labeled as ‘O’ NFRs Conflicts Catalogue 40

  41. Analysis: • Conflicts • 36 pairs have absolute conflict • 19 pairs have relative conflict • 50 pairs have never conflict • The rest of relationships are not known due to there is no information available in the literature about how those pairs of NFRs contribute to each other  presented as “the blank spaces” • NFRs with the most conflict with other NFRs is Performance NFRs Conflicts Catalogue 41

  42. Analysis: • Self-conflicting relationship • Conflicts between the attributes of a single NFRs • E.g. response time VS capacity (performance) increasing the number of concurrent users in the system may diminish the response time of the system NFRs Conflicts Catalogue 42

  43. NFRs Conflicts Catalogue 43

  44. Purpose of study:  to systematically investigate the notion of NFRs in the software engineering community • Covers four essential issues: (1) definition and terminology; (2) types; (3) NFRs VS types of systems and application domains; (4) conflicts among NFRs • Limitation • the potential overlaps that exist among definitions and attributes of each NFRs were not investigated; • this study does not have the intention to create a structural hierarchy of NFRs types. Conclusion 44

  45. Contribution: • software engineering research community • to improve understanding about the notion of NFRs; • to suggest community reaching a consensus on several NFRs dimensions (e.g. definition, scope, terminology, types, and taxonomy); • the top five most considered NFRs presented in this paper (performance, reliability, usability, security, and maintainability) are expected to inform and encourage the research community to perform in-depth studies about these NFRs Conclusion 45

  46. Contribution: • software developers • the comprehensive list of NFRs types will let developers know what types of NFRs are there for the system being developed. • the matrix of relevant NFRs is expected to help developers to identify the important NFRs for the particular system being developed. • the matrix of relevant NFRs can also help the elicitation process by making sure that in the elicitation activity, those relevant NFRs have been discussed with the system stakeholders • Catalogue of NFRs conflicts can be used to identify the NFRs conflicts in various phases of SW development projects Conclusion 46

  47. With respect to NFRs relative characteristic: • Q5b. How can we create a conceptual model of the conflicts among NFRs? • Q5c. Can software developers use this model to perform tradeoffs decision? Future Works 47

  48. Progress so far … • Ontological approach; Helix-Spindle model for ontological engineering • Security - Usability conflicts ontology and its knowledge-base • sureCM Framework • to identify the security – usability conflicts • to characterize the conflicts • to perform tradeoffs decision • MaRK Workshop – 18th IEEE International Requirements Engineering Conference (RE’10) Future Works 48

  49. LNCS CCIS Book Series, Springer-Verlag 2011 (to be appeared)Mairiza, D. and D. Zowghi (2011). Constructing a catalogue of conflicts among non-functional requirements. Evaluation of novel approaches to software engineering, Springer-Verlag. • CCF SIGRE Workshop 2011, Beijing - PRC • Mairiza D., The 1st CCF SIGRE Workshop 2011, Beijing, China, 23 February 2011. • Schlumberger FFTF Forum 2010, Abu Dhabi - UAE • Mairiza D., “Investigating Conflicts among Software Non-Functional Requirements”, Proceedings of the 2010 Faculty For The Future Forum (FFTF 2010), the Schlumberger Foundation, Abu Dhabi, United Arab Emirates, 4-8 December 2010. Publications 49

  50. Peking University 2010, Beijing - PRC • Mairiza D., “Investigating Conflicts among Non-Functional Requirements”, Peking University Workshop, Beijing, China, 20 October 2010. • MaRK 2010 in conjunction with RE 2010, Sydney - Australia • Mairiza D., Zowghi D., “An Ontological Framework to Manage the Relative Conflicts between Security and Usability Requirements”, Proceedings of the Third International Workshop on Managing Requirements Knowledge (MaRK 2010), in conjunction with the 18th IEEE International Requirements Engineering Conference (RE’10), Sydney, Australia, 27th September 2010. • ENASE 2010, Athens - Greece • Mairiza D., Zowghi D., Nurmuliani N., “Towards a Catalogue of conflicts among Non-Functional Requirements”, Proceeding of the 5th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE 2010), Athens, Greece, 2010. Publications 50

More Related