Eliciting requirements is the first step of 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. Some of them are as follows: 

 

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) Large number of functions to be implemented.
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 which may exceed the decided budget. 
 

Customers/Stakeholders are not clear about their needs. – 
Sometimes, the customers themselves maybe 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. 
 

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. 
 

Changing requirements is another issue – 
In 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. 
 

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. 
 

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. 
 

Identifying critical requirements – 
Identifying the set of requirements which 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. 
 

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. 
 

Proper documentation, proper meeting time and budget constraints – 
Ensuring a proper documentation is an inherent challenge, especially in case of changing requirements. The time and budget constraints too need to be handled carefully and systematically. 
 
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 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
                             

Related articles