According to the principles behind the Agile Manifesto
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
As I’m from an operations background, I’ve always had great trouble communicating with the customer over requirements that have been relevant to my domain. The usual situation is that the “customer”, often the product owner, views the working i.e. functionally complete software on a developer’s machine, but bringing this to an operational service level is an afterthought (until it goes offline, and the real customers start complaining).
Traditionally, capturing these specifications has fallen under the umbrella of “non-functional requirements”. As Tom Sulston pointed out to me, this suggests requirements that aren’t working, which is precisely the opposite of what we’re attempting to express.
I’ve sought to tackle this in a couple of ways.
Spread FUD throughout the non-technical customer base.
- “Do you want it to explode?”
- “NO!”
- “Well you should ask for non-exploding software in your stories then!”.
Get the team in a room together and express “cross-cutting concerns” (I half-inched the idea from AOP) that span the project as a whole.
I haven’t been happy with the results of either approach, so I’d be interested to talk to anyone with a satisfactory solution in this space.