Requirements engineering (RE) refers to the process of defining, documenting and maintaining requirements in the engineering design process. It is a common role in systems engineering and software engineering.
The first use of the term requirements engineering was probably in 1964 in the conference paper "Maintenance, Maintainability, and System Requirements Engineering" but did not come into general use until the late 1990s with the publication of an IEEE Computer Society tutorial, in March 1997, and the establishment of a conference series on requirements engineering that has evolved into the current International Requirements Engineering Conference.
In the waterfall model, requirements engineering is presented as the first phase of the development process. Later development methods, including the Rational Unified Process (RUP), for software, assume that requirements engineering continues through the lifetime of a system.
Requirement management, which is a sub-function of Systems Engineering practices, is also indexed in the INCOSE (International Council on Systems Engineering) manuals.
The activities involved in requirements engineering vary widely, depending on the type of system being developed and the specific practices of the organization(s) involved. These may include:
These are sometimes presented as chronological stages although, in practice, there is considerable interleaving of these activities.
One limited study in Germany presented possible problems in implementing requirements engineering and asked respondents whether they agreed that they were actual problems. The results were not presented as being generalizable but suggested that the principal perceived problems were incomplete requirements, moving targets, and time boxing, with lesser problems being communications flaws, lack of traceability, terminological problems, and unclear responsibilities.
There is no evidence that requirements engineering contributes to the success of software projects or systems. Problem structuring, a key aspect of requirements engineering, decreases design performance. Some research suggests that software requirements are often an illusion misrepresenting design decisions as requirements in situations where no real requirements are evident.
Axel van Lamsweerde (born 1947) is a Belgian computer scientist and Professor of Computing Science at the Universite catholique de Louvain, known for his work on requirements engineering and the development of the KAOS goal-oriented modeling language.Colette Rolland
Colette Rolland (born 1943, in Dieupentale, Tarn-et-Garonne, France) is a French computer scientist and Professor of Computer Science in the department of Mathematics and Informatics at the University of Paris 1 Pantheon-Sorbonne, and a leading researcher in the area of information and knowledge systems, known for her work on meta-modeling, particularly goal modelling and situational method engineering.Concept of operations
A concept of operations (abbreviated CONOPS, CONOPs, or ConOps) is a document describing the characteristics of a proposed system from the viewpoint of an individual who will use that system such as a business requirements specification or stakeholder requirements specification (StRS). It is used to communicate the quantitative and qualitative system characteristics to all stakeholders. CONOPS are widely used in the military, governmental services and other fields.
A CONOPS generally evolves from a concept and is a description of how a set of capabilities may be employed to achieve desired objectives or end state.The first standard was 1362-1998 - IEEE Guide for Information Technology - System Definition - Concept of Operations (ConOps) Document that was superseded by the document 29148-2011 - ISO/IEC/IEEE International Standard - Systems and software engineering -- Life cycle processes --Requirements engineering.
Then came the 2012 AIAA revision proposal Guide: Guide to the Preparation of Operational Concept Documents (ANSI/AIAA G-043A-2012) (Revision of G-043-1992), and today we have ISO/IEC/IEEE 15288:2015 Systems and software engineering -- System life cycle processes.
In the field of joint military operations, a CONOPS in DoD terminology is a verbal or graphic statement that clearly and concisely expresses what the joint force commander intends to accomplish and how it will be done using available resources. CONOPS may also be used or summarized in system acquisition DODAF descriptions such as the OV-1 High Level Operational Concept Graphic.Functional requirement
In software engineering and systems engineering, a functional requirement defines a function of a system or its component, where a function is described as a specification of behavior between outputs and inputs.Functional requirements may involve calculations, technical details, data manipulation and processing, and other specific functionality that define what a system is supposed to accomplish. Behavioral requirements describe all the cases where the system uses the functional requirements, these are captured in use cases. Functional requirements are supported by non-functional requirements (also known as "quality requirements"), which impose constraints on the design or implementation (such as performance requirements, security, or reliability). Generally, functional requirements are expressed in the form "system must do
A goal model is an element of requirements engineering that may also be used more widely in business analysis. Related elements include stakeholder analysis, context analysis, and scenarios, among other business and technical areas.International Requirements Engineering Board
The International Requirements Engineering Board (IREB) e.V. was founded in Fürth in Germany in October 2006. IREB e.V. is as a legal entity based in Germany.
The IREB is the holder for the international certification scheme Certified Professional for Requirements Engineering (CPRE).
It is IREB's role to support a single, universally accepted, international qualification scheme, aimed at Requirements Engineering for professionals, by providing the core syllabi and by setting guidelines for accreditation and examination. The accreditation process and certification are regulated by the steering committee of IREB. The steering committee of IREB is built out of the personal members of IREB. Personal members of the IREB are international experts in requirements engineering from universities, economy and education.Meta-process modeling
Meta-process modeling is a type of metamodeling used in software engineering and systems engineering for the analysis and construction of models applicable and useful to some predefined problems.
Meta-process modeling supports the effort of creating flexible process models. The purpose of process models is to document and communicate processes and to enhance the reuse of processes. Thus, processes can be better taught and executed. Results of using meta-process models are an increased productivity of process engineers and an improved quality of the models they produce.Non-functional requirement
In systems engineering and requirements engineering, a non-functional requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. They are contrasted with functional requirements that define specific behavior or functions. The plan for implementing functional requirements is detailed in the system design. The plan for implementing non-functional requirements is detailed in the system architecture, because they are usually architecturally significant requirements.Broadly, functional requirements define what a system is supposed to do and non-functional requirements define how a system is supposed to be. Functional requirements are usually in the form of "system shall do
Non-functional requirements are often called "quality attributes" of a system. Other terms for non-functional requirements are "qualities", "quality goals", "quality of service requirements", "constraints", "non-behavioral requirements", or "technical requirements". Informally these are sometimes called the "ilities", from attributes like stability and portability. Qualities—that is non-functional requirements—can be divided into two main categories:
Execution qualities, such as safety, security and usability, which are observable during operation (at run time).
Evolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the system.Pairwise comparison
Pairwise comparison generally is any process of comparing entities in pairs to judge which of each entity is preferred, or has a greater amount of some quantitative property, or whether or not the two entities are identical. The method of pairwise comparison is used in the scientific study of preferences, attitudes, voting systems, social choice, public choice, requirements engineering and multiagent AI systems. In psychology literature, it is often referred to as paired comparison.
Prominent psychometrician L. L. Thurstone first introduced a scientific approach to using pairwise comparisons for measurement in 1927, which he referred to as the law of comparative judgment. Thurstone linked this approach to psychophysical theory developed by Ernst Heinrich Weber and Gustav Fechner. Thurstone demonstrated that the method can be used to order items along a dimension such as preference or importance using an interval-type scale.Requirement
In product development and process optimization, a requirement is a singular documented physical or functional need that a particular design, product or process aims to satisfy. It is commonly used in a formal sense in engineering design, including for example in systems engineering, software engineering, or enterprise engineering. It is a broad concept that could speak to any necessary (or sometimes desired) function, attribute, capability, characteristic, or quality of a system for it to have value and utility to a customer, organization, internal user, or other stakeholder.
Requirements can come with different levels of specificity; for example, a requirement specification or requirement "spec" (often imprecisely referred to as "the" spec/specs, but there are actually different sorts of specifications) refers to an explicit, highly objective/clear (and often quantitative) requirement (or sometimes, set of requirements) to be satisfied by a material, design, product, or service.A set of requirements is used as inputs into the design stages of product development. Requirements are also an important input into the verification process, since tests should trace back to specific requirements. Requirements show what elements and functions are necessary for the particular project. When iterative methods of software development or agile methods are used, the system requirements are incrementally developed in parallel with design and implementation. With the waterfall model requirements are developed before design and implementation.Requirements Engineering Specialist Group
The Requirements Engineering Specialist Group (RESG) is a Specialist Group of the British Computer Society. It runs events on all aspects of Requirements.Requirements analysis
In systems engineering and software engineering, requirements analysis encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product or project, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating and managing software or system requirements.Requirements analysis is critical to the success or failure of a systems or software project. The requirements should be documented, actionable, measurable, testable, traceable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.Requirements elicitation
In requirements engineering, requirements elicitation is the practice of researching and discovering the requirements of a system from users, customers, and other stakeholders. The practice is also sometimes referred to as "requirement gathering".
The term elicitation is used in books and research to raise the fact that good requirements cannot just be collected from the customer, as would be indicated by the name requirements gathering. Requirements elicitation is non-trivial because you can never be sure you get all requirements from the user and customer by just asking them what the system should do OR NOT do (for Safety and Reliability). Requirements elicitation practices include interviews, questionnaires, user observation, workshops, brainstorming, use cases, role playing and prototyping.
Before requirements can be analyzed, modeled, or specified they must be gathered through an elicitation process. Requirements elicitation is a part of the requirements engineering process, usually followed by analysis and specification of the requirements.
Commonly used elicitation processes are the stakeholder meetings or interviews. For example, an important first meeting could be between software engineers and customers where they discuss their perspective of the requirements.Requirements management
Requirements management is the process of documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. It is a continuous process throughout a project. A requirement is a capability to which a project outcome (product or service) should conform.Requirements traceability
Requirements traceability is a sub-discipline of requirements management within software development and systems engineering. Traceability as a general term is defined by the IEEE Systems and Software Engineering Vocabulary as (1) the degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another; (2) the identification and documentation of derivation paths (upward) and allocation or flowdown paths (downward) of work products in the work product hierarchy; (3) the degree to which each element in a software development product establishes its reason for existing; and (4) discernible association among two or more logical entities, such as requirements, system elements, verifications, or tasks.
Requirements traceability in particular, is defined as "the ability to describe and follow the life of a requirement in both a forwards and backwards direction (i.e., from its origins, through its development and specification, to its subsequent deployment and use, and through periods of ongoing refinement and iteration in any of these phases)". In the requirements engineering field, traceability is about understanding how high-level requirements – objectives, goals, aims, aspirations, expectations, needs – are transformed into low-level requirements. It is therefore primarily concerned with satisfaction relationships between layers of information (aka artifacts). However, traceability may document relationships between many kinds of development artifacts, such as requirements, specification statements, designs, tests, models and developed components. For example, it is common practice to capture verification relationships to demonstrate that a requirement is verified by a certain test artifact.
Traceability is especially relevant when developing safety-critical systems and therefore prescribed by safety guidelines, such as DO178C, ISO 26262, and IEC61508. A common requirement of these guidelines is that critical requirements must be verified and that this verification must be demonstrated through traceability.Software architecture
Software architecture refers to the high level structures of a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations. The architecture of a software system is a metaphor, analogous to the architecture of a building. It functions as a blueprint for the system and the developing project, laying out the tasks necessary to be executed by the design teams.Software architecture is about making fundamental structural choices which are costly to change once implemented. Software architecture choices include specific structural options from possibilities in the design of software. For example, the systems that controlled the space shuttle launch vehicle had the requirement of being very fast and very reliable. Therefore, an appropriate real-time computing language would need to be chosen. Additionally, to satisfy the need for reliability the choice could be made to have multiple redundant and independently produced copies of the program, and to run these copies on independent hardware while cross-checking results.
Documenting software architecture facilitates communication between stakeholders, captures early decisions about the high-level design, and allows reuse of design components between projects.Software prototyping
Software prototyping is the activity of creating prototypes of software applications, i.e., incomplete versions of the software program being developed. It is an activity that can occur in software development and is comparable to prototyping as known from other fields, such as mechanical engineering or manufacturing.
A prototype typically simulates only a few aspects of, and may be completely different from, the final product.
Prototyping has several benefits: the software designer and implementer can get valuable feedback from the users early in the project. The client and the contractor can compare if the software made matches the software specification, according to which the software program is built. It also allows the software engineer some insight into the accuracy of initial project estimates and whether the deadlines and milestones proposed can be successfully met. The degree of completeness and the techniques used in prototyping have been in development and debate since its proposal in the early 1970s.Software requirements
Software requirements is a field within software engineering that deals with establishing the needs of stakeholders that are to be solved by software. The IEEE Standard Glossary of Software Engineering Terminology defines a requirement as:
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 document.
A documented representation of a condition or capability as in 1 or 2.The activities related to working with software requirements can broadly be broken down into elicitation, analysis, specification, and management.Web engineering
The World Wide Web has become a major delivery platform for a variety of complex and sophisticated enterprise applications in several domains. In addition to their inherent multifaceted functionality, these Web applications exhibit complex behaviour and place some unique demands on their usability, performance, security, and ability to grow and evolve. However, a vast majority of these applications continue to be developed in an ad-hoc way, contributing to problems of usability, maintainability, quality and reliability. While Web development can benefit from established practices from other related disciplines, it has certain distinguishing characteristics that demand special considerations. In recent years, there have been developments towards addressing these considerations.
Web engineering focuses on the methodologies, techniques, and tools that are the foundation of Web application development and which support their design, development, evolution, and evaluation. Web application development has certain characteristics that make it different from traditional software, information system, or computer application development.
Web engineering is multidisciplinary and encompasses contributions from diverse areas: systems analysis and design, software engineering, hypermedia/hypertext engineering, requirements engineering, human-computer interaction, user interface, information engineering, information indexing and retrieval, testing, modelling and simulation, project management, and graphic design and presentation. Web engineering is neither a clone nor a subset of software engineering, although both involve programming and software development. While Web Engineering uses software engineering principles, it encompasses new approaches, methodologies, tools, techniques, and guidelines to meet the unique requirements of Web-based applications.
ISO standards by standard number