Requirements: The word says it all. Software requirements are must haves. What is required for the applications to run properly? What is necessary in order to make the application successful? Do all the participating people understand what the client's expectations are? Or do we just assume we know what they want and proceed with that misunderstanding?
This tip provides insights into developing and implementing software requirements that are cohesive, on target and testable. It outlines a step-by-step requirements building process, looking at issues and practices in needs analysis, walkthroughs, reverse presentations and business analysis.
Analyzing clients' needs
Does the client really understand what they need? Do they have a clear understanding of what the final product should do? Not always. If developers don't get a clear understanding of clients' true need, creeping scope often results. To prevent scope creep, or constantly changing and expanding requirements, your team must unmask the client needs that are really necessary to make the project successful. The Need Analysis is a good way to do this.
The purpose of a Needs Analysis is to separate the "needs" from the "wants." The client may want more than what is available, have the money for, can be done within the time frame, etc. The business analyst is chartered with interfacing with the client and discussing the client's needs. This discussion will lead to the specification which summarizes the results of those discussions.
Often the specification is written in the client's language, so the client will sign off on the document. That's where a problem can begin, because how many other people in the organization speak the client's language? Usually, the answer is few, if any. Thus there must be a process in place to clarify for each participant exactly what their roles will be in the project. That is done during the Needs Analysis.and walkthroughs. The Needs Analy...
To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
sis and walkthroughs go hand in hand, since the requirements may change as a result of the walkthroughs.
Who should attend a Needs Analysis/walkthrough session?
The best practice is including anyone who plays a role in the software project's success: project managers, business analysts, programmers, testers, quality assurance (QA) managers, clients, and so on. This meeting of many minds will result in a specification, so no design, code or anything should be started until the Needs Analysis and the walk-through – discussed in the sidebar -- is finished.
Now, some people on a software team will complain, saying: "This takes time and we don't have the time." Sound familiar? Yet, what makes more sense: knowing what needs to be done before starting, or fixing things later because the development team didn't fully understand what the client meant in the first place?
Speaking programmers', testers' languages
Since the specification is written in the client's language, there's a need to convert the client's language into the language of the development group and the testing group. Programmers, for instance, must understand how make the application run on the system. Then there are testers, who have to understand how they will prove that the application meets the user's needs. Testers don't care what language the program was written in, only whether it meet the user's needs. They must know the user expectations and how users use the application.
Two entirely different needs, yet are they? The overall objective is always to deliver a product that is going to satisfy the client.
Once you've translated your specifications, do a walkthrough. If, after the first walkthrough, you find that people are still confused, it's time to draw a picture thus we need graphics.
Requirements walkthroughs a must
Many development subgroups do walkthroughs on design, code, etc. It's not as common, however, for them to walk through the specification or requirements. Yet, software projects can fail because of miscommunications about what a client meant versus what he said and these misunderstandings can lead to wrong assumptions. Since the specification is written in the client's language, a requirement walkthrough can help make that language clearly understood by the development group and the test group.
(For more details on how to handle this process, check out Tony Higgins' advice in making requirements walkthroughs effective and fun.)
Doing a reverse presentation
Once you've got your team on the same wavelength, do a reverse presentation. In a reverse presentation, the development team explains back to the client their understanding of what the client said in the development team's own words. They don't repeat what the client said, they paraphrase, i.e. put in their own words what they think the client said to ensure correct understanding.
In the reverse presentation, using graphics to complement the requirements text documentation is a good practice. Most people can understand graphics more easily than trying to interpret written language. Images reinforce the understanding between the two parties, ensuring that everyone is in sync.
Do the reverse presentation – with graphics -- prior to design. It could take many walkthroughs to reach consensus, and it is probable that we will need to change the specification to match the requirements. So, no design or coding should be done till the walkthroughs are completed. If any design had been done earlier, it may have to be redone to match the new understanding of the requirements. And this will increase the cost of the project.
After following these steps, everyone should be on the same page. The programmers know what the clients expect, and how they will use the application. The testers know enough to design and develop scripts and test cases to emulate the client's environment. The application should be designed, coded and tested in accordance with the user's expectations. Creeping scope should be eliminated or at least reduced. Rework should be kept to a minimum. Time and resources will be maximized.
Since all team members now have a better and clearer understanding of what the client needs, the process for making it happen will be easier to implement. These processes should be designed so they are repeatable and maintainable. The process will stay the same, only the needs may change. Templates can be designed and reused on subsequent projects. This should result in saving time and resources in the future. Everyone can benefit from lessons learned.
About the author: James F. York is president of the software development and IT consulting firm, C/J System Solutions Inc., based in Nashua, N.H.
