Date post: | 17-Dec-2015 |
Category: |
Documents |
Upload: | loraine-small |
View: | 218 times |
Download: | 2 times |
Non-Functional Requirements in Agile Software Development
Darshan Domah, Ph.D.October 3, 2013
AgendaNon-Functional RequirementsWhy they are importantAgile Software DevelopmentNFR in Agile ProcessesOverview of ArtifactsApplication of artifactsNFR Concerns in Agile
© 2013 Darshan Domah, Ph.D.
What are Non-Functional Requirements (NFR)Technical ConstraintsArchitectural ConstraintsNon-Technical attributesAll 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.
NFR ExamplesEnding in -
ilitiesEnding in -
itiesEnding in -
nessOther
Ending
AvailabilityUsabilityPortability ReliabilityMaintainabilitySurvivabilityScalability ReusabilityFlexibility InteroperabilityTestabilityAuditability
SecurityIntegritySimplicityCapacity
TimelinessUser-FriendlinessCorrectnessCompletenessResponsiveness
PerformanceCostEfficiencyAccuracyPrecisionLegalConsistency
Some Uncommon NFR
AdditivityDistributivityNormadicityEvolvability
DecomposabilityWrappability
© 2013 Darshan Domah, Ph.D.
Why are NFR importantMost 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.
Why are NFR important1992 London Ambulance System Failure
Subject of many studies (Brietman et al., 1999)Receive phone call and decide which ambulance
to dispatchAmbulance late dispatch – patient deadAmbulance 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.
Agile software developmentUmbrella of software development methods
Support incremental and iterative developmentScrum, Extreme Programming, Crystal, Feature Driven
Development, Dynamic Systems Development MethodScrum - preferred Agile method; Lightweight and
flexible framework
© 2013 Darshan Domah, Ph.D.
3 Roles
3 Artifacts
5Ceremoni
es
Product OwnerScrum MasterThe Team
Product BacklogSprint BacklogBurndown Chart
Release PlanningSprint PlanningDaily Stand Up MeetingSprint Demo and ReviewSprint Retrospective
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 1 Our highest priority if to satisfy the customer through early and
continuous delivery of valuable software.
Principle 2 Welcome 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 12 At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.© 2013 Darshan Domah, Ph.D.
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.
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.
Overview of the NERV MethodologyNERV: Non-Functional Requirements
Elicitation Reasoning and Validation in Agile Processes
Addresses NFR in Agile ProcessesLightweight framework with several
artifacts:NFR Elicitation TaxonomyNFR Reasoning TaxonomyNFR Quantification TaxonomyNFR Trigger CardNFRusCOM Card (Non-Functional Requirements User
Story Companion Card)NAI (NERV Agility Index)
© 2013 Darshan Domah, Ph.D.
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.
Artifacts Overview: NFR Elicitation Taxonomy
Keywords and related concepts basedElicit 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.
Artifacts Overview: NFR Reasoning Taxonomy
NFR information for Agile teams to reason about them
Decomposition levelsDecomposition goalsPossible operationalizations (solutions to
NFR)Areas of operationalizations
Within codeWithin architectureVia policy
© 2013 Darshan Domah, Ph.D.
Artifacts Overview: NFR Quantification Taxonomy
NFR Quantification information Utilize GQM (Goal, Question, Metric)
processIdentify goal for NFRIdentify questions related to NFRIdentify the metrics to be usedProvide possible quantifiable/testable NFR
criteria
© 2013 Darshan Domah, Ph.D.
Artifacts Overview: NFR Trigger CardNFR Trigger CardNFR Elicitation
1.Who is(are) the user(s)? > Populate User Story Card.2.What is the action performed? > Populate User Story Card.3.What are the keywords in the requirements statement? > Using each keyword, search NFR Elicitation Taxonomy to identify NFR; Populate NFRusCOM Card.4.What are the related concepts associated with the above keywords? > Search NFR Elicitation Taxonomy to identify NFR; Populate NFRusCOM Card.
NFR Reasoning
1.Where can the NFR be addressed; in code, in architecture, or by policy? > Search NFR Reasoning Taxonomy; Populate the NFRusCOM Card.2.What is the operationalization for the NFR? > Search NFR Reasoning Taxonomy; Populate the NFRusCOM Card.
NFR Validation
1.What is the quantification boundary for the NFR? > Search NFR Quantification Taxonomy; Populate the NFRusCOM Card.2. What are the validation criteria for this NFR? > Populate the NFRusCOM Card.
Release Planning
1.What is the Risk description for this NFR? > Populate the NFRusCOM Card.2.What is the priority for addressing this NFR? > Populate the NFRusCOM Card.
© 2013 Darshan Domah, Ph.D.
Artifacts Overview: NFRusCOM Card
© 2013 Darshan Domah, Ph.D.
Artifacts Overview: NAI (NERV Agility Index)
Inspired from the Agile Manifesto and 12 Principles
Metrics includeTeam Maturity IndexTeam Technical Competency FactorTeam -Customer Collaboration IndexAgile Process IndexAgile Project Risk FactorRequirements Ambiguity FactorRequirements Volatility FactorRequirements Risk Factor
© 2013 Darshan Domah, Ph.D.
© 2013 Darshan Domah, Ph.D.
Separating FR and NFR informationEU eProcurement Requirement #1: User Registration
This functional requirement allows for the user registration of new ProcurementOfficers and Tenderers/Economic Operators to the eProcurement system. The registration process must ensure the confidential transfer and storage of all personalinformation of users. Furthermore, mechanisms may be put in place for the validationof the information provided by new users of the system. Hence, the registrationprocess may be performed in two phases. One phase can allow new users to apply forregistration to the system, and another phase can allow authorized personnel tovalidate the submitted information and approve or reject a registration application.
Artifacts Application: NFR AvailabilityNFR: 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/CodeWhat steps are required to handle environmental disaster? Operationalization: Disaster recovery servers; Area - ArchitectureHow do we handle deployment outage? Operationalization: User Notification; Area - PolicyHow 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.
Artifacts Application: NFR SecurityNFR: 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 - ArchitectureHow 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.
Artifacts Application: NFR ComplianceNFR: 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 – PolicyWhat are the clients requirements? Operationalization: Code reviews; Area – Policy/CodeWhich regulatory government body should the software satisfy? Operationalization: Use checklists; Area – PolicyWhich 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.
Additional Reasoning considerations (Miller, 2009)SecurityAre 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?
ReliabilityWhat 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.
Some NFR Quantification examplesNFR Quantified Criteria
Auditability Internal audit should provide 98% compliance with internal audits and 90% compliant with external FDA audits.
Aesthetic 80% of users should have a 9 out of 10 pleasing experience rating when interacting with the application.
Configurability The system will have 99% success in auto-configuration for wireless access for every 8 hours usage.
Performance The application will support up to 300 transactions per second during peak periods.
Ease of Use The 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.
Maintainability All 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.
References Beck, K. et al. (2001). The Agile Manifesto. Retrieved from http://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.
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.
Questions?