Good Requirements are SORTA NUTS

Have you ever let someone down even though you had tried your best and thought you were doing what they wanted? NutsFew things are frustrating as putting forth tons of effort only to find out you were working on the wrong things.

Expectations are such an essential and common component of human relationships and communication that most of the time they are taken for granted. Taken for granted is exactly what expectations should not be.

In project management, we have a plethora of tools and techniques to help us understand expectations and meet them. We understand and fulfill those expectations through good requirements management.

Every stakeholder in a project has expectations for it, including the sponsor, team, customers, and even upper management in many cases. These expectations need to go through a review process and possibly become requirements, which in turn may lead to derived requirements that arise solely to support the main requirements. So what should come out of this review process? What makes a good requirement for a project?

I put together my own acronym based on the old standard SMART goal setting components, combined with sources on soliciting great requirements (see citations at the end of this article). I hope you like these items although I have to warn you, they ARE SORTA NUTS.

Accounted for Documented! Documented! Documented!
Ranked Prioritize for when you can’t do it all
Empathetic No conflicting requirements, understand diverse stakeholder needs
Specific Clear, concise, to the point
Owned Who’s expectation is being filled, and/or is an SME for this requirement?
Realistic Is it feasible?
Time-specific Dependencies and timing taken into account
Actionable Is this something you can execute on?
Need-focused Focus on needs, not preconceived solutions
Useful What is the business justification?
Testable How do you know when the requirement is satisfied?
Sufficient Enough detail to tell what they really want?

What factors do you look for in great requirements? Leave a comment below and let everyone know!

Sources and links:

The Art of Requirements Gathering, George Spafford

Eliciting Software Requirements, Presentation by Jesse Borschel – Sioux Empire PMI Chapter


2 thoughts on “Good Requirements are SORTA NUTS”

  1. User Avatar

    I know exactly what you are talking about. I think there are 2 main causes for a project manager not understanding the expectations or true needs of stakeholders:

    1. As you stated, it can be uncomfortable to push back on the customer and make them drop their pre-conceived notions of what the solution should be. If you don’t however, expect that about half the time the solution won’t really solve the root problem. Compare the time and effort up-front to define the root problem with the potential re-work required on the back-end if the pre-conceived solution fails. In my experience, you avoid this risk almost completely by laying it all out on the table right away.

    2. The second reason seems to be that project managers don’t realize the need to analyze their assumptions, and the stakeholder/sponsor assumptions, objectively. They just say “I was told to go implement this, so here we go!” Requirements gathering is not a good time to make assumptions lightly.

    Josh Nankivel

  2. User Avatar

    Great topic. I try to notice times when I’m reluctant to have those “expectation” conversations and think “I’ll just hope for the best.” When I can spot it, that’s a flag that something is going off track.

    The thing I wonder about is what makes it tough to have those “let’s set expectations” conversations?

    Everyone knows setting expectations clearly is important–how many do it consistently?

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top