I just came across this wording the other day. For some years ago I was working in a team, where we from time to time evaluated requirements specifications. In those days a Bikini-specification was a specification that – just like a bikini – shows some valuable things but still leaves important parts hidden ;-)
Actually it is quite common for not-so-good-specifications that, what is described is not that bad written, but a lot of important elements are still missing.
The Bikini specification comes in two different flavors:
1: Some parts are missing. This is the most obvious part. Some important subjects are simply missing from the specification. For example:
If writing requirements for a new payroll system you might have missed describing, that the system must calculate the retirement savings for each employee.
2: The requirements are not described detailed enough. For example:
If writing requirements for a new payroll system you might have required:
“The system must be able to calculate the amount in euros granted for the employee’s retirement savings”
The requirement is understood (it is understood that you require the system to calculate something for retirement savings) but exactly what do you want the system to do? How should a programmer be able to implement this requirement?
It would have been less Bikini, if the requirement had said:
“The system must be able to calculate the amount in euros granted for retirement savings
For each hour worked the employee is entitled to additional 7% in retirement savings. The retirement saving calculation must be based on the number of hours worked in a given month (including overtime) x 7%. The total retirement saving will be paid by the employer alone.
… and then of course, you could add several additional details à what happens if the employee goes home sick after working a few hours? is the retirement calculation based on the hours actually worked only? Is the calculation per hour only? What if the employee is entitled to 150% hours in some circumstances etc. etc.”
But when should you stop? When is enough, enough?
Rule of thumb:
See it from a risk perspective: How likely is it that your requirement will be misinterpreted and misunderstood? AND what is the impact, if the requirement is misunderstood?
The answers here should give you a hint whether you should detail your requirement further or stop where you are.
Furthermore, how du you know if your requirement specification is a Bikini specification?
Rule of thumb:
Try to do a quick brainstorm with your key users / stakeholders. Ask them to name three requirements/areas that the developers will probably get wrong. If they can come up with three suggestions very very fast AND/OR if they could name many many more AND/OR if the three things mentioned are some very easy obvious parts (you should feel embarrassed) -> chances are that you are having a Bikini….
Comments