Learn Keys to Gathering Requirements

While they might not care about a new software system’s technical details or functional specifications…

Executives want to end up with a solution that supports their organization’s ability to hit target goals. Too often projects fail due to a poor job gathering requirements.

If requirements are not carefully defined from the outset, the software being developed will likely fail to meet the organization’s needs and cost more than necessary.

What is a Requirement?
A requirement is a document that defines what you are looking to achieve or create. It identifies what a software solution needs to do, what it should look like, and it explains its functionality and value. You can use different terminology to capture requirements. High-level requirements are sometimes referred to simply as “needs” or “goals.” Software developers often refer to requirements as “use cases,” “features,” or “functional requirements.”

What does it Take to Be Successful at Gathering Requirements?
Gathering requirements can be difficult. The process requires good listening skills and the ability to elicit details while keeping the big picture in mind. It helps to be able differentiate between what people say and what they actually mean.  Those skilled in requirement gathering can often improve the business processes simply by asking the right questions. For example, being able to determine which Key Metrics the end system should track can be critical in helping an organization meet its goals.

What Makes a Good Requirement?
A good requirement should be valuable and actionable; it should define a need as well as provide a pathway to a solution. Good requirements need to be concise and specific, and should answer the question, “What do we need?” Rather than, “How do we fulfill a need?” A stakeholder might request a feature that describes how the product will provide value in solving a problem. A solution developer might define a requirement based on how the final product should look or perform from a usability or UI (user interface) standpoint.

Does Everyone Know What We’re Building and Why?
Choosing the correct Business Intelligence tools is important, but getting collaboration and buy-in from different departments and stakeholders in the organization is even more critical. Simply investing in infrastructure and tools will not guarantee success. According to Zach and Chris Gemignani, success depends on data communication. In their book, Data Fluency, they guide readers to make sure their solutions:

  • Tell a compelling data story
  • Are easily understood
  • Drive decision-makers to the best outcomes using data

Team collaboration can help in planning good requirements that result in user-friendly solutions which answer key business questions for all users. Collaborative teams work hard to make sure everyone has a stake in projects and provide feedback. If different groups of people will add and/or use the data in the system differently, ensure that requirements are gathered from each group. If stakeholders feel “out of the loop,” they will be less likely to adopt the new systems. Success of a Digital Transformation depends on having a Data Fluent Culture in your organization.

Use Case in Requirement Gathering
Here is an example of some of the discovery questions we at CloudBase Services recently asked our client, Sullivan Solar Power, in gathering requirements for a project to improve their QuickBase app:

  • Will different groups of people add/use the data in the new part of the system differently? (If “yes,” gather requirements from each group)
  • What do you want the new part of the system to do?
  • How is that job currently done?  What’s working right now?  What’s not?
  • Does the data needed for the new part of the system exist?
    • Is it already in QuickBase?
    • If not, who will enter it into QuickBase?
      • What’s the simplest way for them to enter it into QuickBase?
      • How will the system check the data to make sure it’s correct
  • What information should the system create?
    • Who should see the new information?
    • When?
    • How?  Does the format matter?
  • Will the people who see the information (created by the new part of the system) easily understand it?
    • What judgments will they make based on the information?
    • What actions will the aforementioned people take based on the information?
    • Is the new information mission-critical? Confidential? Time-sensitive?
  • Once the new functionality is added to the system, what can be eliminated?
    • Can spreadsheets or emails be eliminated?
    • Can meeting prep and meetings be shortened?
  • What does success look like?
  • What did I miss?

This is one example of how to ask the right questions in the Requirements Gathering process. At CloudBase Services, we walk our clients through a thorough Requirement Gathering process. We partner with many providers including QuickBase, Salesforce, Tableau and Apttus X-Author to provide our clients with customized, flexible solution that meet their unique needs. Please reach out to our team at CloudBase Services if you have any questions or want feedback about best practices in gathering requirements for your project.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>