, Requirements Gathering Process in Software Developement, Docuneedsph

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.


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 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.

Source link

Sharing is caring!

Related Posts

Leave a Reply