Why Should You Care About Software Requirements Engineering?

In this article, we'll talk about software requirements, software requirements engineering, and the process of software requirements.

Software Requirements

Software requirement is a specification of what the software should do, as well as limitations concerning its use. Software requirement should represent clearly defined user needs in terms of the software system which will be designed for them. The basic characteristic of software requirements is that they can be verified as individual software properties, that are then viewed as functional requirements, or as properties at the system level, which are viewed as nonfunctional requirements. Software requirements are derived from user requirements, which represent what the service or the system should provide to the user and what limitations exist. Besides software requirements, system requirements are also derived based on user requirements, which refer to the system as a whole and encompass software, hardware, people, services, and processes.

Software requirements are divided into:

• **Functional requirements**
• **Nonfunctional requirements**

Functional requirements are requirements that describe how the system behaves in certain situations. Nonfunctional requirements are requirements that most commonly relate to some limitations of the system. These limitations are most often imposed by standards that apply in the domain of the problem, but they may also be time limitations or limitations of individual processes.

Functional requirements can be common in terms of what the system should do, but they can also be very specific and determined by local rules and work methods in a small subsystem. Functional requirements must be complete, which means that all functionalities must be defined.

Nonfunctional requirements usually are very strict concerning the system characteristics, and if their implementation is avoided, the system could be unusable. Implementation of nonfunctional requirements is usually related to the whole system or its individual segments. There are three sources of nonfunctional requirements:

• **Product requirements**
• **Organizatinal requirements**
• **External requirements**

Product requirements refer to limitations relating to the software product and its performances, such as execution speed, memory usage, usability, etc.

Organizational requirements refer to limitations derived from the rules and procedures of an organization that is a purchaser of the software and also, to limitations derived from the rules and procedures of an organization that produces the software. This group includes requirements that are related to the choice of an operating system for software execution, how to use the software, choice of a programming language (or more of them) for designing the software, as well as respecting processes and standards in the domain of application and software development.

External requirements refer to all requirements that don't apply to the software product and organizations that are included in its development and usage. This group includes limitations regarding various business regulations, legislative restrictions, and ethical aspects of software usability.

Nonfunctional requirements arise from user needs, due to the existence of budget constraints, organization rules, procedures, software interoperability needs, and hardware requirements.

Recap of nonfunctional requirements:

Product requirements include:

• **Usability**
• **Reliability**
• **Security**
• **Efficiency**

Organizational requirements include:

• **Environmental requirements**
• **Software execution requirements**
• **Software development requirements**

External requirements include:

• **Regulations in the domain of application and software development**
• **Legislation**
• **Ethical requirements**

## Software Requirements Engineering

Software requirement engineering is the field of software engineering which refers to the systematic handling of software requirements and encompasses requirements specification, analysis, documentation, control, and validation. Although it is at the software life cycle's very beginning stage, software requirements engineering is connected with all phases in its life cycle.

Software requirements engineering and phases in the software life cycle:

1. Project planning. Software and system requirements represent the basis for project planning within the software life cycle. Requirements define the project's flow, roles within the project, deadlines, use of appropriate methods and tools, as well as the flow of software life cycle. Also, software and system requirements serve as the basis for risk management, expenses, and limitations in project development.

2. Software design and construction. Software design and construction rely on minutely specified software requirements. During the design and construction, there might be a need for changing requirements.

3. Testing. Software testing consists of testing individual parts and the whole system by the organization that produces the software, where specification verification is performed, i.e. checking if the software is created according to the specification. After that, the acceptance test is done (by an organization that is the software user), where specification validation is performed, i.e. checking if the software satisfies the requirements specified by the user.

4. Documentation. Software requirements are documented in the form of a specification that is later used during the next phases in the software life cycle. During the software life cycle, software requirements can change, which usually happens during the iterative cycle of software development, or later, when changes are done during the maintenance.

5. Maintenance. This is the last phase in the software life cycle. As said in the previous phase, changes can be done during the maintenance.

Software requirements engineering - main activities recap:

1. Requirements creation:
   • **Acquisition**
   • **Analysis**
   • **Specification**
   • **Validation**
2. Requirements management

The Process of Software Requirements

The process of software requirements covers activities of acquisition, analysis, specification, and validation of requirements.

Starting assumptions for the process of software requirements are clearly defined strategic and operating requirements of an organization that needs the software. Before initialization of the process, it is sometimes necessary to create a feasibility study to see all factors and limitations that can affect the process, and later, to the whole software life cycle.

Requirements Acquisition

Requirements Acquisition is the first phase in building and understanding the software that is developed. This phase represents a relationship between the problem domain and the technical domain where the software is developed. In this process phase, the project scope and software product are defined. In this phase, all potential requirement sources and goals must be perceived:

• Adjustment of the software product with business goals of an organization which needs the software
• Risk management and creation of the feasibility study
• Introduction to the domain where software requirements are derived and where the concepts are identified in the problem's domain
• Taking into account different views of different groups of software users
• Identification of business rules that set different limitations in terms of structure and functionality of the software
• Viewing characteristics and limitations of the environment in which the software will be used
• Viewing the organizational environment in which the software is implemented

Software requirements acquisition is related to information acquisition, from where software requirements will be derived and defined. Techniques for software requirements acquisition are:

• **Interviews**. This technique provides requirements acquisition through conversation with the software users. The conversation is recorded and analyzed.
• **Scenarios**. This technique is based on the assumption and analysis of different usage scenarios based on questions that relate to the way of doing business in the working environment. This technique is usually done by the use of UML Use Case Diagrams.
• **Prototypes**. This technique is suitable for resolving unclear or contradictory requirements, and it is based on presenting the working environment which has to help users to clarify requirements. Prototypes can be done as descriptions and sketches on paper, ad-hoc software applications that demonstrate potential solutions for the software.
• **Meetings**. This technique includes more people in a discussion and identification of ideas related to requirements. The basic assumption of this approach is that the mutual work and discussion of more people can positively affect problems and requirements identification.
• **Practice observation**. This technique implies the active stay in an organization and tracking of everyday activities. This is a long and demanding process in terms of the time needed for practice and resource observation.
• **User stories**. This technique is based on short stories where users describe the way of doing the job based on which functional requirements are defined. Stories are analyzed, and then requirements are defined.

### Requirements Analysis

Software requirements analysis is the set of activities that has the following goals:

• Observation and rectification of conflicts in requirements
• Identifying the boundaries of the software product, and defining interaction with the environment
• Detailed description of system requirements with the goal to identify software requirements

The basic activities in a phase of software requirements analysis are:

• **Requirements classification**. Requirements classification can execute based on more criteria: functional and nonfunctional, requirement refers to the process or the product, the requirement is basic or derived from other requirements, prioritization, requirements scope, and stability/variability during the software life cycle.
• **Conceptual modeling**. Conceptual modelling of the real problem is the basis for requirements definition and software modelling. The conceptual model should encompass the domain and the concept of software usage, as well as entities that exist in the problem domain. The usual way for conceptual modelling is the use of Unified Modeling Language (UML), where Use Case Diagrams that describe use case scenarios are common.
• **Architecture design and requirements allocation**. In this phase, the requirement process overlaps with the design process of the system and the software, and it is closely related to conceptual modelling. Allocation of the system components according to requirements is important here.
• **Requirements adjustment**. Given that requirements are acquired by different users, very commonly, there are contradictory requirements that must be adjusted. In this phase, it is very important to resolve all mutually exclusive requirements, and then execute prioritization of identified requirements.
• **Formal analysis**. Requirements formal analysis is done in the end phase of the requirements process when all requirements are clearly defined.

### Requirements Specification

Requirements specification is the activity during which documents that can be reviewed, evaluated, and approved, are created. Usually, the following documents are created:

• **Interviews**. This technique provides requirements acquisition through conversation with the software users. The conversation is recorded and analyzed.
• **Scenarios**. This technique is based on the assumption and analysis of different usage scenarios based on questions that relate to the way of doing business in the working environment. This technique is usually done by the use of UML Use Case Diagrams.
• **Prototypes**. This technique is suitable for resolving unclear or contradictory requirements, and it is based on presenting the working environment which has to help users to clarify requirements. Prototypes can be done as descriptions and sketches on paper, ad-hoc software applications that demonstrate potential solutions for the software.
• **Meetings**. This technique includes more people in a discussion and identification of ideas related to requirements. The basic assumption of this approach is that the mutual work and discussion of more people can positively affect problems and requirements identification.
• **Practice observation**. This technique implies the active stay in an organization and tracking of everyday activities. This is a long and demanding process in terms of the time needed for practice and resource observation.
• **User stories**. This technique is based on short stories where users describe the way of doing the job based on which functional requirements are defined. Stories are analyzed, and then requirements are defined.

### Requirements Analysis

Software requirements analysis is the set of activities that has the following goals:

• Observation and rectification of conflicts in requirements
• Identifying the boundaries of the software product, and defining interaction with the environment
• Detailed description of system requirements with the goal to identify software requirements

The basic activities in a phase of software requirements analysis are:

• **System Definition Document**. This document is also called a User Requirements Document or a Document or concept of operations document. This document contains a description of the problem domain, the goal of software design, and a description of limitations and assumptions that affect software design. This document also can contain conceptual models of the system, environment, entities, and users.
• **System Requirements Specification**. This document contains a description of system elements that are not the software: operating system, hardware, etc.
• **Software Requirements Specification**. This document represents the basis for signing the contract between an organization that is a purchaser of the software and an organization that produces the software. The document contains a detailed description of software requirements, estimated deadlines, identified limitations, risks, as well as a plan of the software and requirements verification and validation.

### Requirements Validation

Requirements validation provides achievement of the following goals:

• Check if all requirements are well interpreted by software engineers/developers
• Check if created documents with requirements specification are adjusted with the standards of an organization that produces the software
• Check if requirements are consistent, clear and complete

Techniques for requirements validation are:

• **Requirements Reviews**. This technique usually includes several people that review the documentation, checklist, as well as rules for documentation reviews.
• **Prototyping**. This technique provides the check if software engineers/developers understood requirements specification. Also, the technique provides the acquisition of feedback information about the specification that allows the check if specification satisfies user requirements.
• **Model Validation**. Model validation makes sense when the formal analysis is done, and when the specification is done by the use of the standard formal modelling techniques. Model validation is usually done by special modelling tools.
• **Acceptance Tests**. The basic assumption in the design and implementation of the software requirements process is to get a product (software requirements specification), that can be checked. Acceptance tests are created for functional requirements and software users also participate in their creation.

## Conclusion

The question is, why should you care about software requirements engineering?

If you (as an organization or an individual) plan to design a large-scale software system, then software requirements engineering is recommended as the first phase of the software life cycle. On the other hand, if you plan to design a short-term software project (e.g. freelance software project) that needs to be done ad-hoc and quickly, then probably you won't have the time to deal with software requirements engineering.