1. Darshan Domah, Ph.D. October 3, 2013

2. Agenda Non-Functional Requirements Why they are important Agile Software Development NFR in Agile Processes Overview of Artifacts Application of artifacts NFR Concerns in Agile © 2013 Darshan Domah, Ph.D.

3. What are Non-Functional Requirements (NFR) Technical Constraints Architectural Constraints Non-Technical attributes All agree they are very important in software Functional Requirement: What software will do. Login (FR) Non-Functional Requirement: How the software will do it. Only authorized uses can login (NFR) Ending in: -ilities -ities -ness © 2013 Darshan Domah, Ph.D.

4. NFR Examples Ending in -ilitiesEnding in - ities Ending in -nessOther Ending Availability Usability Portability Reliability Maintainability Survivability Scalability Reusability Flexibility Interoperability Testability Auditability Security Integrity Simplicity Capacity Timeliness User-Friendliness Correctness Completeness Responsiveness Performance Cost Efficiency Accuracy Precision Legal Consistency Some Uncommon NFR Additivity Distributivity Normadicity Evolvability Decomposability Wrappability © 2013 Darshan Domah, Ph.D.

5. Why are NFR important Most software failures due to NFR factors rather than Functionality It is widely known that software project failures are caused by the non-satisfaction of quality attributes like performance, usability, and reliability instead of failures in functional features (Jeon, Han, Lee & Lee, 2011). Failure to address NFR in the early stages of software development, results in the system not meeting their NFR and also result in increased cost to retrofit NFR into the system (Farhat, Simco & Mitropoulos, 2009). © 2013 Darshan Domah, Ph.D.

6. Why are NFR important 1992 London Ambulance System Failure Subject of many studies (Brietman et al., 1999) Receive phone call and decide which ambulance to dispatch Ambulance late dispatch – patient dead Ambulance arrived 11 hours after a patient had a stroke Reasons for failure(NFR aspects among others) Reliability – system relied on perfect vehicle location Performance – designed for functionality and not speed Integrity – System did not know the exact vehicle location Cost- System designed by the lowest bidder Usability – System had a slow GUI © 2013 Darshan Domah, Ph.D.

7. Agile software development Umbrella of software development methods Support incremental and iterative development Scrum, Extreme Programming, Crystal, Feature Driven Development, Dynamic Systems Development Method Scrum - preferred Agile method; Lightweight and flexible framework © 2013 Darshan Domah, Ph.D. 3 Roles 3 Artifacts 5 Ceremonies Product Owner Scrum Master The Team Product Backlog Sprint Backlog Burndown Chart Release Planning Sprint Planning Daily Stand Up Meeting Sprint Demo and Review Sprint Retrospective

8. Agile Manifesto and 12 Principles We are uncovering better ways of developing software by doing it and helping others to do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Principle 1Our highest priority if to satisfy the customer through early and continuous delivery of valuable software. Principle 2Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Principle 5 Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Principle 12At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. © 2013 Darshan Domah, Ph.D.

9. Agile Successes Agile methodologies like Scrum, XP, Crystal, and Adaptive Software Development (ASD) lean on fast adaptation to change and focus on short term goals and incremental delivery within sprints; these short time-boxes Incorporate complete software development life cycle (Sriram & Mathew, 2012). Agile methods practitioners agree on the Agile Manifesto which provides guidance in implementing Agile (Beck, K. et al., 2001). Scrum allowed self-organizing teams to align individual and organizational objectives, increase the speed of development, promote a performance driven culture, creates business value, and allows stable and consistent communications with all stakeholders (Sutherland et al., 2007). Productivity gains, team-work-life balance, market fitness and responsiveness were the successes reported by Adobe after implementing the Scrum methodology within its development organizations (Green, 2012). © 2013 Darshan Domah, Ph.D.

10. NFR in Agile Non-functional requirements (NFR) have not been properly elicited, reasoned and validated in Agile software development where the emphasis remains on Functional Requirements (FR). NFR have been ignored or ill-defined at best in Agile software development (Paetsch, Eberlein, & Maurer, 2003) Agile projects tends to focus on functionality of the software and this creates huge costs and wasted efforts at later stages when NFR are not considered in Agile process (Um, Kim, Lee, & In 2011) © 2013 Darshan Domah, Ph.D.

11. Overview of the NERV Methodology NERV: Non-Functional Requirements Elicitation Reasoning and Validation in Agile Processes Addresses NFR in Agile Processes Lightweight framework with several artifacts: NFR Elicitation Taxonomy NFR Reasoning Taxonomy NFR Quantification Taxonomy NFR Trigger Card NFRusCOM Card (Non-Functional Requirements User Story Companion Card) NAI (NERV Agility Index) © 2013 Darshan Domah, Ph.D.

12. NERV Methodology artifacts NFR Elicitation Taxonomy A searchable classification of NFR with various criteria and related NFR concepts NFR Reasoning Taxonomy A searchable classification of NFR operationalization solutions with different levels of decomposition for reasoning about NFR NFR Quantification Taxonomy A searchable classification of NFR solutions with different levels of decomposition for identifying quantified validation criteria for NFR. NFR Trigger Card Guiding artifact for capturing FR information, NFR information, and Sprint planning information NFRusCOM Card (Non-Functional Requirements User Story Companion) Artifact to capture NFR information separate from functional requirements NERV Agility Index An aggregate score number representing the degree of agility for each FR and NFR © 2013 Darshan Domah, Ph.D.

13. Artifacts Overview: NFR Elicitation Taxonomy Keywords and related concepts based Elicit NFR from requirements Performance (Space, time, main memory, secondary memory, response time, throughput, second, minutes, hour, day, week, month, year, byte, kilobyte, megabyte, gigabyte, execution, instruction execution, perform efficiently …) © 2013 Darshan Domah, Ph.D.

14. Artifacts Overview: NFR Reasoning Taxonomy NFR information for Agile teams to reason about them Decomposition levels Decomposition goals Possible operationalizations (solutions to NFR) Areas of operationalizations Within code Within architecture Via policy © 2013 Darshan Domah, Ph.D.

15. Artifacts Overview: NFR Quantification Taxonomy NFR Quantification information Utilize GQM (Goal, Question, Metric) process Identify goal for NFR Identify questions related to NFR Identify the metrics to be used Provide possible quantifiable/testable NFR criteria © 2013 Darshan Domah, Ph.D.

16. Artifacts Overview: NFR Trigger Card © 2013 Darshan Domah, Ph.D.

17. Artifacts Overview: NFRusCOM Card © 2013 Darshan Domah, Ph.D.

18. Artifacts Overview: NAI (NERV Agility Index) Inspired from the Agile Manifesto and 12 Principles Metrics include Team Maturity Index Team Technical Competency Factor Team -Customer Collaboration Index Agile Process Index Agile Project Risk Factor Requirements Ambiguity Factor Requirements Volatility Factor Requirements Risk Factor © 2013 Darshan Domah, Ph.D.

19. Separating FR and NFR information EU eProcurement Requirement #1: User Registration This functional requirement allows for the user registration of new Procurement Officers and Tenderers/Economic Operators to the eProcurement system. The registration process must ensure the confidential transfer and storage of all personal information of users. Furthermore, mechanisms may be put in place for the validation of the information provided by new users of the system. Hence, the registration process may be performed in two phases. One phase can allow new users to apply for registration to the system, and another phase can allow authorized personnel to validate the submitted information and approve or reject a registration application. © 2013 Darshan Domah, Ph.D.

20. Artifacts Application: NFR Availability NFR: Availability Elicitation Handiness, accessibility, available, availability, convenience, error tolerance, fault, tolerance, robustness, ready for immediate use, service interruption tolerance, system degradation toleration, business continuity, operational … Reasoning How do we provide continuous availability? Operationalization: Design for high uptime; Area – Architecture/Code What steps are required to handle environmental disaster? Operationalization: Disaster recovery servers; Area - Architecture How do we handle deployment outage? Operationalization: User Notification; Area - Policy How do we protect against Spyware /Malaware? Operationalization: Run protection software; Area - Policy Validation G1: To have a system be in operation when needed. Q1: What is the uptime and downtimes? Q2: What is the recovery time after a failure? M1: Ratio of uptime/downtime. M2: Time lapse after a failure. Quantified criteria 1: System will have an uptime of 99.9999%. Quantified criteria 2: The backup system should be available within 5 minutes after a failure of original system. © 2013 Darshan Domah, Ph.D.

21. Artifacts Application: NFR Security NFR: Security Elicitation Secure, security, malicious access, unauthorized use, modification, destruction, disclosure, unauthorized access, authorization, confidentiality, integrity, non- repudiation, accountability, accountable, authenticity, authenticate, identify, accuracy, internal consistency, external consistency, external confidentiality, internal confidentiality … Reasoning How many security measures do we need? Which users will have all time access? How de we ensure internal confidentiality? Operationalization: Access authorization via authentication; Area - Architecture How do we ensure external confidentiality? Operationalization: Encrypt communication messages; Area – Architecture/Code Validation G1: To have software application securely available to authorized users. Q1: What level of access is required? M1: % authorized user access. M2: Number of allowable trials. Quantified criteria 1: The login feature will successfully authenticate 100% of all user ID/password combinations. Quantified criteria 2: 3 user login trials will be allowed for the user before denying access. © 2013 Darshan Domah, Ph.D.

22. Artifacts Application: NFR Compliance NFR: Compliance Elicitation Compliance, conformity, conformation, abidance, comply, submit, accede, bow, put forth, obedience, abidance, adherence, conformance, conformity, submission, subordination, conform to official requirements, satisfy government regulations… Reasoning What corporate standards need to be followed: Operationalization: Annual Audits; Area – Policy What are the clients requirements? Operationalization: Code reviews; Area – Policy/Code Which regulatory government body should the software satisfy? Operationalization: Use checklists; Area – Policy Which non-government body should be satisfies? Operationalization: Use checklists; Area – Policy Validation G1: To have software be compatible with accepted standards. Q1: What are the standards applicable to the software? Q2: What is the level of compliance required? M1: Number and types of standards. M2: % compliance levels. Quantified criteria 1: The software will be compliant on 3 different standards where it is on operation; the US, EU, and Japan. Quantified criteria 2: The compliance of the application should be at a +5% additional compliance on top of the minimum acceptable levels set by the US, EU, and Japanese standards. © 2013 Darshan Domah, Ph.D.

23. Additional Reasoning considerations (Miller, 2009) Security Are there any data privacy protection to address? What are the customers’ security concerns? What are the user locking criteria? What security levels should be applied to inactive users? Are there different security implementations at different customer locations? Reliability What are the customers’ reliability level expectations? What is the desired mean time between failures? How many failures are acceptable with a specific time period? What types of failure data need to be captured? Who needs to receive error logs? What are the critical reliable time periods? © 2013 Darshan Domah, Ph.D.

24. Some NFR Quantification examples NFRQuantified Criteria AuditabilityInternal audit should provide 98% compliance with internal audits and 90% compliant with external FDA audits. Aesthetic80% of users should have a 9 out of 10 pleasing experience rating when interacting with the application. ConfigurabilityThe system will have 99% success in auto-configuration for wireless access for every 8 hours usage. PerformanceThe application will support up to 300 transactions per second during peak periods. Ease of UseThe average user with 1 year computer experience will be able to navigate to their desired page within 5 seconds upon landing on the home page. MaintainabilityAll production released defects need to be fixed, tested and re-deployed for users within 72 hours of filing defect reports. Multi_Language Support The web application will be available in all 23 official languages of the EU. © 2013 Darshan Domah, Ph.D.

25. References Beck, K. et al. (2001). The Agile Manifesto. Retrieved from http://www.agilemanifesto.orghttp://www.agilemanifesto.org Breitman, K. K., Padro Leite, J. C. S., & Finkelstein, A. 1999. The world’s a stage: a survey on requirements engineering using a real-life case study. Journal of Brazilian Computer Society, 1(1). Farhat, S., Simco, G. & Mitropoulos, F.J. (2009, March). Refining and reasoning about nonfunctional requirements. In Proceedings of the 47th Annual Southeast Regional Conference (ACM-SE 47), pp. 1-5. Green, P. (2012, August). Adobe Premiere Pro Scrum Adoption: how an agile approach enabled success in a hyper-competitive landscape. In Proceedings of AGILE 2012 Conference (AGILE ‘12), pp. 172-17. Jeon, S., Han, M., Lee, E. & Lee, K. (2011, August). Quality attribute driven agile development. In C. Lu (Chair). 2011 Ninth International Conference on Software Engineering Research, Management and Applications. Conference conducted at the meeting of the IEEE Computer Society, Baltimore, Maryland, USA. Miller, R. E. (2009). The Quest for Software Requirements. Milwaukee, Wisconsin, USA. Maven Mark Books. Paetsch, F., Eberlein, A., & Maurer, F. (2003, June). Requirements engineering and agile software development. Proceedings of the Twelfth IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE’03) (pp. 1-6). Linz, Austria. Sriram, R. & Mathew, S. K. (2012, June). Global software development using Agile methodologies: a review of literature. Proceedings of the 2012 IEEE International Conference on Management of Innovation and Technology, (pp. 389-393). Sanur Bali, Indonesia. © 2013 Darshan Domah, Ph.D.

26. References 2 Sutherland, J., Viktorov, A., Blount, J., & Puntikov, N. (2007). Distributed Scrum: Agile Project Management with Outsourced Development Team. In 40th Annual Hawaii International Conference on System Sciences (HICSS'07), pp. 274a. Um, T., Kim, N., Lee, D., & In, H.P. (2011, May). A quality attribute evaluation method for an agile approach. In S-S Jang & K-J. Ahn (Co-Chairs). First ACIS/JNU International Conference on Computers, Networks, Systems, and Industrial Engineering. Conference conducted at the meeting of the IEEE Computer Society, Jeju, Jeju Island, Korea. © 2013 Darshan Domah, Ph.D.