The Whys Of Requirements Specification

One of the biggest gaps in the requirements discovery and specification, and solution design is formed because the whys are not communicated to the solution developers. The requirements specification usually talks only about what the solution should do. There is nothing that tells them why it is so. When their decisions are not aware of the underlying reasons, they can work against the overall benefit and at times make the solution a failure. Here are some things that I think should be communicated to the solution developers:

  • problems and pain points in the current system
  • priorities of requirements
  • business constraints
  • other non-software components, like processes and skills
  • rationale behind important decisions

A lot of businesses do feasibility studies but they are not shared with the developers. Or sometimes businesses have already identified a solution that they are using to build their requirements. Or sometimes businesses just do not invest enough in identifying their problems and pain points.

Unless the solution developers know the ROI behind the code they are writing of tools they are integrating, they are not going to be able to effect it. It is always better to define the problem in its own space, keep it solution agnostic and share it with people who are developing your systems. Or this gap can lead you to the wrong solution or a solution for the wrong problem.

Say your thought!

If you want to use HTML you can use these tags: <a>, <em>, <strong>, <abbr>, <code>, <blockquote>. Closing the tags will be appreciated as this site uses valid XHTML.



Abhijit Nadgouda
iface Consulting
+91 9819820312
My bookmarks


This is the weblog of Abhijit Nadgouda where he writes down his thoughts on software development and related topics. You are invited to subscribe to the feed to stay updated or check out more subscription options. Or you can choose to browse by one of the topics.