Capturing Measurable Non Functional Requirements

  • 4,729 views
Uploaded on

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

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

More in: Technology , Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
4,729
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
162
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Capturing Measurable Non-Functional Requirements Shehzad Lakdawala, Enterprise Architect http://ae.linkedin.com/in/shehzadl [email_address]
  • 2. 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
  • 3.
    • NFRs are the qualities 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 should function The System should perform The system can be enhanced/changed easily Business Needs
  • 6. User Concerns
    • Ease of 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 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
  • 8. Classifying Requirements 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
  • 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
  • 15. Who will benefit from 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