User:AndreaArzer/Requirements engineering

= Requirements engineering = Requirements engineering (RE) is the process of defining, documenting, and maintaining requirements in the engineering design process. It is a common process found within systems engineering and software engineering and prevalent within all technical industry standards. The goal of requirements engineering is to improve the understanding of a proposed system, or system-to-be, by developing accurate, precise, and comprehensive requirements. Requirements engineering consists of the following activities: elicitation, evaluation & agreement, specification, consolidation & validation, and management.

Requirements engineers start with an opaque understanding of the system from the personal points of view of the system's stakeholders from which the requirements are elicited, and the representation is generally informal. Through requirements analysis, (which the IREB considers to be a synonym of requirements engineering as well as a subsection of the requirements engineering cycle) in conjunction with stakeholders, requirements engineers work towards the desired output: a complete representation of the system, based on agreements between stakeholders, and formally stated to limit ambiguities and confusion.

History
The first use of the term requirements engineering is believed to have been in the conference paper "Maintenance, Maintainability, and System Requirements Engineering", published in 1964. In the early 1990's requirements engineering became recognized as a distinct professional discipline, but it did not come into general use until the late 1990s with the publication of an IEEE Computer Society tutorial in March 1997. Prior to this however, there was the International Symposium on Requirements Engineering in 1993 where the main focus was to provide an outlet for the best papers on requirements engineering. A year later a conference series on requirements engineering was established that has since evolved into the International Conference on Requirements Engineering. At the 2000 edition of the International Conference on Requirements Engineering, discussions of a merger of the two conferences started. In 2001, the merger of these two conferences became official and the name of the conference was the International Requirements Engineering Conference.

Requirements engineering is presented as the first phase of the development process in the waterfall model. Later development methods, including the Rational Unified Process (RUP) for software, assume that requirements engineering continues through a system's lifetime.

Requirements
Main article: Requirements

Within requirements engineering, requirements concerning a system's functionality are generally distinct from other requirements, the main distinction between a functional or a non-functional requirement. Requirements can be further divided into functional requirements, performance requirements, specific quality requirements, and constraints.

Functional requirements are mainly focused on what a product must do or what a system should be able to perform. They are the description of behavioral aspects and can be described as a specification of behavior between inputs and outputs. Other than behavioral aspects, functional requirements are also characterized by stimuli, reactions, and data.

Non-functional requirements define the qualities that a system is supposed to have. Examples of non-functional requirements include: compliance, efficiency, effectiveness, response time, and scalability.

A non-functional requirement is either an attribute or a constraint. Within attributes, performance requirements pertain to performance concerns and have to do with aspects such as throughput and timing. Other attributes include specific quality requirements, which pertain to quality concerns other than the quality of functional requirements. A constraint is a requirement that constrains the solution space; these limit the system, define what is relevant, and shape the scope of the system. In other words, non-functional requirements describe the non-behavioral aspects of a system, capturing properties and constraints under which a system must operate.

Non-functional requirements can generally be divided into execution qualities and evolution qualities. The former is concerned with aspects such as usability and security; these aspects are observable at run time. The latter is concerned with aspects such as testability and maintainability.

Requirements engineering cycle
The activities involved in requirements engineering may vary depending on the type of system being developed and the organization's specific practice(s), but there is a general roadmap that many requirements engineering projects follow. Generally, the bulk of requirements engineering is done before other steps in the development process to establish a common understanding of the context, the system-to-be, and the development priorities. The phases named and described below are interrelated and non-linear; activity that is related to one phase may advance or backtrack progress on another phase. The terms used to describe the phases and the grouping of techniques within the phases may be rearranged in specific instances of implementation. Requirements Analysis, when not understood as a synonym of requirements engineering, is a subsection of requirements engineering that focuses on the optimization of requirements after elicitation.

Some engineering fields (or specific situations) require the product to be completely designed and modeled before development, requiring the design phase to be performed in advance, similar to how blueprints for a building must be completed before a construction contract can be approved and signed.

Elicitation
Requirements elicitation is the process of discovering and otherwise identifying candidate requirements and assumptions based on interactions with stakeholders of the proposed system. This phase of requirements engineering depends on effective communication and should be a cooperative process between the stakeholders and the requirements engineer to develop a shared understanding of the needs, context, and vision of the project.

The fundamental activities during elicitation are:


 * Building an understanding of the system domain - To support consensus and accuracy of requirements, requirements engineers should investigate the context of the current system to find relevant constraints and current problems.
 * Identifying sources of requirements - Requirements can be elicited from interviews with stakeholders, users, or subject matter experts. They can also be elicited from existing or legacy systems, current processes, and documentation.
 * Analyzing the stakeholders - It may be helpful to prioritize the stakeholders, and the requirements elicited from them, based on the stakeholder's importance to the system-to-be.
 * Selecting techniques and tools - Using multiple elicitation techniques can lead to more thorough requirements. Elicitation techniques have been borrowed and adapted from other disciplines such as social sciences, organizational theory, group dynamics, and knowledge engineering.
 * Eliciting requirements

Evaluation & agreement
The evaluation and agreement stage focuses on the identification of conflicting concerns and risks, as well as comparisons between alternatives. Through different methods of evaluation, needs and options can be prioritized and weighed within the context of the proposed system. When working with limited resources, it's important to prioritize requirements to develop the most important elements in an efficient manner, with the aim of getting the highest value for the lowest cost. Within this phase, strategies from the fields of decision theory and risk management can help evaluate alternative options. Both written and graphical tools can be used as aids; written analysis tools include use cases and user stories, and graphical tools include UML and LML.

Specification
The specification phase of requirements engineering emphasizes the formalization of the requirements. Requirements should be documented, detailed, and structured so the document is understandable to relevant stakeholders. Requirements can be documented in a formal artifact called a Requirements Specification (RS), exemplified by a Software requirements specification (SRS), which can contain structured language, diagrams, and formal specifications.

User stories are a concise, structured notation used to express requirements, increasingly employed in agile development. User stories capture the essential elements of a requirement: who it is for, what that user/stakeholder expects from the system, and why that expectation is important. In agile development, user stories are the most used method of representing and documenting requirements, preferred by nearly 73% of requirements analysts.

IEEE Recommended Practice for Software Requirements Specifications defines eight important characteristics for a requirement: correct, unambiguous, complete, consistent, ranked for importance/stability, verifiable, modifiable, and traceable.

Consolidation & validation
Requirements consolidation and validation focuses on checking that the documented requirements and models are consistent and meet the stakeholders' needs. It’s important to verify that stakeholders’ desires and needs are adequately covered by the requirements, that there’s agreement between stakeholders, and that context assumptions are reasonable. This is also the stage to evaluate the comprehensiveness of the RS and to identify and rectify any inconsistencies or omissions. To support requirements engineers, some consolidation and validation elements can be initially [evaluated with NLP] (*link to currently unpublished 'NLP for RE' Wikipedia page*); some techniques base this evaluation on the Quality User Story framework which determines the quality of user stories in terms of syntax, pragmatics, and semantics.

Management
Requirements management, the connection between requirements engineering and the development of the proposed system, is a sub-function of Systems Engineering practices. Systems and their requirements change over time due to changing business processes, competitors and their actions, changing priorities, changing technology, changing laws/regulations, different stakeholder needs, or feedback from users. Requirements management includes storing, changing and tracing requirements, as well as supervising the system as it is developed and implemented to ensure that requirements remain accurate and relevant. As such, requirements management is the connection between requirements development and the development of the proposed system.

Requirements engineering tools
The different stages of requirements engineering contain complex activities, and each stage relies on human decisions, making automating them more complicated. However, new tools and software are developed and updated regularly to support the requirements engineering process through its different stages; studies have found 100 different tools throughout requirements engineering resources on the Internet. Tools and software support the different requirements engineering stages with capabilities and features focused on requirements elicitation, requirements analysis, requirements specification, requirements modeling, goal modeling, requirements verification and validation, requirements management, requirements traceability and other capabilities. These applications are often referred to as requirements engineering tools and can be classified by their different capabilities and purposes according to the ISO/IEC TR 24766:2009 standard.

For more information and an extended list of available requirements engineering tools, as well as their classification and capabilities in detail, see Requirements Engineering Tools.

Common challenges and possible solutions
As requirements are the foundation that projects are built on, organizations benefit from being able to identify and prevent mistakes as early as possible during the requirements engineering phase. A reported 48% of problems identified during development can be traced back to inadequate requirements engineering and the further along in the development stage a requirement-related problem is discovered, the higher the rework costs can be. Therefore, this chapter displays requirements problems often addressed in literature, as well as how agile methodology could help prevent encountering some problems.

Scope creep and over-scoping
Requirements are constantly discovered, changed, evolved and discarded. Unforeseen changes can increase the time and cost required for development and unmanaged and unexpected changes to the scope can lead to problems in already existing architectures, designs, implementations and tests. Therefore, it is important to prevent scope creep, an uncontrolled growth of the scope, and to define what changes will be accepted in what time frame. Over-scoping happens when the scope of the project is larger than the provided resources can handle; this can, amongst other reasons, be caused by miscommunication, requirement changes, quality issues, and a lack of stakeholder involvement in the different stages of the process that limits their ability to indicate unwanted or out-of-scope requirements.

Quality issues of requirements
If requirements are documented inadequately, there can be consequences for the entire requirements engineering cycle, as they need to be reworked at later stages, and can increase development and sustainment costs and cause schedule overruns. The following table shows common undesirable qualities of requirements that were mentioned in multiple studies. Much of the research on this topic has focused on requirements engineering in the field of software development.

Inadequate communication and customer involvement
Communication problems and gaps, where required information is not provided to the necessary people, are common problems when interacting with stakeholders. Communication gaps can happen when stakeholders are unclear about their own needs, when erroneous assumptions are made, or when seemingly obvious information is omitted. Furthermore, the interplay between culture, conflict, and distance in globally-distributed requirements negotiations and undefined vocabulary, use of domain specific terminology and missing domain knowledge can lead to misunderstandings between stakeholders and the project team. These challenges can cause problems during modeling, design, and implementation. Additionally, if stakeholders are involved only during the early stages of the requirements cycle and requirements are discovered at later stages, they might not be integrable and could cause problems in the negotiation and validation of requirements.

Inadequate validation and verification of requirements quality
Requirements need to be validated and verified to ensure that they are complete and accurate. Requirements validation may be skipped due to a lack of stakeholder time, tight project schedule, or low project funding, leading to incomplete or incorrect requirements and a finished product that does not reflect the stakeholder's needs. When eventually discovered, requirement defects will be significantly more expensive and time intensive to fix than they would have been had they been fixed during early requirements verification.

Tackling the challenges with agile methods
Research discusses several possible ways of coping with the challenges of requirements engineering; agile development methodology is the most frequently mentioned possible solution. Agile methods promote frequent face-to-face communication among cross-functional teams, and the gradual detailing of requirements. Additionally, as the customer is present during each step of the process, they are able to recommend changes or to give approval for further progress and are constantly updated about the progress made and can provide timely feedback. However, consistent client availability might not be feasible; experiential research studies have identified that customer availability can be an issue, as the customer must consider cost, time, and available workday bandwidth.

Requirements validation and ensuring requirement quality could be eased by agile methods as well since continuous prioritization is an essential part of these methods; at the end of every sprint, a requirement is demonstrated to customer representatives who can review and suggest changes to ensure that the requirements satisfy their needs. While some agile practices utilize continuous testing, consistent checking or inspection of the requirements is rarely done during agile requirements engineering.

The International Requirements Engineering Board
The International Requirements Engineering Board (IREB) e.V. is an independent, non-profit organization founded in 2006 in Germany by leading requirements engineering representatives from science, research, industry, and consulting. Their goals were to create an internationally accepted and professional basis for requirements engineering, foster further education, and improve requirements engineering and business analysis in practice.

To reach their goals, IREB established an international accepted qualification - the Certified Professional for Requirements Engineering (CPRE). This three-tier qualification is an international certification for professionals in the fields of requirements engineering, business analysis, and software and systems development, and is regulated by the steering committee of IREB, consisting of international requirements engineering experts from universities, industry, and education. The concepts are taught by independent training providers and the exam is administered at approved certification bodies. These regulations ensure that the CPRE follows ISO/IEC 17024:2012 standard, which requires the strict separation of training and certification. IREB has also created the CPRE Glossary, which eases the communication amongst the people involved in the requirements engineering process.

Requirements engineer as a role
According to IREB, a requirements engineer is “a person who — in collaboration with stakeholders — elicits, documents, validates, and manages requirements.” However, according to literature, jobs are rarely titled as Requirements Engineer and the role itself is not defined clearly. Therefore, the tasks performed vary for requirements engineers depending on the organizational structure, project circumstances or personal capabilities. Chong Wang, Pengwei Cui, Maya Daneva, and Mohamad Kassab stated that, even if requirements engineer is described as a profession, “there is a significant incongruity regarding the perceptions of the requirements engineering role, tasks, and responsibilities in the IT marketplace.” Often, a requirements engineer is assigned by their organization either due to some other role or position they currently hold in the project, on a case-by-case basis, or the role and its tasks are distributed amongst different roles.

The following positions may be involved in requirements engineering and hold related responsibilities: executive, software or solution architect, consultant, project manager, system designer, business/data/application analyst, and technical specialist, scrum master or product owner function support, coordinator, information-management advisor. Requirements engineering is mostly done by analysts and consultants, followed by project managers; together, those titles account for 77% of all requirements engineering related positions found.

Applicable standards
Below is a selection of standards that apply to the requirements engineering cycle:

Active standards

 * ISO/IEC/IEEE 12207-2017: Systems and software engineering - Software life cycle processes


 * ISO/IEC/IEEE 15288-2015: Systems and software engineering - System life cycle processes
 * ISO/IEC/IEEE 24765-2017: Systems and software engineering - Vocabulary
 * ISO/IEC/IEEE 29148-2018: International Standard -Systems and software engineering - Life cycle processes - Requirements engineering
 * ISO/IEC TR 24766:2009: Information technology - Systems and software engineering - Guide for requirements engineering tool capabilities
 * ISO/IEC 25001:2014: Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Planning and management
 * ISO/IEC 25010:2011: Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models
 * ISO/IEC TS 25011:2017: Information technology - Systems and software Quality Requirements and Evaluation (SQuaRE) - Service quality models
 * ISO/IEC 25012:2008: Software engineering - Software product Quality Requirements and Evaluation (SQuaRE) - Data quality modelISO/IEC 25020:2019: Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Quality measurement framework
 * ISO/IEC 25020:2019: Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Quality measurement framework
 * ISO/IEC 25021:2012: Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Quality measure elements
 * ISO/IEC 25022:2016: Systems and software engineering - Systems and software quality requirements and evaluation (SQuaRE) Measurement of quality in use
 * ISO/IEC 25023:2016: Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Measurement of system and software product quality
 * ISO/IEC 25024:2015: Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Measurement of data quality
 * ISO/IEC TS 25025:2021: Information technology - Systems and software Quality Requirements and Evaluation (SQuaRE) - Measurement of IT service quality
 * ISO/IEC 25030: Systems and software engineering - Systems and software quality requirements and evaluation (SQuaRE) - Quality requirements framework
 * ISO/IEC 25041:2012: Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Evaluation guide for developers, acquirers and independent evaluators

Inactive standards:

 * IEEE 830-1998: IEEE Recommended Practice for Software Requirements Specifications (Replaced by ISO/IEC/IEEE 29148:2011)
 * ISO/IEC 12119:1994: Information technology — Software packages — Quality requirements and testing


 * IEEE 1465-1998: IEEE Standard - Adoption of International Standard ISO/IEC 12119:1994(E) - Information Technology - Software Packages - Quality Requirements and Testing

Related fields
Requirements engineering draws on various cognitive and social sciences to provide theoretical grounding and practical techniques. Cognitive psychology can inform requirements engineers about the difficulties people may experience when describing their wants and needs. Anthropology provides a methodological approach to observing human activities, which helps with developing a rich understanding of needs for a proposed product. Sociology also provides an understanding of political and cultural changes that might impact a proposed system. Linguistics is important for requirements engineering since the field hinges on accurate communication. Linguistic analyses have changed the way language is used in specifications to avoid ambiguity or to enhance understandability.