UNIT 1 FUNDAMENTALS AND TERMS OF REQUIREMENTS ENGINEERING Flashcards
How do Rupp and Die SOPHISTen define a goal in Requirements Engineering?
Rupp and Die SOPHISTen (2014) define a goal as the
intentional description of a characteristic feature of the system in development or the
associated development project desired by stakeholders.
How are goals integrated in an Agile development system?
In Agile projects carried out using Scrum, goals appear at
different levels. The requirements engineer should set goals for the entire system development in order to give the project direction and purpose. These goals should not be changed in an Agile project without careful consideration, even if the method used to achieve them can be Agile. Justified goal changes are, of course, possible, just as they are in non-Agile projects. Agile projects have sprint goals in addition to system goals; at the beginning of each sprint, the goal is defined between the Product Owner and the team. The goal should be
achieved in one sprint and is regarded as a stage goal. In Agile system development, in addition to the business goals or visions, the overall aim is to deliver executable software
to the customer at the end of each iteration.
How is Requirements Engineering defined by upp and Die
SOPHISTen and what are its goals?
Rupp and Die SOPHISTen (2014) define requirements engineering (RE) as a collaborative, iterative, incremental process. Its goal is to ensure that:
* all relevant requirements are known and understood to the required level of detail.
* all requirements are documented according to the documentation requirements, or
specified according to the specification requirements.
* the involved stakeholders agree on the known requirements.
What are the “stakeholders”?
RE activities always involve several people or groups who must cooperate with each other. Specifically, these are people whose sphere of work is affected by, or comes into contact with, the system being created. One must also consider those whose work is involved in the creation process of the system. All affected or involved persons are called “stakeholders.”
What are “iterations” in Requirements Engineering and why are they necessary?
RE is not a single activity that can be completed at the beginning of a software project; it occurs in multiple cycles (called iterations). By performing RE activities multiple times,
requirements for the system are elicited and refined. Since software engineering is a knowledge-driven process, RE usually takes place throughout the project.
What is the purpose of requirements during a software project?
The requirements specification usually forms the basis for the tender and subsequent contract design. Furthermore, the system is tested based on the requirements specification when it has been accepted. Only a deviation of the actual state from the target state described in the requirements specification is considered a defect, and objections can be made. Requirements serve as the basis for:
* communication,
* determination of rationalization potentials,
* optimization of customer benefit,
* tendering and contract design,
* system architecture,
* testing and acceptance,
* system integration and maintenance,
* troubleshooting and further development, and
* increasing employee and customer satisfaction.
What are two examples of projects that didn’t take requirements as insurance?
- Toll Collect in Germany: it had big goals: the state was supposed to collect several billion euros annually, beginning in August, 2003. Due to various technical difficulties and the
complex and complicated construction, the system could not be put into operation until the beginning of 2005, 16 months late. As of 2021, contractual penalties and lost revenue are being claimed, and some of these issues are still being negotiated. - Denver baggage debacle: A new automated baggage system was meant to be used at the opening of the new airport
in Denver. Among other things, it consisted of a rail network, thousands of baggage carts and engines, and hundreds of computers. However, the system did not have enough fault
tolerance, there were network problems, the software was too complex, and the cost of the realization was far higher than initially estimated. The opening of the airport was delayed by 16 months, which added USD 560 million to the cost of the airport.
Name and describe some Requirements Engineering management practices.
- Problem management: is a process that is responsible for the sustainable resolution and prevention of problems and disruptions, which is achieved by addressing these issues in normal operations. An incident is an event that leads to, or could lead to, the interruption of an information technology (IT) service. The analysis focuses on identifying the underlying causes of a malfunction and recording them in problem records. Problem management recommends changes by submitting requests for change (RfC) to change management.
- Incident management: aims to quickly restore the normal operation of an IT service when an incident occurs, resulting in minimal impact on users or the productivity of a company.
- Change management: aims to manage RfCs efficiently and avoid negative effects on service quality due to changes. Change management activities include managing, documenting, and authorizing RfCs based on impact analyses, as well as planning and coordinating the implementation of changes.
- Innovation management: is a combination of the management of innovation processes and change management.
- Systematic innovation: processes require systematic documentation to provide sufficient data for the cost-benefit analysis and ensure that new concepts are well thought out and
confirmed. - Business process analysis: aims to analyze and document the processes within an organization to find obstacles, bottlenecks, and shortcomings. This helps organizations prepare corrections.
- Portfolio management: is the art and science of selecting and overseeing a group of investments, activities, or projects that meet the long-term objectives of a company. IT portfolio management is a planning discipline that deals with the successful compilation of service offerings (i.e., the portfolio). Portfolio management sets the first, sometimes already detailed, requirements for the system.
How would an iteration process of Requirements Engineering look like?
Business requirements -> Stakeholder requirements* -> Solution requirements -> Transition requirements
* Documentation -> Reconcilement
During an iteration process what is the purpose of requirements documentation?
The goal of the “documentation” activity is to ensure that the current state of knowledge is secured for all stakeholders and everyone involved can obtain an overview at any time. If parts of a software or hardware product are produced and delivered by several companies, the requirements specification flows into the contracts between the involved parties, including test cases for the acceptance of the deliveries. It is therefore desirable to document the requirements using tools that cover the entire requirements life cycle in an automated manner.
What is the traceability of requirements changes?
This is the ability to track the relationships between sets of requirements and designs, from the original stakeholder need to the actual implemented solution.
What are the 3 levels of maturity that a requirement can have?
The Knowledge Areas of the Software Engineering Body of Knowledge (SWEBOK) defines three maturity levels of requirements:
1. The information does not need to be complete or coordinated. Examples may be sufficient.
2. The information should be reliable and resilient; however, it does not have to be complete.
3. The information should meet all quality criteria for good requirements. Particular emphasis is placed on completeness and correctness.
What is the relationship between problem, requirement and system?
Requirements describe necessary functions and properties of a system needed to solve a problem, and the problem describes what will be changed or achieved in the real world. The problem or technical question is usually independent of requirements and solutions. There are always several approaches to solving a problem. The requirements form the relationship between the problem and the solution by describing concrete properties of the solution in order to solve the problem. This also means that
requirements can never be formulated, or are difficult to formulate, independently of the concrete solution idea. Therefore, a definition of the solution determines the formulation of the requirements, though this may be premature.
What are the major types of requirements?
- Functional requirements that concern the result of a behavior to be provided by a function of the system (or component of a service)
- Quality requirements, including a more detailed description of quality, such as response times of a software, minimum availability, time for restart, maximum data
loss in case of failure, validation, or verification of the software - Constraints or requirements that limit the solution space beyond what is necessary to meet the given functional and quality requirements
- Non-functional requirements, can be sorted into:
* technological requirements. A requirement to provide the desired function of specific technologies, techniques, hardware, and software may be understood as constraint.
* user interface requirements. These include the design according to internal or generally accepted design features and the use of end devices with different operating systems, browsers, etc. These may be understood as quality requirements, such as requirements for the scope and language of documentation.
* legal-contractual requirements. Examples include delivery time, guarantee and warranty periods, and contractual penalties.
* maintenance requirements. This category includes requirements such as like the handling of incidents, the designation of response times, and repair times.
What are the main types of requirements for the International Institute of Business Analysis (IIBA)?
- Business requirements are “statements of goals, objectives, and outcomes that describe why a change has been initiated. They can apply to the whole of an enterprise, a business area, or a specific initiative”.
- Solution requirements “describe the capabilities and qualities of a solution that meets the stakeholder requirements. They provide the appropriate level of detail to allow for the development and implementation of the solution. Solution requirements can be divided into two sub-categories”. The sub-categories are functional and non-functional.
- Transition requirements “describe the capabilities that the solution must have and the conditions the solution must meet to facilitate transition from the current state to the future state, but which are not needed once the change is complete”. They also cover “data conversion, training, and business continuity”.
