Requirement is something wanted or needed, it is 1st and most important part of development life cycle and often ignored by software houses and as a result, we get dissatisfied customer and lot of rework is done. The hardest single port of building a software system is deciding what to build, in this phase we answer the question what to build? Not, how to build? If something is missed in this phase, it will be moved to next phases.
Here I will discuss about applying SQA techniques in requirement engineering. In this phase bug prevention and detection can be done. If we have done the bug prevention part, then we can say that we have done quality assurance. It is observed that a good, clear and well documented requirement can lead to high quality software and ambiguous, bad documented requirements can lead to poor quality software and chaos arises in software house.
First take an example of ambiguous requirement and I will discuss later on, how to cope with these requirements and how to achieve good quality, because in this competitive world we cannot compromise on quality, it we do so, our customer can do something bad for our business.
Req_001: ‘Stop not go’, if we received that requirement, it can be interpreted in two different ways.
‘Stop, not go’, if we put emphases on stop, it’s meaning will be ‘You shall stay and shall not go’ as it shows order command.
‘Stop not, go’, if we put emphases on stop not, it’s meaning will be ‘You shall not stay and shall go’ as it shows order command also but meaning became opposite as compared with first case. Early Software development model was picked from construction industry, as we know that Software and Construction industry both are different but they have some things common also. Construction industry processes are stable and they follow water fall model. In construction industry, we cannot copy paste on building but in software industry we can reuse the software code in similar project. So, frequent changes can be incorporated and software industry professionals have introduced iterative models like XP programming, Agile, RUP etc. for software development.
To document the requirements following two methods are used in software industry.
(1)- Throwaway prototyping
(2)- Evolutionary prototyping
In Throwaway prototyping as name suggest we prototype the requirements in the form of storyboard, discuss with client and use the experience and suggestion gain in later development life cycles and throwaway the prototype. Quality assurance techniques are not applied in throwaway prototype.
In Evolutionary prototyping quality assurance techniques are applied and each and every requirement is documented and updated if change occurred in future. Requirement trace-ability is done in evolutionary retyping.
Advantages of Prototyping/storyboard
- As the requirements are documented and communicated with client and in this case responsibility is shifted toward the client, if in future client says, this is an issue, we can decently say, this change was done as per your request and this will be a change not an issue. Software requirement prototyping is the professional way of making the client responsible not the software house for rework which was done.
- Writing early test cases is only possible if we have storyboard/prototype ready. Writing the test cases before the actual testing gives more time to QA to think about different scenarios and do plan for proper testing.
- As we know that storyboard requires time and expense, prototyping cannot be done in the tools which we used during development, specialized tools and training is required, but at the end this cost is much less the rework cost.
- Storyboard makes the programmer to focus on code not on requirement analysis, in this way they can build the software part with much confidence.
- If we are not doing prototyping/storyboarding, we can say that we are not doing SQA on our software product because quality assurance is not possible without QA involvement in requirement gathering phase.
If you are given a development or testing task and its storyboard is ready after client approval, Review and discuss it with storyboard author before starting the development or testing, so that we can deliver to the client with in time and can meets user requirements
Client will be satisfied as we will deliver what he wanted for, IT process will run smoothly and all our effort will be successful
and on the other hand if we are not following that path, all our design, development and testing effort will be useless, there are chances of modification, frustration may arise and client might say ‘you are not paying attention to your own proposed changes’