Embed Size (px)
DESCRIPTION
Non-Functional Requirements are as important as Functional Requirements. Requirement that cannot be measured is not a requirement. NFR's are critical for successful software architecture development
Citation preview
Capturing Measurable Capturing Measurable
Non-Functional RequirementsNon-Functional Requirements
Shehzad Lakdawala, Enterprise Architecthttp://ae.linkedin.com/in/[email protected]
Objectives
• Introduction to Non-Functional Requirements
• Differentiating between functional and non-functional requirements
• Need for non-functional requirements
• How to capture measurable non-functional requirements
• Benefits
NFRs are the qualities of the resulting system NFRs are the qualities of the resulting system
IEEE standard 830 - 1993IEEE standard 830 - 1993
What are Non Functional Requirements
“Functional requirements define WHAT a system is supposed to do”
“Non-Functional requirements define HOW a system is supposed to be”
Introduction
The System should functionThe System should function
The System should performThe System should perform
The system can be enhanced/changed easilyThe system can be enhanced/changed easily
Business NeedsBusiness Needs
User ConcernsUser Concerns
• Ease of Use• Is Secure• Is Available
The system should function
• Performance• Ease of interfacingThe system should perform
• Easy to Change• Easy to upgrade
The system can be easily enhanced, changed
Mapping Business concerns Mapping Business concerns to NFRto NFR
Ease of UseIs Secure
Is Available
UsabilitySecurabilityReliability
PerformanceEase of interfacing
EfficiencyInteroperability
Ease of ChangeEasy to upgrade
MaintainabilityFlexibilityPortabilityScalability
User Concern NFR
The product will support multiple languages
is a usability requirement
The system will run 7 days a week, 24 hours a day is a reliability requirement
An online help system is required is a usability requirement
All presentation logic will be written in Ajax is an implementation requirement
Classifying RequirementsClassifying Requirements
Objective Metrics & Performance Data
AvailabilityNumber of planned outages per month/yearNumber of unplanned outages per month/year Number of Hours per outage
Availability Ability to restore all transactions to a point in time prior to a failure (minutes, hours, days)
Availability Maximum time required to restore configuration/session data (minutes, hours, days)
Availability % Downtime per year Downtime per month*
Downtime per week
90% ("one nine") 36.5 days 72 hours 16.8 hours95% 18.25 days 36 hours 8.4 hours98% 7.30 days 14.4 hours 3.36 hours99% ("two nines") 3.65 days 7.20 hours 1.68 hours99.5% 1.83 days 3.60 hours 50.4 minutes99.8% 17.52 hours 86.23 minutes 20.16 minutes
Business Needs – System should be available during working and non-working hours
AvailabilityAvailability
Objective Metrics & Performance Data
Response Time
Response time for simple TransactionResponse time for medium transactionResponse time for complex transaction
CapacityNumber of Concurrent UsersNumber of Total UsersNumber of Transactions per day
Transaction Category Response Time SLA (sec)Simple 3Medium 6Complex 10
The transactions should be categorized as per the below matrixSimple Transactions: The response time for simple transaction should be 3 seconds or less. Transactions such as page navigation are examples of simple transactionMedium Transactions: The response time for medium transactions should be 6 seconds or less. Submitting information, simple search, simple query are examples of medium transactionComplex Transactions: The response time for complex transactions should be 10 seconds or less. Advanced search is example of complex transaction.
Business Need – System should perform fast
EfficiencyEfficiency
PerformancePerformance
Objective Metrics & Performance DataSupport/Maintenance
Number of support calls expected during the month
Supportability Number of support calls expected out of office hours
SupportabilityResponse time for Critical callsResponse time for High Priority callsResponse time for Low Priority calls
Scalability% increase in yearly volumes for next x years% increase in number of users for next x years% increase in disk space required yearly for next x years
Business Need – System should be supported
SupportabilitySupportability
Objective Metrics & Performance Data
Confidentiality and Integrity The system is protected from unauthorized access
Availability Time to restore/clean/restart compromised system or data
Compliance Compliance with regulations and industry standards (ISO 27001, PCI, COBIT)
Business Need – Protect sensitive information from unauthorized access
SecuritySecurity
Above chart depicts the significance of each listed non-functional requirement to the defined system use-cases in the manner of ‘high’, ‘medium’, and ‘low’.
NFR/Use Case ReferenceNFR/Use Case Reference
Business tracing the non-functional requirements
Infrastructure team In provisioning the infrastructure
Test team in defining test cases and achieving user acceptance
Solution and Design in design and development of application
Enterprise Architecture in defining the right architecture and capacity planning
Management Cost saving and Financial Planning
Operations Team In meeting SLA’s
Who will benefit from NFR’sWho will benefit from NFR’s
QuestionsQuestions
