Capturing Measurable Non Functional Requirements

Capturing Measurable Non Functional Requirements

• 1.
  Capturing Measurable Non-Functional Requirements Shehzad Lakdawala, Enterprise Architect http://ae.linkedin.com/in/shehzadl [email_address]
• 2.
  Objectives Introduction toNon-Functional Requirements Differentiating between functional and non-functional requirements Need for non-functional requirements How to capture measurable non-functional requirements Benefits
• 3.
  NFRs are thequalities of the resulting system IEEE 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”
• 4.
  Introduction
• 5.
  The System shouldfunction The System should perform The system can be enhanced/changed easily Business Needs
• 6.
  User Concerns Easeof Use Is Secure Is Available The system should function Performance Ease of interfacing The system should perform Easy to Change Easy to upgrade The system can be easily enhanced, changed
• 7.
  Mapping Business concernsto 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
• 8.
  Classifying Requirements Theproduct 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
• 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 shouldbe 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 chartdepicts 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
• 15.
  Who will benefitfrom NFR’s 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
• 16.
  Questions