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

1. Capturing Measurable Non-Functional Requirements Shehzad Lakdawala, Enterprise Architect http://ae.linkedin.com/in/shehzadl [email_address]

4. Introduction

5. The System should function The System should perform The system can be enhanced/changed easily Business Needs

7. Mapping Business concerns to NFR Ease of Use Is Secure Is Available Usability Securability Reliability Performance Ease of interfacing Efficiency Interoperability Ease of Change Easy to upgrade Maintainability Flexibility Portability Scalability User Concern NFR

9. Business Needs – System should be available during working and non-working hours Availability Objective Metrics & Performance Data Availability Number of planned outages per month/year Number 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 hours 95% 18.25 days 36 hours 8.4 hours 98% 7.30 days 14.4 hours 3.36 hours 99% ("two nines") 3.65 days 7.20 hours 1.68 hours 99.5% 1.83 days 3.60 hours 50.4 minutes 99.8% 17.52 hours 86.23 minutes 20.16 minutes

10. The transactions should be categorized as per the below matrix Simple Transactions: The response time for simple transaction should be 3 seconds or less. Transactions such as page navigation are examples of simple transaction Medium Transactions: The response time for medium transactions should be 6 seconds or less. Submitting information, simple search, simple query are examples of medium transaction Complex 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 Efficiency Objective Metrics & Performance Data Response Time Response time for simple Transaction Response time for medium transaction Response time for complex transaction Capacity Number of Concurrent Users Number of Total Users Number of Transactions per day Transaction Category Response Time SLA (sec) Simple 3 Medium 6 Complex 10

11. Performance

12. Business Need – System should be supported Supportability Objective Metrics & Performance Data Support/Maintenance Number of support calls expected during the month Supportability Number of support calls expected out of office hours Supportability Response time for Critical calls Response time for High Priority calls Response 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

13. Business Need – Protect sensitive information from unauthorized access Security 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)

14. 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 Reference

16. Questions