The topics covered in this HowTo are:
- What Are HowTo’s?
- Why HowTo’s @ PPA?
- Why We Wrote, HowTo Define Non Functional Requirements (NFRs)?.
- What are Non-Functional Requirements (NFRs)?
- What Are Performance Budgets?
- How does a Performance Budget align with Non-Functional Requirements?
- What Tiers or Components of a System Should Be Considered In Scope When Defining Non Functional Requirements?
- How important are Non Functional Requirements to the success of a program?
- What Information Do You Need To Design Non Functional Requirements?
- Who should Design, Own, and Maintain Non Functional Requirements?
- At what point in the Development Lifecycle should Non Functional Requirements get created
- What Process Should One Follow To Define Non Functional Requirements?
- What are the outcomes you wish to achieve with Non Functional Requirements?
- How To Get Your Teams To Buy Into Non Functional Requirements?
- Measuring & Tracking How Teams Are Tracking With Their Non Functional Requirements?
- Caveats and what to be careful of when designing Performance Budgets?
- How Do You Leverage Non Functional Requirements across other SPE (Systems Performance Engineering) activities through the Development Cycle e.g. NFR’s as input into Performance Testing?
- What Table Of Contents should I Be Considering When Writing a Non Functional Requirements Document?
- Let’s Create A Few Non Functional Requirements
What Are HowTo’s
A HowTo is a document that does precisely what the name suggests i.e. It’s describes “HowTo” achieve a set of outcomes through illustration of all the steps involved. HowTo’s are generally structured and written without too much technical jargon in a straight forward manner without making too many assumptions of the depth of knowledge the reader. HowTo’s are meant to make for easy reading and are logical in the sequence of steps it recommends.
Any background knowledge required to assimilate the information provided in the HowTo is generally highlighted at the start of the HowTo. HowTo’s are generally written for the professional who are clear of what they need to accomplish but have little or no knowledge of how to go about achieving those objectives. HowTo’s are meant to be exhaustive in nature and they are definitely not meant to offer the most efficient way of getting the job done. A HowTo should be seen as a kick starter that helps the user get up and running with a given task without having to master all the required fundamentals.
Why HowTo’s @ PPA?
HowTo’s have been the mainstay of the Open Source and Free Software movement for decades. One of the reasons why Open Source and Free Software is so widely used today is simply because of the depth of documentation that exists and the maturity of the Open Source ecosystem which has delivered scalable, open and reliable software. HowTo’s like many other building blocks have helped the Open Source and Free Software movement grow immensely while eliminating the need to keep re-inventing the wheel. It’s only natural that we at Practical Performance Analyst adopt the best from the Open Source and Free Software movement. A lot of the work we do at Practical Performance Analyst borrows from the fundamentals of the Open Source movement and HowTo’s are definitely one of them.
As HowTo’s @ PPA grows and matures we will hopefully reduce the reinventing of the wheel which happens so very often at organizations, projects and programs when it comes to the science of building/delivering systems that scale.
Links to Content –
- HowTo Define Non Functional Requirements – Part I
- HowTo Define Non Functional Requirements – Part II
- HowTo Define Non Functional Requirements – Part III
- HowTo Define Non Functional Requirements – Part IV
- HowTo Define Non Functional Requirements – Part V
- HowTo Define Non Functional Requirements – Part VI
- HowTo Define Non Functional Requirements – Part VII
- HowTo Define Non Functional Requirements – Part VIII
Trevor Warren (Linked In) focuses on building innovative solutions that have the potential to impact people’s lives in a positive manner. Trevor is inquisitive by nature, loves asking questions and sometimes does get into trouble for doing so. He’s passionate about certain things in life and building solutions that have the ability to impact people’s lives in a positive manner is one of them. He believes that he can change the world and is doing the little he can to change it in his own little ways. When not hacking, building new products, writing content for Practical Performance Analyst, dreaming up new concepts or building castles in the air, you can catch-him bird spotting (watching planes fly above his house). You can reach trevor at – trevor at practical performance analyst dot com. The views expressed on this web site are his own.