Struggling to understand why software that has been delivered doesn’t meet your team’s expectation?
Have you properly collected your team’s needs and defined their requirements in writing or did you just talk to the developer for a few minutes, he got a general idea of what you want, and then sat down at his computer and started to code?
Studies indicate that between 40% and 60% of all defects found in software projects can be traced back to errors made while gathering requirements.
You may want to say, “It’s too early and complicated to figure all these details out now, we need it now!”, “We don’t have any more time to spend, I’ve got to get this done!”. Before you do, take a moment to consider that the earlier you discover the problems, the less time is wasted and the fewer things are affected. The typical outcome of incomplete requirements is a huge gap between what the developers think they are supposed to build and what the users think they will get. This, of course, makes the software take longer to build/ get revised and drives the cost up.
If you are not a software house therefore you are not familiar with the Waterfall model, Agile Methodology and this kind of stuff, so this article will describe the steps for gathering software requirements from your business in order to be passed to your IT people. This is the baseline for an effective software development process.
Step #1 Identify business and software requirements
Your technical requirements must help the project achieve your business goals. When gathering requirements pay attention to understanding the project’s real challenge, the value of addressing it adequately and its causes.
Defining software requirements without having the business mandates they must meet clear in your mind will likely lead to creep and wasting time building the wrong thing.
Step #2 Engage a cross functional team of users
It is always important to engage a broad group of users. All the activities affected by the new software must be represented in the team so everybody interested can give you their points of view and you will have the global picture of the needs of the business. Exclude those who wish to influence the outcome of the project but who don’t have a stake in the success of the project
Step #3 Allocate sufficient time and effort to the requirements process
Spend as long as you possibly can and talk to as many people as possible. Talk to people in a wide range of roles, but ask them all the same questions. For the same point, gather different points of view both managers and staff employees; you will be surprised how much they know about their questions. If it can help you, use the 5 Whys technique to have a deep understanding of the requirements.
Step #4 Document everything about requirements arose
Initial documents on things such as technical specifications, sketches, notes, diagrams, user stories are a fundamental start for a software specification, which becomes an essential artefact for both software developers and users. All formal and informal, functional and non-functional requirements should be documented and made available for next phase processing. After every meeting, go through your notes and clean them up – then share them with the project team, including the stakeholders. This transparency helps make sure everyone’s on the same page.
Step #5 Validate and Prioritise your requirements
It’s easy for requirement gathering sessions to turn into “wish list” gathering sessions, where people tell you everything they want. The point isn’t to ignore that information but rather to clearly and transparently prioritize what you’re hearing and delineating what is in the scope of your initial launch and what is not. There are several techniques to review requirements that also identify wrong and overlooked requirements, which generally are the more important content concerns that typical form-oriented reviews usually miss.
Prioritise and arrange the requirements in order of importance, urgency and convenience. The technique MoSCoW (Must – Should – Could – Won’t haves) can be very helpful for this or scorecard can help as well.
Step #6. Never Neglect Details In Software Development
Many details pertaining to your product may seem generic and obvious, but never trick yourself into it. Write all of them down in a structured way. Don’t rely on vague assumptions. “Users will need to upload documents” is not enough. “How many steps will it take? What fields do they need to enter? What are the formats of files? What are the maximum dimensions of a file? Will there be an overall limit of space? Who can access the files? …”. Within the answers lies the feature.
Step #7. Remember that you’ll miss something anyway
You won’t be able to capture everything once and for all. Things will change. You will think of things later that you forgot to ask. Team members will think of things that they forgot to mention. Priorities will shift. Planning ahead is essential, but the point is being ready to fill in the gaps quickly and effectively. Giving yourself time to actively manage requirements throughout the entire project can help you stop scope creep before it starts, and make sure that your team is always focusing on the right set of priorities that match actual requirements.
There’s obviously a lot more that can be said about requirements gathering, but hopefully this list has given you some helpful tools to manage this process successfully, so as to get what your team really needs.
