Requirements are the Foundation of Good Software
As we have been reviewing techniques for writing test cases as early as possible in the development cycle, Alex is reminded of a software development approach for gathering more complete requirements.
Alex writes:
I have spent many years in software development and there is one approach to software development that I always wanted to try. That was, given a set of requirements, write the User’s Manual. There was a group of developers that held that one could use a software product User’s Guide as the Functional Specifications.
To me this made a lot of sense. Especially today with modern word processors, one could layer Functional Spec details throughout the User’s guide, making validation of the functional specifications very direct and easy. When the User’s guide is published, the functional specifications would be hidden. I realize that now-a-days with so much documentation on line, something would have to be done to strip out the specs for a version that was put online and available for anyone to read.
Unfortunately, our development environment was very conservative and this approach would never fly. But the idea always intrigued me.
Editor:
I also find the idea very intriguing. I worked with a product back in the late ‘90s that tried to follow a similar path. Versata was a software development environment focused around managing business rules. As you manipulated and maintained your business rules, the engine converted those rules into database, data access, business logic and presentation layers.
The big difference in coding in Versata was the focus on your business rules. Not that we don’t focus on business rules in modern software development. However, we focus our development efforts on translating those business rules into software. Versata automates that translation of business rules into code, so that we can focus on workflow and presentation.
While Versata was able to develop some fairly sophisticated systems rapidly, it wasn’t always the best fit application. I haven’t kept up on the product today. I know it is still available; I don’t know the current technology it utilizes or licensing models.
Tomorrow we’ll get back to our example of writing unit tests for a SQL Server stored procedure implementing reporting requirements. You can join into the conversation by writing in to btaylor@sswug.org.
Cheers,
Ben
$$SWYNK$$
Featured Article(s)
Tips for using SQL Server 2012 cursors
In this article, Alexander Chigrik shows some helpful tips to performance tune and optimize SQL Server 2012 cursors.
Featured White Paper(s)
Go Beyond SCOM Monitoring with Foglight for SQL Server
read more)