This presentation focuses on the challenges surrounding building application to perform. It delves on some of the common mistakes made when designing Non Functional Requirements for a given system.

1. WHERE DO WE GO WRONG WITH NON FUNCTIONAL REQUIREMENTS?
12thNovember
v0.4
http://www.practicalperformanceanalyst.com

2. –Things to note
–Examples of Non Functional Requirements
–Why are Non Functional Requirements important
–What does experience tell us
–Where traditionally have we gone wrong with Non Functional Requirements
–Who is best placed to determine relevant Non Functional Requirements
–What can you do to prevent things going pear shaped later in the SDLC
–Q&A
–Thanks for attending the session
AGENDA

3. –Practical Performance Analyst is completely a volunteer driven effort. We welcome your contributions and donations which will help us support the on-going initiatives at Practical Performance Analyst.
–We welcome opposing points of view. We request that you treat everyone on the call with respect and respect their points of view. Please take any personal discussions offline.
–Please let us know if you are interested in helping out at Practical Performance Analyst. We’ve got a few open positions and can always do with some help.
–We are always looking for speakers, if you are interested in sharing knowledge/case studies and becoming a presented, please let us know.
–Please put yourself on mute through the session. Please feel free to ask relevant questions. If the presenter is busy answering a question please write a short note and give the presenter an opportunity to respond.
THINGS TO NOTE

4. –Concurrency -The system should be able to sustain 1000 concurrent users at peak hours. Peak hours are defined as 0800-1000 and from 1600-1800.
–Throughput -The system should be able to sustain 100 TPS at peak. Peak hours are defined as 0800- 1000 and from 1600-1800.
–Availability -The system should be designed to be available 99.999% of the time. The system will be designed for 99.999% availability.
–Utilization –The system should be designed such that system utilization across any of the tiers does not cross 60% at peak workload. Peak workload includes Concurrency, Throughput and Availability.
EXAMPLES OF NON FUNCTIONAL REQUIREMENTS

5. Non Functional Requirements are essential to –
–To determine the amount of Reliability, Availability, Performance, Security, Maintainability, etc. that needs to be built into the Application Architecture
–To determine what business is ready to spend on Reliability, Availability, Performance, Security, Maintainability, etc.
–To determine the resourcing required to meet the various Non Functional Requirements across the SDLC
–To determine the tools and processes required to meet the various Non Functional Requirements across the SDLC
–To be able to translate Non Functional Requirements to targets for Developers across the project
–To be able to articulate performance and availability metrics that need to be validated during Performance /Stress Testing
–To ensure that Business, IT, PMO, Developers, Architects, etc. are speaking the same language when it comes to performance of the platform being designed
WHY ARE NON FUNCTIONAL REQUIREMENTS IMPORTANT

6. –Most project teams lack the ability to articulate expected system performance, reliability and availability since the program as a whole lacks documented Non Functional Requirements
–Most Architects, Development and Test Leads we work with are unable to articulate what the program expects from a Non Functional standpoint
–Ask the Architects, Development Leads, Developers and Testers what their definition of Performance, Reliability, Availability is and you’ll get four separate definitions
–Lack of Non Functional Requirements leads to situations where Infrastructure teams find it challenging to determine the right amount of infrastructure capacity required for test/dev/prod environments
–Lack of Non Functional Requirements leads to situations where Performance Testing teams struggle with articulating relevant test cases due to lack of agreed Non Functional Requirements
–Lack of Non Functional Requirements leads to situations where IT is unable to agree with business on the exact go live criteria
WHAT DOES EXPERIENCE TELL US

7. –Lack of breadth of Non Functional Requirements across the various business critical components
–Lack of depth of Non Functional Requirements across the various business critical components
–Lack of relevance of Non Functional Requirements to performance metrics that can be measured during testing
–Lack of correlation of Non Functional Requirements to existing business workload metrics (for an application that exists in production)
–Non Functional Requirements documented by the Performance Testing team when the application is nearing go live
–Non Functional Requirements determined by the Performance Engineers in isolation from business & IT
WHERE TRADITIONALLY HAVE WE GONE WRONG WITH NFR’S

8. Our view is that -
–Performance Architects need to be in charge of the overall Performance Engineering strategy for a program
–Performance Architects or Performance Leads need to work closely with the Architects, Development Leads, Test Leads, Business and IT on defining the overall Non Functional Requirements
–Performance Architects need to be focused on the detail but also have visibility of the bigger picture. Non Functional Requirements require both depth and breadth across relevant system components
–Performance Architects need to work closely with their counterparts across the SDLC
•Architects –Understand system design and obtain input on Overall NFR’s and Tier wise NFR’s
•Development Leads –Work with the Development Leads and translate Tier Wise NFR’s to module wise NFR’s
•Test Leads –Work with Test Leads on translating NFR’s to relevant Performance Metrics that can be measured, analysed and compared
•Support Leads –Work with Support Leads in understanding current system issues. Obtain workload details from existing system and design Workload models accordingly.
•Business & IT –Work with Business & IT in shaping the relevant details for all NFR’s
WHO IS BEST PLACED TO DETERMINE NON FUNCTIONAL REQUIREMENTS

9. –Define Non Functional Requirements Early on
–Work with Business, IT and other relevant stake holders on nailing down overall program NFR’s
–Translate NFR’s to relevant metrics for developers and testing teams
–Lay down processes and metrics to track performance metrics across Development. Work with the Development teams on implementing the processes and tracking the relevant metrics.
–Lay down processes and metrics to track performance metrics across Testing. Work with the Testing teams on implementing the processes and tracking the relevant metrics.
–Design the Performance Engineering approach to include relevant Resources, Tools and Processes that help the program achieve the various goals from a Non Functional standpoint
–Get Business, IT, Architects, Development leads and other relevant stakeholders to sign up to the relevant Non Functional Requirements
WHAT CAN YOU DO TO PREVENT THINGS FROM GOING PEAR SHAPED

10. –We at Practical Performance Analyst would like to thank you for attending todays webcast
–We value your input. Please take a minute and send us an email with your thoughts, input and feedback at trevor@practicalperformanceanalyst.com.
–Please send us a list of topics that you would like us to include as part of our future webcasts
–Practical Performance Analyst is completely a volunteer driven effort. We welcome your contributions and donations.
–Please let us know if you are interested in helping out at Practical Performance Analyst. We’ve got a few open positions and can always do with some help.
–Come work with us and help build a stronger global community of networked Performance Engineers
THANKS FOR ATTENDING THE SESSION

11. THANK YOUTREVOR@PRACTICALPERFORMANCEANALYST.COM