How do you deal with ambiguous or incomplete functional requirements?

Have discussions with stakeholders to clarify expectations through interviews or workshops. Use user stories to focus on desired outcomes and employ prototyping or wireframes for visual feedback. Adopt an iterative approach, refining requirements as the project progresses, and regularly check in with stakeholders to adjust priorities and address ambiguities.

Below points need to be considered: Elucidate the problem from the customer's perspective. Mention clearly which exact pain-point of the customer is the problem trying to solve. It needs to mention the end goal the user of the product is trying to achieve and the steps they need to perform to achieve the same. More generic requirements can be created as top level requirements, which can be further broken down into smaller requirements (or user stories). Requirements should be strictly reviewed by all the stakeholders involved. The problem statement should strictly avoid any design elements (like API details, DB query details, software modules etc) from creeping into it.

Todo lo que han mencionado es importante y ademas esto: 1. Redacción Clara y Precisa: Redacta los requisitos de manera clara y precisa, evitando ambigüedades. Utiliza lenguaje específico y concreto. 2. Plantillas de Requisitos: Utiliza plantillas estándar para documentar los requisitos, asegurando que todos los elementos necesarios (por ejemplo, descripción, criterios de aceptación, prioridad) estén cubiertos. 3. Criterios de Aceptación: Define criterios de aceptación claros y medibles para cada requisito, especificando cómo se evaluará si el requisito ha sido cumplido.

Una manera de obtener requerimientos claros es alinear la determinación de estos con los objetivos de la organización en la cual se está planteando el desarrollo de un sistema software que pretenda resolver un determinado problema. Los objetivos, misión , visión y otros elementos de alto nivel dentro de la organización permiten orientar los esfuerzos de los involucrados en el desarrollo del sistema requerido.

Tener un método determinado para identificar los objetivos prioritarios y establecer los mecanismos para determinar la prioridad de los requisitos que van a ser atendidos en el desarrollo del proyecto contribuye al desarrollo óptimo y en un periodo de tiempo aceptable.

Es muy importante considerar el uso de modelos de diagrama estandarizados como el UML (Lenguaje de Modelado Unificado), con la finalidad de tener un estándar común que permita apreciar los requisitos de manera intuitiva y que aumente el nivel de entendimiento entre los involucrados en el desarrollo, independientemente del nivel de conocimientos técnicos que tengan estos.

Using a common requirement document template across the organization helps to bring uniformity in capturing requirements. It also helps the document author to think through additional points related to the requirement and capture it. The requirement document template itself should be re-assessed periodically to identify gaps in it based on the feedback received from previous requirement implementations.

An organization can use one tool for Requirement Management which can help the Reuse of the requirements and also maintain a requirement Standard Document/Check List which will help to Eliminate the Errors.

Se deben usar los estándares existentes para la elisión de requerimientos, en primer lugar para determinar de manera adecuada y clara los requisitos y por otro lado para que permita la trazabilidad de estos requisitos a lo largo del desarrollo del sistema software, esto con la finalidad de asegurar la calidad del mismo.

A good communication between the Requirement stakeholders can help to Eliminate many issues in the Initial stage of the project.

While efficient communication is required to get the job done, it is equally important to direct inquires to those who have domain expertise. When relating to business processes, rather than requesting further elaboration from the IT team, ask for a meeting with a business analyst. When internal legal policies are concerned, involve the legal team. And, such. This may cost time during the requirement gathering process; however, it saves tremendous time and expenses during the implementation phase. Getting requirements wrong can be extremely expensive, as it can lead to financial costs, progress disruption, and stakeholder dissatisfaction.

When faced with ambiguous requirements: 1. Clarify the problem with stakeholders. 2. Prioritize critical aspects to address first. 3. Use visual aids like diagrams. 4. Follow industry standards. 5. Embrace feedback and be open to change. 6. Collaborate closely with stakeholders for clarity.