Integrating Software Security into Agile-Scrum Method
Integrating Software Security into Agile-Scrum Method
KSII Transactions on Internet and Information Systems (TIIS). 2014. Feb, 8(2): 646-663
Copyright © 2014, Korean Society For Internet Information
  • Received : November 23, 2013
  • Accepted : January 21, 2014
  • Published : February 27, 2014
Export by style
Cited by
About the Authors
Imran, Ghani
Faculty of Computing, Universiti Teknologi Malaysia (UTM), Malaysia
Zulkarnain, Azham
Faculty of Computing, Universiti Teknologi Malaysia (UTM), Malaysia
Seung Ryul, Jeong
Graduate School of Business IT, Kookmin University, Korea

Scrum is one of the most popular and efficient agile development methods. However, like other agile methods such as Extreme Programming (XP), Feature Driven Development (FDD), and the Dynamic Systems Development Method (DSDM), Scrum has been criticized because of lack of support to develop secure software. Thus, in 2011, we published research proposing the idea of a security backlog (SB). This paper represents the continuation of our previous research, with a focus on the evaluation in industry-based case study. Our findings highlight an improved agility in Scrum after the integration of SB. Furthermore, secure software can be developed quickly, even in situations involving requirement changes of software. Based on our experimental findings, we noticed that, when integrating SB, it is quite feasible to develop secure software using an agile Scrum model.
1. Introduction and Problem Background
A gile methodologies such as Scrum, Extreme Programming (XP), Feature Driven Development (FDD), and the Dynamic Systems Development Method (DSDM), have gained enough attention for software development in recent years [1] . A number of organizations [2 , 3] that practice agile methods suggest that agile methods help during the software development process by emphasizing rapid development statements [4 , 5] . In fact, agile methods are more flexible and help to reduce risks of project failure. However, they need to follow several rules related to the agile manifesto, including those concerning less documentation and team member interactions, which provide for appropriate communication with customers and other users. However, some researchers and practitioners [4 , 6 , 7] highlighted a critical software problem – software security [8 , 10] and [11] . As mentioned in the abstract, like other agile methods, the Scrum model does not provide guidelines for dealing with the security aspects of software [12] . The original Scrum model does not include software security planning from the start [13] . This means that security practices cannot be implemented by the Scrum team. As a result, the agile team may produce vulnerable software that can be exploited by attackers [8] . On the contrary, if the Scrum agile team concentrates on solving software security issues, the agility of the Scrum process may be affected [14] .
Thus, this study attempts to discover whether or not security practices such as SB can work with the Scrum agile model. If so, then developers who focus on developing secure software using Scrum may apply the proposed SB.
- 1.1. Degree of Agility
Based on a survey and assessment of various contemporary definitions, Qumer and Henderson-Seller [15] offer the following definition for the agility of any entity ( ):
“Agility is a persistent behavior or ability of a sensitive entity that exhibits flexibility to accommodate expected or unexpected changes rapidly, follows the shortest time span, uses economical, simple and quality instruments in a dynamic environment and applies updated prior knowledge and experience to learn from the internal and external environment.”
The aforementioned definition can then be simplified by a researcher into five key elements of agility that represent flexibility, speed, leanness, learning and responsiveness. To validate the performance of an agile model, the degree of agility needs to be evaluated by measuring the following elements.
  • • Flexibility: The agile method should be flexible enough to welcome a change in requirements during any phase. A lack of flexibility will create a serious crisis in the agile software process. In other words, we can say that this represents the ability to respond to any change at any given time.
  • • Speed: As the speed of software delivery is one of the most important elements in the agile manifesto, it needs to be considered as an element of agility[16].
  • • Leanness: This represents the elimination of waste or the doing of more with less. Through maximizing the utilization of all resources, and the elimination of unnecessary resources, all tasks are streamlined. At the same time, however, the level of quality should be maintained[17].
  • • Learning: Focuses on improvement during and after product development when software had been delivered to the client.
  • • Responsiveness: This means responding to any change, either within the team, or in the requirements of the software itself[15].
Any software development process that implements the whole of agility, as stated above, can be considered to be an agile method. However, its degree of agility needs to be evaluated before it can be considered to be a suitable agile model.
2. Literature Review
- 2.1. Security Issues and Agility Concerns
In general, existing security standards and practices do not easily align with the agile manifesto due to the strictness of the security requirements phase. In fact, the security practices that are still widely followed were developed before the agile manifesto was introduced. The current reality is that modern software projects undergo constant changes, which leads to process re-iteration, or in other words, repetition in the development process. This new phenomenon creates a dilemma in that there are no established security standards that consider agility, which limits the potential of any agile model, including those that use Scrum [7 , 18] .
- 2.2. Security Issues and Scrum
In particular, Scrum itself has a number of limitations related to security. These are stated below.
  • • As the Scrum release cycle is too short, there is not enough time for the development team to address security requirements for each release.
  • • Although the inclusion of security elements in the existing Scrum does not present a significant issue, issues do arise when such inclusions affect the process characteristics or agility of Scrum.
  • • The authors, Kevin Brady[19]and Mikkosiponenet al.[20], state that knowledge monopolies in a Scrum team are the main factors causing an absence of documentation during the requirement planning. This happens due to the team players not having enough skill in regards to security.
  • • The lack of guidelines in the collection of security requirements is also a factor, as there is no requirements freeze in agile as there is in the other conventional SDLCs[7].
  • • One of the research groups, known as Securosis[22], found that, although the project manager played a major role in Scrum, their lack of security awareness and pressure to complete the project within a minimal amount of time affected the entire process. For example, threat analysis needed to be included in the requirements capturing/analysis guidelines. However, it was either not included at all or the Scrum Product Owner (PO) could not complete it due to a lack of time[22]. The same issue was faced during security testing in sprint phases. As a result, the agility of the process was affected[21].
In order to overcome these issues, this study attempts to suggest ways in which the Scrum process can be suitably combined with security practices. Previous research [23] proposed a solution for this situation. However, there was not enough data regarding how the proposed solution affected Scrum agility. In this paper, we will present our findings regarding these issues.
- 2.3. Software Security Principles
Recapping Security Principles . Security principles are the primary methods used to determine methods for securing software. They are universal guidelines adopted by every developer and project planner, and have been adopted by practitioners and experts in the security field in order to mitigate risks in the architecture, design, implementation, testing and maintenance phases. As illustrated in Table 1 , security principles act as a guideline for a number of existing systems and approaches. As shown in the table, much research has been proposed showing solutions that satisfy some or all of the security principles. The ‘X’ symbol is used when researchers have not mentioned the security principle, while the‘√’ symbol is used when it has been mentioned.
Security Principles
PPT Slide
Lager Image
Security Principles
- 2.4. Software Security Engineering in Phases
Security activities generally include three phases. These are known as the requirement, development and testing phases. A software engineer can sabotage the software at any point in its development life cycle through the usage of intentional exclusions from, or inclusions in. Sabotage can also be performed by modifying the requirements specification, the threat models, the design documents, the source code, the assembly and integration framework, the test cases and test results, or the installation and configuration instructions and tools. The secure development practices described in this book are, in part, designed to help reduce the exposure of software to insider threats during the development process. For more information on this aspect, see "Insider Threats in the SDLC" [13] .
2.4.1. Security during requirement phase: There are a few existing techniques that can be used for eliciting the security requirements. Some of these have been created with attention paid to security, while others have been created in outdated requirement engineering style. These can be enhanced to add a security element. Existing techniques for the security requirement include Misuse cases [34] , Soft Systems Methodology [25] , Quality Function Deployment [26] , Controlled Requirements Expression [35] , Issue-based information systems [28] , Joint Application Development [29] , Feature-oriented domain analysis [36] , Critical discourse analysis [30] and the Accelerated Requirements Method [31] . It is impossible to create secure software without keeping security in mind from the beginning. Preparation must be started during the requirement phase because at the development phase, developers simply follow what is stated in the requirements. For the scrum method, there is an existing security method proposed by EAST Methodology [33] , which is integrated in Scrum. In this method, we can see there is no special backlog for the security part. Instead, the security analysis is combined in the product backlog. In Scrum, the product backlog should not be too complex, as this will affect the leanness agility.
2.4.2. Existing Secure Software Development Lifecycle : Microsoft has developed a guide for the SDL agile process. However, it is commonly believed that because SDL was originally created for Microsoft’s big showcase box products such as Windows and SQL Server, it only works for those kinds of products. This is, of course, patently false. Virtually every Microsoft product and online service, large or small, follows the SDL. Many other organizations outside of Microsoft are also successfully implementing the SDL. However, while the content of the SDL and its requirements and recommendations may be universal, the structure of the SDL as originally designed is more suited to long running waterfall or spiral style development methodologies [32] .
Analysis of Existing Models Secure Software Development
PPT Slide
Lager Image
Analysis of Existing Models Secure Software Development
The table above shows that the existing agile models that are used to develop secure software do not clearly mention or integrate the security principles in the requirement, development or testing phases. The X symbol means the corresponding model does not solve the issue and provide a solution, while the√ symbol means that it does solve the issue and provide a solution.
Table 3 shows an analysis of existing secure software development which compares the Microsoft and EAST models. This analysis has been obtained from a recent literature review (2005 - 2010).
Analysis of Existing Secure Software Development Lifecycle
PPT Slide
Lager Image
Analysis of Existing Secure Software Development Lifecycle
In order to address some of the highlighted issues, we previously proposed the idea of SB for Scrum security practices [23] . For the sake of the reader, we will illustrate our previously proposed SB in the next section. However, the main objective of this paper is to analyze the effectiveness of the SB and provide insights obtained from an industry-based case study.
3. Analysis of Proposed Security Backlog (SB)
- 3.1. Validation and Evaluation
In this section our previously proposed SB and its integration into the Scrum model is analyzed and the authors explain the overall enhanced Scrum model.
As mentioned in Table 4 , existing frameworks do not offer a solution for the security issues in Scrum. Therefore, our aim is to merge two new elements into the existing Scrum. These are 1) a new security component known as SB and 2) a new role known as Security Master (SM). The SM is in charge of the SB during the Scrum lifecycle.
Security Description in Each Phase[23]
PPT Slide
Lager Image
Security Description in Each Phase [23]
The √ symbol means that the phases should practice the respective security principle, while the X symbol means that phases do not need the respective security principle. Based on analysis in Table 3 and security principle roles in Table 2 introduced by various researchers, we come to a conclusion in Table 5 . Table 5 shows analysis regarding how security guidelines should be aligned to each related backlog and phase. The chosen factor is based on security principles stating that nearly all principles can provide guidelines for requirement, development and testing activities.
Relation between Phases and Security Principle
PPT Slide
Lager Image
Relation between Phases and Security Principle
The enhanced Scrum model in Fig. 1 has two additional components. These are:
PPT Slide
Lager Image
Enhanced Scrum process with additional SB and SM
  • 1. A Security Backlog (SB) that manages security in Scrum. (please refer toFig. 2)
PPT Slide
Lager Image
Process Security Backlog in Scrum
  • 2. A Security Master (SM)that handles security in Scrumand is in-charge ofthe SB.
As illustrated in Fig. 1 , the process flow is shown below.
  • 1. The requirements are translated into product backlog and go through SB.
  • 2. Here, the SM figures out certain features in the product backlog that require security attention.
  • 3. The Security Master marks (dotted in illustrations) the selected features in the security backlog. The SM creates a document of its activity for use as a reference during the development and testing phases. The marked security concerns are noted in the sprint backlog for the attention of the developers.
  • 4. Testing is verified in sprint phases by the security master.
As shown above, Fig. 3 displays SQL injection and buffer overflow attack possibilities assigned by the SM. Since the agile method documentation needs to be as simple as that suggested in The Systems Security Engineering Capability Maturity Model (SSE-CMM) and CC, the SB also helps to produce a simple but comprehensive document. At the same time, it attempts to provide clear information regarding the security risks.
PPT Slide
Lager Image
Release Backlog Highlighted with Security Related Features
4. Evaluation
- 4.1. Evaluation of agility in Each Phase
The three phases involved in this Scrum enhancement model are the requirement phase, development phase and testing phase. As discussed in the beginning, the agility is the variable to be evaluated for each phase.
4.1.1. Requirement Phase and Degree of Agility . The requirement phase is conducted by the Product Owner. After collecting the requirements, the selected features are populated in the Product Backlog (hereafter, PB). The PB is given to the Security Master (SM) to evaluate and then to the SB. The security backlog is evaluated using this experience and a conclusion is reached based on the agility provided. If agility is affected, the product owner (PO), Scrum Master and SM suggest improvements.
  • • Speed: Overall, speed does not affect the delivery deadline when a security backlog is implemented in the requirement phase. Since the SM has an additional workforce available, they can identify if previously developed security libraries/classes can be reused. This information may be provided in the description of security requirements in the SB. Another way in which the SB can save time for the PO is by having guidelines without the need for research, or by finding a specific security requirement. Since the PO and SM have simple guidelines to follow in terms of security, the results of security requirements can be generated quickly. In conclusion, the security backlog would not affect the overall delivery deadline. It can also save time and produce swift security results.
  • • Flexibility: In short, flexibility refers to adaptability to expected change requirements. In the beginning, it is difficult to be flexible due to the lack of information within the security backlog. However, this information is also simple enough to analyze. Although flexibility can be affected in the beginning, with time it can be recovered.
  • • Leanness: The security backlog can complete a task within the shortest available time span because of its simplicity. Due to this simplicity, the security backlog can provide a proper understanding to the PO in a short amount of time. As a result, leanness will not be affected.
  • • Learning: If the description in a security backlog is user friendly, it can maintain or improve upon the current knowledge of the PO. Since the history of previous requirements can be maintained inside the SB, it can also provide experience to a new PO. As a result, the security backlog in the requirement phase will have a positive learning curve.
4.1.2. Development Phase and Degree of Agility . The development phase is evaluated by the SM and system developers in the team. The security backlog illustrated in figure 5.2 is evaluated using their experience. If the agility is affected, they suggest improvements.
  • • Speed: The security backlog does not cause any slowdown in developing the system within the required timeframe. However, sometimes it depends on the flexibility or the complexity of a business case. Referring to the description provided in the SB can also help the developers save time in tracing any errors or bugs that have occurred in the sub-modules. By using the SB, the developers can also add or modify any new code to any of the sub-modules for implementation of security. As a result, the speed is generally not affected.
  • • Flexibility: The developer can accommodate expected changes or user requirements within any sub modules during the development period. For unexpected changes the SB can be updated from time to time.
  • • Leanness: Since the backlog will have guidelines and standards for the developers, they can still maintain simplified codes during development to produce quality products through the help of SB. Developers can avoid adding any un-used or useless codes when developing by using the SB. This can be done in the beginning and can then be reused.
  • • Learning: Security backlogs can maintain or improve the current knowledge of the developers regarding the product or system that is being developed. Since the descriptions can help new developers develop new code, the security backlogs also provide experience to developers regarding the previously developed products.
4.1.3. Testing Phase and Degree of Agility . The testing phase is evaluated by the team’s tester. The SB, as illustrated in, is consulted due to their experience. If affected is agility, the tester suggests improvements.
  • • Speed: The implementation of SB in Scrum development improves the tester’s work flow. Use of the security backlog can save time during the testing phase in selecting the appropriate method, since the requirements will be focused on testing SQL injection, buffer flow, and so on. The testing process will become faster and easier as the tester comes to more quickly understand the features "to be tested" from the backlog. With this information provided in the SB, all testing can produce quick results.
  • • Flexibility: The SB is not rigid and offers the flexibility to add, modify or delete the security features scheduled to be tested.
  • • Leanness: The SB helps the tester complete tasks and activities in the shortest amount of time by going through the major list.
  • • Learning: The tester gains new knowledge as information inside the security backlog is stored and updated. This saved experience will allow a new tester to improve and learn more quickly.
- 4.2. Scrum Master’s Evaluation about Responsiveness
The Scrum Master, or project manager, is the one responsible for evaluating the overall responsiveness of an agile development process using SB. It has been noted that SB did not affect the responsiveness of the overall project. SB is sensitive and can adapt to the environment. It has been applied on a small scale and accepted by an experienced team using the Scrum method. Their feedback is shown in Table 6 .
Industrial Feedback
PPT Slide
Lager Image
Industrial Feedback
Based on the industry feedback shown in Table 6 , it is safe to say that SB can be implemented as part of the enhancement process in a Scrum method selected for security. This information has been used to calculate agility using the 4-DAT framework, in order to compare agility both before and after security backlog implementation was performed according to our model.
4.2.1. Evaluating Degree of Agility .
In order to evaluate the degree of agility, the 4-DAT framework has been used in our case study. Table 7 shows the degree of agility using Scrum without implementing the SB. In reference to the phases in Table 7 :
Degree of Agility before Enhancement
PPT Slide
Lager Image
Degree of Agility before Enhancement
  • • The 0 in column four means leanness was not achieved by the Scrum master. This means the PB was not effective enough to practice security for the Scrum master.
  • • The 1 in other columns means that the other agility features were achieved.
  • • 7/7 is the total of the values in columns 1, 2, 4, 5. It means the relevant agilities in the columns were achieved.
  • • 0/7 is the total of the values in column 3. It means the relevant agility in the column was achieved.
In order to calculate agility the following formula has been adopted:
PPT Slide
Lager Image
Thus, Degree of Agility of Practices = 28/(7*5) = 0.80. The formula, label 0 and 1 were also implemented in Tables 7 and 8 using the same technique.
Degree of Agility after Enhancement
PPT Slide
Lager Image
Degree of Agility after Enhancement
Table 7 shows the difference from Table 8 , which includes the security backlog. The industrial experts who evaluated the SB in Table 7 agree that the SB can be implemented and does not affect the five criteria of agility i.e., flexibility, speed, leanness, learning and responsiveness. Based on the conclusion of Table 7 ’s industrial evaluation, the security backlog considered in Table 8 can be performed. Thus, number 1 should be put inside the blank space for all agility.
The data in Table 9 refers to the activity in practices for Scrum practices. The degree of agility has improved from 0.80 before implementation to 0.83 after implementation.
Calculation Degree of Agility
PPT Slide
Lager Image
Calculation Degree of Agility
The degree of agility is illustrated in Figure 4 adds a comparison before and after the security backlog has been added. The phases and practices have been calculated, and the result in Fig. 4 shows the practices clearly.
PPT Slide
Lager Image
Comparison Degree of Agility
Based on Fig. 4 , the degree of agility has improved in the practices from 0.8 (before implementation) to 0.83 (after implementation). The improvement shown after implementation shows that the security backlog does not add any delay to speed, flexibility, leanness, learning or responsiveness if the security applied is part of the Scrum method. This shows that such implementation is relevant and can be performed without any fear of affecting agility negatively.
5. Conclusion
After preliminary analysis, comparison, and collection of literature such as journals, books, magazines and case studies, we were able to successfully identify the issues related to the Scrum method. Through further research, we were able to discover the relationship between the security principles and security in each of the Scrum phases. The second issue, then, was to enhance the Scrum model. The enhanced Scrum model that we have proposed has been evaluated in the requirement, development and testing phases. These research objectives were completed successfully. An agile team presented evaluations and feedback in regards to the enhancement model gathered from industry events. Team members who had experience using the agile model (team leaders, requirement engineers, developers and testers) evaluated whether agility was affected or not. Based on their evaluations, the research was considered relevant, and possible to implement. We also evaluated the degree of agility before and after enhancement using the 4-DAT framework.
The results showed that agility is improved if the security backlog (SB) is implemented, which means that agility is not negatively affected if the SB is added to the Scrum model. It is appropriate to clarify that, in this study, the agility of phases has not been considered. Thus, this is out of the scope of this study and can be considered in future research. In addition, the purpose of this study was not to prove that PB is unsuitable. On the contrary, the intention was to discover, after the enhancement of PB, how far Scrum agility was affected overall.
We wish to thank the teams at Twin System Company, Malaysia for their tremendous contribution in conducting the case study and Ministry of Science, Technology and Innovation (MOSTI), Malaysia to financially supporting this project under research grant vot 4S028.
Imran Ghani is a Senior Lecturer at Faculty of Computing, Universiti Teknologi Malaysia (UTM), Johor Campus. He received his Master of Information Technology Degree from UAAR (Pakistan), M.Sc. Computer Science from UTM (Malaysia) and Ph.D. from Kookmin University (South Korea). His research focus includes agile software development practices, semantics techniques, web services, software testing, enterprise architecture and software architecture.
Zulkarnain Azham earned his Bachelor’s Degree in Software Engineering, Master’s Degree in Computer Science (Information Security) from Universiti Teknologi Malaysia (UTM), Johor Campus. Currently, he is doing Ph.D. in Computer Science at Universiti Teknologi Malaysia (UTM). His research focus is on information security.
Seung Ryul Jeong is a Professor in the Graduate School of Business IT at Kookmin University, Korea. He holds a B.A. in Economics from Sogang University, Korea, an M.S. in MIS from University of Wisconsin, and a Ph.D. in MIS from the University of South Carolina, U.S.A. Dr. Jeong has published extensively in the information systems field, with over 60 publications in refereed journals like Journal of MIS, Communications of the ACM, Information and Management, Journal of Systems and Software, among others. Dr. Jeong’s areas of interest are Process Management, Software Engineering, Systems Implementation, and Information Resource Management.
Dyba T. , Dingsoyr T. 2008 “Empirical studies of agile software development: A systematic review” Information and Software Technology Article (CrossRef Link) 50 833 - 859    DOI : 10.1016/j.infsof.2008.01.006
Mchugh O. , Conboy k. , Lang M. 2012 “Agile practices: The Impact on Trust in Software Project Teams” IEEE Software Article (CrossRef Link) 29 71 - 76    DOI : 10.1109/MS.2011.118
Slaten k. , Droujkova M. , Berenson B. S. , Williams L. , Layman L. 2005 “Understanding Student Perceptions of Pair Programming and Agile Software Development Methodologies: Verifying a Model of Social Interaction” IEEE Agile Conference Article (CrossRef Link) 323 - 330
Amir S. S. , Amir A. S. , Fereidoon S. 2008 “Toward Empowering Extreme Programming from an Architectural Viewpoint” in Proc. of 9th International Conference XP 2008 Vol.9, Article (CrossRef Link) 222 - 223
Breivold H. P. , Sundmark D. , Wallin P. , Larsson S. 2010 “What Does Research Say about Agile and Architecture?” IEEE Software Engineering Advances Article (CrossRef Link) 32 - 37
Wäyrynen J. , Bodén M. , Boström G. 2004 “Security engineering and eXtreme programming: an impossible marriage?” in Proc. of 4th Conference on Extreme Programming and Agile Methods Vol.3134, Article (CrossRef Link) 117 - 128
Xiaocheng G. , Richard F. P. , Fiona P. 2007 “Extreme Programming Security Practices” in Proc. of 8th International Conference XP 2007 Vol.4536, Article (CrossRef Link) 226 - 230
Sani A. , Firdaus A. , Jeong S. R. , Ghani I. 2013 “A Review on Software Development Security Engineering using Dynamic System Method(DSDM)” International Journal of Computer Applications Article (CrossRef Link) 69 (25) 33 - 44    DOI : 10.5120/12131-8527
Ghani I. , Yasin N. I. B. 2013 “Software Security Engineering in Extreme Programming Methodology: A Systematic Literature Review” Journal Science International Lahore Article (CrossRef Link) 25 (2) 215 - 221
Firdaus A. , Ghani I. , Yasin N. I. M. 2013 “Developing Websites using Feature Driven Development: A Case Study” Journal of Clean Energy Technologies Article (CrossRef Link) 1 (4) 322 - 326    DOI : 10.7763/JOCET.2013.V1.73
Sani A. , Ghani I. , Jeong S. R. 2013 “Secure Dynamic System Development Method (Sdsdm) Model For Secure Software Development” Journal, Science International Lahore, Special Issue Article (CrossRef Link) 1059 - 64
Sutherland J. , Schwaber K. 2011 “The Scrum Papers: Nut, Bolts, and Origin of an Agile Framework” Scrum Inc Article (CrossRef Link)
Julia H. A. , Sean B. , Robert J. Ellison , Mcgraw Gary , Nancy R. 2008 “Software Security Engineering: A Guide for Project Manager” Addison-Wesley Professional Article (CrossRef Link)
Keramati H. , Mirian-Hosseinabadi S. H. 2008 “Integrating Software Development Security Activities with Agile Methodologies” in Proc. of IEEE/ACS International Conference on Computer Systems and Applications Article (CrossRef Link) 749 - 754
Qumer A. , Henderson-Sellers B. 2008 “An evaluation of the degree of agility in six agile methods and it applicability for method engineering” Information and Software Technology Article (CrossRef Link) 50 280 - 295    DOI : 10.1016/j.infsof.2007.02.002
Walker R. 2009 “Improving Software Economics: Top 10 Principles of Achieving Agility At Scale” Improving Software Economics white paper Article (CrossRef Link)
Lowell L. , Carmen Z. , Erdogmus H. 2004 “Extreme Programming and Agile Methods – XP/Agile Universe 2004” in Proc. of 4th Conference on Extreme Programming and Agile Methods Article (CrossRef Link) 121 -
Erdogan G. , Meland P. H. , Mathieson D. 2010 “Security Testing in Agile Web Application Development – A Case Study Using the East Methodology” in Proc. of 11th International Conference XP2010 Vol.48, Article (CrossRef Link) 14 - 27
Brady K. 2006 “AGILE/SCRUM Fails to get to grips with Human Psychology” at , Article (CrossRef Link)
Mikko S. , Richard B. , Tapio k. 2005 “Integrating Security into Agile Development Methods” in Proc. of Proceedings of the 38th Hawaii International Conference on System Sciences Article (CrossRef Link)
Anti V, S. 2010 “Secure software development and agile methods – notes” at , Article (CrossRef Link)
Adrian L. 2010 “FireStarter: Agile Development and Security” at , Article (CrossRef Link)
Azham Zulkarnain , Ghani Imran , Ithnin Norafida 2011 “Security Backlog in Scrum Security Practicesm” in Proc. of 5th Malaysian Software Engineering Conference Article (CrossRef Link)
McGraw G. 2006 “Software Security: Building Security In” Addison-wesley software security series Article (CrossRef Link)
Checkland P. 1990 “Soft Systems Methodology in Action” John Wiley & Sons Toronto, Ontario, Canada Article (CrossRef Link)
QFD Institute 2005 “Frequently Asked Questions About QFD” at , Article (CrossRef Link)
Christel M. , Kang K. 1992 “Issues in Requirements Elicitation” Software Engineering Institute Article (CrossRef Link)
Werner Kunz , Horst Rittel 1970 “Issues as Elements of Information Systems” at , Article (CrossRef Link)
Wood J. , Silver D. 1989 “Joint Application Design: How to Design Quality Systems in 40% Less Time” John Wiley & Sons New York Article (CrossRef Link)
Schiffrin D. 1994 “Approaches to Discourse” Blackwell Oxford, UK Article (CrossRef Link)
Hubbard R. , Mead N. , Schroeder C. 2000 “An Assessment of the Relative Efficiency of a Facilitator-Driven Requirements Collection Process with Respect to the Conventional Interview Method” in Proc. of 4th International Conference on Requirements Engineering Article (CrossRef Link) 178 - 186
2009 “Security Development Lifecycle for Agile Development” Mirosoft at , Article (CrossRef Link)
Gencer E. , Master Thesis 2009 “Security Testing of Web Based Applications” Norwegian University of Science and Technology Department of Computer and Information Science Master Thesis Article (CrossRef Link)
Sindre G. , Opdahl A. 2001 “Capturing security requirements through misuse cases” in Proc. of Proceedings of the 14th Norwegian informatics conference Article (CrossRef Link)
Mullery G. 1979 “CORE: A method for controlled requirements expression” in Proc. of Proceedings of 4th International Conference on Software Engineering. (ICSE-4) Article (CrossRef Link) 126 - 135
Kang C. , Cohen G. , Hess A. , Novak E. , Peterson A. 1990 “Feature-oriented domain analysis (FODA) feasibility study” Software Engineering Institute, Carnegie Mellon University Technical report CMU/SEI-90-TR-21 Article (CrossRef Link)
Alnatheer M. , Nelson K. 2009 A proposed framework for understanding information security culture and practices in the Saudi context. SECAU - Edith Cowan University Australia, Perth, Australia In: Proceedings of the 7th Australian Information Security Management Conference 6 - 17
Vaha-Sipila A. (2011) “Software security in agile product management” , Article (CrossRef Link)