Standards As Requirements

One of the challenging tasks of software development is identifying the right requirements. Though there are many established techniques and practices for eliciting and gathering requirements, I have seen that every professional has his/her own way of doing it. And like estimation, it is not science, soft skills and cognitive thinking contribute a lot of the effectiveness. When I am involved in one of these discussions, I try to look at standards and best practices as requirements. Of course, this can put additional load, but it helps a lot, especially if you are developing an industry-wide product.

A note - I am loosely tying the word standards to the group of established standards, laws and best practices.

Standards Are Implicit Requirements

Whenever I have mentioned this, I have first received a negative reaction. So let me illustrate what I mean by using standards as requirements.

If I am developing a web site, something as simple as a blog, the usual suspects are ability to add/manage posts, categorize them, syndicate and probably through a WYSIWYG editor. And of course these are needs of the domain of blogging and are extremely important. But there are some requirements which do not figure in the documents, like the blog should carry valid (X)HTML code, or that the text should be readable, or that the content should be syndicated using standard protocols. They seem very obvious, but they never explicitly figure in the list or in the evaluations.

There can be many more considered. In fact you will find a mesh of standards, if you consider an enterprise application like ERP.

Evaluate Standards

There are various types of standards that you might need to consider. There are industry wide vendor neutral standards, vendor specific standards, technical standards, laws of the land and sometimes standards specific to your customer.

I qualified standards as guidelines instead of rules because it is important to evaluate them and study their applicability to the problem at hand. Standards for namesake do not provide any benefit, they can in fact turn out to be an overhead. Though many standards can overlap across problems, every single problem is unique by itself, and its users might benefit differently from the standards. For example, if you are developing an application for a closed group of users you can choose to apply accessibility as per the need. Standards should be subject to cost-benefit analysis, just like every other requirement. However, it is extremely important that you understand benefits of using and dangers of ignoring the standards well enough to take the decision.

Standards benefit the users, and so indirectly benefit makers and owners of the software. Considering the standards can give you a ready-made set of requirements, which can make your product ready for the industry and interoperable with other tools in the industry.