Lecture
The topic of requirements in software engineering, development, and systems testing is a fundamental and integral part of the process of creating high-quality and effective products. Software development and systems engineering begin with defining what must be created and how this is to be achieved. This is where requirements come into play, serving as a bridge between the customer's vision and the final result.
In this review we will delve into the world of requirements, examining their analysis, various types, key attributes, and their connection to SWEBOK (Guide to the Software Engineering Body of Knowledge). We will analyze how requirements form the fundamental basis for development, provide an understanding of the functional and non-functional aspects of projects, and contribute to the effective management of the entire development lifecycle. Our study will cover not only the essence of requirements, but also how their analysis and proper management affect the success of projects and the compliance of the resulting products with customer expectations and software engineering standards.
Let's consider the following questions:
A requirement — is a specification (description) of what must be implemented.
Requirements describe what needs to be implemented, without detailing the technical side of the solution. What, not how.
Requirements for requirements:
Requirements analysis — is part of the software development process that includes gathering software requirements, systematizing them, identifying relationships, and documenting them. In English, this discipline is also known as Requirements Engineering. When gathering requirements, it is important to take into account possible contradictions between the requirements of different stakeholders, such as customers, developers, or users.
The completeness and quality of requirements analysis play a key role in the success of the entire project. Software requirements must be documentable, feasible, testable, and detailed enough for system design. Requirements can be functional and non-functional.
Requirements analysis includes three types of activity:
Requirements analysis can be a long and difficult process, in the course of which many subtle psychological skills come into play. New systems change the surrounding environment and relationships between people, so it is important to identify all stakeholders, take all their needs into account, and ensure that they understand the implications of the new systems. Analysts can use several methods to elicit the following requirements from the customer: conducting interviews, using focus groups, or creating requirement lists. More modern methods include building prototypes and use cases. Where necessary, the analyst will use a combination of these methods to elicit the precise requirements of stakeholders so that the resulting system satisfies business needs.
The process of analyzing requirements for an information system includes the following phases:
A stakeholder — is an individual or organization having rights, a share, requirements, or interests with respect to a system or its properties that satisfy their needs and expectations (ISO/IEC 15288:2008, ISO/IEC 29148:2011).
Surveying stakeholders is a widely used technique when gathering requirements. Such surveys can reveal requirements that fall outside the scope of the project or that contradict previously gathered ones. However, each stakeholder will have their own requirements, expectations, and vision of the system.
Requirements often have a complex, overlapping functional purpose that is not known to individual stakeholders. Such requirements are often missed or not fully defined during their surveys. Such requirements can be uncovered by holding JRD sessions. Such sessions are conducted under the supervision of a trained facilitator. Stakeholders take part in discussions to define requirements, analyze their details, and reveal hidden, overlapping relationships between requirements.
The traditional way to document requirements — is to create requirement lists. In a complex system, such requirement lists can run to hundreds of pages.
A fitting metaphor would be an extremely long shopping list at a store. Such lists are extremely inefficient in modern analysis, although they are still used to this day.
Advantages
Disadvantages
Alternatives to large, predefined requirement lists can be found in user stories, which define requirements in plain language.
Best practices use a compiled requirement list simply as a prototype and repeatedly ask the question «why?», until the actual business goals are uncovered. Stakeholders and developers can then design tests to measure what level of each goal has been achieved so far.
Such goals change more slowly than a long list of well-defined but unmeasurable requirements. Once a small set of critical, measurable goals has been established, rapid prototyping and short development stages can deliver real value to stakeholders even before the project is finished.
In the mid-1980s, prototyping (prototyping) was seen as the solution to the requirements analysis problem. Prototypes — are mock-ups of a system. Mock-ups let users envision a system that has not yet been built. Prototypes help users imagine what the system will be like and make it easier for users to make design decisions without waiting for the system to be finished. The greatest improvements in mutual understanding between users and developers have often been observed with the introduction of prototypes. Early reviews of the system lead to fewer changes at later stages of development and consequently significantly reduce costs.
However, over the following decade, prototyping, although recognized as an effective technique, did not solve the requirements analysis problem:
Prototypes can be flat diagrams (often called wireframes) or working programs using synthetic functionality. Wireframes can be presented as graphic documents. In cases where the finished software must have a graphic design, color is removed from the wireframe (that is, a grayscale palette is used). This helps prevent misunderstandings about the final look of the program.
A use case (Use Case) — is a technique for documenting potential requirements for creating a new system or modifying an existing one. Each use case describes one or more ways the system interacts with the end user or another system to achieve a specific goal. Use cases usually avoid technical jargon, preferring instead the language of the end user or a domain expert. They are often created jointly by requirements analysts and stakeholders.
Use cases — are the most important tool for modeling requirements for the purpose of specifying the functionality of the software or system being developed as a whole. They may contain an additional textual description of all the ways users can work with the software or system. Such a textual description is called a scenario. As a rule, use cases answer the question «What must the system do for a specific actor (Actor)?», without answering the question «How must the system implement this?» In this case, the scenario text supplements the graphical representation of the use case in the form of a description of the sequence of steps or actions that a user can follow to achieve the desired goal while interacting with the system. Completeness of the functional requirements for the system being developed is achieved by specifying all use cases with the corresponding scenarios, reflecting all the wishes and needs of the users of the system being developed.
The software requirements specification (Software Requirements Specification, SRS) is a complete description of the behavior of the system to be created. It includes a set of use cases that describe all types of user interaction with the software. Use cases are also known as functional requirements. In addition to use cases, the software specification also contains non-functional (or supplementary) requirements. Non-functional requirements — are requirements that impose additional constraints on the system (such as performance requirements, quality standards, or design constraints).
Recommended approaches for the specification of software requirements are described by the IEEE 830—1998 standard. This standard describes possible structures, desirable content, and qualities of a software requirements specification.
Requirements are systematized in several ways. Below are general classifications of requirements relating to technical management.
Customers are those who perform the primary functions of system design, with special emphasis on the system's user as the key customer. User requirements define the main goal of the system and, at a minimum, answer the following questions:
Functional requirements explain what must be done. They identify the tasks or actions that must be performed. Functional requirements define the actions the system must be capable of performing, the input/output relationship in the system's behavior.
Non-functional requirements — are requirements that define the criteria for the operation of the system as a whole, rather than individual behavioral scenarios. Non-functional requirements define system properties such as performance, maintainability, extensibility, reliability, and environmental factors of operation.
Requirements that are implied by, or transformed from, a higher-level requirement. For example, a requirement for greater range or higher speed may lead to a requirement for low weight.
Known requirement classification models include FURPS and FURPS+, developed at Hewlett-Packard.
Steve McConnell, in his book «Rapid Development», describes in detail how users can hinder the gathering of requirements:
This can lead to a situation where user requirements keep changing even after the system or the development of a new product has already begun.
Possible problems caused by engineers and developers during requirements analysis:
One solution to the communication problem was to hire specialists in business or systems analysis.
Techniques introduced in the 1990s — prototyping, the Unified Modeling Language (UML), use cases, and agile development methodology — are also intended to solve the problems described above.
Exit criteria are the criteria or requirements that must be met to complete a particular task or process, as used in some areas of business or science, such as software development.
The term exit criteria is often used in "R and D" ("Research and Development"), but it can be applied to any area where business process reengineering is (or can be) applied. The benefits of "business process reengineering" include the use of terminology: a clear understanding of goals, the use of language (and data) when discussing (or) measuring methods for getting things done, and taking a scientific approach toward evaluating and improving the methods being used.
For example, to verify the quality of programs using the Fagan method, low-level documents must meet certain criteria, exit criteria (as specified in the higher-level document), before the development process can be accepted into the next stage.
In the telecommunications field, when testing new software or hardware for release, a set of test specifications is created to test the new product and ensure it meets the minimum acceptable operating characteristics. This test specification will state the minimum criteria required for the testing process to be considered complete and the product ready for release, i.e.: exiting the testing phase of the program.
Are we building the product? And are we building the product right?
Acceptance criteria are important, yet in my experience, often a forgotten or underestimated aspect of the iterative planning process. Acceptance criteria play a very important role, because projects have succeeded or failed based on the team's ability to satisfy their customers' documented and perceived acceptance criteria. When we clearly define acceptance criteria, we avoid surprises at the end of the sprint, or the release, and ensure a higher level of customer satisfaction. In other words, we can answer these two important questions: Are we building the right product? And, are we building the product right?
Acceptance criteria are the conditions that a software product must satisfy in order to be accepted by the user, the customer, or, in the case of system-level functionality, the consuming system.
Acceptance criteria represent a set of statements, each with a clear pass/fail outcome, that define functional and non-functional requirements and are applied at the Epic, Feature, and Story levels. Acceptance criteria represent our "Definition of Done", and by Done I mean Done well.
Moreover, partial acceptance is not possible: either the acceptance criteria are satisfied or they are not.
A pitfall that I urge my teams to avoid is writing acceptance criteria after development has already begun. This leads to simply checking that the built functionality works, rather than verifying that the functionality meets user needs and expectations. If we write and review acceptance criteria before implementation begins, we are more likely to capture the customer's intent rather than the reality of development.
Acceptance criteria define when a work item is complete and functions as expected. Acceptance criteria should be expressed clearly, in plain language the customer would use, without ambiguity about the expected result. This is what sets our testers up for success, since they will take our acceptance criteria and translate them into automated test cases to run as part of our continuous integration build.
Another pitfall I coach my teams to avoid is the "how" trap. Acceptance criteria should specify intent, but not the solution (for example, "The user can approve or reject an invoice", rather than "the user can click a checkbox to approve an invoice"). Criteria should be independent of implementation, and discuss what is expected, rather than how the functionality will be implemented.
The Given / When / Then format is a useful way to define acceptance criteria:
Given some preconditions When I perform some action Then I expect some result
When we write acceptance criteria in this format, it not only provides a consistent structure, but it also helps determine when testers start and finish testing for that particular work item.
Sometimes it is difficult to construct acceptance criteria using the given-when-then format. This is particularly true when working with user stories at the system level. In those cases, I have found that using a verification checklist works well.
Another advantage of verification checklists is that they are also easy to mark off individually as complete as we implement the functionality.
What are some of the problems or techniques you have found when writing acceptance criteria?
Ian Sommerville & Pete Sawyer
A requirement – is a specification of what is to be obtained.
Requirements describe the behavior of a system, or the attributes and properties of a system.
Requirements can also act as constraints on the process of developing a system
L. Novikov, in the Russian edition of the Rational Unified Process notation
Requirements – are separate (discrete) statements that together form a coherent picture
A requirement can describe particular characteristics or properties of a software product
A requirement can itself have a set of properties (attributes)
Requirements can have a complex structure of relationships and connections (for example, hierarchical)
SWEBOK defines the structure of the «Software Requirements» knowledge area and identifies the main activities involved in the development and management of requirements
Product and Process Requirements – parameters relating to the product or to the process of its creation
SWEBOK Functional and Non-functional Requirements
: functional requirements specify “what” the system must do, i.e. they describe the functions performed by the software; functional requirements are often presented in the form of scenarios (use cases); non-functional requirements impose certain constraints, i.e. under “what conditions” (for example, response speed when performing a given operation)
Independent or general properties (Emergent Properties) – these properties denote requirements that are addressed to the system as a whole and cannot be attributed to its individual elements. That is, such requirements relate to the synergistic effect that such a system may possess («the whole is greater than the sum of its parts»). An example would be a requirement for the «throughput» of a call center, which will depend on how the communications equipment, the operator, and the software interact under specific conditions.
Quantifiable Requirements – requirements that can be quantitatively defined/measured, for example, the system must provide a throughput of “so many requests per second”; at the same time, it is extremely important to understand that framing the question (that is, formulating the requirement) as “the system must provide increased throughput” without specifying particular quantitative characteristics is simply an improperly defined requirement.
System Requirements and Software Requirements – this division is based on the definition of a “system” given by INCOSE (International Council on Systems Engineering): “a combination of interacting elements <created> to achieve defined purposes; may include hardware, software, firmware, other means, people, information, techniques (approaches), services, and other supporting elements”; thus it is implied that a system is a broader concept than software and includes the environment in which the software operates as such; from this, naturally, follow requirements for the system as a whole and for the software (or software system) in particular. Often, in the literature on requirements management, system requirements are described as “user requirements”; SWEBOK restricts the use of the term “user requirement” to requirements for the end-user/customer system
To manage requirements changes today, an approach formulated by the American software engineer and IT consultant Karl Wiegers is often used. The main content of K. Wiegers's approach is set out in his book «Software Requirements».
When creating an information system, two types of requirements are distinguished: functional and non-functional. Wiegers identifies three types of functional requirements:
However, as practice has shown, functional requirements alone are not enough for the system, since a system built on their basis alone will not satisfy all business requirements. In this regard, K. Wiegers identifies three types of non-functional requirements for the system:
It is worth noting separately that in his work K. Wiegers pointed out the difference in the sources used to form functional and non-functional requirements. Thus, the main sources for forming functional requirements are the functional descriptions of automation objects, company departments, roles, etc. Non-functional requirements, in turn, can be formulated on the basis of quality characteristics. The process of forming requirements is built on the basis of a survey of the enterprise, including interviews with employees and stakeholders, observation of the work process, questionnaires, etc.
Business requirements contain the high-level tasks and goals of the developing organization or of the system's customers. As a rule, they are voiced by those who fund the project, the buyers of the system, the manager of the actual users, or the marketing department. These requirements explain why the organization needs such a system, or, in other words, describe the goals that the organization intends to achieve with its help. Business requirements are recorded in the corresponding section of the Software Requirements Specification, although they may also be recorded in the form of a vision and scope document, which is sometimes also called the project charter or the market requirements document
User requirements describe the goals and tasks that the system will allow users to accomplish. Excellent ways of representing this type of requirement include use cases, scenarios, and «event – response» tables. Thus, user requirements define what customers will be able to do with the help of the system. Classification of requirements
System requirements define the functionality and characteristics of the system that developers must build so that users can accomplish their tasks (within the scope of the business requirements). The term system requirements denotes high-level requirements for products that contain many subsystems, that is, systems (IEEE, 1998 c). By system, we mean the software or the subsystems of software and hardware. People – are part of the system, so certain system functions may extend to people as well. Classification of requirements
Functional requirements define the functions performed by the system, and depend on user needs and the type of task being solved. Functional user requirements describe functions in a generalized form. By elaborating these requirements, developers form a more detailed and precise description of the system's services – functional system requirements. Special attention must be paid to the precise description of requirements when documenting them. Inaccuracies in the description will be interpreted differently by users and developers. Such a situation will lead to the development of new requirements or the modification of existing ones, and, consequently, to changes in the system and its increased cost. A requirements specification containing user and system requirements must be comprehensive and consistent. It must define all the functions of the system, and there must be no incompatible or mutually exclusive function definitions. Classification of requirements
Non-functional requirements define the characteristics and constraints of the system and are not directly related to functional requirements. They are formed on the basis of existing quality attributes, external interface requirements, and constraints. Non-functional requirements are divided into: non-functional product requirements, non-functional process requirements, and external non-functional requirements
Business rules include corporate policies, government regulations, industry standards, and computational algorithms. Business rules are not requirements for software, because they lie outside the boundaries of any software system. However, they often impose constraints, determining who may perform particular use cases, or dictating what functions the system must have in order to comply with the relevant rules. Sometimes business rules become a source of quality attributes that are realized in functionality. Business rules – are one of the main sources of functional requirements for software, since they determine the capabilities the system must have in order to enforce the rules. Classification of requirements
Facts – are simply true statements about the business, often describing links and relationships between important business terms. Facts are also called invariants – immutable truths about data entities and their attributes. Examples of facts: every product bears a unique barcode; delivery is paid for every order; every order line item contains data about the product and its price.
Constraints – define what operations the system and its users can perform. Here are some words and phrases that are often used to describe a restrictive business rule: must, cannot, and only. Most likely, the organization has security policies that define the procedure for accessing information systems. They usually state which passwords should be used, how often they must be changed, whether old passwords may be reused, and so on. All these restrictions on access to the application can be considered business rules.
Operation triggers. A rule that, under certain conditions, causes some action to be performed is called an operation trigger. A person can perform these actions independently. Alternatively, the rule can control certain program functions, thanks to which the application implements the desired behavior model when certain conditions are met. The conditions that determine whether an operation is executed are sometimes a complex combination of «true» and «false» values that hold for several separate conditions. An expression of the form «If <some condition is true or a certain event has occurred>, then <something will happen>», – is a sign that describes an operation trigger. .
Inference, sometimes also called inferred knowledge, is a rule that establishes new facts based on the truth of certain conditions. An inference creates a new fact based on other facts or calculations. Inferences are often written in the «if – then» format, which is also used for writing business rules that trigger operations; however, the «then» part of an inference contains a fact or assumption rather than an action. Here are a few examples of inferences: if a payment has not been received within 30 calendar days of the invoice being sent, the invoice is considered overdue; if a supplier cannot deliver the ordered goods within five days of receiving the order, the order is considered unfulfilled.
Computations. Computers perform calculations, and therefore one class of business rules defines calculations performed using mathematical formulas and algorithms. Many calculations are performed according to rules external to the enterprise, for example, income tax withholding formulas. Unlike operation-triggering business rules, which sometimes require creating specific functional requirements for the software in order to be implemented, calculation rules, in the form in which they are expressed, can be directly treated as software requirements. Business rules for calculations can be presented in text form or in symbolic form, for example as mathematical expressions, but presenting such rules as a table is much clearer than a long list of complex text expressions.
Non-functional product requirements define its operational qualities, i.e., they define how well the system will work. Such characteristics are often called software quality attributes or factors. The main difficulty is that quality attributes are hard to define (identify), they cannot be measured, and they strongly affect the implementation of the system.
Quality attributes are an additional description of the product's functions, expressed through a description of its characteristics that are important to users or developers. Such characteristics include ease and simplicity of use, portability, integrity, efficiency, and fault tolerance.
There is a large number of quality attributes.
For example, the ISO 9126 standard proposes evaluating software products according to six quality characteristics, recommending the use of 21 quality indicators (sub-characteristics). This same standard advises taking into account that perceptions of quality differ for different groups of stakeholders, citing as an example the perceptions of quality held by users, developers, and project managers.
Availability refers to the planned up time during which the system is actually available for use and fully operational. Formally, availability is equal to the system's mean time to failure (MTTF) divided by the sum of the mean time to failure and the expected time to recover the system after a failure.
Efficiency is a measure of how efficiently the system uses processor performance, disk space, memory, or connection bandwidth.
Flexibility. This attribute is also called extensibility, augmentability, or scalability. Flexibility shows how easily new capabilities can be added to the product.
Integrity, which also includes security, is related to blocking unauthorized access to system functions, preventing information loss, protecting the software from viruses, and protecting the confidentiality and security of data entered into the system.
Interoperability shows how the system exchanges data or services with other systems. To assess interoperability, you need to know which applications clients will use alongside your product, and what data exchange is expected.
Reliability is the probability that the software will run without failures for a certain period of time. Fault tolerance is sometimes considered one of the characteristics of reliability. Indicators such as the percentage of successfully completed operations and the mean time the system runs before a failure are used to measure software reliability.
Fault tolerance, sometimes also called failure resilience, is the degree to which a system continues to correctly perform its functions despite incorrect input data, deficiencies in connected software or hardware components, or unexpected operating conditions.
Convenience and ease of use. This attribute is related to a host of factors that form the basis of what users often describe as user-friendliness. Convenience and ease of use are measured by the effort required to prepare input data, operate the system, and obtain the final output information.
Ease of maintenance. This attribute shows how convenient it is to fix errors or modify the software. Ease of maintenance depends on how easy it is to understand how the software works, change it, and test it, and is closely related to flexibility and testability. This indicator is extremely important for products that undergo frequent changes and for those that are created quickly (and possibly with savings on quality).
Portability. Its measure can be considered the effort required to move the software from one operating environment to another. Portability is often also taken to include the ability to internationalize and localize the product.
Reusability. A constant challenge in software development – reusability – measures the effort required to convert software components for further use in other applications. The cost of developing software with reuse capability is significantly higher than that of creating a component that will only work in one application. It must be modular, well documented, independent of specific applications and the operating environment, and also possess certain universal capabilities.
Testability. This attribute is also called verifiability, and it shows how easily software components or the integrated product can be checked for defects.
Most quality attributes conflict with each other, and for certain combinations of them trade-offs are unavoidable. Users and developers must decide which attributes are more important than others and adhere to these priorities when making decisions.
The table below reflects the relationships between the most common quality attributes. A «+» sign in a cell means that increasing the value of the attribute in the corresponding row has a positive effect on the attribute in the corresponding column. A «-» sign in a cell means that increasing the value of the attribute in that row has a negative effect on the attribute in the corresponding column. An empty cell means that the attribute in that row has little effect on the attribute in the column.
Positive and negative relationships between quality attributes
Process non-functional requirements depend on the policies and organizational procedures of the customer and the developer. They define constraints related to the use of specific technologies and development standards, implementation constraints, such as the use of a specific programming language and design methods, documentation requirements, deadlines for producing the software product, and so on.
External non-functional requirements take into account factors external to the system and its development process. They define the interaction of the system being designed with other systems, personnel qualification requirements, legal requirements, logistical requirements, environmental requirements, ethical, environmental, and similar requirements.
Quality criteria for individual statements of the requirements specification
Quality criteria for the requirements specification as a whole
Quality criteria for individual statements of the requirements specification
Completeness
A requirement is complete if and only if it contains all the information necessary to develop the corresponding functionality that should be implemented in the product.
If, in the process of developing requirements, some data is missing, the «TBD» (to be determined) mark should be used in the margin as a standard flag to highlight such a place. All gaps in each fragment of the requirements must be filled in before the requirements specification is finally approved.
Correctness
A requirement is correct if and only if it represents something required of the product being created.
Feasibility
A requirement is feasible if and only if it can be implemented within the known constraints of the product being created and its operating environment, including the agreed timeframe and budget.
Necessity
A requirement is necessary if and only if it reflects a capability that is genuinely needed by users or that is required to comply with external system requirements or standards. In addition, the requirement must originate from a person who has the authority to formulate requirements.
Ordering by importance and stability All requirements must be ordered by their importance to the customer and their stability. This ordering process is especially important for scope management. If resources are insufficient to implement all requirements within the allotted time and budget, it is useful to know which requirements are not so mandatory and which the customer considers critical.
Unambiguousness A requirement is unambiguous if and only if it can be interpreted in only one way. If the wording of a requirement can be interpreted differently by developers, users, and other project participants, it may well turn out that the system built will be completely different from what the customer envisioned.
Verifiability Requirements must be verifiable. A requirement as a whole is considered verifiable if and only if each of its constituent elementary requirements is verifiable. An elementary requirement is considered verifiable if and only if there exists a finite, cost-effective process by which a person or a machine can determine that the developed software system actually satisfies the given requirement. The practical task is to define requirements in such a way that they can subsequently be tested to determine whether they are actually being met.
Quality criteria for the requirements specification as a whole
Completeness A set of requirements is complete if and only if it describes all the important requirements of interest to users, including requirements related to functional capabilities, performance, design constraints, attributes, or external interfaces.
Consistency A set of requirements is consistent if and only if no subset of it, consisting of individual requirements, contradicts other subsets. Conflicts can take various forms and appear at different levels of detail.
Modifiability A set of requirements is modifiable when its structure and style are such that any change to the requirements can be made simply, completely, and consistently, without violating the existing structure and style of the entire subset. This requires that the requirements package have minimal redundancy and be well organized, with an appropriate table of contents, indexes, and cross-referencing capability.
Traceability A set of requirements is traceable when the origin of each of its constituent elementary requirements is clear and there is a mechanism that makes it possible to refer back to these requirements during further development activities. Traceability is extremely important. Developers can use it both to achieve a better understanding of the project and to provide a higher degree of confidence that all requirements are being met.
Priorities – is a way of resolving the conflict between competing requirements for limited resources. Determining the relative priority of each capability makes it possible to plan development so as to provide the greatest value at the lowest cost. Prioritization is most critical when working within very tight time constraints.
The project manager must balance the desired project scope against constraints determined by schedule, budget, human resources, and quality. One way to achieve this is to remove (or defer to a later version) low-priority requirements when new, more important requirements are accepted or other project conditions change.
Participating in prioritizing requirements is one of the customer's responsibilities in the «customer – developer» relationship. Discussing priorities helps not only to determine the order in which requirements are implemented, but also to clarify customer expectations. Both customers and developers should contribute to prioritizing requirements.
Customers need the functions that are most valuable to the business or to ease of work. However, once developers outline the costs, effort, technical risk, or trade-offs associated with each requirement, customers may change their minds and conclude that the requirement is not as important as they initially thought. Developers, in turn, sometimes decide to implement certain low-priority functions at an early stage because of their impact on the system architecture.
When assessing priorities, take into account the connections and relationships between different requirements, as well as their alignment with the project's business goals.
One approach to assessing priorities proposes taking into account two dimensions: importance and urgency. Each requirement is considered either important or not important, and either urgent or not urgent. This produces four combinations for defining the priority scale:
High-priority requirements – both important (users need the functions) and urgent (they are needed already in the next release). Some requirements have to be included in this category due to contractual or legal obligations, or for compelling business reasons.
Medium-priority requirements – important (users need the functions), but not urgent (they can wait for the next release). Low-priority requirements – not important (users can do without this function if necessary) and not urgent (users can wait, indefinitely even).
Requirements in the fourth cell seem urgent, but in reality they are not important. Do not waste time working on them – they will not make the product more valuable.
Thus "Requirements" play a critical role in the software development process and systems engineering. Here are a few key takeaways on this topic, including the analysis and types of requirements, attributes, and a reference to SWEBOK (Guide to the Software Engineering Body of Knowledge).
Types of requirements:
Requirement attributes:
SWEBOK (Guide to the Software Engineering Body of Knowledge): SWEBOK is a reference guide that defines the knowledge and skills required for the professional practice of software engineering. It includes an extensive body of knowledge and practices related to requirements, design, development, testing, and project management in the field of software engineering.
Requirements analysis: The requirements analysis process includes gathering, documenting, analyzing, and managing requirements. Requirements analysis helps determine which requirements are critical, which can be changed, and how they are interrelated.
In conclusion, requirements play a key role in the software development lifecycle and are important for achieving successful project outcomes. Their analysis, proper documentation, and management are essential for ensuring the quality of the developed system and its compliance with customer needs and software engineering standards. SWEBOK is a valuable resource for software engineering professionals, providing a common framework for defining the necessary knowledge and skills.
Comments