There's just one problem - that the phrase
was never spoken in any TV series or film in the Star Trek franchise.
We can trawl through them all and we'll find something very similar in a few occasions, "Scotty, beam us up" or "Beam them out of there, Scotty”. But never properly, word-for-word “Beam me up Scotty”. Never-the-less, the phrase has entered culture so much that we know it's
associated with the series. We just have the inconvenience of not
being able to be backed up by the facts!
I've recently learned that something similar with requirements. On my Waterfall
project, we've been living and breathing the same set of requirements
since Christmas. We've had meetings about them, we've had a dozen
updated copies of the. We've discussed them informally.
our surprise then when we had software delivered this week, and it
didn't quite meet expectations. We turned to our source of truth,
the requirements, and found … erm that they weren't there. Not
quite as we'd imagined them.
kind of asked for a certain behaviour, and we'd definitely discussed
them. But rereading them from a different angle now, maybe not.
no doubt is the weakness of Waterfall projects. When you talk about
the requirements so much, it's very easy to read them “in the same
manner as how you've discussed them”.
difference sadly is one between “what you think the requirements
say” and “what they actually say”. Oops.
in my mind is definitely the power of Agile, where it's the group
discussion and consensus which is the living and breathing source of
truth for the project, instead of the derived set of documentation
(often delivered weeks after all those conversations).
This week I’ve been having a bit of fun talking with testers
about implicit (unspoken) requirements we might have for products. [Don't take the next bit too seriously]
One that seems quite obvious is,
“It’s a bad product if it ends up killing someone”
Of course testers know better, “but our product is an
electric chair … so isn’t it the purpose of it?”.
How could we check this?
In a real project we’d ask a Business Analyst for their opinion.
I have a great relationship with Patrick, one of my Business
Analysts. We share a bay, and there’s a
lot of good natured banter. Like me he
used to be a programmer, and he turned BA, whilst I turned Tester – so we’re
kind of equal but opposite.
So I put it to him,
To: Patrick, chief BA From: Mike, chief Tester Subject: Electric chair requirements We’re working on an electric chair, and we need your business analysis of it. For our product, is the guy strapped into the chair the end-user, the customer or just an interested party? When it comes to the reliability of the product, who would you consult most with, they guy throwing the switch or the guy sitting in the chair? Where is the customer experience in this scenario? Mike
His response was so good, I’ve just had to build a blog
around it …
To: Mike, chief Tester
From: Patrick, chief BA
Subject: RE: Electric chair requirements
The end-product is a chair that
is capable of sending a high enough current discharged through the body of the
person in the chair to end their life in (insert parameters here eg. 5 seconds).
The Customer is the person who
is paying for the product, together with all the people who work with
them/support them to ensure that the product fulfils it’s set objective (“a
chair that kills with electricity”).
The business rules for this
product can be that,
the power is not to ignite the
that it won’t prolong death
that the current won’t blow the
the Business owner,
the chair manufacturer,
the electrician looking after
to determine best death time
within the parameters.
So the deliverable is a chair
that kills people, the business owner owns the relationship with the person in
the chair, not the BA or the Project!