In Software development arena, I often hear people saying, “Functional Specification document is like a Bible for us.” Well, I tend to question this statement. It is too much ambiguous to me. What does a Bible mean? Does it mean the key source of information? (note: I am not pointing to the holy Bible). I asked if that is what they meant – whether as a key source of information for application development and testing. I heard “Yes – the information in this document is fairly technical in nature and derived from the Requirements Document. ”
Great – so that means, somebody wrote the Requirements as the understanding from the Business owners. The requirements were reviewed by the business owner and the representatives, and perhaps few end users have reviewed the requirements and passed along the feedback. Let’s assume requirements on paper are according to what end users have visualized. Note – requirements might not have all the prototypes and the exact screenshots to help their imagination.
So, now, Functional document is a subset of Requirements depending on the functional ownership of the piece of application. Requirements on the other hand, supposedly, the end to end solution, as what business is looking for. Now, comes the functional dev and test teams, looking at Functional document ” so called the key source” that provides the subset of the requirements. My question is, if the key developers and testers are not even reviewing the requirements, as to what Business wants, how would they be able to translate the piece of software into what business wants. At the end of the day, what we develop is for the end users to be efficient in what they do and not become frustrated of not having the feature they were looking for.
I was often countered, “why would you even want to look at the requirements document when we are deriving the information into Functional?” my answer was “a big picture“. As a developer, at times be blindfolded on 4 key points and forget the rest
- Object in question or to be coded
- What are the input parameters
- What are the output parameters
- what are the business rules (logic) go into this object
Well, that does not work for a testing individual to know just that, to perform his job. He needs to know more and beyond the vertical object to ensure many many factors impacting or influencing due to one vertical piece. This kind of information can be obtained :
- partly from the functional,
- partly from the requirements and
- mostly from the end users or the product owner or from the user surveys depending on who the end users are.
- Additionally, having the prototypes to the end users would definitely be a big bet.
Additionally, being involved in FS development and reviewing the Requirements at the same time and having the prototypes up-front, would potentially save a lot of cycle time at the later time and potentially reduce or eliminate any re-work due to mis-representation during the requirements process. We are all humans, at times what we draw on a piece of paper might be different when translated to the prototypes and users would see in a different angle when presented with at least the prototypes than doing a visio diagram or describing 5 pages for a little dialog box kind of UI.
I just noticed a post from Shrini about testing the Requirements Heuristics. Quite informative.
In summary, please, involve the business owner and the end users as part of the functional development and through the process till the end of the development/testing cycles. This helps the end users feel they are involved and will certainly be a lot of help to the dev/test teams as part of this process and at the same time, they get what they want and be accountable for what they have asked for since they were involved in design and decision process. At the end of the day, product is something that should help the end users to be effective in their activities and not hinder their productivity with a new piece of software application.
From the dev/test teams perspective, it is the quality output that we deliver to the end users / customers (note: the term quality output might be debatable, but let’s go with whatever you define quality as. this post doesn’t go into that level.)
(note: this post was not reviewed before posting to the blog)