7 Tips to Gather Better Requirements For Your Software Project

Old Topic, New View:

Yes, The same question was asked by one of our prospects yesterday, can you help me with few tips to gather better requirements for software development project. It is prevalent I face during my sales meetings with the prospect. The prospect who am speaking with is from a marketing background. He runs a very successful business for last 15 years. He has a software product idea to build. Because of his experience, he wants to understand more about the software business and the product development. He has more questions than the people I spoke earlier. The discussion was so long than the standard sales calls. At some point time, I had communicated to him saying that I will send some web references. I thought he could read and understand the concepts on his own. Went to google and did the query on”Tips to Gather Better Requirements For Software Project.”

The top results are as follows:

To my surprise, all these articles are ages old. The requirements for software project development is never ending phenomenon. But the references are not very recent. So decided to write about this topic on my own.

Essential point first:

” Requirements are the key for any project success.”

To start the discussion, In the current scenario, one should understand that on any steps to develop a software product:

 

  1. Technology may change
  2. Increased Knowledge levels of product users
  3. New Project execution models added in the tool kit every other day
  4. Skills of the team are different
  5. Tools to support development are abundant

Most of all, I can go on to add more such points. But whatever am going to add one thing is not going to change.

 

Yes, that is “Requirements” gathering.

 

There are right tools available to gather requirements now. But the human touch on the work is never changed. Well-documented requirements indicate the half built product.

 

Here are some helpful tips that can be used to gather requirements for a software product:-

1) Product owner Cooperation:

First of all, all great development experience starts with this one. The product owner should accept the fact on the importance of documenting the requirements. Time bound discussions which converted into black & white documents are the foundation for the success. The time spent on this requirements document will never go redundant. The mutual trust and cooperation are very critical.

 

2) Right Tool:

In addition, You have to choose the right tool to document the requirements. Tools should be easy to use for nontechnical stake holders too.

right tools

The tool should cover all the aspects of the requirements such as user stories, validation criteria, discussion board, etc. We use “Trello” to capture requirements.

 

3) Objective Based Meetings:

meetings
 

The meetings scheduled to understand the requirements should be objective based. If the discussion is boundless, there is a good chance of missing the peak.  Adequate exploration of the Grey areas is mandatory. There should not be any assumptions or conclusion less pending points.

 

4) Make it Visual:

The screen of the software application should capture visually by the business analyst. The visual representation helps a lot to come to a common understanding. The vision of the software product will get better with better visuals. This visual not necessarily have to be HTML.  A screen drawn on paper with the pencil could help too. We use Balsamiq to capture the screen mock-ups. Product stakeholders could see the moving parts of the application even before it’s developed in the Balsamiq mockups.

 

5) Technical Landscape:

When the idea is discussed to document the requirements it is always a good practice to avoid thinking about technological landscape. The intention of the requirement gathering is to document the business need first. There may be a ready-made technical solution available. “Technical” discussion needs to happen on the “Solutioning” phase. To think about technical bottlenecks in the requirements gathering phase might impact the documentation process.

 

6) Process Standards:

process standards
 

In requirements phase, the stake holders would define the “Process Standards” also.
Mutual Acceptance on the following are important:

  • Ways to track the user stories for development
  • How the screen mocks will be tracked against user stories
  • How to map test cases (Unit, System, Integration) against user stories
  • Ways to manage back logs in the development cycle
  • How to execute the verification & validation process

Again these are some basic questions to start the brainstorming on the process aspect. Ensure sufficient information regarding the process standards are discussed and accepted during the collection of Requirements For Software Project.

 

7) Nonfunctional requirements:

Requirements For Software Project is not only for the “Functional” aspect of the product. Consequently, there are many unknown “Non-Functional” things comes as part of the package.  A total number of application users, security, compatibility, etc. are few of the non-functional requirements we have to take care. These expectations are very critical. It might take more time to root out these non-functional requirements. But a proper questionnaire, educating the stakeholders on this topic, brainstorming, etc. would help to bring out the hidden expectations about the software product.

 

Note: Please refer the wiki on Non-functional requirement – Wikipedia to know about this topic entirely.

More on my experience:

Trust me; we had a great deal with 7 points in all the software products we develop in the near past.

 

We could see a clear pattern of the product success reasoning which caters towards these points. Every product development should take care of these 7 points, and these 7 points might not be a full list, but this an elementary list of points.  The process of developing a quality software product is an art. The requirements gathering is a critical part of the art which depends on the scientific ways of exploration & execution.

 

Would love to hear more about your software product development experience.  Please feel free to write about your experience or ask any question of the comments sections below.

 

We Agira team would love to help with your product development. We do have vibrant experience on software product development, therefore we could make your vision come true. If we could get an opportunity to help you and work with you, we will be delighted, please “Contact Us” immediately. Would love to hear from you !!!