To download a hi-res PDF of this quote, click on Business Analysis Wisdom - Roxanne Miller wisdom #1
The much-loved Nonfunctional requirements
Roxanne Miller authored the wonderful book (that has a prominent place on my bookshelf) “The Quest for Software Requirements“.
The Quest for Software Requirements
Roxanne’s book is made up of two parts.
In the first part “Right Process, Right People, Right Tools” she explores what requirements are (and what they are not), along with the best ways to draw those requirements out (elicit) from the right people (stakeholders).
In the second part, “Right Approach, Right Questions”, Roxanne delves deeply into nonfunctional requirements. This is where the book is incredibly valuable.
Nonfunctional requirements are often the most challenging of the requirements. They can be hard to define, and may often be given less attention than their cousins, the well-known “functional” requirements.
Roxanne tackles this subject in depth. In her book, she includes over 2000 questions that Business Analysts can use during elicitation, and she explains where, and why, each question can be asked.
Why and How?
Roxanne was kind enough to have a small chat with me about her book.
I was curious where her inspiration for such a useful tome came from.
Here’s her answer:
Over the years, I noticed that Business Analysts would have a placeholder for NFRs in their requirements deliverables (SRS, or Requirements Definition Document). However, 99% of the time that NFR section of the deliverable was blank or empty. That is, it wasn’t being filled in. Of course, I asked why not. Responses were usually that they didn’t know what they were, they didn’t know how to write nonfunctional requirements, and they didn’t know who to elicit them from. I saw this as a whole that needed to be plugged.
The book took Roxanne about 18 months to write, and when I asked her what she did to prepare for the book she told me:
I did lots and lots of research. I read books. I read articles. I talked to practitioners. I talked to experienced developers. I talked to requirements industry leaders. Some of the knowledge was drawn from my own project experiences, and observing first hand the consequences of not defining or ignoring NFRs.
Roxanne was kind enough to let me use some of the quotes in my new book “Business Analysis Wisdom”.
You can see one of these at the top of this post, as well as ….
To download a hi-res PDF of this quote, click on: Business Analysis Wisdom - Roxanne Miller wisdom #2