WHERE DO WE GO WRONG WITH NON FUNCTIONAL REQUIREMENTS?

12th November

v0.4

http://www.practicalperformanceanalyst.com

– 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

– 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

– 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

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

– 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

– 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

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

– 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

– 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

THANK YOU

TREVOR@PRACTICALPERFORMANCEANALYST.COM