What are some strategies for identifying functional requirements that may not be immediately obvious?

To unveil implicit requirements: Conduct workshops engaging stakeholders for diverse insights. Create user stories and prototypes to visualize needs. Analyze competitors for unmet user needs. Encourage brainstorming for varied viewpoints. Gather continuous user feedback for evolving needs. Assess existing systems against desired outcomes. Engage users via interviews and surveys. Identify risks to anticipate mitigating requirements. Utilize change control boards for hidden needs.

Studying the Business Requirements Document would be a good starting point. It's pretty useless talking with a non-technical person about functionality. They don't care HOW an invoice comes out of the System, they care about THAT it comes out.

Two tools that have been highly effective for me are: - Day in the life of the user/stakeholder: if you can map out everything your user gets done in a day (all activities, whether related to your software or not), you will understand how your product/solution will fit in their day and can design POWERFUL systems. - Jobs to be Done Framework: When you buy a product, you essentially ‘hire’ it to get a job done. If it does the job well, you hire that same product again when confronted with the same job. And if the product does a crummy job, you ‘fire’ it and look around for an alternative to hire to solve the problem. Map the jobs to be done, and do them well, and you will win!

The technique should be chosen by understanding the Person(s) with whom we are eliciting requirements. Ex: If a customer if very strong technically and is well aware of the product, He generally presents a solution and asks as Product enhancement. It is then needed to put appropriate question in 1:1 meeting to really understand what problem He wants to be solved

La utilización de múltiples técnicas de elicitación para descubrir requisitos funcionales es una estrategia sólida y efectiva en el proceso de desarrollo de software o sistemas. Cada técnica ofrece una perspectiva única, permitiendo recopilar información variada y detallada sobre las necesidades de los usuarios y el sistema. La combinación y comparación de datos provenientes de distintas fuentes ayudará a obtener una visión más completa y precisa de los requisitos, además de identificar posibles inconsistencias o lagunas. Esta práctica es fundamental para mitigar suposiciones y conflictos, asegurando así que los requisitos funcionales estén bien definidos y alineados con las expectativas de los usuarios y las necesidades del proyecto.

True open ended questions will be very helpful when Customer is not able to communicate or holding to himself. Probing questions help to dig deeper and understand the motivation.

In my role, open-ended questions are vital for understanding users deeply, unveiling nuanced preferences often overlooked. For instance, exploring aspirations and their alignment with long-term goals provides valuable insights. Probing questions act as a magnifying glass, delving into motivations and details, revealing hidden requirements. Addressing challenges in the current process and understanding their vision adds depth. Exploring impacts on team dynamics and uncovering latent concerns refines understanding. This approach unravels unspoken needs, enhancing the user experience. Fostering dialogue beyond surface discussions creates a comprehensive foundation for a solution meeting explicit and subtle requirements.

Hacer preguntas abiertas y de sondeo es una estrategia efectiva para descubrir requisitos funcionales ocultos o implícitos. Las preguntas abiertas permiten a los usuarios expresar sus necesidades libremente, lo que brinda una visión más amplia y detallada de lo que realmente desean. Esta técnica fomenta la comprensión completa de los requisitos, asegurando que se capturen tanto las necesidades explícitas como las implícitas de los usuarios y partes interesadas.

Proper understanding of the functionality is essential in doing the work more effectively. Don't feel bad for asking questions, validation and verification are crucial in maintaining the quality standards of the project.

Another tool that comes very handy to verify and validate requirements are low cost prototypes like wire frames, mainly for user experience related requirements

Certainly! Scenarios and use cases are like stories that show how people will use a system. They help us understand what users need and how the system should work. By creating these stories, we can spot problems early on and make sure the system fits people's needs. Additionally, using relatable examples helps developers see the requirements more realistically.

Use cases and scenarios are definitely powerful tools to capture requirements in entirety. By analysing and identifying all possible use cases we can capture both nominal and all exceptions including how to handle those exceptions. Also useful in understanding and capturing non functional requirements

Identifying the stakeholders and listing the various usecases is very essential in product development. And usecases shouldn't be limited to end user specific, but should be looked at from the perspective of the complete product lifecycle. It should also consider the target markets.

scenarios and use cases are the way to go. It is also important to consider risk analysis such as needs assessment, business impact analysis and root cause analysis. create a model to estimate outcomes, probabilities and financial projections. create different scenarios for the studied risks. Sometimes the plan is to not do anything that makes financial sense and just live with the risks.

Involucrar a usuarios y partes interesadas durante todo el proceso de desarrollo es esencial. Su participación garantiza que sus necesidades se reflejen en el sistema final, generando aceptación y satisfacción. Además, permite adaptarse a cambios y gestionar nuevos requisitos de manera efectiva, mejorando la relación con los involucrados y el producto final.

Involving end-users and stakeholders et alia for eliciting functional requirements is of cardinal significance in order to define comprehensive requirements of the system. Majority of failures and/or roadblocks in system implementation are attributed to the gaps in functional requirements.

While defining functional requirements, many a times, subliminal and intrinsic requirements pertaining to functions performed are ignored to be catered for. This is increasingly happening in case of application systems using AI capabilities. This happens more in case of functional requirements pertaining to UI where UI/UX design is to be capable of intuitive responses.

To uncover hidden functional requirements, I encourage my team to work backwards: imagine a way of developing from the desirable outcome to the current stage. I found that with this technique, many of the hidden rocks could be easily found and dealt with. Additionally, we don't forget to conduct risk analysis to identify potential challenges and discover functionalities that address them. These imaginative strategies ensure a comprehensive understanding of requirements beyond conventional approaches.