Project failure is often the result of misunderstood requirements during the software development process. If we are to achieve successful results, we must try to be as intelligible as possible and create accurate requirements.
Software requirements analysis and documentation
The problem of acquiring the correct version of final requirements occurs not only in software development, but also among family members (which may be a common reason for quarrels). Below we use an example of a husband and wife interaction to illustrate how business analysis techniques, such as BPMN (Business Process Model and Notation) diagrams, can create some of the clearest records of final requirements or uncover potential misunderstandings. These can be used for a simple shopping task or a complex software project.
The main idea is that regardless of what methodology was used in the process of gathering and documenting requirements (or communicating with your husband or wife), the final version of requirements should be clear, and clear in the SAME way for all stakeholders (or family members). Good requirements always give the CORRECT, intended way of realizing some functionality (or doing some shopping).
The 6 steps of gathering requirements during the software development process
It’s not surprising that correct, clear and complete software requirements specifications (SRS) are the key to successful development of products in the IT industry.
Here are some techniques that the business analyst, as a member of the project’s team, can use to create requirements documentation.
Interviewing.
Brainstorming. Brainstorming with other business analysts and project team members is a very effective technique for idea generation. Brainstorming should have two phases – creating ideas and validating ideas. After this stage, the business analyst should have the list of requirements, their priority and some ideas about how they should be realized.
Prototyping. Software is often designed to change the way users realize some process. So business owners and users should not be expected to visualize the new software. Creating the prototype (simple paper prototype for some projects or a more complicated dynamic one created with the help of special software) is the way to give first sight of the product to the stakeholders and help them visualize how it’ll work. Discussion with stakeholders and users after prototype demonstration can help to identify some additional valuable functionality and features or to intercept redundant ones.
Requirements documenting (Use Cases, User Stories, SRS, etc. depends on general methodology). The result of this stage are clear and complete documents about how users can interact with the product, what are the responses of all actions in different conditions and how all the functionality and features should be realized.
Business Process Modeling. Creating diagrams (UML activities diagrams, BPMN diagrams or something else) that model and visualize the business processes for which we are gathering business requirements can be very helpful for a clear understanding and documentation of requirements. They are extremely effective at communicating scope because they can help reach a common understanding with stakeholders and developers about requirements for some functionality and features of the product.
Analysis, review and verification of documents. All business requirements documents must be reviewed by project’s members and stakeholders before their implementation. The significance of this stage cannot be overstated. You can use all best business analysis practices, write many documents and create complicated diagrams… but requirements could still be misinterpreted. Review the documentation and make sure the requirements are verified.
Why analysis and verification is vital…
An unverified requirements document could land you in trouble. Here we turn to our husband & wife example:
Dear, please go to the supermarket…
This is short funny story about a misunderstanding between family members:
Wife asks her husband (a software engineer) to go to the supermarket and buy some goods:
“Dear please, buy a stick of sausage, and, if they have eggs, then buy ten.”
After some time the husband comes back with 10 sticks of sausage.
“Why did you buy TEN sticks of sausage and where are the eggs?” the wife asks.
“They did have eggs, so I bought ten sausages,” the husband answers.
Of course, the wife wanted the husband to buy 1 stick of sausage and 10 eggs (her requirement). But even this simple requirement, as we see, could be executed in different ways.
To model this situation we have created BPMN diagrams. In spite of a comprehensive modeling technique, where both parties thought requirements were clear, we can see that the final result of the wife’s requirement implementation isn’t correct because the requirements were not verified. We ended up with ten sticks of sausage and no eggs…
To avoid misunderstanding, it is a good idea to include one additional verifying action in the husband’s sequence of operation. For example, it would be beneficial to include an action [Ask wife] –> “Am I understanding you correctly?” before going to the supermarket. I hope (but I’m not absolutely sure…in family life everything is possible), that after a similar verification, the wife would explain her requirement more clearly.
Husband’ pool in this case could be presented in the following way:
In this case we can see that the realization of wife’s requirements is correct. So, if we are going to model the process named “Ask husband to go to the supermarket” we should add the additional question “Am I understanding you correctly?” in the husband’s sequence. The probability of a correct purchase in this case will be higher.
So, be careful and insist on reviewing your requirements documents before implementation.
3 C’s of business analysis
Clear, Complete and Correct requirements for the future product are the key to success in software development and creating such documents is the main goal of business analysis. Each step of the requirements gathering process must be done with the 3 C’s in mind.
Questions about gathering software requirements? Feel free to contact us!
