Requirements Gathering Questions: The Most Asked Questions About Requirements Gathering

This blog post will pose and answer questions for requirements gathering.

In the intricate landscape of software development, the art of requirements gathering stands as a pivotal process, one that hinges on asking the right questions. This blog post aims to delve deep into this realm, addressing a comprehensive array of questions for requirements gathering and shedding light on the nuanced art of elicitation.

We recognize that the process of gathering requirements is not merely about collecting data but about engaging in a dialogue that helps us elicit requirements effectively. To achieve this, we will explore a variety of requirements gathering interview questions. These questions are designed not just to gather information but to actively engage stakeholders, thereby uncovering the underlying needs and expectations that drive a project.

Furthermore, we will dive into elicitation questions, a key element in the requirements gathering process. These questions are crafted to probe deeper, revealing the hidden layers of requirements that are often overlooked but are critical for the success of any software project.

Throughout this exploration, we will also aim to define and demystify terminology related to requirements management. We understand that the language used in this field can sometimes be complex, and our goal is to make it accessible and understandable. This will help in navigating through all the alternative scenarios that might arise in requirements management, ensuring a comprehensive understanding for professionals at all levels.

Whether you are a seasoned project manager, a budding business analyst, or anyone involved in software development, this blog post is designed to equip you with the essential questions and knowledge needed to master the art of requirements gathering. By the end of this journey, you will have a richer understanding of how to elicit requirements effectively, ensuring that your projects are built on a foundation of clarity and precision.

When embarking on software development, one of the foundational steps is to effectively navigate through the maze of requirements gathering. This crucial phase involves not just posing general questions but identifying targeted ones that cut through to the core of high-level requirements. Such an approach is key to formulating better requirements that are both comprehensive and specific. This also helps reduce software development project failure.

At this juncture, the role of a requirements questionnaire becomes indispensable. It serves as a tool to systematically capture the essence of what the software aims to achieve, ensuring that the questions asked are not just general, but are also aligned with the broader project objectives. This involves a careful consideration of high-level requirements that guide the overall direction of the project.

In this context, the involvement of key stakeholders cannot be overstated. Their insights, expectations, and needs are instrumental in shaping the questions in the requirements questionnaire. By understanding their perspectives, one can ensure that the requirements gathered are not only in sync with the technical and functional aspects of the project but also resonate with the stakeholders’ vision and goals.

Furthermore, setting a clear project objective from the outset provides a compass for the business analysts requirements gathering process. It acts as a benchmark against which all requirements can be measured and evaluated, ensuring that they contribute meaningfully to the end goal of the project.

Lastly, the process of requirements gathering is not a one-off exercise but a continuous cycle of inquiry and refinement. Follow-up questions and ongoing engagements with stakeholders are vital to clarify, adjust, and enhance the requirements as the project evolves. This iterative process ensures that the requirements remain relevant, realistic, and aligned with the changing dynamics of the project environment.

Key Requirements Gathering Questions and Answers

What is requirements gathering?

Requirements gathering is the process of identifying and documenting the needs and expectations of stakeholders for a particular project or system. This process helps to ensure that the final product or solution meets the needs of all stakeholders and is aligned with the overall goals and objectives of the organisation. It involves a range of activities, such as conducting interviews and focus groups, analysing existing systems and processes, and creating user stories or functional requirements. The outcome of the requirements gathering process is a set of clear and well-defined requirements that can be used as the foundation for designing, building, and testing of the solution.

What are the two main types of project requirements?

Project requirements are typically divided into two groups:

• Business requirements: What the project should accomplish. These are also known as “functional requirements.”
• Technical requirements: How your project will meet organisational needs. These are also known as “nonfunctional requirements.”

What is a Requirements document?

What is required of the product is laid out in a requirements document. The product vision and the means by which it must be realised by the project’s conclusion are among the items it specifies. However, it makes no mention of how it will be supplied in detail. More emphasis should be placed on setting the product’s context, such as the necessity for the product or the issue it resolves. There are no specifics about how it will be implemented. Learn more in our other blog ‘How to Write a Software Requirements Document (SRD).’

What are entities in requirements gathering?

In the context of requirements gathering, entities refer to the objects, people, or concepts that the system being developed will interact with or represent. Examples of entities in a requirements document might include “customer,” “employee,” “product,” or “invoice.” Identifying and defining entities is an important step in understanding the scope of a project and determining the functional and non-functional requirements for the system.

What are the fields in an entity in requirements gathering?

In requirements gathering, fields are the specific characteristics or attributes of an entity that are relevant to the system being developed. Fields can also be called properties, data elements or columns. For example, in an entity called “customer,” fields might include “customer name,” “address,” “phone number,” and “email address.” In an entity called “product,” fields might include “product name,” “description,” “price,” and “quantity in stock.” Defining the fields for each entity helps to clarify the data that the system needs to collect, store, and manipulate in order to meet the requirements.

What are the actions for an entity in requirements gathering?

In requirements gathering, actions refer to the operations or functions which can be performed on an entity by the system being developed. Actions can also be called behaviours or methods. Examples of actions for an entity might include:

• Retrieving or displaying information about the entity (e.g. “View Customer Details”)
• Creating new instances of the entity (e.g. “Add new Product”)
• Updating or modifying existing instances of the entity (e.g. “Edit Customer Information”)
• Deleting instances of the entity (e.g. “Delete Product”)
• Performing calculations or other processing on the entity’s data (e.g. “Calculate total cost of all products in an Order”)

Defining the actions for each entity helps to clarify the functionality that the system needs to provide in order to meet the requirements.

What are usability requirements?

Usability requirements are a type of non-functional requirement which describe how user-friendly, efficient, and satisfying the system being developed should be for the end-users. These requirements are used to ensure that the system is easy to use, understand, and navigate. Usability requirements can include aspects such as:

• Ease of learning: New users should have little trouble picking up and using the system.
• Efficiency of use: The site should allow users to accomplish their tasks quickly and easily.
• Memorability: Users should be able to recall how to use the system even after not using it for a while, thus it should be constructed accordingly.
• Error recovery: When users make mistakes, the system product should give them the proper feedback and direction and should make it simple for them to correct their mistakes.
• Satisfaction: The system should be pleasant to use and should not cause frustration or dissatisfaction for the users.

The inclusion of usability requirements in the requirements gathering process is crucial to ensure that the end product is user-friendly and meets the needs and expectations of the users.

What are security requirements?

Security requirements are a type of non-functional requirement describing the measures which  need to be taken to protect the system and its data from unauthorised access, use, disclosure, disruption, modification, or destruction. These requirements are used to ensure the confidentiality, integrity, and availability of the system and its data. Security requirements can include aspects such as:

• Authentication: Before allowing access to users, the system should be able to confirm their identity.
• Authorisation: To guarantee that users can only access the resources they are authorised to access, the site should be able to enforce access controls.
• Data encryption: The product should be able to encrypt sensitive data to protect it from unauthorised access or disclosure.
• Data integrity: The system should be able to detect and prevent unauthorised changes to data.
• Access control: The site should be able to restrict access to certain resources or functionality based on user roles or other attributes.
• Auditing and logging: For the sake of security and compliance, the system should be able to monitor and record user actions.

The inclusion of security requirements in the requirements gathering process is crucial to ensure that the end product is secure and meets the needs and expectations of the users and stakeholders.

What are performance requirements?

Performance requirements are a type of non-functional requirement which describe the required performance characteristics of the system, such as response time, throughput, capacity, scalability, and availability. These requirements are used to ensure that the system meets the performance expectations of the users and stakeholders. Performance requirements can include aspects such as:

• Response time: The time it takes for the system to respond to a user’s request.
• Throughput: The number of transactions or requests the system can handle in a given period of time.
• Capacity: The maximum number of users or amount of data the system can support.
• Scalability: The ability of the system to handle an increase in load or workload.
• Availability: The percentage of time the system is operational and available to users.

The inclusion of performance requirements in the requirements gathering process is crucial to ensure the end product meets the performance expectations and can handle the expected load.

What are reliability requirements?

Reliability requirements are a type of non-functional requirement which describe the required level of dependability and consistency of the system, such as its ability to function correctly and without failure over time. These requirements are used to ensure that the system meets the reliability expectations of the users and stakeholders.

What are supportability requirements?

Supportability requirements are a type of non-functional requirement which describe the necessary level of support and maintenance the system needs in order to be used effectively and efficiently. These requirements are used to ensure that the system can be supported, maintained and upgraded over time.

What are legal and regulatory requirements?

Legal and regulatory requirements are a type of non-functional requirement which describe the necessary compliance with laws, regulations, standards, and policies the system must abide by. These requirements are used to ensure the system meets the legal and regulatory requirements of the country, industry or sector it will be used in. Legal and regulatory requirements can include aspects such as:

• Data Privacy: Compliance with regulations such as General Data Protection Regulation (GDPR) and Health Insurance Portability and Accountability Act (HIPAA) to protect sensitive information
• Accessibility: Compliance with accessibility standards such as Web Content Accessibility Guidelines (WCAG) to ensure the system can be used by people with disabilities.
• Payment card industry data security standards (PCI-DSS) for systems handling credit card transactions
• Health Information Portability and Accountability Act (HIPAA) compliance for systems handling medical information
• Compliance with industry standards such as ISO 27001 for information security management systems.

The inclusion of legal and regulatory requirements in the requirements gathering process is crucial to ensure the end product meets the legal and regulatory requirements and can be used legally and ethically in the country it will be used in.

What are system requirements?

System requirements are a type of non-functional requirement. This is how the system will run on different platforms. Sometimes referred to as web browser support requirements, these refer to the necessary level of support and compatibility a web application or website needs in order to be used effectively and efficiently across different web browsers. These requirements are used to ensure that the application or website can be accessed and used by a wide range of users, regardless of which web browser they are using.

Why would you use software for requirements gathering process?

Using software for requirements gathering can benefit the process by improving discovery of requirements, standardising the process and improving its quality, creating more accurate and clear documentation, and facilitating collaboration among stakeholders. Software can be more flexible in the workflow of requirements gathering and provide features beyond simple templates. It can also ensure that a consistent and structured process is followed, making the organisation more resilient to staff changes and resulting in better quality requirements gathering. By having a clear and accurate document outlining the requirements of a project, stakeholders and the development team can reduce the chance of missing vital requirements, improving estimation, and reducing project overruns and potential failure. Read more on this in our other blog, ‘Why You Should Use Software for the Requirements Gathering Process.’

Read our ‘Complete Guide to Requirements Gathering in 2023‘ for more!

List of Questions about Requirements Elicitation:

Questions on ‘How’ Requirements:

1. In what ways will stakeholders utilize this feature?
2. Does this feature represent a process? What are its steps? Alternatively, what inquiries should I make to understand these steps better?
3. What approaches could we consider to fulfill this business requirement?
4. In what alternative ways might we view this feature?
5. How can we determine when this task is accomplished? What are the indicators of its success?

Questions on ‘Where’ Requirements:

1. What is the starting point of this process?
2. From which location will users access this feature?
3. In what physical setting will users interact with this feature? For example, are they at home, in an office, or elsewhere?
4. In what locations will the outcomes be observable?

Questions on ‘When’ Requirements:

1. At what times will this feature be put into use?
2. By when is information regarding this feature required?
3. Under what circumstances might this feature malfunction?
4. When can we initiate the use of this feature?
5. What is the deadline for this feature’s completion?

Questions on ‘Who’ Requirements:

1. Who are the intended users of this feature?
2. Who will provide the necessary inputs for this feature?
3. Who will be the recipients of this feature’s outputs?
4. Who will be informed about the effects of using this feature?
5. Whom can I consult for additional insights about this feature?

Questions on ‘What’ Requirements:

1. What current knowledge do I have about this feature? Or, what assumptions am I making about it that need verification?
2. What functionalities does this feature require?
3. What outcome is expected from using this feature?
4. What are the constituent elements of this feature?
5. What steps should be taken next?
6. What prerequisites are there before starting?
7. What would happen if different scenarios occur? Consider various alternatives and question the appropriate responses.
8. What aspects need to be monitored?
9. What kind of device will the stakeholder use to interact with this feature?
10. What other questions should I be considering to uncover unexpected insights?

Questions on ‘Why’ Requirements:

1. Are there alternate methods to achieve this goal?
2. Does this feature align with the business’s needs and address the problem at hand?
3. Upon implementing this feature, what will be the resulting situation?
4. What is the most crucial aspect of this feature?

Integrating Key Stakeholders with Requirements Gathering Questions

Connecting the role of key stakeholders with the process of requirements gathering is vital for the successful development of a project. By aligning stakeholder engagement with targeted requirements gathering questions, you can ensure that the project meets both user needs and business objectives. Here’s how to integrate key stakeholders within the framework of requirements gathering questions:

1. Tailoring Questions to Stakeholder Roles:
   • For clients and end-users: Focus questions on user experience, functionality, and business needs. Example: “What functionalities do you consider essential for this feature?”
   • For project managers: Ask questions about project scope, timelines, and resource allocation. Example: “What is the deadline for this feature’s completion?”
   • For developers: Inquire about technical feasibility, integration with existing systems, and technical constraints. Example: “What technical challenges might we encounter in implementing this feature?”
2. Utilizing Stakeholder Feedback in Questionnaire Design:
   • Design the requirements gathering questionnaire based on preliminary feedback from stakeholders to ensure it covers all critical areas.
   • Include specific sections in the questionnaire that address the unique concerns and expectations of different stakeholder groups.
3. Engaging Stakeholders in the Question-Answer Process:
   • Involve stakeholders in the process of defining and refining requirements questions. This collaborative approach helps in capturing comprehensive and relevant information.
   • Conduct interactive sessions like workshops or interviews where stakeholders can directly respond to the questions, providing more nuanced and detailed insights.
4. Mapping Questions to Stakeholder Expectations:
   • Align the questions to the specific interests and priorities of the stakeholders. For example, questions about usability and user interface might be more relevant to end-users.
   • Ensure that the questions are designed to elicit information that directly contributes to meeting the project’s objectives, as defined by key stakeholders.
5. Feedback and Follow-Up with Stakeholders:
   • After gathering responses, engage stakeholders in a discussion to clarify, expand upon, or validate the information received.
   • Use follow-up questions to delve deeper into specific areas of interest or concern identified by stakeholders.
6. Using Questions to Manage Stakeholder Expectations:
   • Address potential conflicts or misunderstandings by including questions that clarify the scope and limitations of the project.
   • Use the requirements gathering process as an opportunity to set realistic expectations and align stakeholder visions for the project outcome.
7. Continual Engagement and Iterative Process:
   • Treat requirements gathering as an iterative process, where stakeholder input is continually sought and incorporated throughout the project lifecycle.
   • Regularly update stakeholders on how their feedback has been integrated into the project, maintaining their engagement and buy-in.

By effectively integrating key stakeholders into the requirements gathering questions, you not only ensure that the project is aligned with their needs and expectations but also enhance the overall quality and success of the project. This collaborative approach fosters a sense of ownership and satisfaction among all parties involved, leading to more effective and successful project outcomes.