Darshan Domah, Ph.D. October 3, 2013. Agenda Non-Functional Requirements Why they are important Agile Software Development NFR in Agile Processes Overview

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


NFR ExamplesEnding in -

ilitiesEnding in -

itiesEnding in -

nessOther

Ending

AvailabilityUsabilityPortability ReliabilityMaintainabilitySurvivabilityScalability ReusabilityFlexibility InteroperabilityTestabilityAuditability

SecurityIntegritySimplicityCapacity

TimelinessUser-FriendlinessCorrectnessCompletenessResponsiveness

PerformanceCostEfficiencyAccuracyPrecisionLegalConsistency

Some Uncommon NFR

AdditivityDistributivityNormadicityEvolvability

DecomposabilityWrappability


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).


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


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


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).


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)


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)


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


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 …)


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


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


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.


Artifacts Overview: NFRusCOM Card


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



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.


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.


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.


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?


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.


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.


http://www.agilemanifesto.org/

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.


Questions?

Documents

Darshan Domah, Ph.D. October 3, 2013. Agenda Non-Functional Requirements Why they are important Agile Software Development NFR in Agile Processes Overview