Requirements dont need to compile
When capturing requirements, or really any standardised technical documentation, there is often a tendency to get a little too hung up on the format and structure of the document itself.
Don't get me wrong, UML is a useful standardisation, and an important one that allows ubiquity in communication between architects, designers and developers - regardless of their level of domain knowledge. But the 80/20 rule so often shows up when producing anything in a highly specified way.
In other words, getting the general gist of a requirement out may not take long at all and is time well spend. Elaborating and fleshing out that requirement is also highly productive and interesting as the elusive dark corners of the domain are exposed. Then comes the potentially low value and distracting part. That is, to bring the captured requirements up to the internal standards that we set for ourselves for documentation in a corporate environment.
Theres nothing wrong with having high standards for requirements or any other kind of technical documentation, the trouble comes when we get so caught up trying to meet our own technical standards, that we run out of time for the high value (and fun) stuff. We get distracted from the real reason for capturing requirements (that is, to share them with others) and get overly focussed on filling in all the blanks in document templates.
Of course its always a judgement issue to know when enough detail is there, and to be sure that your reader wont fall between the gaps in your technical assumptions. But people arent computers and they dont need every fine detail to be able to understand and follow along. A requirements specification, that perhaps breaks a little UML or any other standard along the way, but still manages to effectively communicate to its reader, is not necessarily of lesser quality than say a less briefer brief. This is much like the way that Domain Specific Languages sacrifice a little language ubiquity for the sake of getting right to the point a whole lot quicker. Of course you may not understand the point, but hey, you're not a computer!
Hail to the requirements
It all starts with the requirements.
It often ends there too. But what better place to start a technology blog than to post about that inescapable centre of project gravity - that ball and chain to creativity - and undeniable task master that is the project requirements.
Often disliked, more often neglected, they are always there - written or remembered, lost but never forgotten, specified or implied, the requirements stand as the yardstick for measurement of any technical development project or meaningful endeavour.
Sure, we can argue about them. Who owns them? Who writes them? Who brings their documentation back up to date 5 years later? Few dare to put an actual business value on their documentation, but when they arent captured the long term costs to business are equally immeasurable.
In many ways capturing requirements is no more about creating something new, than recognising and crystalising what is there already. Possibly in the minds of several stakeholders, probably contradictory and incomplete. The process of capturing requirements takes something that is implied and makes it explicit. Something that is in many places, or nowhere at all, comes to be in one place, in one form. Once there, they can be thrashed out, holes filled, contradictions unwound. Once there they give a developer a reason for developing (heh heh as if we didnt need one). Once there they give a test analyst something to measure against. When they are lacking we can spend most of our time justifying anything we do at all. (and rightly so)
Many things can be discovered along the way to a well specified system. Domains evolved, new languages used, and many too are the tools, techniques, approaches, TLAs, methodologies and consulting companies that litter the path. But like it or not, when it comes to requirements, we need them. And they need us, but it still all starts with the requirements.