From Requirements to Tables to Code and Tests

From WikiContent

Revision as of 16:08, 6 February 2009 by Gbcambridge (Talk | contribs)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

It is generally reckoned that the process of getting from requirements to implementation is error prone and expensive. I guess I do not need to elaborate on all of the reasons as they are pretty well known. However, some key reasons are lack of clarity on the part of the user ..incomplete / inadequate requirements and misunderstandings on the part of the developer .. catch-all "else" statements and so on. We then test like crazy to show that what we have done at least satisfies the law of least surprise! Now I want to focus here on the business logic, not the interconnecting tissue. The execution of the business logic delivers the value of our application.

Let's abstract business logic a little. We can imagine that for some circumstance, say evaluation of a client, or a risk, or simply the next step in a process, there are some criteria to be satisfied. Also depending on these criteria there are various, one or more, actions to be performed. It would be convenient to capture the requirements in this form... a list of the criteria, C1, C2,... Cn and a list of Actions. Then for each combination of Criteria we have a selection of Actions. If each of the criteria is a boolean, then we know that there are possibly 2 raised to the nth power of possible criteria combinations to be addressed. This is a big step forward from conventional requirements capture. We can prove completeness! Further, if the requirements are captured in this form then we have an opportunity to largely automate the code generation process. In doing thsi we have massively reduced the gap between the user adn the developer. Some

Personal tools