Prerequisite – Requirements Elicitation
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.
The complex system requirements include those requirements which are unclear and difficult to implement.
- 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.