In the defense industry the word requirements means a series of statements that have the word 'shall' in them. These statements are testable, measureable, and specific. This approach has carried over into the IT industry so that those deploying systems have similiar documents with all the 'shall' statements that the system must do.
For the delivery of information systems, this approach sucks. No one, and I mean NO ONE, can take a document with 300 shall statements and understand what the system will do. Did I say no one?
But here's the rub: when it comes to design, development, testing and deployment, shall statements are very helpful. Shall statements are the machine code that makes the information system development process work, so we can't ignore them.
Too many times I see battles between those that work with users to identify requirements with group facilitation techniques, wireframing, etc. and say the systems engineer's won't connect with users due to their stupid requirements documents (and their right). And the systems engineer's say that the facilitators don't provide enough details to adequately develop systems (and their right).
This is the roll of the chief engineer and program manager - make sure both are happening and that what we discover from the user with user centered techniques translates into the machine code that the developers need.
2 comments:
I mean NO ONE, can take a document with 300 shall statements and understand what the system will do.
Those "shall"s may not be wholly comprehensible by any individual, but as a developer I can feed those "shall"s into a UML tool (like Rational System Developer) which will reveal the necessary components, their attributes/behaviors, and their relationships - all leading to a natural implementation of the overall requirements rather rapidly. The trick is knowing the tools, trusting the emergence of the desired result from the nature of the requirements, and preventing other people from interfering by injecting their self-rightous half-baked ideas into a system they don't understand.
It's like the sculptor's aphorism: "start with a block of marble, and just remove whatever is not part of the statue." For programming, just implement what is required, and the program will emerge. Lose sight of that principle in either case, and you'll end up with something irredeemably different from what is intended.
And that's the second half of the statement. The shall statements are important for the engineering of the solution. The problem is that unless the customer can comprehend what their getting, the down stream process will systematically and efficently generate something that the user doesn't want. The solution isn't better shall statements. We need to capture what the user wants using other tools, then turn them into shall statements.
Post a Comment