Under most models of software development of any
significant scale, user sign-off of requirements is a must before the development
can continue. Even agile methodologies that involve a customer representative in
the development team needs to have a set of at least significantly complete
requirements before development can begin.
Requirements form the basis for generating a Tender or Quote
and help generate a Statement of Works. Detailed requirements are often
elicited during contract negotiations and once established, a fixed price can
be agreed (if that is the model being used). Requirements sign-off is all
important in formally contracting what needs to be provided in any software
project deliverable. It is the signed requirements document that is brought
out when there is confusion about items being in or out of scope, and
determining if a product has been completed.
A hopefully typical contract stipulates that software is “done”
when all Acceptance Tests have passed. Although our contracts often stipulate
that once all sites are Live the software has been accepted and the project is “done”,
though in my experience this is painful because reasons for not going Live are
quite often more political than technical or caused by any software defect, and
it’s these situations where Acceptence Test success would greatly speed up the “Done”
state of a project (and the “paid” state of the Invoice).
My company traditionally produces an “Operational Scenarios
Document” (OSD) as the document indicating the requirements and to be signed
off the customer. The OSD is simply a document containing all the user stories
or use cases of the system to be built. I believe this presents a more
understandable view of the system to the customer, as it’s written in their language.
From the OSD Analysts produce a more engineering oriented “Software Requirements
Document” (SRD), where the OSD is broken down into hundreds and thousands of numbers
system requirements.
The problem with this approach is the OSD only captures user
facing actions such as steps in a business process. It is up to the SRD to
capture the more fine grained requirements, such as “Patient information shall
include a valid Medicare number in the format XXXX-XXXX-XXXX X”. As such, we’ve
captured the necessary requirement, but there’s nothing to formal (read “legal”)
to cover either us or the customer. Generally this isn’t a problem, but we’ve probably
all experienced scope-creep and ambiguous (signed) requirements are the genesis
of scope creep.
Enter signed Acceptance Tests and Acceptance Test Driven
Development (TDD at a higher abstraction). Acceptance Tests define exactly
what the system has to do before the customer will consider it “Done”.
Acceptance Tests don’t just include functional requirements; they also test the
non-functional stuff like performance, security, and useability. If functionally
is not covered by the Acceptance Tests, it’s not required by the customer.
Now, I’m not saying that no software project should be
undertaken before Acceptance Tests are supplied. That’s clearly unworkable in
all but the situations where the customer team has experienced analysts, with a
good understanding of the software development process, on board. What I do
think is that an analyst or developer should always be mindful of Acceptance
Tests when eliciting requirements from customers during workshops. Questions like
“What are the steps you take when placing an order” are not enough. “What
state will the order be in once it has been successfully placed?”, or “What
happens if an order is placed and there is not enough inventory to fulfil it?”
are necessary. Hopefully these are already questions that are being asked as
part of the user story generation.
The differences between Acceptance Tests and Use Cases
(or OSD’s) are small but significant. Where an OSD is used by the customer to
accept that you understand the requirements of the software under design,
Acceptance Tests are used by customer to determine if you supplied what they
asked for. Both OSD and Acceptance Test Document can be generated from the
same information at the same time, so it makes sense to generate them at the
same time and include both in any formal signed requirements.
From a development perspective, you can use user stories/user
cases/operation scenarios in tandem with acceptance tests to define the use
cases to be developed in each iteration, producing software that is of business
use after iteration one and the customer can hook into the feedback loop early
in a project.
Critically, Acceptance Tests are generally customer
supplied artefacts and as such, you as a developer have a higher level of
confidence that developing a system to meet Acceptance Tests will result in a successful
project.