Requirements and Requirements Engineering | Principles of Software Engineering Tutorials

In this page

Requirements

The description of the features and functionalities of the target system is called requirements. The expectations of users from the software product are communicated through requirements.

IEEE defines a requirement as follows:

A condition or capability needed by a user to solve a problem or achieve an objective.
A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification or other formally imposed documents.
A documented representation of a condition or capability as in 1 and 2.

There are two categories of software requirements:

Functional requirements.
Non-functional requirements.

Requirements Engineering

Requirements engineering refers to the broad range of tasks and techniques that lead to an understanding of requirements. It is a major software engineering activity that begins during the communication activity and continues into the modelling activity. It bridges the gap between design and construction.

Requirements engineering provide,

Understanding what the customer wants.
Analysing requirements.
Assessing feasibility.
Negotiating a reasonable solution.
Specifying the solution unambiguously.
Validating the specification.

It consists of seven distinct tasks: elicitation, elaboration, negotiation, specification, validation, and management.

Inception

In general, most projects begin with the identification of a business need or the discovery of a potential new market or service. Business stakeholders define a business case for the idea, attempt to identify the breadth and depth of the market, perform a rough feasibility analysis, and identify a working description of the project’s scope.

At the start of a project, you establish a basic understanding of the problem, the people who want a solution, the nature of the desired solution, and the effectiveness of preliminary communication and collaboration between the other stakeholders and the software team.

Elicitation

Make inquiries with the customer about the system’s or product’s objectives, what is to be implemented, how the system or product fits into the needs of the business, and finally, how the system or product is to be used on a daily basis. A number of issues arise during the elicitation process.

Problems of scope

The system’s boundary is unclear, or customers/users provide unnecessary technical detail that may confuse, instead of clarifying overall system objectives.

Problems of understanding

Customers/users are unsure of what is required, have a poor understanding of the capabilities and restrictions of their computing environment, do not have a complete understanding of the problem domain, have problems communicating needs to the system engineer, ignore information that is considered “obvious,” specify requirements that conflict with the needs of other customers/users, or specify requirements that are ambiguous.

Problems of volatility

The specifications change over time. You must approach requirements gathering in an organised manner to help overcome these issues.

Eloboration

During elaboration, the information gathered from the customer during inception and elicitation is expanded and refined. The goal of this task is to create a refined requirements model that identifies various aspects of system function, behaviour, and information.

The creation and refinement of user scenarios, that describe how the end user and other actors will interact with the system, drives elaboration. Each user scenario is parsed to extract analysis classes—visible to the end user business domain entities. Each analysis class’s attributes are defined, and the services required by each class are identified. The relationships and collaboration among classes are identified, and a variety of supplementary diagrams are created.

Negotiation

It’s fairly common for different customers or users to propose competing requirements, claiming that their version is “essential for our special needs.”

You must resolve these conflicts through a negotiating process. Customers, users, and other stakeholders are asked to rank requirements and then discuss any conflicts in priority. Using an iterative approach that prioritises requirements, assesses their cost and risk, and addresses internal conflicts, requirements are eliminated, combined, and/or modified so that each party achieves some level of satisfaction.

Specification

To different people, specification means different things. A specification can be a written document, a collection of graphical models, a formal mathematical model, a set of usage scenarios, a prototype, or any combination of these. Some argue that a “standard template” for a specification should be developed and used, arguing that this results in requirements that are presented in a consistent and thus more understandable manner.

However, when developing a specification, it is sometimes necessary to remain flexible. A written document combining natural language descriptions and graphical models may be the best approach for large systems.

Topics covered in this section