Friday, August 01, 2008
Best Practices in Capturing Business Requirements
Have you noticed that within most enterprises, requirements are captured in Microsoft Word documents that often become big, unreadable, ambiguous and unmaintainable messes? Maybe we need to revisit the requirement of comprehensive documentation and consider writing requirements in code...
Even though modern software development occurs in object-oriented languages, most of the thinking is still highly procedural. While industry analysts aren't talking much about other approaches such as BPM and usage of rules engines such as Blaze and iLog, a conversation should occur where we ask ourselves, why can't code be documentation?
If you look at security approaches such as entitlements management where the grammar is based on XACML, you can create some requirements that are declarative, unambigous and most importantly executable. The real challenge and stimulus for comprehensive but otherwise unmanageable documentation is usually for those who are not IT professionals but work in an IT organization to participate in the lifecycle of software.
Worst practices such as CMMi measure the amount of documentation but not necessarily is quality nor does it take into consideration maturity of declarative approaches to solve all concerns. Why haven't we all figured out that to produce software that is runnable and understandable by CEOs, marketing, customer's , etc is easier to explore the musts, coulds, shoulds and do nots with working software than a paper document.
CMMi, PMP and our love of governance attempts to make implementation irrelevant yet that is the sole reason that IT as an entity exists. Besides, writing documents is easy while writing high quality software is hard. So, this shouldn't mean that we should go from easy to hard in terms of a lifecycle but rather that working on the hardest stuff first is more important than doing the low-hanging ceremonial fruit.
At some level, IT as a profession really blows it because we do a great job of capturing functional requirements and suck at capturing system qualities. Imagine a business requirements declaration saying that the system should be secure and be resistant to the OWASP Top Ten. How can someone figure out whether this is in conflict with some feature the user has asked for especially if they are dozens if not hundreds of pages apart? When will we acknowledge that implementation are little decisions made all over and that requirements documentation only decide certain aspects?
Other perspective says that if a requirement is not eventually written into the code, the requirement is meaningless. I wonder how many meaningless requirements are out in the wilderness? Every piece of software is a set of requirements written into code. If you do not expect to eventually record the requirements into the software, why do them at all? We can disagree about the necessity to do a requirements document, but not about the necessity to record requirements into software.
| | View blog reactionsEven though modern software development occurs in object-oriented languages, most of the thinking is still highly procedural. While industry analysts aren't talking much about other approaches such as BPM and usage of rules engines such as Blaze and iLog, a conversation should occur where we ask ourselves, why can't code be documentation?
If you look at security approaches such as entitlements management where the grammar is based on XACML, you can create some requirements that are declarative, unambigous and most importantly executable. The real challenge and stimulus for comprehensive but otherwise unmanageable documentation is usually for those who are not IT professionals but work in an IT organization to participate in the lifecycle of software.
Worst practices such as CMMi measure the amount of documentation but not necessarily is quality nor does it take into consideration maturity of declarative approaches to solve all concerns. Why haven't we all figured out that to produce software that is runnable and understandable by CEOs, marketing, customer's , etc is easier to explore the musts, coulds, shoulds and do nots with working software than a paper document.
CMMi, PMP and our love of governance attempts to make implementation irrelevant yet that is the sole reason that IT as an entity exists. Besides, writing documents is easy while writing high quality software is hard. So, this shouldn't mean that we should go from easy to hard in terms of a lifecycle but rather that working on the hardest stuff first is more important than doing the low-hanging ceremonial fruit.
At some level, IT as a profession really blows it because we do a great job of capturing functional requirements and suck at capturing system qualities. Imagine a business requirements declaration saying that the system should be secure and be resistant to the OWASP Top Ten. How can someone figure out whether this is in conflict with some feature the user has asked for especially if they are dozens if not hundreds of pages apart? When will we acknowledge that implementation are little decisions made all over and that requirements documentation only decide certain aspects?
Other perspective says that if a requirement is not eventually written into the code, the requirement is meaningless. I wonder how many meaningless requirements are out in the wilderness? Every piece of software is a set of requirements written into code. If you do not expect to eventually record the requirements into the software, why do them at all? We can disagree about the necessity to do a requirements document, but not about the necessity to record requirements into software.
