Software Engineering | Challenges in eliciting requirements

Eliciting requirements is one of the most challenging aspects of software engineering. Some common challenges include:

1. Understanding the user’s needs: Requirements are often poorly defined and may change over time, making it difficult for engineers to understand the user’s true needs.
2. Managing stakeholders: There may be multiple stakeholders with different goals and priorities, making it difficult to satisfy everyone’s requirements.
3. Identifying and mitigating risks: Engineers must identify and mitigate potential risks associated with the requirements, such as security vulnerabilities or scalability issues.
4. Handling ambiguity: Requirements may be ambiguous, inconsistent, or incomplete, making it difficult for engineers to understand what the system should do.
5. Keeping up with changing technology: Requirements must be aligned with the latest technology trends and innovations, which can be difficult to predict and keep up with.
6. Maintaining a balance between feasibility, cost and time: Engineers need to balance the feasibility of implementing a requirement, the cost of implementation, and the time required to implement it.
7. Maintaining traceability: Engineers need to maintain traceability of requirements throughout the development process to ensure that all requirements are met and any changes are tracked.

Eliciting requirements is the first step of the Requirement Engineering process. It helps the analyst to gain knowledge about the problem domain which in turn is used to produce a formal specification of the software. There are a number of issues and challenges encountered during this process. 

Prerequisite – Requirements Elicitation 

Some of them are as follows: 

1. Understanding large and complex system requirements is difficult: The word ‘large’ represents 2 aspects: 
   • (i) Large constraints in terms of security, etc. due to a large number of users.
   • (ii) a Large number of functions to be implemented.
2. Undefined system boundaries: There might be no defined set of implementation requirements. The customer may go on to include several unrelated and unnecessary functions besides the important ones, resulting in an extremely large implementation cost that may exceed the decided budget.  
3. Customers/Stakeholders are not clear about their needs: Sometimes, the customers themselves may be unsure about the exhaustive list of functionalities they wish to see in the software. This might happen when they have a very basic idea about their needs but haven’t planned much about the implementation part. 
4. Conflicting requirements are there: There is a possibility that two different stakeholders of the project express demands which contradict each other’s implementation. Also, a single stakeholder might also sometimes express two incompatible requirements.  
5. Changing requirements is another issue: In the case of successive interviews or reviews from the customer, there is a possibility that the customer expresses a change in the initial set of specified requirements. While it is easy to accommodate some of the requirements, it is often difficult to deal with such changing requirements. 
    
6.  Partitioning the system suitably to reduce complexity: The projects can sometimes be broken down into small modules or functionalities which are then handled by separate teams. Often, more complex and large projects require more partitioning. It needs to be ensured that the partitions are non-overlapping and independent of each other. 
7. Validating and Tracing requirements: Cross-checking the listed requirements before starting the implementation part is very important. Also, there should be forward as well as backward traceability. For eg, all the entity names should be the same everywhere, i.e., there shouldn’t be a case where ‘STUDENT’ and ‘STUDENTS’ are used at separate places to refer to the same entity. 
8. Identifying critical requirements: Identifying the set of requirements that have to be implemented at any cost is very important. The requirements should be prioritized so that crucial ones can be implemented first with the highest priority. 
9. Resolving the “to be determined” part of the requirements: The TBD set of requirements include those requirements which are yet to be resolved in the future. The number of such requirements should be kept as low as possible. 
10. Proper documentation, proper meeting time, and budget constraints – 
    Ensuring proper documentation is an inherent challenge, especially in the case of changing requirements. The time and budget constraints too need to be handled carefully and systematically.

Solutions to Overcome Challenges in Eliciting Requirements:

1. Maintaining proper documentation.
2. Trying to understand from a stakeholder’s perspective.
3. Establishing proper communication with stakeholders.
4. Identifying conflicting requirements from the stakeholder side.
5. Establishing structured and insightful discussions with end-users.
6. Performing proper market research and competitor analysis.

Advantages or Disadvantages:

Advantages of eliciting requirements in software engineering include:

1. Improved communication: Eliciting requirements helps to improve communication between stakeholders, developers, and users, which can result in a better understanding of the user’s needs and a more successful end product.
2. Reduced rework: By identifying and addressing requirements early on in the development process, engineers can reduce the likelihood of costly rework later on.
3. Increased user satisfaction: By thoroughly understanding and addressing the user’s needs, engineers can create software that is more likely to meet the user’s expectations and result in increased satisfaction.
4. Improved system quality: By identifying and mitigating risks associated with the requirements, engineers can improve the overall quality of the system.
5. Better alignment with business goals: By aligning the requirements with the business goals, engineers can ensure that the software is developed in a way that supports the overall objectives of the organization.

Disadvantages of eliciting requirements in software engineering include:

1. Time-consuming: Eliciting requirements can be a time-consuming process, which can slow down the development process.
2. Costly: Gathering requirements can be costly, especially when involving multiple stakeholders.
3. Risk of changing requirements: Requirements may change over time, which can lead to confusion and require additional work to keep the project aligned with the updated requirements.
4. Difficulty in identifying all the requirements: It can be difficult to identify all the requirements, especially when dealing with complex systems or new technologies.
5. Difficulty in predicting future requirements: It can be difficult to predict future requirements, which can result in the software becoming outdated or needing to be redesigned.
6. Difficulty in handling user’s changing needs: As the users start using the system they might realize that they need something that was not anticipated during the requirements gathering phase.

Summary

There are many problems associated with the engineering of needs, including problems in defining the scope of the system, problems with promoting understanding between the various communities affected by the proposed system, and problems in addressing the instability of demand. These problems can create unsustainable needs and cancel program development, otherwise, the development of a system will be considered unsatisfactory or unacceptable, have high repair costs, or will be subject to change. By improving service delivery, the needs engineering process can be improved, which has resulted in improved system requirements and a better system.

Engineering needs can be deduced from the requirements of the promotion, specification, and validation requirements. Most current strategies and needs focus on clarity, that is, service representation. The report focuses on rather than concerns about nominations, those issues with engineering needs that have not been adequately addressed by specification strategies. A lifting approach is proposed to address these concerns.

This new approach seeks to incorporate the benefits of existing promotion strategies while taking a closer look at the activities undertaken during the service delivery process. These activities include fact-finding, data collection, evaluation and planning, prioritization, and integration. Taken on their own, the existing promotion strategies are lacking in one or more of these areas.