FURPS+: Specification tests domain
// For all categories see FURPS+: Table of Contents
Specification — is a major and one of 3 main sources of requirements (other two are common sense and standards). Specification is intensively used during Test Cases Design process. That’s why there are 4 requirements for any Specification:
- Clarity
- Consistency
- Measurement
- and Completeness
— and that’s what Specification should be questioned about.
So, a few words about every category below.
Clarity
I am sure, that everyone who writes Specifications must read books on Copywriting and Typography. Copywriting books teach you be clear instead of being clever, and typography books teach you how to make your copy to look good and easy to read. There is also a number of brilliant articles on typography like this one: typography in 10 minutes.
More than that, every Software Engineer should write and every writer is a programmer. And the best programmers have a class on writing to teach.
Consistency
Maybe because of context is over consistency, in Russia we use another, more clear word for this category: “incontradictivity” — to say it in English. I.e. Consistency in Specification asks that requirements must fit and support each other and do not contradict with each other.
Measurement
Nuff said :)
But I’ll add a few coins. Specification requirements must be measurable: vague words “fast”, “very fast”, “very-very-very fast”, etc. — are not acceptable in Specification. They need to be explained: how many nanoseconds it should take in 95% of cases? — that’s the right physical and statistical question to be answered in Specification.
Completeness
And finally, Specification must be complete. I.e. it must describe all the features and options of software. Because if software does something that is not described in Specification, it is either Specification is incomplete or it is a bug in software (undeclared functionality — is a bug in software). Both these cases must be fixed.
I hope you enjoyed reading and found this article useful. If so, please like to recommend others!
If you have anything to add, share, argue or to comment in this article — please, do it! Only in collaboration we can build something really amazing in Software Quality Assurance.
