Interview Questions for Business Analysts and Systems Analysts


Recent Interview Questions | Search | Subscribe (RSS)

?
INTERVIEW QUESTION:

What are the characteristics of a good requirement?

Posted by Chris Adams

Article Rating // 45588 Views // 5 Additional Answers & Comments

Categories: Solution Assessment and Validation (BABOK KA), Testing & Quality Assurance (QA)

ANSWER

While different organizations and authors may describe a slightly modified list, the following characteristics are generally accepted as those defining a good requirement.

Cohesive:  The requirement defines a single aspect of the desired business process or system.

Complete:  The individual requirement is not missing necessary or relevant information.  Additionally, the entire set of requirements should cover all relevant requirements.

Consistent:  The requirement does not contradict another requirement.

Modifiable:  Like requirements should be grouped together to allow similar requirements to be modified together in order to maintain consistency.

Correct:  The requirement meets the actual business or system need.  An incorrect requirement can still be implemented resulting in a business process or system that does not meet the business needs.

Observable:   The requirement defines an aspect of the system that can be noticed or observed by a user.  This is often referred to as “Implementation Agnostic” as the requirement should not specify aspects of system architecture, physical design or implementation decisions.   These aspects of a system should be defined separately as constraints.

Feasible:  The requirement can be implemented within the constraints of the project including the agreed upon system architecture or other physical design or implementation decisions.

Unambiguous:  The requirement is written objectively such that there is only a single interpretation of the meaning of the requirement.

Verifiable:  It can be shown that the requirement has been met by the final solution via inspection, demonstration, test, or analysis.

--
Chris Adams
LinkedIn Profile
print this answer

RATE THIS TOPIC

ADDITIONAL ANSWERS / COMMENTS

Adrian M. posted on Wednesday, November 18, 2009 1:15 PM
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.
Adrian M. posted on Wednesday, November 18, 2009 2:01 PM
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:)
Adrian M. posted on Wednesday, November 18, 2009 9:13 PM
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.
Joe posted on Monday, April 19, 2010 10:36 AM
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
Oz posted on Wednesday, December 7, 2011 8:51 PM
Joe I would go with the SMART criteria as a sound formalised method to check the veracity / conformity of a requirement.
Only registered users may post comments.

Do your homework prior to the business analysis interview!

Having an idea of the type of questions you might be asked during a business analyst interview will not only give you confidence but it will also help you to formulate your thoughts and to be better prepared to answer the interview questions you might get during the interview for a business analyst position.  Of course, just memorizing a list of business analyst interview questions will not make you a great business analyst but it might just help you get that next job.





Select ModernAnalyst Content

Register | Login

Featured Digital Library Resources 
Copyright 2006-2015 by Modern Analyst Media LLC