This short article talks about how the requirements process can be carried out in the context of a scientific software development project.
In this article, we elaborate on the requirements process - which encompasses the discovery and documentation of requirements. No single methodology exists for requirements engineering. The process can be sequential or iterative. It may target internal or external users. The requirements documentation needs for, say, a web service framework are radically different from those for avionics software. In any case, a full treatment of requirements engineering praxis goes beyond the scope of this article. Instead, we outline the four common steps involved.
- Requirements Elicitation: Gathering data on the needs and wants of stakeholders.
- Requirements Analysis: Identifying the requirements.
- Requirements Specification: Producing a requirements specification artifact that models and expresses the requirements.
- Requirements Validation: Ensuring that the requirements match the needs and wants of stakeholers.
The elicitation and analysis steps are collectively known as the sensemaking phase of the requirements process, and the specification and validation steps are known as the problem structuring phase.
How should the requirements process be carried out in the context of a scientific software development project? A review of the literature suggests three trends of interest:
- Scientific software tends to be exploratory. Many key requirements may be unknown at the start.
- It is often long-lived. It is likely that the requirements will change over time.
- Software developed for the broader community has frequently come out of smaller projects intended for internal use. Therefore, stakeholders can change, and with them, the requirements.
Because of these factors, one should ensure that the requirements process is being thought of not as a singular event but as an ongoing activity that spans the lifecycle of the scientific product.
