다음을 통해 공유

Modern business rules specification

  • 아티클

Business rules, yes business truly rules in software development; if software doesn’t behave accordingly established forms, conventions and requirements of the business, then it is useless.

 

Therefore, behavior specification is paramount and is one of the more important aspects of successful software development. Yet, static documentation for specifications is one of the most ambiguous and tedious work in our profession.

 

Often the end result of specification is a lot of paperwork, which represent a bunch of work which rarely helps to really convey the essence of a software system. Moreover, it is the source for a great deal of miscommunication and the infamous “what the customer really need – what was built” trade.

 

Computers are tools and also can help with this beyond static electronic documents.

 

What if the very acceptance criteria for a software system could be clearly communicated? And then registered as an executable electronic document that at execution time unambiguously reports if the specified software system fulfills the expected behavior?

 

This very same active specification documentation helps to guide design and programming activities and gives clear indication of the progress and obvious criteria for code complete decisions (no more ’90% done, 90% work to do” syndrome).

 

Current Microsoft Office Smart Documents architecture or next Microsoft Visual Studio Tools for the Microsoft Office System Version 2005 or other tools like ASP.NET or plain Windows Forms are enablers for such idea.

 

https://fit.c2.com/ by Ward Cunningham or https://fitnesse.org/ by Robert C. Martin, both along with corresponding contributors represent implementations of this technique.

 

An executable document specification exercising on-demand the key components of a software system (the very same in the production build) with actual data representing authentic business scenarios (use case realizations) and reporting “ok, as expected” and “failed, expected-actual” results.

 

This is what current professionals and future generations of software developers are going to use as tools to alleviate problems with specification of business policy in software behavior.

Comments