requirements engineering

The topics of requirements engineering (also called requirements analysis or business analysis) covered in the IREB are:

• Introduction and overview to requirements engineering: understanding the value of RE. 
• Three types of requirements 
  • Functional requirements 

They concern a result or behavior to be provided by a function of a system. These include requirements for data or the interaction of a system with its environment. 

• Quality requirements 

They refer to quality aspects that are not covered by functional requirements, such as performance, availability, security, or reliability. 

• Constraints (boundary conditions) 

Constraints are requirements that limit the solution space beyond what is necessary to meet the given functional and quality requirements.

• Role and tasks of a requirements engineer 
• Work products and documentation practices as well as documentation structures
• Prototypes in requirements engineering (exploratory and evolutionary)
• Quality criteria for work products and requirements
• Sources and elicitation methods for requirements
• Conflicts and conflict resolution
• Validation of the quality of requirements
• Processes and work structures
• Requirements management, life cycle and versioning
• Prioritization and traceability
• Tool support / tooling

IREB stands for International Requirements Engineering Board and is an international non-profit association dedicated to the continuous improvement and development of the requirements engineering profession. 

Some particularly important terms that IREB requirements engineers should also be familiar with are:

A requirement is primarily a need that a stakeholder has. This requirement is said to be a capability or property of the system according to the stakeholder's requests. In the preliminary stages of software development, a requirement is the documented representation of a need, capability, or property.

Requirements specification is a systematically presented collection of requirements, typically for a system that meets certain criteria. In some situations, we distinguish between a customer requirements specification (usually written by the customer) and a system requirements specification or software requirements specification (written by the vendor). 

A work product is a recorded intermediate or final result produced in a work process. There are a variety of work products in RE; for example, these range from short-lived graphic sketches to evolving collections of user stories to formally released contractual requirements specifications with hundreds of pages.

A requirements configuration is a consistent set of work products that contain requirements. Each configuration is defined for a specific purpose and contains at most one version of each work product. For example, the purpose of configurations is to perform a review on a set of work products or to estimate development effort.

A baseline is a stable, change-controlled configuration of work products and is used for release planning or other delivery milestones in a project. Baselines are used for release planning and release definition as well as project management purposes such as effort estimation.

The Kano model describes the relationship between customer satisfaction and the fulfillment of customer requirements. It is named after Noriaki Kano, a former professor at Tokyo University of Science. In 1978, he divided customer requirements into five possible dimensions that have different effects on customer satisfaction:

• Basic characteristics
• Performance characteristics
• Excitement characteristics
• Insignificant characteristics
• Rejection characteristics

Each characteristic can relate to both products and services and have an impact on individual customer satisfaction.

Configuration refers to a consistent set of logically related items. The items are individually identifiable work products or parts of work products in no more than one version per item.

Modeling languages are languages for expressing models of a particular type. They may be textual, graphical, symbolic, or a combination of these dimensions.

A phrase template is a template for the syntactic structure of a phrase that expresses an individual requirement or user story in natural language.

Stakeholder is a person or organization that has influence on the requirements of a system or that is affected by that system. The influence can also be indirect: for example, some stakeholders must follow instructions from their managers or organizations.

A UML activity diagram is a function and flow diagram of the Unified Modeling Language (UML), a modeling language for software and other systems. It is the graphical representation of the interconnectedness of elementary actions and their connections with control and data flows.

A use case is a set of possible interactions between external actors and a system that provides a benefit to the actor(s) involved. Use cases describe a system from the perspective of a user (or other external actor). Each use case describes a functionality.

Requirements management is intended to achieve a common understanding between the supplier and the ordering party about a system to be developed. At the same time, the documents created in requirements management, e.g., requirements specifications, often serve as the contractual basis for implementation.