Requirements engineering and quality

This article covers requirement quality or

what does a good requirement look like? 

how we can measure the quality of a requirement?.

It also explains the context of requirements and warns against over use.

If you would like an introduction to Requirements Engineering – see Requirements Engineering – an introduction

Word of warning

Although our end goal is a quality set of requirements, it is critical that we maintain a dialogue with the stakeholders. Always accept the requirements provided by the stakeholders as a draft and and work towards improving them. Part of the process of producing quality requirements will be to educate the stakeholders as to what constitites a quality requirement.

Quality criteria

The structure of our requirement statements should conform to an agree standard which gives us a goal that drives some of our questions. There are two good approaches to requirements structure defined in Writing Better Requirements (Ian Alexander) and Mastering the Requirements Process (Suzanne and James Robertson – they have a requirement template available here – Volere requirement ‘snowcard’).

There are some key elements to consider for any requirement

  • the class of users to which it applies
    Note: a glossary will be necessary to ensure any terms are fully explained and agreed by all
    e.g. The bank clerk shall be able to assess a customer’s credit worthiness
     
  • any constraints that may apply
    e.g. The bank clerk shall be able to assess a customer’s credit worthiness within 30 seconds of entering their personal details
     
  • must be verifiable
    Would you be able to write a test that verifies this requirement undisputably?
     
  • makes only one simple statement with no alternatives stated
    e.g. The bank clerk shall be able to assess a customer’s credit worthiness and resolve any issues that arise with their manager
    This requirement is NOT simple and should be broken into two separate requirements
    The bank clerk shall be able to assess a customer’s credit worthiness
    The bank clerk shall be able to resolve any issues that arise with their manager
     
  • makes no reference to the solution or design of the system
    e.g. The bank clerk will receive an email informing them of the customer’s credit score
    This requirement indicates that the response is received by email. This raises questions which may drive out the actual requirements.     Email suggests that receipt of the credit score is not time critical as the turn around time of an email cannot be guaranteed. This may be a constraint that is more generous with regard to time e.g. can receive a response before the account is opened but not necessary within seconds 

    Email also suggests this is undertaken away from the customer’s view. Is it important that the customer does not see the credit score?

    Possible requirements:
    The bank clerk will be informed of the result of the credit score within one hour
    The credit score will not be revealed to the customer

  • doesn’t use terms that are vague or open to interpretation
    e.g. The bank clerk will be able to offer products to customers whose credit score is good
    The term ‘good’ is vague. However, depending on the project,  it may be agreed by all the project stakeholders that this is sufficent for a high level requirement and the detail can be explored later.

 

The house style should be used where requirements are expressed in a similar manner as it is quicker to see any shortcomings.

For example, it can be agreed whether to mention the system or solution at all (e.g. ‘The system shall’). Also, decide on the use of the word ‘shall’, ‘should’, ‘could’ ,’would’ or ‘will’. The words ‘will’ or ‘shall’ are preferred as anything else suggests the priority which is a separate attribute.

In addition to the actual text of the requirement, there are other key elements that every requirement needs:

  • requirement id – this should be unique
     
  • priority – this could be critical, high, medium or low, or must, could, should or would (from MoSCoW method)
    It is not so important what the names of the priorities are as long as they are understood and agreed by the stakeholders. As a rule of thumb, no more than a third of requirements should be mandatory. 
     
  • owner
    there will usually be one (or more) stakeholders who are, effectively, owners or originators of a requirement. This usually means they have a vested interest in its delivery and should be consulted on any changes or its removal. 

There are some other attributes which are optional but should be considered depending on the specific project:

  • status
    This is useful if the requirements are being considered by a group of people and they need to reach consensus on whether a proposed requirement should be submitted. Possible statuses would include – draft, reviewed, approved, rejected
     
  • rationale
    The requirements will become very pared down, simple statements which don’t shed any light on why the requirement exists. This field can be used to capture the reason why the requirement exists which is useful when the project objectives are changed
     
  • dependency
    This shows relationships between requirements where one is dependent on another. 
     
  • parent requirement
    This allows a hierarchy of requirements to be developed. i.e. high level based on business objectives and child requirements which flesh out the detail
     
  • category
    It may be useful to group related requirements together.  For example, there may be a business unit responsible for regulatory issues and another for legal. Ensure this adds value and is not confused with Owner.

 

The big picture

Typically, the requirements should be presented as part of a larger document that provides context and describes other relevant information.  This would include, as a minimum, the following:

  • the business context, including the strategy and objectives
     
  • relevant business process(es) – current and planned (or ‘to be’ and ‘as is’)
     
  • the scope of the project
     
  • broad description of the user population
     
  • stakeholders 
  • glossary or definition of terms
     
  • assumptions, issues and risks
     
  • dependencies (other projects or existing processes and systems)

This document may contain other supporting information such as a high level use case model(s) (see Use Cases – an Introduction) and business object model(s) which show the key business entities and their relationships. 

 

Requirement statements vs other forms of expressing requirements (e.g. use cases)

It is important not to use the simple requirement statement described above for the finest detail of system behaviour or characteristics. There is a risk of producing a very large document which is in essence a series of declarative statements that describe the desired system behaviour.

This is not appropriate when defining all of the system behaviour as there are much more ‘user friendly’ models for defining behaviour (e.g. use cases, prototypes for illustrative purposes) or entities, data and relationships (e.g. business object models/domain models, state transition diagrams) for defining data.

It is the job of the business analyst to interpret and he/she should be able to select the moset effective means of communication and should not rely on prescriptive approaches as there is no one approach that works in all situations.

Requirements engineering is very effective at introducing formality which drives better quality and provides an effective means of measuring and ensuring delivery. However, there are more effective techniques to communicate the detailed system behaviour in support of the requirements.

 

Related Links

You might find the following links useful:

 

‘Writing Good Requirements’ from Software Development Magazine

‘Quality Requirements Checklist’ from Journal of Object Technology regarding quality of quality requirements – useful, academic article. Also see Nonfunctional requirements for more on quality requirements

Good requirements within this article from Wikipedia – concise table describing good requirements within this article

 

Thank you for reading this article, please make comments if you have questions, disagree or wish to discuss further

It's only fair to share...
Share on Facebook1Digg thisBuffer this pageShare on LinkedIn0Share on Google+0Share on VKTweet about this on TwitterShare on Tumblr0Pin on Pinterest0Share on Yummly0Flattr the authorShare on Reddit0Print this pageShare on StumbleUpon0Email this to someone

About Alex Papworth

9 Responses to “Requirements engineering and quality”

Read below or add a comment...

  1. A couple of comments and a reference:

    Negative Requirements

    ‘The credit score will not be revealed to the customer.’
    In my opinion, negative requirements (those that state what is NOT to happen) are redundant. Firstly, I always consider that the system shall do nothing unless I specifically state it as a requirement. So, in the above example, because I never stated that the credit score will be revealed to the customer, by default it will not. Secondly, where do you stop? Can I reveal the credit score to the customers’ brother, their financial advisor? There are an infinite number of negative requirements that can be derived for any system. It is impossible to state them all, nevermind test them.

    Functional Requirements

    Every functional requirement should have an associated timing. If you do not specify a time to complete, then so long as my implementation of the requirement does nothing, it will never fail testing because it will never time-out. A template that I like to consider when writing functional requirements is of the form:
    ‘Upon’ something externally visible happening, ‘the system shall’ do something externally visible, ‘within’ an allotted time.

    Requirements Analysis

    A 3rd area of requirements engineering is requirements analysis. This is the process of determining that your requirements are complete, and that you have a complete set of requirements. I have just posted a small presentation on this subject to my web site.
    http://www.umllmu.com/Flash/Realizing%20The%20AUC.html

    Les.

    • Alex P says:

      Hi Leslie

      I’m sorry for the late reply. I agree with your comment on negative requirements. The example chosen was poor but was taken from a real project where this did add value. In this instance, the bank clerk and customer were working through an account opening application jointly. The customer would see all parts of the interview EXCEPT for those pertaining to their credit score.
      This is actually good as I like to see some debate!!
      In general, I’d agree that every functional requirement should have timing associated OR there should be a single nonfunctional requirement that covers ALL response times – either would be good.

      Thanks for providing the link

      Alex

  2. alarroste says:

    Hello webmaster,
    I would like to share with you a link, write to alarroste@mail.ru

Trackbacks

  1. […] For more on requirements quality, see Requirements engineering and quality […]

  2. […] requirements arising from previous workshop and address quality issues (see Requirements engineering and quality). In particular, where requirements are really solutions then drive out the rationale or the […]

  3. […] For more on requirements quality, see Requirements engineering and quality […]

  4. […] all the requirements must be complete,  clear, unambiguous and measurable (for more on this, see Requirements engineering and quality). In order to achieve this, the critical successs factors, business objectives and all of the […]

  5. […] requirements arising from previous workshop and address quality issues (see Requirements engineering and quality). In particular, where requirements are really solutions then drive out the rationale or the […]



Leave A Comment...

*