Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  Metrics for tracking requirement quality
Previous Previous
 
Next Next
New Post 3/18/2008 6:08 AM
User is offline Jonyce
2 posts
No Ranking


Metrics for tracking requirement quality 

Hi, I'm new to the forum and figured this would be the best place to ask my question. 

I'm trying to find some metrics that I can use to determine the quality of the requirements we are creating for our customers. What measurements can we use to show our customers that we are generating quality requirements and capturing their needs effectively and efficiently?

I've done several searches online but haven't run into anything I can use yet.  Any suggestions and guidance would be greatly appreciated.

 
New Post 3/19/2008 1:03 PM
User is offline Adrian M.
764 posts
3rd Level Poster




Re: Metrics for tracking requirement quality 

It is very hard to objectively quantify and/or measure the quality of requirements upfront.

The main thing you need to do upfront is consider putting in place some guidelines and best practices for writing and capturing requirements, for example:

  • ensure each requirement is tracked back to a business goal/need - or else you're likely working on the wrong thing;
  • ensure each requirement is objective and un-ambiguous; requirements which are not objective are open for interpretation and the clients tent to not interpret them in your favor - > examples of bad requirements: the system shall "be fast", "support multiple users", "be user friendly"...
  • insist that requirements only contain the requirement and not design decisions aka keep solutioning apart from requirements;
  • validate the requirements with the business stakeholders;
  • create prototypes or wire-frames or solution documents which explain how the requirements might be realized by the system and place those in the broader business process => get feedback from the stakeholders.

OK - we can you measure the quality of requirements?  Probably only after the fact... The real test of good requirements if they deliver a system which fills the need the business has.  Once requirements have been realized and delivered you can measure all kinds of things such as:

  • from the stakeholder's perspective, how many requirements were not implemented as per their expectations => need to find the root cause: ambiguous requirement, business need changed, etc.
  • track how many requirements change over time for reasons other than changing business need,
  • how many new high priority requirements are discovered during the development, QA, and production.

The one thing to keep in mind is that it is also possible that each requirement, by itself, is a "quality" requirement and still deliver a system which does not meet the business need.  Why?  There could be many reasons but one of the, related to requirements is:  the totality of requirements don't solve the business problem.  It is rare that one single requirement solves a business need.  Usually it's the entire package or sets of requirements which provide value to the business.

Hope this helps!

- Adrian


Adrian Marchis
Business Analyst Community Blog - Post your thoughts!
 
New Post 3/19/2008 6:12 PM
User is offline Craig Brown
560 posts
www.betterprojects.net
4th Level Poster




Re: Metrics for tracking requirement quality 
Modified By ModernAnalyst.com  on 3/19/2008 11:46:22 PM)

I lke Guy's article on aligning requirements to project goals (or strategy).

In it he presents an ER iagram which you can use to map the alignment of your requirements to the project goals.

You can read Guy's article here.

I guess this is just one part of the puzzle - it looks at whether your requirements are the right ones.  It doesn't assess whether there is anything missing.  That role should probably come from the stakeholder validation.

(Added later: By the way, I forgot I had posted up this blog carnival post on requirements analysis.  Much of it is focused on how to ensure your requirements are of good quality.  There is no silver bulet, but there are plenty of ideas there for you.  Read ther carnival on requirements analysis  here.)

It's important to note that requirements elicitation is often an iterative process and that you probably won't get everything nailed down in the first iteration.  In fact people quote rates of requirements change around the 5% mark per month the project is in progress. 

Don't sweat it too much. The real; trick is in keeping everyone talking to each other continuously throughut the project lifecycle.

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Metrics for tracking requirement quality

Community Blog - Latest Posts

Fabricio Laguna talks Business Analysis and AI
I recently connected with Fabricio Laguna, aka The Brazilian BA. Fabricio is a passionate and pioneering business analyst from Brazil. During our conversation, we had a thought-provoking discussion on how artificial intelligence stands to shape the field of business analysis in the years ahead. While AI promises to transform many aspects of busines...
Business Architecture, Ontology and More with Terry Roach
It's been a privilege meeting Terry Roach, a visionary in the field of enterprise architecture and business architecture. Terry's insights into the evolution of business models, the importance of ontology in architecture, and the potential of AI to shape our future were not only thought-provoking but also a reflection of his extensive exper...
Today I had the pleasure of chatting to Jignesh Jamnadas, Chief Operations Officer at Mosaic, about his Blueprints for Success. As a Senior Finance and Operations Executive, Jigs (as he is known to many) has a holistic understanding of all facets of business and a flair for managing both people and processes. Having worked with Jigs, I was struc...

 



Upcoming Live Webinars




 

Copyright 2006-2024 by Modern Analyst Media LLC