A solid database design provides a firm and extensible base an organisation’s data. A well-architected solution brings with it a sense of integrity and elegance that allows systems to be extended easily, and yet retain its integrity.
If any of these are badly done, the resulting solution is flaky, troublesome, and a menace to update.
But bad requirements are even worse, for they are our map to what should be built. If the requirement is wrong, the solution built is wrong. If the requirement has gaps, then the solution will have gaps. If the requirement is misunderstood, then the solution is wrong.
There is an art to producing requirements.
1. Requirements Must Have an Owner
2. Requirements Must be Singular
3. Requirements Must be On the System and Not the Operator
4. Requirements Must be Unambiguous
5. Requirements Must Not Specify the Solution
6. Requirements Must have a Rationale
7. Requirements Must be Tied to the Concept of Operations
8. Requirements Must be Justified
9. Requirements Must be Prioritised
10. Requirements Must be Contextualised
No comments:
Post a Comment