Requirements Engineering (RE), also called Requirements Analysis, ranks as one of the most important activities of software- and system-development. It defines the requirements for a system by implementing a systematic approach starting with the project idea and the defined goals and leading up to a complete set of requirements.
The primary goal of Requirements Engineering is to create a shared understanding of what needs to be developed among all project members. The quality of the results of a development project fundamentally depends on the extent of lived and applied Requirements Engineering methods.
Successfully completing a system development project is the main goal of every project. The reality, alas, paints a different picture, considering that about one third of all IT-projects fail and around 60% are in critical states. Most of the time, causes for failure lie in the analysis phase, where most errors occur. However, the implementation of Requirements Engineering methods has a positive impact. The methods of Requirements Engineering are based on four main activities:
The International Requirements Engineering Board (IREB) is responsible for the standardization of the methods of Requirements Engineering and offers those using these techniques a certificate in Requirements Engineering. An overview of Requirements Engineering can be found in the “Short RE Primer” by SOPHIST.
When it comes to the elicitation of functional and non-functional requirements, it is important to consider various factors. Besides providing a unified understanding of the basic goals of the project, all requirements sources (e.g. stakeholders, documents, systems in use) need to be elicited and suitable elicitation techniques (creativity-, observation-, survey-, document-centric- and support-techniques) need to be determined. This approach guarantees that all basic-, performance- and excitement-factors are accounted for in a system. In addition to the recognized approaches of the IREB standards (CPRE Advanced Level Elicitation & Consolidation) the following methods have proven themselves helpful – the SOPHIST Set of Regulations for eliminating transformational effects and the SOPHIST Selection matrix for elicitation techniques for increasing the quality of the specification.
Writing functional and non-functional requirements aims at describing a requirement in an unambiguous, testable and comprehensible way. There are different documentation techniques that are suitable for recording requirements. For one, requirements can be documented in prose using the SOPHIST MASTeR template (Immaculate SOPHIST Templates for Requirements), which enables one to write uniformly built requirements clauses. Another technique is a model-based form of documentation which uses a modeling language such as Unified Modeling Language (UML), System Modeling Language (SysML), or Business Process Model and Notation (BPMN) for business processes. A combination of prose and model based requirements is equally possible. Prose requirements can specify models just as much as model-based requirements can complement prose requirements by providing an overview. To avoid differing interpretations of the terminology that is being used writing requirements, it is helpful to compile a glossary. The SOPHIST Set of REgulations is also implemented in the documentation of requirements.
Validating and consolidating requirements is the art of modifying the elicited and documented requirements in such a way that all stakeholders agree on the results. For that matter, it is imperative to establish quality assurance that systematically evaluates requirements. This quality assurance process defines how validation is to be conducted and which validation techniques are to be used, including inspection, prototypes, case studies, analysis models and metrics. It also determines which quality criteria have to be met, such as completeness, consistency, testability and unambiguity. Contradictory perceptions of several different stakeholders can lead to a seeming incompatibility of requirements, which essentially stems from professional or personal conflicts. Such conflicts are to be detected, analyzed, and resolved with the help of consolidation techniques. The final results are to be properly documented.
Requirements Management entails the principles and methods of filing requirements and related relevant information in such a way that every participant can find what he or she needs. There is a wide variety of structures that offer stabilizing frameworks for managing requirements. Standardized document structures such as Volere, the V-model XT or the Standard IEEE 29148 structure have proven themselves particularly successful. SOPHIST additionally relies on the SOPHIST IVENA- and DOHA-Standardized Document Structures. In order to make specifications of a certain scale manageable, specialized Requirements Management tools are needed, which have to be customized to the company-specific development process and the specifically used Requirements Engineering methods. In practice, a model-based documentation of requirements is difficult to handle without the suitable accompanying software as well.
In order to determine the factor of usability, the analysis of requirements must take those stakeholders into consideration who will eventually be the ones using the system that is being developed. Particularly challenging in this respect are innovative systems, for which real stakeholders do not exist yet. The Persona-concept of SOPHIST USER provides a solution for that. This method manages to depict unavailable stakeholders by creating persona-profiles that help to deduce requirements for the system in development and to verify and complement the resulting artifacts regarding its usability.
In recent years, SOA (service-oriented architecture) has evolved from a buzzword to a staple IT-term. A service-oriented architecture is based on services which are supposed to be provided and used independently from each other. To specify services, a comprehensive methodical framework is necessary which defines precisely how requirements for services and further requisite components in an SOA-environment are to be elicited, documented, validated, consolidated and managed. The SOPHIST brochure RoSE (Requirements-oriented Service Engineering ) offers a concise overview of the methods of Requirements Engineering in the SOA-environment.
The introduction of Requirements Engineering is in itself a project and can, like any other project, fail, if it does not adhere to a suitable introduction strategy. It is, therefore, well worth investing time in advance in planning, selecting a team and defining the work packages, in order to develop a successful concept of marketing and knowledge transfer, for instance, and choosing the appropriate pilots.
If you have any questions to the consulting and project work of SOPHIST, we are at your disposal: from the organization and preparation to implementation and follow-up. We will be happy to help you.
+49 (0)9 11 40 900 64
+49 (0)9 11 40 900 62
Do you need more information?
Just give us a Call and let us direct you to the right contact person?
Tel: +49 (0)9 11 40 90 00
Our office hours: Monday to Thursday: Friday:
08:00 - 12:00 Uhr 08:00 - 12:00 Uhr
13:00 - 18:00 Uhr 13:00 - 17:00 Uhr
Of course you are also welcome to reach various departments directly by e-mail:
All about trainings, projects or consulting activities:
All about our job offers and your career opportunities at SOPHIST:
All about our events, marketing activities and publications:
You might also be interested in these topics: