UNIT 8 MANAGEMENT OF PRIORITIZATION REQUIREMENTS AND TECHNIQUES Flashcards
What does requirements management mean and what does it entail?
Requirements management (RM) includes all measures necessary to document, change, and track requirements and requirements-related artifacts. Requirements engineering
(RE) is particularly important in the run-up to projects in which the focus is on mechanical or software engineering, as the aim here is to capture the knowledge and experience of
the stakeholders and use insight-driven processes to produce a new solution, product, or software system.
Typically, requirements proliferate and evolve over the course of a project. For this reason, requirements have a life cycle with varying statuses. To ensure that functionality and quality have been implemented correctly, it must be possible to trace how requirements define features and quality. Requirements must also be traceable because they form the basis of a contract.
The requirements define what is to be delivered as part of the system development, and some requirements are applied in different ways for the product to succeed. Some are part of the basic functionality, and their absence can lead to user dissatisfaction and the product’s purpose being defeated. If some requirements are ignored or implemented
incorrectly, the product can be rejected. Therefore, it is important to have explicit requirements in place so they can easily be traced.
RM is a core activity of RE. It begins with the determination of the requirements and affects the further processes of the development work. The challenge is managing the large number of individual requirements without error. This is often several hundred to several thousand that are selected, documented, tested, and agreed upon.
What are some properties requirements should have in Requirements Management, which factors should be considered and what statuses they might have?
To make requirements traceable throughout the entire software process, they must have certain properties. These properties are noted as the attributes (metadata) of a requirement. Depending on the set of requirements, attributes can be managed manually or by computer and are referred to as requirements metadata. Typical attributes include:
* unique identifier (ID),
* name, and
* description of a requirement by text or by graphics.
In later stages, other attributes, such as the relative effort required to implement the requirement, can be added. The following factors must also be taken into consideration
when developing requirements:
* Requirements are created by an author and originate from a source.
* Requirements evolve to some degree, and their evolution is documented by a version number. Information to be included with the changes are the date, reason for the changes, and the name of the person making the changes.
* Priority of the requirement should be documented using must have, should have, could have, won’t have (MoSCoW) or legally binding attributes, such as “must,” “shall,” “should,” or “nice to have” in order to indicate which requirements can
be dropped or delivered with a lower quality in case of, for example, scarcity of time or budget due to Agile principles in project management.
* The urgency of the requirements can be determined using a numerical value (for example, from 0=low to 5=urgent) to signal the sequence for implementation, ensuring that
they are accurately prioritized.
The status of requirements can be documented by combining the stability and specification attributes. Typical statuses include:
* recorded. The requirement is determined and documented, but not reconciled.
* in coordination. The requirement is in the coordination process, but has not yet been coordinated because, for example, conflicts still need to be resolved.
* approved. The requirement is final (until new changes occur) and ready for implementation.
* implemented. The requirement has already been implemented. Changing this requirement will start a Request for Change (RfC) and may require separate approval pro-
cesses.
Traceability can be significantly improved if the history of the attributes can be traced back, e.g., by keeping a table that shows which status changes were made and for what
reason.
Why are different requirements viewed with tables, tools, or graphs?
Since requirements are defined in large numbers for a system, and the information about a requirement can be very extensive, views of requirements are created.
A view on a set of requirements always serves a specific reporting purpose and can be created specifically for a certain addressee (e.g., management). Requirements management tools create these views automatically through filters or database queries.
A selective view of requirements displays only a portion of the total information available for a requirement. For example, certain requirements can be selected, or individual attributes can be hidden.
What is the versioning of requirements?
The versioning of requirements helps with the traceability of changes and enables the requirements engineer to access specific change states. The identification is done via a
unique version number. Smaller changes are recorded by incremental increases after the decimal point, while larger changes are recorded by whole number changes before the
decimal point.
Sometimes, it is necessary to link the totality of all valid requirements (usually the last versions of the requirements) to a requirement configuration, also named “release,” e.g., in
order to be able to document the development of the requirements over different releases of a software.
Describe the Life Cycle of Requirements in the Software Development Process.
At every change in the development process, there is a unique version of each requirement, which belongs to a clearly-defined release. Each requirement should belong to at least one release. When changing requirements, the
requirements manager should consider whether to update an existing release or create a new release.
Requirements determine the functional scope of a system and define the quality aspects and constraints of any software development project. All downstream phases in the software process are based on the requirements. It is therefore important to be able to trace the development of requirements in the software process. Based on the requirements, expenditures can be estimated, or one can examine whether the required functionality was converted. Requirements therefore have a life cycle in which they take different conditions.
At first, requirements are usually included in a request for proposal, i.e., they are formulated abstractly as a project vision. When the project is started, the requirements are
roughly specified, i.e., selected and documented. After the initial selection, the requirements are detailed and fine-tuned so that the customer can accept the specification. This
means that the requirements are the basis for the functional and technical specifications. These then form the contractual basis for the service to be delivered. Based on the specifications, test cases have already been created in parallel or can now be added, which serve to check the implementation of the requirements. It is advantageous to use automatic test environments that check the code units for correctness during implementation, and then later test and document the new release in its entirety—if necessary, with the interfaces to other systems—against the specified test cases in the integration test. If the new functions are not installed in a single new release for all customers, this will significantly increase the maintenance and servicing effort needed for the various releases. It is more efficient to
create only one new release, and, if required by the customer, make the new features available only to users belonging to this customer.
It is also advisable to perform integration and functional tests on the customer’s test environment in a production-like environment before going live. If the tests fail, then the
errors must be corrected and the test cases repeated. Only after the customer accepts the changes, usually by executing and checking off the test cases in a list, can the new system be put into production. It is recommended to observe intensely and provide highly-available services in the care period after the start of a productive operation.
Why is it important to prioritize requirements?
There are various facets to consider when prioritizing requirements. First, it is important to consider whether a requirement should be fulfilled in every case, or whether minor changes in quality are acceptable. Second, the order in which the functions should be made available needs to be taken into account. Third, the urgency of the attribute or the
sequence number after the process, including fulfillment time, should be defined. Prioritization tends to change throughout the course of a project. This is normal because the set of functional requirements is subject to revision, and the technical or organizational framework conditions are often adjusted. In the final phases of the project, it is often necessary to identify, from the list of known defects, the most important ones that need to be fixed with the resources that are still available. In each of these situations, requirements must be prioritized. Thus, the order in which the tasks will be implemented must be determined each time.
To determine the priority of a requirement, various factors must be taken into account. The financial value of a requirement expresses its contribution to making money or reducing costs. The costs (e.g., for the development effort, hardware, paid services, licenses, or support) influence the priority just as much as the risk incurred by a difficult requirement. In addition, dependencies between requirements can influence he order in which they are processed. Weighing the prioritizing factors is the task of the
requirements manager. An important factor for determining the priority of a requirement is customer satisfaction, which can be expressed in Kano categories.
If a risk associated with a requirement is higher than its value, the risk takes priority. Laws pose a risk to the project if they are not implemented or are implemented incorrectly in an information system. In this case, the risk should be weighted more heavily than the value of another requirement. Customer satisfaction also has a significant influence on the value of a requirement. If a stakeholder does not accept the system because it lacks basic functionality, the value of the system decreases. Dependencies can influence priority so that, instead of implementing requirements with the highest value, requirements are implemented in an order determined by the dependency.
What is the MoSCoW Method Technique for Prioritizing Requirements?
The categorization of requirements according to the MoSCoW method makes prioritization clear. Prioritization is determined by labeling requirements with the key words “must have,” “should have,” “could have,” and “won’t have,” which serve to explicitly state the legal necessity.
Categorization within the circle of stakeholders can be difficult because everyone wants as many requirements as possible to be fulfilled. Since the focus of Agile implementation is on adherence to budget and schedule with a flexible scope, categorization provides the basis for decisions with the aim of not fulfilling requirements, or fulfilling them with lower quality (in the sense of, for example, longer response times or missing functions while preparing search results.).
What is the Value-Risk Matrix Technique for Prioritizing Requirements?
A simple technique for prioritizing requirements is the value-risk matrix. This is done by comparing the value of a requirement to its risk. The value-risk matrix is explained by a simple graph with the risk (y-axis) and value (x-axis) ranging from low to high. There are four quadrants in the graph: avoid implementation, last to be implemented, implement second, and implement first. To determine the priority of a requirement, each requirement must be placed in exactly one field.
Requirements with low value and high risk are avoided. If both value and risk are low, these requirements are implemented last. Requirements with high value and low risk generate a rapid increase in value and are therefore processed first. Requirements that have high value and high risk are to be implemented second. The granularity, in which value and risk are quantified, can be an arranged variable. The more gradations in the evaluation, the more precisely the priority of a requirement can be determined, but it comes with a greater effort to determine the category and an increased risk of misjudgment.
An advantage of the value-risk matrix is its simplicity. However, customer satisfaction and dependencies are not explicitly considered. In addition, there is also the possibility that many requirements have a high value and carry a high risk, so it cannot be decided which requirements should be first. In order to prioritize the most important requirements in more detail, they can be classified according to their influence on customer satisfaction using the Kano types.
Describe the Customer Satisfaction According to Kano and how it relates to Prioritizing Requirements.
The Kano model classifies requirements in terms of importance to stakeholders. It differentiates between basic, performance, and delight attributes. Basic attributes are taken for granted by stakeholders and, if they are not implemented, this can result in extreme dissatisfaction. Performance attributes are basic, but explicitly required, requirements, in which the implementation leads to stakeholder satisfaction. Delight attributes are unexpected requirements that the stakeholder perceives as a pleasant surprise.
The definition of basic, performance, and delight attributes regularly evolve because stakeholders grow accustomed to functionality and, after a while, take it for granted. The
“undo” function serves as an example. It was perceived as a true innovation, eventually becoming a standard part of programs because it made work noticeably easier. Shortly
after the “undo” function was established as an integral part of systems, it began to be explicitly demanded (performance attribute). Nowadays, this function is a basic attribute; no stakeholder will explicitly demand it, but they will still require and expect its implementation.
Explain the Team Estimation Game Technique for Prioritizing Requirements.
In the concrete planning of requirements, prioritization by a linear order is useful. This means that all requirements are numbered completely, and no number is assigned more than once. The requirement with the smallest number has the highest priority, and all following priorities result from the ascending order. By listing activities or requirements this
way, the order in which they must be processed is clearly defined.
To reach an agreement on the order as quickly as possible while involving multiple people, the Team Estimation Game is a useful tool. The result of the Team Estimation Game is
a list, whereby the sorting criterion can be freely defined. Examples of possible criteria are relevance, effort, size, and complexity. Thus, the Team Estimation Game can be applied in any situation where a set of items needs to be put into an order.
In preparation for the workshop, the activities or requirements to be prioritized must each be written or printed on a card or piece of paper. These cards are then placed on the table face-down in a pile.
The first card is turned over and placed face-up on the table (preparation). The first player then turns over the second card and places it either to the left or to the right of the card
already on the table, depending on whether they consider the second card to be more or less important than the first (first move). The second player now has two options: Draw a
new card from the deck and place it between the cards already face-up, or switch the two cards that are already face-up if the player thinks they are in the wrong place. Then it is the next player’s turn. As soon as the last card from the pile of face-down cards has been dealt, the players only have the option to exchange cards. This happens until none of the
players want to swap anymore.
In what order should you use prioritization of requirement techniques if dealing with many stakeholders?
If a large number of requirements need to be ranked, the techniques presented can be combined. In a first step, the importance of the requirements can be pre-categorized using the MoSCoW method. Then, the must-have requirements are entered into a value-risk matrix. The most valuable and riskiest requirements can be classified according to Kano. If the classification according to Kano and the classification in the value-risk matrix does not result in a sufficiently prioritized list of requirements, the most important requirements can still be put in order by using team estimation. Based on the order, it can be determined which requirements will be implemented next.
