In our previous 2 articles, we’ve discussed how business requirements should originate in a cascading manner from goals and objectives, to assist in assigning their relative priorities.  We also reviewed tools that can be leveraged to help us remember the different areas or categories of requirements to capture.  But now let’s step back and consider, just what is a requirement anyway, and what is it not? 

It is generally considered that a well defined requirement possesses the following attributes:

  • Necessary – The system cannot meet prioritized needs or goals without the requirement
  • Feasible – The requirement is doable, within available cost and schedule
  • Correct – The facts related to the requirement are accurate and it is technically and legally possible
  • Concise – The requirement is stated simply
  • Unambiguous – The requirement can only be interpreted one way
  • Complete – All applicable conditions are stated, and the requirement expresses a whole idea or statement.
  • Consistent – The requirement is not in conflict with any other requirements
  • Traceable – The requirement can be traced to its source, and it can be tracked throughout the system, (e.g., to the design, code, test, and documentation)
  • Allocated – The requirement is assigned to a component of the designed system
  • Design independent – The requirement does not impose a specific implementation solution
  • Non-redundant – The requirement is not a duplicate requirement
  • Stated using a standard construct – The requirement is stated as an imperative using the word shall
  • Associated with a unique identifier – Each requirement has a unique identifying number
  • Devoid of escape clauses – Requirements do not use if, when, but, except, unless, and although, and do not include speculative or general terms such as usually, generally, often, normally, and typically.

Additionally, a business requirement differs from a business rule.  According to Gladys S.W. Lam, Principal at BRSolutions.com, who writes in her article, “Business Rules vs. Business Requirements,” Business Rules Journal, Vol. 7, No. 5 (May 2006), URL:  http://www.BRCommunity.com/a2006/b290.html  ,

  • Business rules are lists of statements that tell you whether you may or may not do something or that give you the criteria and conditions for making a decision
  • Business requirements are what you need to do to enable the implementation of and compliance with business rules.
  • Business rules are what they are.  They shouldn’t change to fit the business requirements.
  • A change in a rule can mean different or additional requirements.

 

An example of a business rule might be: 

A Customer must have an Email Address

The associated business requirement that enables implementation and compliance with that business rule is:

Customer must have capability to enter email address for a customer. 

The solution chosen to implement that requirement might be to provide a GUI. 

Obviously, requirements such as the one stated above are still fairly high level and must still be broken down further before they could be actionable by an implementation team.  There are still more detailed specifications related to the capability to enter an email address such as which fields to enter, error handling, and many other aspects that a development team should define.

Business requirements are best defined in layers with a set of un-actionable requirements such as: Customer must have capability to enter email address, at one layer, and the lower level specifications related to that requirement captured at a layer beneath it and tied back to the requirement above it.