Top 5 Practices of Requirements Gathering for Software Development

Let’s Get Started with Requirements Gathering

If there’s one thing we harp on over and over here at Endertech, it’s the importance of a thorough planning and architecture phase. This phase focuses on documenting the precise specifications of your business or project (your vision), along with the potential plan for how the project might be built (our technical expertise). This is when we move from a bird’s-eye view of what you might want to build and get into the nitty gritty of exactly what you want to build.

We’ve written on best tips to successful software development from a company’s point-of-view, but this article will focus primarily on how to document all the details of your vision, or what we call Requirements Gathering. You want to go from A to B, this is how we pave the road.

First, Listen

Every project has some underlying primary goal, a pain that needs to be solved. Startups will solve a pain for some industry, existing businesses might solve a pain for their own operations… whatever this pain is, it acts as the foundational guide to push the stakeholders forward, it’s the sole purpose of bringing a project to fruition. Statements like “I wish…”, “if only…”, “this already exists, but it really needs to do XYZ”. Our job is to listen to you tell your story and listen for those pain points.

Aside from listening for a pain point, we also have to learn how existing businesses operate, sometimes it’s a multi-decade-old businesses and we need to both fully understand it and also envision how it can operate *better* in a very short period of time. There is always a list of things that could be better, otherwise you wouldn’t be here. Sometimes it’s an extremely long list, and that’s OK. During requirements gathering we will ask a lot of questions, and for us this first step involves more listening than talking.

Documentation

You know the ins and outs of your business and can talk about those details “til the cows come home,” but you didn’t just come here to talk… and we didn’t just come here to listen. As we’re listening, we’re diligently taking notes and documenting everything we hear. As we discuss the system as it unfolds we may also need to create visualizations to help come to mutual understandings of new ideas.

The notes we take eventually go into our project management software as discrete tasks that can be assigned to a developer. The most important part, however, is focusing on distilling the information into organized, actionable, and prioritized chunks.

We do this by breaking down the project into smaller features we call “epics”, then these features are broken down even further into individual tasks called “stories”. Stories and epics can be prioritized independently.

We also prioritize using project versions:

• Version 1: aka “The must haves” — project must have in order to go live
• Version 1.5: aka “Lets focus on it after launch”
• Version 2+: “Nice to haves”, future visions, etc.

If your business or system already exists, we may also take a comprehensive archive of screenshots of all the pages and features. It’s important to keep this photo archive organized in a way that future developers might come in and get an experience of the project without having the same thorough discussion about it.

Visualizations

Visualizations are a kind of documentation, less about us creating discrete tasks, and more about explaining new ideas. Perhaps a wireframe on how a page might function, or a workflow diagram to outline a complex workflow of your business that you deal with every day but have never had to articulate out loud in this way.

In that sense, we are both discovering the project together and coming to a mutual understanding of what it might become.

Time Management

Full disclosure: despite the importance of planning meetings and the creativity they inspire, they can also be long and tedious. It tasks you with detailing the ins-and-outs of your business workflows, things you might not be used to articulating on that level of detail. At the same time, we are presenting solutions from a technical perspective, which may seem abstract or complicated. Not everyone on your team is technically minded, nor do they need to be… remember, we’re the computer geeks, so you don’t have to be.

Having said that, it’s crucial to stay sensitive and aware of how people are doing during the meetings. Are people losing focus, or having trouble after a certain amount of time? Maybe schedule the meetings to be shorter, or plan to take breaks at specific points in time. It’s also extremely helpful to ensure that we bring in the right team members at the right times. A requirements gathering plan should help keep people focused and efficient.

Finalizing Costs and Features

So we’ve talked a lot about… talking. What’s next?

The first main outcome of the planning phase is, of course, the plan. Again, this acts as the blueprint for your project build, the most of which is already complete! By documenting everything as we go, we have done most of the work. If additional visualizations are part of your project, like wireframes or mockups those can also be completed.

The second main outcome of the planning phase is an estimate. Our team goes off to digest your project, including other team members that will be involved in your build. If there are bigger architectural questions that need answering, this is where a systems architect will come in to help imagine what the solution will be and articulate those “behind the scenes” details. With all details articulated, we produce our time estimates for each individual technical task using a scale that represents the relative complexity and time needed to complete that task. The estimates we create are based on our years of development experience, and the relative scale we use helps to ensure that overall project estimates are accurate.

These two items closeout the requirements gathering process but the estimate we provide at the end of this will act like a menu of features and their associated costs. You, as the client, will choose from this menu to define the last set of features that fit your needs and constraints. We can both have confidence in this menu and its estimates because we created and clarified it as a collaboration.

The Final Step, Getting Started

This isn’t really an official step but to our clients, it’s the most exciting. In summary, our requirements gathering process sets you and your development team up perfectly to transition right into the development phase.

Here’s why:

• Everyone’s already plugged in and thinking about the project.
• We have an actionable list of to-dos that are detailed and prioritized.
• You know what to expect in terms of timeline, budget, and features.
• We’ve developed rapport across the teams and a routine of meeting about the project that we can continue as we begin development.

With all this complete, we set up Sprint 1, get the team started, and schedule the first development review meeting with you.

From there, we rinse and repeat in an Agile Process… but that’s for another article!

By - Marc Nimoy, Senior Project Manager, Senior Developer