The Problem With Business Requirements: Series Wrap Up

There are high-level requirements, there are detail requirements, and then there is this in-between thing called business requirements.

The problem with business requirements is that they are allowed to be high-level, detailed or anything in between. As long as some business user says that they require it, the business analyst is duty bound to record it. The world (and business information system projects) would, in my opinion, be a much better place if there were no business requirements.

What I have found in my years of mentoring is that many BAs have trouble with the distinction between high-level and detail requirements. A primary objective of the Requirements In Context series that I just completed was intended to help make this distinction. This article is intended to be a summary of takeaway points from the series. Two of those points are:

• High-level requirements should always have a business (and project) context
• Detail requirements are most easily discovered when focusing on an HLR context.

Part 1 of the series introduced the need for improved requirements, presenting the classic ‘Swings’ cartoon as evidence that things do not appear to have improved much over the years when it comes to delivering business information systems. Part 2 talked about business functions as a context for high-level requirements. A generic functional view from 10,000 feet of an organization was presented as the ultimate business context. This generic business model was comprised of management functions, support functions, and line of business functions. High-level business functions were seen to act as a context for a number of business processes within that function. Each process, in turn, was seen to act a context for a set of business activities.

High-Level Requirements Guidelines

Part 3 of the series talked about project scope, and how scope statements and context diagrams can be excellent sources of HLRs. Examples were given of turning scope statements directly into high-level requirements. Part 4 provided guidelines for keeping high-level requirements high. It recommended that business analysts and project managers think of this exercise as ‘requirements planning’ rather than ‘gathering high-level requirements.’ What you definitely do NOT want to happen is for an HLR gathering session to degenerate into a business requirements gathering session.

Before diving into the subject of detail requirements, Part 5 of the series discussed four ‘build or buy’ delivery contexts (i.e. takeaway points):

• Build – In-house with embedded SME (e.g. full Agile)
• Build – In-house without embedded SME (e.g. Agile-like, Waterfall)
• Buy – a custom-built solution (outsourced development)
• Buy – a package solution (with optional customization)

It turns out that only the first of the above contexts allows for getting by without well-documented detail requirements. This is possible because with full Agile, the Scrum Team includes a business subject matter expert that is available full-time(ish). Performing the role of Product Owner, this person provides the necessary details just in time for each sprint.

Detail Requirement Form – User Story or Shall Statements?

I did my best in the series to stay out of the debate over the best form of requirement statements – User Stories or Shall Statements. At the end of the day, I believe that content is what’s most important, not form. Meanwhile, I will say that I like user stories. The main reason is that they have a clearly defined structure – a single sentence containing the elements who, what and why. Conversely, Shall statements just get the ball rolling with “The System shall …”. After that, it’s pretty much a free-for-all. A requirement in Shall statement form can be a single sentence, or it can run on for multiple pages. And don’t get me started on ‘shall’. I’ve actually never met a business analyst who likes the term in that context. The only thing worse (in my opinion) is replacing it with a term that implies the priority of the requirement. e.g. “The System must …”.

Detail Requirement Content – Seven Plus Or Minus Two

A detail requirement can be about a single attribute such as the ability to change the status of an order. Or it can be about a long list of attributes that are intended to be included in a screen or report. When there are a small number of fields involved (a rule I’ve always been partial to is “seven plus or minus two”), the content of the requirement can be contained within the user story or shall statement. The following example is taken from Part 5:

• Given access to base exchange rates made available from European Central Bank
• When the ECB exchange service makes new rates available
• Then the following details about each currency is recorded and available for use converting between currency pairs:
  • To Currency e.g. USD
  • Effective Date
  • Exchange Rate From Euro e.g. 0.89
  • Rate Type e.g. Mid-Market

Note that in the above example the attributes involved ended up in the acceptance criteria. I consider this part of the requirement. If anyone has a good example of a user story that handles detail in the user story ‘sentence’ itself, please do share or describe it in an added comment below.
Conversely, I strongly recommend not trying to name long lists of attributes in a detail requirement. Instead, it should be possible to manage that amount of detail using a context-specific template. The following contexts are suggested as template candidates:

• Report
• Interface (Input or output)
• Screen
•  Internal Batch Process (e.g. periodic generation of interest)
• Permanent Data Storage (i.e. fields in one or more new tables)
• Complex Derivation

Each of the above context types includes a link to the series article discussing it along with an example detail requirement for the context. Here is one such example from Part 7. Again we see the acceptance criteria as a place to include a reference to where the appropriate full/complete requirement detail has been recorded:

• Given a customer placing an order on-line
• When the customer has completed the order process including confirming the order
• Then the details of that order are displayed as per the “Customer Order Confirmation Screen” specification found Appendix C.

The final context in the series is derived data. It’s discussed in Part 8. As with the context types listed above, simple derivations may be included within the requirement itself while more complex derivations might benefit from being described in supporting documentation referenced in the requirement statement.

Why So Much Detail?

As mentioned at the beginning, business requirements that contain only ‘middle of the road’ detail serve little purpose. Designers, developers, and testers don’t have sufficient information to do their jobs in three of the four delivery contexts listed. When additional detail is needed (and it certainly will be) either a business SME will need to be contacted, or else the project ends up being yet another casualty of ‘The Swings.’

Making use of context-specific templates can help guide BAs to record sufficient detail to deliver each of those items ‘in context’ for the project, based on HLRs that identify them. And with this level of detail business information systems can be built that (hopefully) satisfy the business needs.
So, as promised – takeaway points from the Requirements In Context series:

• High-level requirements can be sourced (partially) from project scope and context diagrams
• Keep high-level requirements high level
• Detail Requirements are most easily found within an HLR context
• Detail requirements should be fully detailed (not just listed), using context-specific templates when needed

And a bonus takeaway point introduced in this summary article:

• Avoid producing Business Requirements