I have long been a believer in the saying Context is everything.

As a business analyst dealing

with business users, understanding the context of the topic of discussion is essential.
In thinking about what constitutes quality requirements, it occurred to me that there are a number
of additional contexts that play a role. Examples include the organizational maturity level (from
Informal through to Optimized) and delivery context (green fields through to package
acquisition).
Related Article: Want Faster Requirements? Build Them Like a Snowman!
This is the first in a series of articles about business requirements. My primary objective is to
help business analysts improve their elicitation and documentation of requirements. With an
increased awareness of multiple contexts I believe that the quality of the requirements
documented can be improved, and subsequently, lead to the better design, development and
implementation of business systems.
Mark Twain is credited with saying, Everyone talks about the weather, but nobody does
anything about it. The equivalent saying in the IT context would be, Everyone agrees that good
requirements are essential, but nobody does anything about them. A perfect illustration of this

ithe class
The Swings:

ic IT cartoon

What is not funny about this cartoon is that the situation it depicts is as true about business
systems delivered today as it was when the above version was published. Over 40 years of
struggling, and most often failing to meet user expectations, in spite of unimaginable
improvements in technology.
I have no illusions that what I intend to present will magically make it all better. But these
articles are at least my attempt to do something about it. If you are reading this, it means you are
interested in improving your BA skills. Hopefully learning about the impact of different contexts
on requirements will lead to that.

The Business Information System Context

I find it virtually impossible to take off my business analyst hat. Any time a family member or
friend mentions that they want something a new car, an electrical appliance, I immediately go
into requirements mode. I start asking questions intended to help them focus on their thinking
in order to lead to making the best choice.
It occurred to me that it as I begin to present the various contexts related to requirements that I
should set the context for this series of articles. The context of requirements that I intend to focus
on is business information systems. And while a complete information system includes a
hardware and a network aspect, the requirement contexts that will be discussed will not include
these technical aspects. The requirements contexts will focus on business analysts interacting
with business users to deliver the functional and information components of a system.
Please note that when I use the term system,' from a requirements perspective that doesnt mean
that every requirement will result in a computer-based solution. Having gathered requirements, a
subsequent exercise is to determine which of them will be given automated support and which
will be left as manual processes.

Functional and Information Components

The earliest computers were primarily electronic calculators. They allowed complex formulas
to be broken down into individual computational steps. Having expressed these steps in a
language the computer could understand the resulting instruction set was ready to receive the
data to be manipulated. The end product was a set of calculated results.
When businesses began using computers, their objective was to maintain data about their
business. Computational requirements were minimal. Simple things like adding or subtracting
deposits and withdrawal amounts from a customers account balance. The original computerized
business systems all performed their functions by reading in batches of data, operating on each
record as it went through the system, and producing individual results before the next record was
processed.
With the advent of database management systems and access in real time to computer
applications, more and more business processes could be supported by computers. Today
virtually every office worker has a computer on their desk. And thanks to wireless networks and
portable devices workers (and customers) outside of the office have access to the information
they need when they need it.
With the focus of business information systems being the support of functions that capture and
utilise data I offer a variation on the Nike slogan Just Do It. The objective of the business
information systems we gather and document requirements for should be Just Know It.

Functional Context / High-level Requirements

Having established the context for these articles to be business information systems, the journey
itself will begin in the next article. In it, I will present a technique I have used for many years to

help establish the functional context for a requirements gathering effort. The more common term
for this functional context is Project Scope.
I will also discuss the possibility of combining the scoping exercise with the producing of highlevel requirements. The result of doing this reduces that requirements task down to hours rather
than days (or weeks). This will be the first of several demonstrations of the strength of applying
the thinking that Context is everything.
In the first installment of this series it was stated that the overall objective of these articles is to
improve the quality of requirements produced by business analysts. Following the adage that
Context is Everything it established that a number of different contexts will be explored. And
in keeping with this principle it set business information systems as the context of the
requirements to be addressed.

Classic Business Functions

My very first position as a business analyst 30 years ago was with a company that had just
completed an enterprise-wide planning effort.(1) They had gone so far as to remodel one of their
conference rooms for the specific purpose of displaying the results on multi-layered whiteboards.
The most prominent board displayed a functional model of the business. It was said to be a view
of the company from 10,000 feet up. The functions were organised into three categories:
Management, Support and Line of Business.The following diagram is a slightly simplified
version of that model:

In my first article I presented the classic Swings cartoon. It is a classic because it has remained
relevant all these years. I consider the high-level functional model presented above to be a
classic. It too has stood the test of time. Throughout my years as a business analyst, working in a
wide variety of industry segments and government agencies in three countries, this model has
proved to be both relevant and useful.
Related Article: Just Know It! Requirements in Context
Not all organisations utilise every one of the functions shown. And some organisations have
multiple lines of business. For example Walt Disney - Film production would be one, theme
parks another. In this style of model, each would have its own Line of Business functions to
provide contexts for dealing with very different products. Regardless of the numbers of lines of
business, the Management and Support functions are applicable across the organisation.

Enterprise Resource Planning

Thirty years ago using a model like this to plan an organisations business information systems
was leading edge. Database management systems had been around just a few years. Their use
typically involved one-for-one replacement of application-specific files. A batch processing
inventory management system would be upgraded to an online inventory management system
supported by an inventory database. A batch processing sales management system would be
upgraded to an online sales management system supported by a sales database. And on and on.
High-level functional models like this were used to demonstrate to the organization that a shared
set of data could and should be used to support multiple functions across the business. The idea
was to stop developing application-specific information systems and start developing an
enterprise-wide one. Fast forward to today and this vision has become business as usual for many
organisations. It is common today for an organisation to have a relational database that holds
data utilised by multiple business functions. Some of these systems have been developed inhouse. Others utilise one of the commercially available Enterprise Resource Planning (ERP)
systems. Probably the original and best known of these is SAP.
The following is a list of integrated SAP modules that an organisation to pick and choose from:

Human Resource Management

Production Planning
Material Management
Financial Supply Chain Management
Sales and Distribution
Project System
Financial Accounting and Controlling
Plant Maintenance
Quality Management

Quite a striking correlation between these modules and the high-level functions from that 30year old model.

High-level Requirements From High-level Functions?

This series of articles is about requirements in context. The Functional context is where we are
starting. The functions from the 10,000-foot level are the most general functional context I can
imagine. Could these be used to draft requirements? I can think of one scenario where they could
- an organization interested in acquiring an ERP system. Here is an example of one such highlevel requirement:
The system shall support Accounting processes integrated between themselves and with
processes of other functions.
Each ERP function the organisation is interested in should have its own requirement naming a
high-level function it wants within its integrated system. Each would be assigned its own
priority. Some would likely be must haves while others might only be nice to haves. (Who am I
kidding? we all know that to business users every requirement is a must have.)

Processes within Functions

The view from 10,000 feet is an interesting functional context, but outside of acquiring an ERP
system we need business functions closer to earth. Fortunately the majority of functional
modelling techniques include the concept of functional decomposition. That technique used to
produce the model above offered a simple three-level decomposition scheme. The things at the
top level were called Functions. A level below functions were things called Processes. The third
and lowest level things were called Activities.
Functions were considered to be ongoing activities. A person working in Accounting or HR
does their job year round, year in and year out. Processes in the context of this model were
defined to be things that have a start and an end point. A given Function typically would
decompose into 10-ish Processes. Again using SAP as an example, we see its HR module breaks
down into 12 processes:

Organizational Management
Personnel Administration
Recruitment
Payroll
Travel Management
Personnel Management
Time Management
Compensation Management
Training and Event management
Wages
Personnel Development
Workforce Administration

Its easy to envision most, if not all of the above processes having start and end points. For
example, while it could be argued that Recruitment goes on continuously, in reality filling a

specific position starts with some form of notification of the opening and ends ideally with a
successful candidate coming on board. Here is an example of a high-level requirement utilising a
Process context:
The system shall support the recruitment process including keeping records of published
notifications, candidates, interviews and proof of fairness during the selection process.

Activities within Processes

The term Activity can be defined as the individual steps in a process. Visualise a workflow
diagram. The boxes in the diagram that dont themselves require further decomposition would be
considered activities. The basic idea is that an Activity is that it should be simple enough that an
individual is able to complete it in a single sitting. No need to hand the work off to anyone else
mid-activity or to have to wait for some other activity to complete. An example of an activity
within the Recruitment process would be one called Make Offer to Candidate. An example of
a high-level requirement ustilising an Activity as a context would be:
The system shall support keeping a record of offers made to selected candidates.
I have used a variety of functional modelling techniques from dataflow diagrams to business
process modelling notation (BPMN). Regardless of the terminology used in any particular
method, I have found the definitions of the three functional levels presented above to be
excellent guideposts for both functional modelling and drafting requirements.

Next Time Project Scope as a Context for High-Level Requirements

Gathering of requirements is typically managed within a project, and part of managing a project
is establishing its scope. Requirements are expected to address the things within this scope. Next
time we will look at scope and how high-level requirements can be derived directly from it, and
actually as part of the scoping effort.
(1) The enterprise-wide planning methodology utilized by the company described was called
Strategic System Planning (SSP) developed by Robert Holland.
The first article in this series established the context of requirements being addressed are those
that relate to business information systems and that various contexts have an impact on those
requirements. The second article addressed the first of these contexts - Functional. That context
was further divided into three conceptual levels labelled Functions, Processes and Activities. An
example high-level requirement was presented at each of these levels.

Project Scope
This article moves on to a different context - Project Scope. We will see how scope statements,
when making reference to business functionality, leads directly to high-level requirements.

Gathering requirements for a business information system is most often done within the context
of a project. Approval of a project includes its sponsors signing off on its scope. The scope of a
business information system project is typically defined in functional terms. Items in scope make
reference to (or should make reference to) business functions, processes and/or activities that are
to be delivered.
Related Article: Using Feature Trees to Depict Scope

A Context Diagram Is Worth A Thousand Words

In addition to the bulleted item list of scope, it is very common for the project initiation
document to include a context diagram. The objective of a context diagram is to illustrate what is
inside the system and what is outside. Things outside the system represent sources and/or
consumers of data. The original form of context diagram comes from Dataflow Diagramming
(DFD). The top-most level of functional decomposition using DFDs was considered a context
diagram. The Unified Modelling Language (UML) Use Case modelling also supports a form of
context diagram. Both of these diagramming techniques represent the system and both portray
things outside the system boundary. The DFD term for these outside things is External Entity.
The UML term is Actor. The definition of these two terms is virtually identical.

A DFD context diagram says nothing about the functions inside the system. That is left to
subsequent levels of functional decomposition. Clues are provided by labels given to the data
flows. The Use Case context diagram provides more of a clue to the functions within scope by
including named use cases. Data flows in a DFD context diagram connect only to the system.
Actor connectors in a Use Case context diagram connect to one or more specific use cases within
the system.

High-Level Requirements From Project Scope

Examples of high-level requirements were presented in the previous article based on a high-level
business function, a medium-level business process and a low-level business activity. We are
about to present an example of a project and its scope. As mentioned above, the scope of
business information system projects is very often expressed in functional terms. It should,
therefore, be possible to derive high-level requirements from scope items.
Consider the following situation involving a large hypothetical on-line retailer we will call
Nile.com:
Nile.com has a well-established purchase process for its on-line customers. The check-out
portion of this process includes activities for identifying the intended shipping address and for
providing some form of payment. What the process does not currently include is anything to do
with tax on items being purchased. As the result of pressure from various tax authorities this
needs to change.
In establishing a project to deal with this change in the business environment the following scope
items were agreed by the business sponsor and signed off:

Maintaining tax-related details for designated tax authorities

Determining applicable tax on items being purchased
Including applicable tax with purchases
Accounting for tax charged

The Use Case form of context diagram for this example would look like this:

Scope items will seldom be stated so conveniently that they can be converted one-for-one into
the names of use cases. For the sake of brevity, please accept that the scope items in this example
are ones that I prepared earlier.
The objective of this article is to show that it is possible to derive high-level requirements based
on a projects scope. The following are examples of such requirements from the scope in this
scenario:

Scope Item 1 - Maintaining tax-related details for designated tax authorities

The system shall support an administrator maintaining tax-related details required to perform
tax determination. This includes establishing tax authorities that are the source of tax rates and
to whom collected taxes need to be paid. It also includes mapping of products to tax rates for
each authority where there are product-specific rates or specific product types that are tax
exempt.

Because charging tax is new to this organisation there may not be an in-house subject matter
expert available when it comes time to sorting out the details for this requirement. Until more is
known this high-level requirement acts as an appropriate placeholder for what is likely to be a
number of business processes. One would likely be needed for setting up new tax authorities, one
for setting up the tax rates and where applicable, one for specifying different rates for different
product types. The requirement from a business perspective is fairly straight forward maintain
whatever details are necessary to be able to charge tax. The devil is in the detail.

Scope Item 2 - Determining applicable tax on items being purchased

The system shall be able to identify the appropriate tax that applies to the purchase of a given
product based on the product type and the tax authority(s) that have jurisdiction where the
shipment is to be delivered.
Where the previous requirement calls for wholly new business processes to be supported within
the business information system, the functional context of this requirement would be somewhere
within the Identify the shipping address activity within the Purchase process. At this point
the product(s) are known, and the shipping address details can be used to determine any
applicable tax authority(s). Subsequent detail requirements would get into how an appropriate
tax rate is determined and specifics of where that rate is used in calculating the total charge to the
customer.

Scope Item 3 - Including applicable tax with purchases

The system shall present to the customer all applicable tax amounts as part of the purchase
process.
This statement should be sufficient as a high-level requirement from a business perspective. Part
of the detailed requirements analysis would include identifying all of the places where the
customer sees purchase price details. Each of those places will require modification to include
whatever tax applies, if any.

Scope Item 4 - Accounting for tax charged

The system shall report charged tax amounts as a distinct component of each purchase to the
general ledger system identifying appropriate GL Codes and the designated tax authority.
Wherever money is involved the organisations general ledger needs to be kept informed. In this
case it is unlikely that there will be any new processes or even activities required. Reporting to
the GL will be in place for the current untaxed purchases. This reporting will just require an
enhancement to include the tax amount and its corresponding GL Coding. There should also be
an existing Accounts Payable process that handles making payments to suppliers for the
organisation. The different tax authorities that are to receive payment of collected taxes should
be covered under that process.

Next Time Keeping High-Level Requirements High-Level

The four requirements derived from the project scope items would not be the only ones for the
whole project. But it must be said that they cover the agreed scope of the project and that they
are high-level (not slipping into detail). Next time we will look into how to keep high-level
requirements high-level when dealing with stakeholders that are asked to participate in the
context of Gathering high-level requirements.
This article discusses the importance of keeping high-level requirements (HLRs) at a high-level.
It presents examples of functional, data, report, interface and non-functional requirements.
Guidelines are offered for each example about things best left to detail requirements. Lastly, it
offers suggestions for managing business user expectations during HLR sessions.

What, Not How

Most often the principle What, not how is quoted to remind business analysts to keep
requirements at the business level, to not jump ahead to design or solutions. But its also useful
to keep this in mind when gathering high-level requirements, to avoid getting into detail that is
best left for detail requirements.
Related Article: Requirements in Context Part 3: Scope=High-Level Requirements
This series of articles is about contexts for requirements. Every high-level requirement should be
thought of as a context for the detail requirements that are to follow. Thus, HLRs should not
themselves be too detailed (nor take too long to document). One of the most frustrating things a
BA can experience is inviting a business user to a detail requirements session and getting the
response, But I already gave my requirements. Doing a proper job of starting with what
should make it clear to all involved that there must be a how to follow.

High-level Functional Requirements

The What, Not How principle should be applied to HLRs about processes. Consider the
following requirement about an on-line purchase process:
The system shall not allow a customer order to proceed to the payment step without shipping
details having been identified.
On the assumption that the project scope includes delivering an on-line purchase process, the
above requirement is very how-ish. If you visualise a workflow diagram of an on-line purchase
process, according to this requirement there should be no path leading to the Provide Payment
Details activity that has not gone through a Provide Delivery Details activity.
Workflow diagrams that include decision points, loops and such represent the detail of a given
process. The only process diagram appropriate when discussing HLRs should be a quick sketch
that represented the sunny day scenario through that process. Something like the following:

What a sketch such as this looks like as a high-level functional requirement would be this:
The system shall support customers making on-line purchases including selecting products,
specifying shipping details, providing payment details and confirming the order.
A truly high-level functional requirement for a business process should be a simple list of its
primary activities. If its a complex process with many activities, only a suggestive list should
be included - just enough so that the reader recognises what the process is. This leaves the
complete set of activities and flow details for detail requirements definition.
NOTE: If an organisation is interested in exploring business process reengineering (BPR) or
business process improvement (BPI), this should be a separate exercise from requirements
gathering. While its true that simply implementing some automation support to an existing
business process should have a beneficial effect, those are small-i improvements. The objective
of BPR and BPI is to deliver big-I improvements.

High-Level Data Requirements

The following requirement is one I actually saw in a signed-off HLR document:
Each Customer record must be assigned a unique identifier.
This requirement is about one specific attribute of the business entity Customer. Attributespecific requirements are detail-level. Consider this alternative:
The system shall support establishing new customers, including capturing details such as name,
address, and contact information, ensuring that every customer is uniquely identifiable. E.g.
Fred Smith assigned customer number 555123, The Carter Foundation assigned customer
number 654287.
This version still mentions attributes, but only as an indication of the detail to follow. The phrase
such as implies this is not an exhaustive list. The idea is to describe a given entity such as
Customer by naming just enough attributes and/or relationships so that the reader recognises the
concept. Its the difference between asking someone to name two of the seven dwarves from
Snow White and asking them to name all of them. Your subject matter expert (SME) should be

able to come up with indicative attributes in seconds. An example or two is another way to
ensure that the concept is clear.
From the simple examples included in the HLR above we understand that customers can either
be individuals or organisations.

High-Level Report Requirements

Up until now we have distinguished high level from detail level keeping in mind the What, not
how principle. For reports, we still want to avoid the how, but the what should be augmented
by adding four additional Ws Who, When, Where and Why. Journalism students used to be
taught that the first paragraph of a news story should always include information about each of
the five Ws.
An example of a high-level report requirement in user story format that includes all five of the
Ws is:
As a Customer [who] I want to receive an Order Confirmation that includes details such as the
items purchased, amount charged and expected delivery date [what] sent to my email address
[where] following the completion of each order [when] so that I have an off-line record of my
purchase [why].
The Shall version need not be very different beginning with The system shall provide a
Customer with ...
Some memory joggers as to what reports may be needed are:

Event Based milestones within a process or at its end, or alerts triggered by thresholds
being reached
Periodic daily, weekly, monthly or annual reports
Statutory required by government or other regulatory bodies
Management used to monitor progress against plans or budgets

As with the functional and data HLRs, the objective is to set the context for detail to follow.
There is really no difference between the need to deliver a function and the need to deliver a
report (that is truly needed). There should be one HLR for each, kept to a high-level description
that establishes an understanding of what it is.

High-Level Interface Requirements

The previous article talked about context diagrams that represented a projects scope. The things
outside the system boundary in such diagrams represented either types of business users or else
other systems. Each system represented at the context diagram level will need at least one
interface HLR. These should cover the same five Ws described above for reports. An example of
this in shall style is:

The system shall support sourcing of foreign exchange rates [what] from the European Central
Bank [where] on a daily basis [when] to support currency conversion when the on-line customer
[who] deals in a different currency than the supplier of a product [why].

High-level Non-Functional Requirements

There is no question that business information systems must be secure, that they should be
usable, and they should perform well. Continuing with the what, not how principle, I believe it
appropriate to include just a single HLR that lists exactly which NFR types will need to be
detailed at some point in the project. This single requirement might be worded something like:
The system shall satisfy details of the following types of non-functional requirements:

Security
Usability
Performance
Availability
...

Exactly when the details of NFRs should be addressed will depend on what the next step of the
project is. In the meantime, there is at least one HLR included acting as a context for details to
follow.

Gathering ONLY High-level Requirements

The problem with inviting business users to a high-level requirements session is that many
believe that this is where they are expected to discuss their requirements. In addition, some bring
with them their pain points from the business information system. The unique identifier
requirement mentioned above was most likely contributed by a user that was having trouble
identifying customers.
I would suggest that a better name for an HLR gathering session would be Requirements
Planning. The invitation should include the agreed project scope items. These set the context for
identifying HLRs. The objectives of the session should be stated to be something like:
To list specific business processes or activities, types of data, reports, and interfaces that are
expected to be delivered by the project.
To identify SMEs for each of these items to participate in subsequent detail requirements
sessions.
The previous article in this series demonstrated how starter HLRs can be derived from
function-based scope items. Having these drafted in advance of an HLR session they can be
presented as examples for the appropriate level of detail that is being sought.

Next Time Where To From HLRs Build or Buy Context

Where this article highlighted the importance of keeping HLRs high-level, the next article
focuses on the importance of detail in detail requirements. We also discuss the rationale for this
detail for different delivery contexts (i.e. build or buy).
The previous article in this series was about keeping the content of high-level requirements
(HLRs) at a high level. This article is about the content of detail requirements containing the
appropriate amount of detail. We start with a discussion of four delivery contexts, two involving
building the solution in-house and two involving purchasing solutions. Examples of requirements
are presented using two forms - User Stories and traditional Shall statements. But regardless of
form, at the end of the day, content is king.

Build or Buy Contexts

The availability of subject matter experts (SMEs) is a critical factor in sourcing content for detail
requirements. For the purpose of this article, we will assume that such people are available. Of
equal importance to this deliverable is the consumer of these requirements those responsible
for delivering (i.e. designing, developing and testing) the solution based on the detail. Consider
the following delivery contexts:

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)

NOTE: The Build/Buy decision process itself is out of scope of these articles.
Related Article: Requirements in Context Part 4: Keeping High-Level Requirements HighLevel

Build - In-house With Embedded SME

What could be better than having the source of detail requirements, an SME, as a full-time
member of the development team? Not only that but working on a business information system
that can be implemented bit by bit. Personally, I have only experienced Agile-like development.
But based on reports from colleagues there are organizations where these conditions exist.
In full Agile environments, whether user stories eliminate the need for detail requirements or
they are just considered to be an improved form of requirements, each user story still needs to
include content that drives development and guides testing on the way to done. From a
requirements perspective, the real improvement is that development does not need to wait for a
full set of requirements before work begins. Also, the delivery of results into production occurs
not long after the requirement has been expressed.

Full marks to this delivery context and the Agile user story form that drives it. But developing
and testing has to involve the complete content of what is wanted, so ultimately that content
needs to be recorded somewhere (see examples below).

In-house Build Without Embedded SME

I am fresh off a project that utilized Agile-like development. We were given traditional business
requirements. Some were high-level, others low-level-ish. As a BA, my role in one of the Scrum
teams was pseudo product owner. It was my job to interpret selected requirements and write the
corresponding user stories and acceptance criteria. Where a requirement was unclear or did not
contain sufficient detail, it was necessary to go back to the business requesting clarification.
Besides the problem with requirement content, the overall project was not suited to incremental
implementation. At the end of each sprint, teams were able to demonstrate the results of
completed stories, but these elements needed to wait many months for a major release of the
system.
Functionality being delivered in each major release had to undergo both integration testing and
user acceptance testing (UAT). Acceptance criteria from the user stories were of some use to the
broader testing efforts, but end-to-end tests had to be developed separately. And because the
business users had not been involved with the user stories, they had to come up with their own
UAT test cases.
Based on this experience, my conclusion is that the Agile-like context would benefit from detail
requirements that contain the most complete content possible. Requirements in either Shall or
User Story form can and should include acceptance criteria. This would support any level of
testing required.

Buy A Custom-Built Solution

The model of custom-built solutions that I am most familiar with involves the following steps:
1. The business provides requirements for what is to be delivered and selects a supplier.
2. The supplier produces a Statement Of Work (SOW) based on the requirements, specifying what
they agree to deliver.
3. The supplier delivers the solution for UAT and bug fixing.
4. The supplier expects final payment and supports warranty period.

My most recent experience involving a supplier was from the business perspective. The
development form that the supplier used was Agile. But given that they were relying on clientprovided requirements rather than embedded SMEs, they were really only Agile-like. Nor was
the detail in their SOW in user story format. The crucial point about this context is that it
necessitates the requirements content, regardless of form, to be complete and detailed at the point
in time the supplier commits to deliver for a contracted cost.

Buy A Package Solution

Package solutions are almost always a compromise between requiring customization to support
the acquiring organizations current business processes and adjusting the organizations current
business processes to align with what is supported by the package out of the box. Any
customization required most often is done by the package supplier. If customization is wanted,
then requirements for that work falls into the Buy context described above. Even if functional
customization is not necessary, there will likely be interfaces and/or reports that need to be
developed or customized. Each of these will require detail requirements to support that
development. Again it is the content of that detail that is critical, not its form.
So basically regardless of any build or buy context, detail requirements in one form or another
are involved ideally providing unambiguous content. So lets have a look at what level of detail
should be provided for different types of requirements.

Content Detail for Report Requirements

In the previous article the following example of a high-level report requirement was presented:
The system shall support on-line customers being provided with the details of the order that they
just placed including a list of items purchased, the amount charged, and expected delivery date
in an email so that they have an off-line record of their on-line purchase.
The objective of a Report HLR is to describe it just enough so it is understood in terms of its
purpose and value to the overall business information system. During detail requirements, the
trick is not to record the detail as a series of individual detail requirements. The detail should
ideally be specified in a report template.
A proper report template provides for capturing required information such as frequency, delivery
method, and selection criteria. There should be provision for including a layout of the report
showing relative placement of headings and labels. Lastly, the template should cater for
recording supporting information about the fields seen in the layout. Fields like Customer
Number, Transaction Date/Time, and summary total fields would need little or no
explanation. But fields that require special lookup or values derived from other fields should be
described, preferably including examples.
With report details recorded in a template-based specification, the detail requirement itself
actually can be very simple. The following are examples of how simple a report detail
requirement can be when the detailed content is relegated to a specification:
User Story Format:
As a Customer, I want to receive an email containing the details of what I just ordered on-line so
that I have an off-line record of my purchase.
Shall Statement Format:

The system shall produce an email to on-line customers upon their submission of each order.
Both requirements should include acceptance criteria:
Acceptance Criteria

Given an on-line customer

When the customer places an order
Then the Customer receives an email that conforms to the Customer Order Confirmation
Email specification found Appendix C.

While acceptance criteria in the Given/When/Then format has its origins in Agile, there is no
reason it cant be included with Shall statements.
Assuming that all aspects of the report share the same priority, business rationale, and need to be
tested together, there is little or no advantage in representing different aspects as separate detail
requirements.

Content Detail For Data Requirements

When the scope of a project is known to include new types of data (records and/or fields), ideally
its good for these to be included as detail data requirements. The previous article had this
example data HLR:
The system shall support establishing new customers, including capturing details such as name,
address, and contact information, ensuring that every customer is uniquely identifiable. E.g.
Fred Smith assigned customer number 555123, The Carter Foundation assigned customer
number 654287.
From a detail requirements perspective, new record types needed in the business information
system should be named and defined. Volume-related estimates are good to have. For new fields
(including links to other tables) again business name and definition are useful. For fields, the
details of their data type and size should be specified.
Depending on the complexity of the information there may need to be some database design
done on the way to a solution. Still, for any new tables and/or fields designers and database
administrators need specific information that can only come from an SME. As with reports, the
types of information needed about data is common and best served by a Data Definition
template.
This again means that all that is needed is a single detail requirement in one form or another. The
Shall format example would look like this:
The system shall provide storage for information about Customers as described in the Customer
data specification found in Appendix D.

Again, while the above requirement does not appear detailed, the overall information provided
(mostly in the template specification) provides what is needed to get the job done. Also like the
detail report requirement, if the full content is not provided, when it comes time to design and/or
build the data solution an SME will need to be consulted.

Content Detail For Interface Requirements

System interfaces either import data thats needed by a business information system or else
export available data needed by some other system. Where the project scope has identified that
information needs to pass between systems, there should be a high-level requirement that
represents that need. The example from the HLR article was:
The system shall support sourcing of foreign exchange rates from the European Central Bank on
a daily basis to support currency conversion when the on-line customer deals in a different
currency than the supplier of a product.
From a detail requirements perspective, an SME should know what data items are expected from
or by the other system. It should be possible to list those data items based on the existing (or
under development) business information system.
If the number of data items is small, they can be listed right in the detail requirement. If larger or
complex data structures are involved, the details can be described separately (dare I say using an
interface template?). An example in user story form with a self-contained list of interface data
items would be:
As the system, I want to receive daily currency exchange rate data from the European Central
Bank so that I can convert purchase amounts from a supplier currency to a customers preferred
currency.
Acceptance Criteria

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:
o To Currency E.g. USD
o Effective Date
o Exchange Rate From Euro E.g. 0.89
o Rate Type E.g. Mid-Market

Data items in an interface list should include details such as attribute name, description, and
examples. The objective is to support the subsequent mapping of corresponding items on each
side of the interface during the interface development phase, where field details of size and type
can be addressed. This technical mapping is done by someone familiar with the business
information systems database schema. That person will also need access to the external systems
interface specification.