Personally, in small projects, the most common problems are miscommunication with the client (having different understanding on the terminologies and processes); clients confused with what they really want - giving the data gatherer incorrect data; spending too little time in collecting data (time constraint) - results to incomplete data to analyze

In some of the projects I have participated in, one of the main problems is that key stakeholders do not participate or dedicate very little time to participate in the requirements elicitation sessions, and delegate the task to other people who do not fully understand the business or do not have the decision-making power to define the requirements, which often results in missing requirements or incorrectly identified ones. Another difficulty I have often encountered is that the client themselves does not know what they want, and produces constant changes in the requirements, causing delays in the project.

Some common problems during requirements elicitation are: • Incomplete or ambiguous requirements: Requirements are not detailed or specific enough, leading to misunderstandings. • Conflicting requirements: Requirements conflict with each other, requiring negotiation and prioritization. • Incorrect assumptions: Unverified assumptions are made about user needs or technical capabilities. • Lack of stakeholder involvement: Key users and domain experts are not involved enough, leading to imprecise requirements. • Changing requirements: Requirements constantly change during the elicitation process, causing confusion and inefficiency. • Lack of shared understanding: Stakeholders have different interpretations of the requirements, which can cause problems later on.

Requirements elicitation(RE) is the process through which analysts determine the software requirements of stakeholders. Requirements elicitation is seldom well done, and an inaccurate or in-complete understanding of user requirements has led to the downfall of many software projects. The common problems with RE can be summarize in: •There are human aspects of RE that preclude simple communication between stakeholders•The language of humans is not always suitable for technological solution•Requirements change as the project proceeds •Clients will sometimes ask for requirements that the organization does not need•The client cannot say what the business needs•Some clients do not want to help you with the project•RE failed because it was not done properly •Symptoms that are not problems are often reported•RE is not deterministic.

I think one of the main problems is to define the limits of the software, which is often difficult and can lead to incomplete requirements. Stakeholders often do not have a complete understanding of their needs or do not master the problem; and during the development time of the system the needs of the user may change with better knowledge of the problem or organizational changes, and this may lead to a change in the requirements.

Para mí los problemas más comunes a la hora de obtener los requisitos es la falta de comunicación del analista con el cliente, otro problema es a la hora de documentar el requisito ya que si los requisitos no se documentan adecuadamente, pueden surgir problemas en la implementación y en la validación del software.

In reality, there may be several common problems that arise when obtaining requirements, such as ambiguity of requirements, poor communication with the client and the development team; changes in requirements, which may change over time or otherwise; as well as incomplete or inaccurate requirements, this being one of the most common problems, resulting in the product not satisfying the customer.

@

Algunos de los problemas comunes durante la educción de requisitos son:

Comunicación inadecuada entre los clientes, usuarios finales, desarrolladores, etc. Esto puede conducir a malentendidos, o falta de claridad en los requisitos. Otro de los problemas más comunes es que obtenemos requisitos vagos, ambiguos o incompletos, teniendo como consecuencia la implementación de funcionalidades incorrectas o la omisión de aspectos importantes. Cabe señalar además que, si los interesados no se involucran lo suficiente durante la obtención de requisitos, es probable que se pierda información importante y que el software no cumpla con las expectativas deseadas.

Los problemas más habituales en los requisitos son los defectos y las no aceptaciones

• Defecto: uno o más requisitos no son conformes al modelo de calidad de requisitos. Se pueden clasificar en:
• No conformidad: uno o más requisitos no cumplen las especificaciones descritas sobre el contenido, estructura, formato, etc. Los defectos de este tipo se detectan durante la verificación de la calidad de los requisitos del sistema y no suele ser necesario conocer el dominio del problema para detectarlos, ya que son de un carácter más sintáctico que semántico. Falta de información: uno o más requisitos necesitan más información para definir correctamente alguna característica del sistema. Los defectos de este tipo se detectan principalmente durante el análisis de requisitos del sistema. Conflicto: dos o más requisitos contienen información contradictoria entre sí.Los defectos de este tipo se detectan principalmente durante el análisis de requisitos del sistema
• No aceptación: uno o más requisitos no son aceptados por clientes y usuarios durante una sesión de validación de requisitos.

Los errores que más se cometen en la obtención de requisitos:

• hacer un levantamiento de información sin preparación previa, con información previa podemos preparar entrevistas y talleres más efectivos para entender la necesidad de nuestro cliente, generar más confianza sobre el desarrollo de nuestro trabajo y provechar mejor el tiempo.
• Suponer que se hace en dos horas y en una sola sesión.Es importante tener presente, que el tiempo que se deja de invertir en el entendimiento de la necesidad a solucionar, va a ser mucho más costoso más adelante.
• No explicar al cliente la importancia del levantamiento de requerimientos. El cliente debe entender la importancia de esta etapa, tener una postura de compromiso y colaboración para facilitar la información para el entendimiento y planteamiento de soluciones acordes a su necesidad. Definir una metodología sencilla y clara para todos los participantes, ayudará a que el proyecto se realice con menos contratiempos.
• Buscar todas las respuestas en un solo usuario.Es importante identificar quién será o quiénes serán los usuarios finales y funcionales
• No identificar claramente los requerimientos críticos del cliente
• Limitarse a proponer o tomar pedidos Tampoco se debe tener una postura pasiva para tomar nota de lo que el cliente quiere, como si se tratara de un pedido, es importante, luego de tener la información clara ponernos en el rol para analizar y realizar propuestas de valor.
• Tener una sola perspectiva Realizar el levantamiento de información desde una perspectiva, dificulta el entendimiento e impide el planteamiento de soluciones acertadas.
• No provocar Respuestas Es importante realizar preguntas adecuadas que generen respuestas abiertas y faciliten la dinámica de entendimiento de los requisitos.
• Hacerlo aburrido usar cuestionarios y entrevistas extensas hace que se torne aburrido la obtención de los requisitos.
• Creer que cualquier persona lo puede realizar Es importante el conocimiento técnico, pero también lo es contar con habilidades de comunicación, de análisis, empatía, e incluso de redacción. La labor de obtener los requisitos, no debe subestimarse, ni debe limitarse a un requisito más para el inicio de los proyectos. Esta fase debe tomarse en serio y debe realizarse de forma concienzuda.

During the requirements elicitation several problems can occur, it is important to identify and prevent them. I consider that the most common problems in this process are usually the following:

· The lack of communication of the project team with the customer that can be produced because the customer does not know how to explain what he wants, because the users have different points of view and express it differently or because they use their own terms that the project team does not understand them.

· Lack of communication can also be a problem within the project team, based on differences in knowledge and experience.

· When requirements are incomplete, not obvious, come from many sources, the language is ambiguous, or there is an unwieldy amount of requirements for the project, it tends to become a problem that generates misunderstandings.

· The pressure exerted by the customer on the project to get a system into production in the short term causes time constraints.

· Another problem is the change of requirements throughout the project life cycle because it causes delays.

In my experience, among the main causes that cause problems during the elicitations of software requirements, are the following:

- Adequate communication with the parties is not established and not understood from the perpective of each one.

- The most importan and compes requirements from the stakeholder side are not identified.

- Requirements are not adequately documented.

There are several common problems that can arise during software requirements elicitation.

In my personal experience, there are some common problems that can arise during requirements elicitation, which can lead to software defects. Some of the most common problems that i had encountered are:

Not explaining the importance of this process in software development to the client, which leads to rush to obtain requirements, resulting in incomplete or incorrect requirements.

Poor communication: Communication problems can arise during requirements elicitation, such as misinterpretation, language barriers, or differences in technical understanding, which can lead to ambiguous or contradictory requirements.

Lack of validation: It is important to validate the requirements to ensure that they are complete, accurate, and feasible. Without proper validation, requirements may not accurately reflect the needs of the user, leading to software defects.

Los errores más comunes que se presentan a la hora de realizar el levantamiento de la información son:

1-Hacer un levantamiento de información sin preparación previa. Con esta información podemos preparar entrevistas y talleres más efectivos para entender la necesidad de nuestro cliente, generar más confianza sobre el desarrollo de nuestro trabajo y aprovechar mejor el tiempo.

2-No explicar al cliente la importancia del levantamiento de requerimientos.El cliente debe entender la importancia de esta etapa, tener una postura de compromiso y colaboración para facilitar la información para el entendimiento y planteamiento de soluciones acordes a su necesidad.

3-No identificar claramente los requerimientos críticos del cliente. Nuestro trabajo debe estar orientado a identificar el enfoque crítico para el negocio, es decir, lo que es relevante para nuestro cliente desde la perspectiva de negocio y no tanto a identificar cuál es la complejidad técnica de lo que se vamos a realizar.

4-Creer que cualquier persona lo puede realizar.Es importante el conocimiento técnico, pero también lo es contar con habilidades de comunicación, de análisis, empatía, e incluso de redacción.

La labor de levantamiento de requerimientos, no debe subestimarse, ni debe limitarse a un requisito más para el inicio de los proyectos.

Ian Sommerville, a renowned author in the field of software engineering, identified some common problems that can arise during software requirements elicitation. These problems include:

Comprehension problems: Stakeholders may have difficulty explaining their needs or expectations, and team members may have difficulty understanding them.

Ambiguity problems: Vague or imprecise statements can lead to incorrect or incomplete interpretations of the requirements.

Variability problems: Requirements may change over time due to changes in stakeholders' needs or expectations, which can make it difficult to define concrete requirements.

Prioritization problems: Stakeholders may not agree on which requirements are most important or urgent, which can make planning and decision-making for the team difficult.

Validation problems: Defined requirements may not actually be what stakeholders need or expect, which can lead to the delivery of inadequate or insufficient software.

Durante la obtención de requisitos de software, pueden surgir varios problemas comunes que pueden dificultar el proceso y afectar la calidad del software resultante. Algunos de estos problemas incluyen:

• El equipo de desarrollo puede no tener suficiente conocimiento sobre el dominio del problema que están intentando resolver. Esto puede llevar a la omisión de requisitos importantes o la inclusión de requisitos irrelevantes.
• La comunicación entre los miembros del equipo y los interesados clave puede ser deficiente, lo que puede resultar en una comprensión incorrecta de los requisitos o en requisitos mal interpretados.
• Los requisitos pueden ser ambiguos o contradictorios, lo que puede resultar en una implementación incorrecta o en una solución de software que no cumple con las necesidades del cliente.
• Los cambios frecuentes en los requisitos pueden resultar en retrasos en el desarrollo y en la entrega tardía del software.
• La falta de participación de los interesados clave puede llevar a la omisión de requisitos importantes o a la inclusión de requisitos irrelevantes.
• La falta de documentación adecuada ya que puede dificultar la comprensión de los requisitos por parte del equipo de desarrollo y puede dar lugar a una implementación incorrecta de los requisitos.

Numerous problems can occur during software requirements elicitation, which can be grouped into 3 main categories: scope problems, comprehension problems, and volatility problems.

- Scope problems, where requirements may address too much or too little information:

- System boundaries are not well defined: if the system boundaries are not clearly defined, there can be confusion about which requirements should be included and which are outside the scope of the system. This can lead to the inclusion of unnecessary requirements.

- Unnecessary design information may be given: If the requirements focus too much on the design of the system, rather than focusing on the objectives and needs of the users, there may be unnecessary inclusion of detailed system design information. This can lead to unnecessarily detailed and complex requirements that make system implementation difficult.

- Problems of understanding, both within groups and between groups such as users and developers:

1. Users do not have a good understanding of their needs: They may have difficulty in clearly expressing their needs and objectives, which can lead to incomplete or ambiguous requirements.

2. Users do not have a good understanding of computer capabilities and limitations: Users may not be familiar with the capabilities and limitations of computer systems, which may lead to requirements that are not practical or feasible.

3. Analysts have poor knowledge of the problem domain: Analysts may have limited understanding of the problem domain, which may lead to requirements that do not address all user needs.

4. User and analyst speak different languages: Users and analysts may have different backgrounds and terminologies, which can lead to misunderstandings and incorrect requirements.

5. Easy to omit "obvious" information: Information that is considered "obvious" but is actually important to understanding the requirements may be omitted.

6. Conflicting views of different users: Users may have different views and objectives, which may lead to contradictory or conflicting requirements.

7. Requirements are often vague and impossible to test, e.g., "easy to use" and "robust" 8.

- Volatility issues, i.e., the changing nature of requirements.

1. Requirements evolve over time: user needs and objectives may change as the project progresses, which can lead to changes in requirements.

2. Changes in the project environment: Changes in the project environment, such as changes in government regulations or newly available technologies, may cause requirements to change.

3. Changes in stakeholders: such as the arrival of new users or the departure of analysts.

4. Lack of initial understanding: If requirements are not specified in sufficient detail at the outset, changes may be needed as user needs are better understood.

During software requirements elicitation, various issues can arise that make it difficult to accurately and completely define the project requirements. Among the most common problems are a lack of effective communication between stakeholders and the development team, difficulties in understanding customer requirements and end-user needs, frequent changes to requirements during the software development cycle, ambiguity in requirements definition that can lead to misinterpretations and inadequate solutions, a lack of experience or technical knowledge by the development team to address project-specific requirements, a lack of interest or commitment by stakeholders to provide detailed information about requirements, time and budget constraints that can affect the quality of requirements elicitation, inadequate documentation of requirements that makes verification and validation difficult, and inadequate testing of requirements to ensure that quality criteria are met. These problems can have a negative impact on the quality of the resulting software, and it is important to address them effectively to ensure project success

Software requirements elicitation is a critical activity in the software development process, and there are several common problems that can be encountered during this phase. Here are some of them: Lack of communication between the client's stakeholders and the project team. Lack of stakeholder involvement: Key users and domain experts are not sufficiently involved, which can lead to inaccurate requirements definition. Lack of shared understanding: Stakeholders have different interpretations of the requirements, which can cause problems later. Incorrect Assumptions: Unverified assumptions are made about the user's technical needs or capabilities. Conflicting Requirements – Requirements conflict with each other, requiring negotiation and prioritization. Poor requirements change management – Requirements are constantly changing during the procurement process, leading to confusion and inefficiency. Ambiguous or incomplete requirements: Requirements that are not clearly defined or can be interpreted in different ways, leading to misunderstandings and confusion among developers.

Para mi algunos de los problemas comunes de la educción de requisito son:

-fallas de comunicación dentro del equipo del proyecto

-problemas terminológicos incompletos u ocultos

-apoyo insuficiente por parte del líder del proyecto

-requisitos inconsistentes

-Falta trazabilidad

-Requisitos cambiantes.

Software requirements elicitation is a critical process in software development and can be challenging due to various issues that can arise during the process. Some of the common problems include lack of effective communication between the development team and stakeholders, lack of understanding of the requirements by the development team, lack of clarity in the requirements, lack of involvement of key stakeholders, difficulty in identifying all the necessary requirements, and lack of flexibility in the requirements elicitation process. These problems can lead to poor understanding of requirements, which in turn can result in software that does not meet the needs of the customer or end user, development delays and additional costs. It is important to address these problems proactively and use effective requirements elicitation techniques to ensure the success of the software project.

During software requirements elicitation, there are several common problems that software teams often encounter. For example, communication issues between the development team and stakeholders can lead to misunderstandings about what the requirements are and what is required to implement them. In addiction, the development team may not fully understand the business goals and objectives of the project, which can lead to requirements that are not aligned with the needs of the stakeholders.

Another problem is the lack of user involvement, when stakeholders are not involved in the requirements gathering process, they may not have adequate input into the features that are being developed, leading to a product that does not meet their needs. And if we add to this that as requirements are elicited, the scope of the project may expand beyond the initial goals, this can lead to missed deadlines, increased costs, and decreased quality. That's why it is important to develop correct documentation when developing software, which is another problem that can occur, as there can be conflicting requirements and these have to be well documented.

On the other hand, sometimes requested features and requirements cannot be implemented due to technical limitations, which can lead to frustration on both sides.

Overall, effective requirements elicitation is critical for software development to be successful. Recognizing and addressing these common problems during the requirements gathering process can help teams avoid misunderstandings, missed deadlines, and cost overruns.

Según la revista Gerencia, en su artículo: “Inspección de requerimientos para desarrollo de software”, la mayor cantidad de errores que posee un software o aplicación desarrollada, se inyectó en la etapa de requerimientos. Además, la interpretación errónea de los requerimientos genera productos que difieren de las expectativas de los clientes/usuarios.

Entre los problemas que se pueden presentar están:

En general, la educación de requisitos es un proceso complejo que puede presentar varios desafíos. Es importante abordar estos problemas de manera proactiva y utilizar técnicas efectivas de educción de requisitos para garantizar que los requisitos sean precisos, completos y relevantes.

During software requirements elicitation, there are several common problems that can arise, including:

1. Incomplete or unclear requirements: Often, stakeholders may have difficulty articulating their needs, resulting in incomplete or unclear requirements. This can lead to misunderstandings and misinterpretations, making it difficult to develop software that meets their needs.

2. Ambiguous requirements: Requirements that are ambiguous or open to interpretation can lead to confusion and disagreement among stakeholders, potentially delaying the software development process.

3. Vague requirements: Requirements that are too general or vague can make it difficult to determine whether the software has met the specified requirements.

4. Conflicting requirements: Stakeholders may have different or conflicting requirements, making it challenging to develop software that meets everyone's needs.

5. Requirements volatility: Requirements can change over time, especially in complex software development projects. This can result in additional work and delays if not managed properly.

6. Lack of stakeholder involvement: If key stakeholders are not involved in the requirements elicitation process, their needs may not be adequately addressed, potentially resulting in software that does not meet their needs.

7. Poor communication: Communication problems can arise between stakeholders and developers, leading to misunderstandings and a lack of clarity around requirements.

These problems can make the software requirements elicitation process challenging, but they can be mitigated by using appropriate techniques such as prototyping, use cases, and user stories, and by involving stakeholders throughout the development process.

Some common problems during Software Requirements Eduction

Lack of comunication: can happen at any stage of the process eduction of requirements. Frequently, stakeholders do not have a clear idea of ​​what they need or may have difficulties expressing them. Lack of communication and mutual understanding can lead to inaccurate or incomplete requirements definition and bad interpretation or implementation of these.

Changes in requirements: requirements may change as the project progresses, due to changes in stakeholder needs, discoveries in the development process, or changes in market conditions. If changes are not managed properly, they can have a significant impact on project planning and development, which can lead to delays and quality issues.

Lack of prioritization of requirements: not all requirements are essential, so it is important to prioritize them and focus on those that are critical to the success of the project. The absence or mismanagement of requirements priorities can lead to an inefficient allocation of resources and an ineffective approach to system implementation.

To mitigate these problems, it is important to use effective techniques such as interviews, surveys, use cases, and prototyping. Also, have clear and effective communication between stakeholders and requirements analysts, and work as a team to define and document requirements clearly and precisely.

Software requirements elicitation is a critical and complex task, and there can be several associated problems. The following are some of the most common problems in software requirements education:

1. Miscommunication: It is common for developers and end users to have difficulty communicating about software requirements. This may be due to lack of a common language, lack of understanding of user needs, or lack of time to meet and discuss requirements.

2. Constant changes in requirements: It is common for requirements to change over time, which can make it difficult to capture accurate and complete requirements at the beginning of the project. Changes in requirements can be caused by factors such as changes in the business environment, changes in user expectations, or changes in technology.

3. Ambiguity and lack of precision: It is important that requirements are clear and specific to avoid misunderstandings and confusion. Ambiguous and vague requirements can lead to the implementation of software that does not meet user expectations.

4. Lack of user involvement: End users often do not actively participate in the requirements elicitation process, which can lead to a lack of understanding of their needs and expectations. Lack of user involvement can also lead to lack of requirements validation and lack of software acceptance.

5. Lack of adequate documentation: It is important to document software requirements clearly and concisely so that they can be understood and validated by all stakeholders. Lack of adequate documentation can lead to loss of critical information and lack of tracking of changes in requirements.

6. Lack of validation and verification: It is important to validate and verify requirements to ensure that they are accurate, complete and consistent. Lack of validation and verification can lead to the implementation of software that does not meet the user's needs or that has errors and defects.

It is important to keep in mind that software requirements education is an ongoing process and must be managed effectively to ensure project success.

However, some common problems during software requirements elicitation are:

Ambiguity in requirements: Requirements may be poorly defined or unclear, leading to misunderstandings between stakeholders.

Incomplete requirements: Stakeholders may not provide all the necessary information, leading to missing or incomplete requirements.

Conflicting requirements: Different stakeholders may have conflicting requirements, making it difficult to determine the best solution.

Changing requirements: Requirements may change during the development process, leading to delays and additional costs.

Resistance to change: Stakeholders may resist changes to existing processes or systems, making it difficult to elicit new requirements.

Lack of domain knowledge: Stakeholders may not have sufficient knowledge of the domain, making it difficult to provide accurate requirements.

Communication barriers: Communication barriers such as language differences or cultural differences can make it difficult to elicit accurate requirements from stakeholders.

Unrealistic expectations: Stakeholders may have unrealistic expectations regarding the software's capabilities, leading to requirements that cannot be met within the project's constraints.

Scope creep: Stakeholders may continuously add new requirements during the development process, expanding the project's scope beyond its initial boundaries.

Lack of stakeholder involvement: Stakeholders may not be involved in the requirements elicitation process, leading to requirements that do not meet their needs.

Poorly defined acceptance criteria: Acceptance criteria may be poorly defined, making it difficult to determine when the software meets the stakeholders' requirements.

Lack of documentation: Requirements may not be properly documented, leading to confusion and misunderstandings during the development process.

Poorly defined priorities: Stakeholders may not prioritize requirements, making it difficult to determine which requirements should be addressed first.

Lack of feedback: Stakeholders may not provide feedback on requirements, making it difficult to determine if the requirements are accurate and complete.

Technical limitations: Technical limitations may prevent certain requirements from being implemented, leading to a need for alternative solutions.

Inadequate communication: Communication between stakeholders, developers, and project managers may be inadequate, leading to misunderstandings and misinterpretations of requirements.

Inconsistent requirements: Requirements may be inconsistent or contradictory, making it difficult to determine which requirements should take precedence.

Cultural differences: Stakeholders from different cultures may have different expectations and requirements, leading to misunderstandings and conflicts.

Budget constraints: Budget constraints may limit the resources available for developing the software, leading to compromises in meeting all requirements.

Time constraints: Time constraints may limit the amount of time available for developing the software, leading to compromises in meeting all requirements.

Scope creep: Additional requirements may be added during the development process, leading to scope creep and potentially delaying the project.

Lack of user involvement: Users may not be involved in the requirements gathering process, leading to a lack of understanding of their needs and potentially resulting in a product that does not meet their expectations.

Technology limitations: Certain technologies may not be available or feasible to use, limiting the ability to meet certain requirements.

Legal and regulatory requirements: Legal and regulatory requirements may need to be met, adding additional constraints and requirements to the project.

Stakeholder disagreements: Stakeholders may have different opinions and priorities, leading to disagreements on requirements and potentially delaying the project.

Insufficient resources: The project may not have enough resources, such as budget, staff, or time, to complete the requirements and deliver the product on time.

Communication breakdown: Poor communication among team members, stakeholders, or customers can lead to misunderstandings and delays in the project.

Poor project management: Ineffective project management practices, such as poor planning, monitoring, and control, can lead to missed deadlines, cost overruns, and quality issues.

Cultural differences: Cultural differences among team members or stakeholders can lead to misunderstandings and conflicts that can delay the project.

Market changes: Changes in the market or industry can require changes to the product requirements, potentially delaying the project.

External dependencies: The project may be dependent on external factors, such as suppliers or vendors, and delays in these dependencies can impact the project timeline.

Quality issues: Quality issues with the product or deliverables can lead to rework or delays in the project schedule.

Lack of training: Team members may not have the necessary skills or training to complete their tasks effectively, leading to delays and quality issues.

Scope ambiguity: Ambiguity in the project scope can lead to misunderstandings and disagreements on requirements, potentially delaying the project.

Unrealistic expectations: Unrealistic expectations from stakeholders or customers can lead to overpromising and underdelivering, causing delays and dissatisfaction.

Different problems may appear in the requirements elicitation process, the most common according to the Naming the Pain in Requirements Engineering (NaPiRE) project are:

· Weak Access to customer needs and / or bussiness information

· Inconsistent requirements

· Insuficients suport by customer

· Stakeholders whith difficulties in separating requirements from known solutions designs

· Communication flaws whithin the project team

· Time boxing/ not enough time in general

· Moving targets (changing goals, businnes processes and/ or requirements)

· Communication flaws between us and the customer

· Incomplete and / or hidden requirements

In my daily practice I can confirm the existence of incomplete or hidden requirements; as well as poor communication between team members as one of the most important.

During the eduction of requirements there are always problems, which do not impede the process but do delay it and sometimes a correct result is not achieved: - That there is no proper communication between the analysts and the client or staff that provides the information to be computerized. - That the project team does not have the necessary knowledge of the business, it is important that they clearly understand the business to be computerized. - An assumption that the requirements are self-evident, where the parties infer that the requirement is known to the other. -Ambiguity in the requirements, this occurs when the requirements may be vague or ambiguous, which can make their interpretation and definition difficult. -Lack of feedback and continuous improvement in the process of obtaining requirements. In my opinion, communication between the project team and the client is very important, and above all that the analysts obtain all the knowledge of the business in order to carry out an adequate eduction of requirements.

During software requirements elicitation, there are several common problems that can arise, including:

Ambiguity: Requirements may be written in a way that is not clear or specific enough, making it difficult to determine what is actually needed.

Incomplete requirements: It is not uncommon for requirements to be missing or incomplete, which can lead to misunderstandings and confusion.

Vague requirements: Requirements that are too general or vague can be difficult to interpret, leading to different interpretations and potential misunderstandings.

Conflicting requirements: Sometimes requirements can be in conflict with each other, making it difficult to determine which requirements should take precedence.

Scope creep: This occurs when the project scope expands beyond what was originally agreed upon, leading to additional requirements that were not part of the original plan.

Common problems in the eduction of requirements that can negatively impact the final quality of the software, they are the lack of effective communication, ambiguous or contradictory requirements, lack of prioritization of requirements, lack of validation of requirements, constant changes in requirements, Lack of adequate documentation. It is also important to have a well-defined requirements identification and documentation process and with the active participation of stakeholders in all stages of the project.

From my experience, some of the ones that generate problems during software requirements elicitation are:

- Communication problems between the parties involved

- Failure to consistently use uniform terminology.

- Use of vague or ambiguous terms and phrases.

- Absence of legal documentation that facilitates clarifying the activities of the organization proposed to be computerized.

- Lack of domain and competence of the person designated as

customer and/or domain expert.

Some problems may appear during the requirements elicitation process. Here I show some:

· Unclear or incomplete requirements: Requirements that are unclear or incomplete can lead to misunderstandings, confusion, and delays in the project. It's important to ensure that requirements are clearly defined, detailed, and unambiguous.

· Conflicting requirements: Conflicting requirements occur when different stakeholders have different priorities or requirements that are difficult to reconcile. This can lead to disagreements and delays in the project. To manage conflicting requirements, it's important to identify and prioritize stakeholder needs, and to work with stakeholders to find a solution that meets everyone's needs.

· Stakeholder availability: Requirements elicitation requires the active involvement of stakeholders, but stakeholders may not always be available or may have competing priorities. To manage stakeholder availability, it's important to establish clear communication channels and to schedule requirements elicitation sessions well in advance.

· Inappropriate or ineffective communication: Poor communication can lead to misunderstandings, incorrect assumptions, and incomplete requirements. It's important to establish clear communication channels and to use effective communication techniques, such as active listening and asking open-ended questions.

· Lack of stakeholder engagement: Stakeholders who are not actively engaged in the requirements elicitation process may not provide valuable input or may not fully understand the project's goals and requirements. It's important to involve all stakeholders in the requirements elicitation process and to ensure that their feedback is incorporated into the requirements.

· Insufficient domain knowledge: Requirements elicitation requires a deep understanding of the domain in which the software will be used. If the requirements elicitation team does not have sufficient domain knowledge, they may miss important requirements or misunderstand stakeholder needs. It's important to involve domain experts in the requirements elicitation process.

· Undefined project scope: A poorly defined project scope can lead to unclear requirements, missed deadlines, and budget overruns. It's important to establish a clear project scope that defines the goals, objectives, and boundaries of the project.

I consider that in general the problems in this process are mostly associated to the effective communication and understanding between the parties. This goes through the homogeneity in the terminology used, the expertise on the subject and the correct management of the information on the domain.

Software requirements are fundamental to the success of any software development project. During requirements elicitation, where requirements are captured from stakeholders, several problems can arise.

One of the most common problems is capturing incomplete, ambiguous, vague or conflicting requirements. This can lead to incomplete, confusing or inadequate software that fails to meet needs. It can also be difficult to deal with challenging stakeholders who are reluctant to provide requirements or have conflicting needs. Changing requirements are another challenge as they can impact design and development.

Other problems include “gold plating” or gathering too many unnecessary requirements that complicate the software without adding value. Communication issues such as lack of domain knowledge or effective communication skills can also make requirements elicitation difficult. Lack of prioritization of requirements into essential, important and nice-to-have can cause important requirements to be missed or deprioritized.

Finally, overscoping by trying to include too many requirements resulting in a product that is too complex, expensive or takes too long to build is another common problem. In summary, special attention must be paid to requirements quality, management and prioritization to avoid these problems during software requirements elicitation.

Poor requirements elicitation can have serious consequences on software projects like cost overruns, delayed delivery, low customer satisfaction and ultimately project failure. Focusing on eliciting high quality requirements and managing them effectively is key to software project success.

Luego de consultadas las diferentes bibliografías, se enuncian a continuación algunos de los principales problemas que conducen a una ingeniería de requisitos inadecuada, debido a dificultades en la educción u obtención de requisitos:

• No aplicar una técnica de educción apropiada. Para lograr mejores resultados se debe combinar varias de estas técnicas.
• Dificultad en el descubrimiento por parte de los ingenieros de requisitos de todas las fuentes potenciales de obtención de requisitos, teniendo en cuenta similitudes y conflictos.
• Ausencia o poca claridad de los requisitos.
• Errónea suposición por parte de los implicados de que cierta información no necesita ser establecida explícitamente.
• Existencia de problemas de comunicación debido a diferencias de conocimiento y experiencia.
• Presión sobre el proyecto, ejercida por parte del cliente, para conseguir a corto plazo un sistema en producción.
• Inexactitud en la especificación de los requisitos. Los requisitos de un sistema deben ser completos y consistentes, siendo estos, entre otros, atributos o criterios de calidad a cumplir para los requisitos.
• Los clientes con frecuencia no saben lo que realmente quieren de un sistema informático, lo que poseen es una idea general del funcionamiento del mismo. Presentan dificultad para especificar y detallar que es lo que quieren que haga el sistema. En ocasiones realizan solicitudes inalcanzables, las cuales están fuera del alcance del sistema, siendo estas no factibles.
• Incorrecta definición de las fronteras del sistema, lo que ocasiona problemas en el alcance a definir, debido a que no se tiene claridad en los objetivos generales del sistema.
• Cambios en la importancia de requisitos particulares o levantamiento de nuevos requisitos de nuevos interesados, debido a que no fueron consultados originalmente.
• Requisitos volátiles que cambian con el tiempo.
• No documentar los requisitos a medida que se vayan obteniendo, de forma tal que puedan usarse para ayudar al hallazgo de nuevos requisitos.
• No tener en cuenta los diferentes puntos de vista de los implicados sobre un problema, estos enfocan el problema de diferentes formas. Por lo general los diferentes puntos de vistas permiten el descubrimiento de nuevos requisitos.

Alguno de los principales problemas de la educción de requisito son:

-Apoyo vago insuficiente por parte del lider del equipo

-Posibles fallas de comunicacion dentro del equipo de desarrollo

-Caracter cambiante de los requisitos

-Problemas de terminologia asociados

-Incorrecta trazabilidad por parte de los mismo

-Inconcistencia en los requisitos

-Falta de priorizacion de los requisitos

Algunos de los problemas comunes de la educcion de requisitos

• Falta de comunicación entre stakeholders(implicados) del proyecto. Si la comunicación no es clara y efectiva, es posible que se malinterpreten los requisitos o se pierda información importante.
• Falta de claridad en los objetivos ya que los objetivos suelen ser una buena manera de explicar los requisitos a las partes interesadas y, una vez establecidos, se pueden utilizar para gestionar los conflictos entre las partes interesadas
• Problemas de alcance, problemas de comprensión y problemas de volatilidad.
• Falta de comprensión de las necesidades reales del usuario final.
• Definición de requisitos vagos, incompletos o contradictorios.
• Cambios frecuentes en los requisitos durante el ciclo de vida del proyecto. Si los requisitos cambian constantemente durante el proceso de educación, puede ser difícil mantener un consenso entre los interesados y obtener una lista final de requisitos.
• Falta de priorización adecuada de los requisitos.
• Falta de participación activa de los usuarios finales durante el proceso de definición de requisitos.
• Falta de seguimiento y control del cumplimiento de los requisitos durante todo el ciclo de vida del proyecto.
• Dependencia excesiva de herramientas automatizadas para la identificación y documentación de requisitos, sin la participación humana adecuada.
• Si el equipo encargado de la educación de requisitos no tiene la experiencia o las habilidades necesarias, es posible que no se recojan todos los requisitos relevantes.
• Precipitarse en construir directamente el sistema.
• La suposición de que los requisitos son evidentes por sí mismos.
• Si se llegan a considerar solo los requisitos de los usuarios finales o clientes se podrían pasar por alto requisitos críticos de otras partes implicadas.

• Conflicting requirements
• Unspoken or assumed requirements
• Difficulty in meeting with relevant stakeholders
• Stakeholder resistance to change
• Not enough time set for meeting with all stakeholders
• Issues in describing the system limit
• Issues in understanding among the different groups affected by the improvement of a given system
• Challenges in dealing with the explosive nature of requirements

Some problems are

--------------------------

hidden thinking

in mind demand not logical

unrealistic concept

Unclear description

----------------------

Main Problem

----------------------

Most of the time they cannot say clearly unless you give him/her something as like prototyping.

Common problems during software requirements elicitation include:

• Understanding user needs: Requirements are often poorly defined and may change over time, making it difficult for engineers to understand the true needs of the user.
• Managing stakeholders: There may be multiple stakeholders with different goals and priorities, making it difficult to satisfy everyone's requirements.
• Identifying conflicting requirements from stakeholders.
• Establishing structured and informative discussions with end-users.
• Conducting adequate market research and competitor analysis.
• Making incorrect assumptions: Unverified assumptions are made about user needs or technical capabilities.
• Lack of stakeholder participation: Key users and domain experts do not participate in requirements elicitation.
• Focusing on visual aspects rather than functional aspects.
• Lack of access to end-users.
• Undocumented processes.
• Conflicting requirements.
• Lack of documentation of existing processes.

Although we live in a digital world, sometimes people that are responsible for the demand clarification are not well prepared to do so, they lack the businesses analysis skills and basic technical skills that results in a in a poor Business Requirements Definiton and an equally poor Technical Requirement Specification.

In order to address this a baseline and standard or a guideline to draw this material may assist on improve its quality but it is not bulletproof.

The business requirements must be created and validated by the sponsors and stakeholders that will be affected by the solution, only we reach a common agreement from everyone involved we are one step ahead to have a solution aligned with the business needs.

Also to fail on oversee the market trends will incurr on changes on the projetct along the way, so it is important to consider it for long term.

To have capable people on this process is paramount to ensure that the product delivered will meet the stakeholders expectations, it isn`t easy to do it, but it is achievable.