Requirements Engineering Fundamentals

A software project may be undertaken to replace an existing manual system, enhance or extend a current computerised system, or develop an altogether new system to solve a problem. Irrespective of the nature of the project, each has a clear purpose, usually expressed as what the system will do.

Requirements must be determined and agreed by both customers and developers before the software can be built. Defining good, complete requirements is difficult, and errors at this stage are the hardest and most expensive to rectify later (Brooks Jr, 1995).

3.1 Problem Definition and Feasibility Study

Software projects usually begin when a business need or problem is identified. At project inception, a basic understanding of the problem and its context is established, often in the form of a problem statement addressing questions such as:

• What is the problem to be solved?
• What is the scope and significance of the problem?
• What are the possible solution approaches?

Feasibility Study

A feasibility study is conducted to analyse the potential impact and practicality of the proposed project. Feasibility typically depends on:

• Viability of the concept – whether the proposed solution is realistic and technically achievable.
• Cost–benefit analysis – whether the expected benefits justify the required investment.
• Business model – whether the business model remains justified given the current cost and schedule estimates.
• Product–market fit – whether there is a clear market or user base for the proposed system.

A feasibility study helps decide whether the project should proceed, be modified, or be abandoned in favour of alternative solutions.

3.2 Requirements Engineering Process

Software requirements engineering is a disciplined, process-oriented approach to the definition, documentation, and maintenance of software requirements throughout the software development life cycle (SDLC).

Requirements analysis results in a description of the software’s operational characteristics, its interfaces with other system elements, and the constraints that the software must satisfy.

3.2.1 Core Requirements Engineering Activities

Some of the fundamental activities in requirements engineering (Sommerville, 2005) are illustrated in Figure 21 and can be summarised as:

• Inception and problem statement – establish the basic understanding of the problem and business need at the start of the project.
• Elicitation (requirements gathering) – identify sources of information and discover requirements from stakeholders, users, domain experts, and existing systems.
• Analysis – examine requirements to identify overlaps, omissions, inconsistencies, conflicts, and feasibility issues.
• Negotiation – reconcile conflicting stakeholder views and agree on a consistent, prioritised set of requirements.
• Documentation – record the agreed requirements in a form that both stakeholders and developers can understand, typically as a Software Requirements Specification (SRS).
• Validation – review and confirm that the documented requirements reflect what stakeholders actually need and are technically feasible.
• Management – control and track requirement changes that arise during the project, maintaining traceability and configuration.

The primary output of requirements engineering is the final Software Requirements Specification (SRS), which often acts as a baseline and contract between customers and developers.