Posted by Andrew Midkiff as on LinkedIn:

That's a pretty good answer, but there were a few odd or ambiguous things about it. The question was about the characteristics of a good requirement. Some of the answer relates to the characteristics of a good requirement set, or architecture. Useful information, but somewhat out of scope. :-)

1. To me the answer given seems to be describing the value of discreetness, or not trying to pack too much into a single "requirement." The idea there is that the requirement should be describing a discreet, identifiable result of value. This is the happy medium between over-complicatedness and functional decomposition. Cohesiveness relates, I thought, more to how requirements work together to achieve the overall goals.

2. Complete, consistent, both sound good.

3. Modifiable relates more to requirements architecture and requirements management planning. It has more to do with how you structure your requirements and how you manage them then characteristics of a good requirement. But good info anyway. I might modify it a bit to say that related requirements should be able to be modified together, or modifications that affect more than one requirement should be propagated without redundancy of effort. You know you've failed in keeping your requirements discreet if you have too much work to do to modified the same thing in multiple requirements.

4. The author's definition of Observable is not what I'm used to seeing or teaching. Observable usually means that you can test it. If the requirement results in something that can't be observed, it can't be tested. If it can't be tested, then it can't be verified. The author seems to be confusing this concept with being business-focused, and solution agnostic. I fully agree that solution agnosticism is a very desirable characteristic of business requirements, and I can talk for days on it (much to the chagrin of my colleagues) but it is not the same thing as Observable. The author talks about the characteristics of Observable under the heading of Measurable, when they're really the same thing.

5. Feasible is a tricky and dangerous characteristic to deal with. At some point in the project, we can't be worrying much about "feasible", such as before we have a solution in mind and we're just trying to understand business needs. But at a slightly later stage, we must become aware of feasibility. The trickiness comes when we start talking about the feasibility of a requirement. If some functionality or constraint is truly needed to get the value looked for by the stakeholders, i.e. it is a true requirement, then feasibility only applies to specific solutions. If the functionality is truly not deliverable in any form within the confines of the project, then the required value will not be delivered and it becomes a business risk to deal with. If the functionality cannot be delivered with the desired characteristics (e.g. throughput) then it becomes a business design issue to deal with. Where we get into difficulty is when a solution is described as the requirement, (an automated adjudication system) and when THAT cannot be delivered in the scope or time of the project, than the "requirement" is deemed not feasible. If that happens, then you are already way outside solution agnosticism and way into the tangled swamp of confusing solutions with requirements. That way lies madness.

6. Unambiguous is a condition "devoutly to be wished" but usually can not be achieved through written means alone. All language has a certain level of ambiguity inherent into it since it is all an abstraction of reality. This includes modeling languages, but they can achieve a higher level of specificity over normal language if used rigorously because of the very specific definitions given to specific symbols and the ability to layer and nest models. But even they aren't perfect. For that, we need all of the tools, including collaboration. "Unambiguous value" though, is a characteristic of a good requirement.

Posted by Gina (Eugenia) Schwalm, PMP, CBAP on LinkedIn:

Rather than saying "good" requirement (what is good?) --- maybe we ask which characteristics of a requirement or set of requirements can help us communicate them in a way that they can be translated into an implementable and verifiable solution.

As Andrew mentions in his breakdown of each - it depends.

In other words - if that requirement was handed to me (as a designer, developer, tester, database administrator, etc.), then I should be able to translate it into a workable solution. If there isn't enough there to do that, than further collaboration would be required if there is time for iterations and collaboration (such as with AGILE). If it is waterfall methodology, then it would require more formality, structure, level of detail (higher quality). So the quality of the characteristics will vary depending on the type of project and the methodology approach.

Also, does the level of requirement matter (business, stakeholder, solution)? Does a business requirement have different characteristics or variations of their definitions as compared to a solution requirement (functional and non-functional requirements)? - sorry for answering a question with questions:)

Posted by Andrew Midkiff on LinkedIn:

Gina brings up a good point.

Add "Actionable" to the list of characteristics of a good requirement. And the criteria for Actionable depends upon the context in which it is acted upon. If you're in an agile development space, then communication should be immediate and constant, so you need less detail in order to be able to act. There is an inverse relationship between detail needed in your requirements and availability of the analyst to the design and build teams. If the primary consumers of your requirements don't have the information they need to act upon those requirements, then the requirement is not finished.

On the other hand, this assumes that all stakeholders have the same understanding of what action they need to take based on the requirements. I've seen too many instances of requirements being declared "not finished" because someone is looking for something in the requirements and not finding it. (usually a full description of the solution that isn't supposed to be there) But that is another issue related more to managing process, definition of work and expectations rather than the standards around what is a good requirement.

And one more characteristic that I ran out of space to add is "Value-driven." A good requirements is one that is based on a measurable value to the user of the system.

The traditioanl definition of a use case still encapsulates a great deal of this: describes the interaction between an actor and the system in order to achieve an observable result of value to the actor.

Hi All,
I'm just embarking on my 3rd year dissertation/Project for a Bsc in Computing and am going down the analysis career path, I have a few questions:

The above list of requirement attributes:-
- Would you go through your requirments list/matrix and analyse each one against the criteria?

- Regarding the above requirement attributes, could the below selected be replaced with SMART objectives?
Observable:
Feasible:
Verifiable:
Actionable:

How would you measure the value to a user.

Also is there any sort of indicator of when a solution is being confused with a requirement?

Thanks,
Joe

Joe I would go with the SMART criteria as a sound formalised method to check the veracity / conformity of a requirement.