Darshan Domah, Ph.D.
October 3, 2013
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.
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.
NFR Examples
Ending in -ilities
Availability
Usability
Portability Reliability
Maintainability
Survivability
Scalability Reusability
Flexibility
Interoperability
Testability
Auditability
Ending in ities
Security
Integrity
Simplicity
Capacity
Ending in -ness
Timeliness
User-Friendliness
Correctness
Completeness
Responsiveness
Other Ending
Performance
Cost
Efficiency
Accuracy
Precision
Legal
Consistency
Some Uncommon
NFR
Additivity
Distributivity
Normadicity
Evolvability
Decomposability
Wrappability
© 2013 Darshan Domah, Ph.D.
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.
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.
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
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
© 2013 Darshan Domah, Ph.D.
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.
Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly.
Principle 5
Principle 12
© 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 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.
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 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.
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.
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.
Artifacts Overview: NFR Trigger Card
NFR Trigger Card
NFR 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 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.
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.
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.
Artifacts Application: NFR Security
NFR: Security
Elicitation
Secure, security, malicious access, unauthorized use, modification, destruction,
disclosure, unauthorized access, authorization, confidentiality, integrity, nonrepudiation, 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.
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.
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.
Some NFR Quantification examples
NFR
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.