Requirements are an essential part of any software project and the foundation on which all projects should be built. The gathering of and compiling of requirements for a software project is very much a partnership between the user of the software and the developer. Obviously, the customer or software user needs to communicate to the developer what they need, but at the same time the developer needs to be able to anticipate needs and ask the right questions during the requirements gathering phase of a project.
I have been doing custom software development, meaning working with the end-user or customer directly to develop something to meet their needs, for about 20 years. I started working for the QA team of a software group, providing automation for testing of our main project. I then moved on to the R&D department once gain providing automation for building new systems quickly in a hosted environment. The software team I am part of now does development projects for our customers to specifically meet their needs and improve their process and performance, mainly through integration and enhancement of Microsoft Dynamics. In all these different companies and positions, whether working with end-users inside the same organization or customers outside the organization, having a good foundation and spending the time and effort to create valid and accurate requirements has been a hurdle, but a necessity for a successful project.
[emaillocker]
Some points I have realized or read over the years for good requirements gathering follow below:
-
Do not make assumptions as to the user customer’s needs, ask them.
-
Involve the end-users as soon as possible, get in touch with the actual people that will be using the software on a daily basis, they are the ones that truly understand what Is needed.
-
Scope creep is a major issue in most projects, especially custom development. A clear and defined scope is going to save a lot of headaches for all involved in the long run.
-
A great way to show a customer what you envision is with a prototype.
-
A well-written, clear and easy to follow documentation of the requirements is essential and before they sign off, go over it with the customer
-
It is important to understand the environment in which the software will run
Now first and foremost be sure that as we are all human, these ideal points will not always be possible to accomplish. Requirements gathering is not “sexy” and many times it is something that the customer does not want to pay for. This is why it needs to be understood and stressed how important this step is.
The stronger the foundation, and understanding of the project, the smoother it will go when development beings and you move on to the Testing and Support phases of the project. There will be times when getting the perfect set of requirements is not possible, but the better the requirements and understanding of the requirements by both the customer and developer the more solid the software will be.
The requirements document will be the jumping-off point for your design, user documentation, and internal documentation. It will in fact trickle down to all aspects of the project at some point.
Some techniques for gather requirements include
One-on-one Interviews
Sit down with the client and ask them what they need. Asking open-ended questions and getting the client talking about their hopes for the project is a good way to understand their needs.
Group Interviews
Similar to the one-on-one, but with a group of people, the same types of questions are asked, but with more of the users in the room, they may pick up on other’s statements and expand or correct them. This can be helpful, but too many cooks spoil the broth and these meetings can stray from the goal.
Questionnaires
Providing questionnaires to the customer to fill out can be a good starting point or supplemental approach to interviewing.
Use Cases
A use case if a story about how a certain process in the software should work, they may be easier for users to communicate clearly.
There are many more techniques and methods of gathering good requirements the above are only a few. There are many online resources for requirements gathering and development methodologies in general.
I can’t stress enough how having a strong requirements process and documentation in place will ensure that your software projects are smoother and of better quality. Meeting the needs and wants of the customer is the goal of any custom software and learning what those needs and wants is at the heart of requirements gathering. I have worked on many projects over the years and I can think back to each that had a well-defined set for requirements and know that those projects were the least stressful and delivered the best possible outcome for the customer.
WILL STAFFORD | .Net Business Solutions Team Leader
Will is responsible for the creation and maintenance of software customizations, reports and applications. He works on the entire development life cycle, gathering requirements, designing, coding, testing and providing support for applications. Will handles custom applications and the KTL suite of products. He has worked in the GP channel for over 15 years on integration and customization to Microsoft Dynamics. Will has extensive knowledge of Visual Basic, Visual Basic for Applications, MS SQL Server T-SQL, Crystal Reports and SQL Reporting Services. Will also works with the Microsoft .Net framework, including WPF, Web Services, Desktop Applications and Web Application development.
[/emaillocker]
