Lecture
Requirements is a specification (description) of what should be implemented.
Requirements describe what needs to be implemented, without detailing the technical side of the solution. What, not how.
Requirements for requirements:
• Correctness
• Unambiguity
• Completeness of requirements
• Consistency of requirements set
• Testability (testability)
• traceability
• Understanding
Requirements analysis is a part of the software development process, which includes the selection of software (software), their systematization, identification of interrelations, as well as documentation. In the English-speaking environment, they also talk about the discipline “requirements engineering” (English Requirements Engineering ). In the process of collecting requirements, it is important to take into account possible contradictions of the requirements of different stakeholders, such as customers, developers or users.
The completeness and quality of the requirements analysis plays a key role in the success of the entire project. Software requirements must be documented, executable, testable, with a level of detail sufficient for system design. Requirements can be functional and non-functional.
Requirements analysis includes three types of activities:
Requirements analysis can be a long and difficult process, during which many subtle psychological skills are involved. New systems change the environment and relationships between people, so it is important to identify all interested parties, take into account all their needs and ensure that they understand the implications of new systems. Analysts can use several methods to identify the following requirements from a client: conducting interviews, using focus groups, or creating lists of requirements. More modern methods include prototyping and use cases. Where necessary, the analyst will use a combination of these methods to identify the exact requirements of the stakeholders so that a system is created that satisfies business needs.
The process of analyzing information system requirements includes the following phases: [1]
A stakeholder is an individual or organization that has rights, shares, requirements or interests in relation to a system or its properties that meet their needs and expectations (ISO / IEC 15288: 2008, ISO / IEC 29148: 2011).
Stakeholder survey is a widely used technique in collecting requirements. These surveys can identify requirements that are not within the scope of the project or that contradict previously collected. However, each stakeholder will have their own requirements, expectations and vision of the system.
Requirements often have complex intersecting functionality, not known to individual stakeholders. Such requirements are often overlooked or not fully determined during their interviews. Such requirements can be identified during CPT sessions. Such sessions are conducted under the supervision of a trained specialist. Stakeholders participate in discussions to identify requirements, analyze their details and reveal hidden intersecting relationships between requirements.
The traditional way to document requirements is to create lists of requirements. In a complex system, such lists of requirements may take hundreds of pages.
The corresponding metaphor can be an extremely long shopping list in a store. Such lists are extremely ineffective in modern analysis, although they are still used today.
Benefits
disadvantages
Alternatives to large, predefined requirements lists can be user stories that define requirements in ordinary language.
Best practices view the compiled list of requirements simply as clues and constantly ask “why?” Until true business goals are revealed. After that, stakeholders and developers can develop tests that measure what level of each goal has been achieved. Such goals change more slowly than a long list of certain, but immeasurable requirements. Once a small set of critical, measurable goals is established, rapid prototyping and short development steps can provide real value to stakeholders even before the project is completed.
In the mid-1980s, prototyping was considered as a solution to the problem of requirements analysis. Prototypes - system layouts. Layouts allow users to submit a system that has not yet been built. Prototypes help users imagine what the system will look like, and make it easier for users to make design decisions without waiting for the system to complete. The greatest improvements in understanding between users and developers were often seen with the introduction of prototypes. Early system reviews lead to fewer changes in the later stages of development and therefore significantly reduce costs.
However, over the next decade, prototyping, although it was recognized as an effective technique, did not solve the problem of requirements analysis:
Prototypes can be flat diagrams (often called wireframes) or work programs that use synthetic functionality. Frameworks can be represented by graphic documents. In cases where the finished software should have a graphic design, color is removed from the frame (that is, a gray color palette is used). This helps prevent misunderstandings about the final look of the program.
Use Case (Eng. Use Case ) - a technique for documenting potential requirements for creating a new system or modifying an existing one. Each option 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 expert in the field. They are often created jointly by requirements collectors and stakeholders.
Use cases are the most important tool for modeling requirements in order to specify the functionality of the software being developed or the system as a whole. They may contain an additional textual description of all the ways users can work with the software or the system. Such a text description is called a script. As a rule, use cases answer the question “What should the system do for a specific actor (English Actor )?” Without answering the question “How should the system implement this?” In this case, the text of the script complements the graphical representation of use cases in the description form a sequence of steps or actions, following which the user can achieve the desired goal while interacting with the system. The completeness of the functional requirements for the developed system is achieved by the specification of all use cases with appropriate scenarios, reflecting all the wishes and needs of users to the developed system.
The software requirements specification (eng. Software Requirements Specification, SRS ) is a complete description of the behavior of the system to be created. It includes a number of usage scenarios that describe all types of user interaction with the software. Usage scenarios are also known as functional requirements. In addition to usage scenarios, the software specification also contains non-functional (or additional) requirements. Non-functional requirements — requirements that impose additional constraints on the system (such as performance requirements, quality standards, or design constraints).
Recommended approaches for specifying software requirements are described in IEEE 830–1998. This standard describes the possible structures, desired content, and quality specifications of software requirements.
Requirements are systematized in several ways. The following are general classifications of requirements that relate to technical management.
Clients are those who perform the basic functions of system design, with a special focus on the user of the system as a key client. User requirements will determine the main goal of the system and, at a minimum, answer the following questions:
Functional requirements explain what needs to be done. They identify the tasks or actions to be performed. Functional requirements determine the actions that the system must be able to perform, the input / output relationship in the system behavior.
Non-functional requirements - requirements that define the criteria for the operation of the system as a whole, rather than individual scenarios of behavior. Non-functional requirements define system properties such as performance, maintainability, extensibility, reliability, environmental factors of operation.
Requirements that are implied or converted from a high-level requirement. For example, a requirement for a longer range or high speed may result in a low weight requirement.
Known requirements classification models include FURPS and FURPS + developed by Hewlett-Packard.
Steve McConnell, in his book "Rapid Development" [2], describes in detail how users can prevent the collection of requirements:
This can lead to situations where user requirements continue to change, even when a system or development of a new product has been launched.
Possible problems caused by engineers and developers during requirements analysis:
One of the solutions to the problem of communication was to hire specialists in business or systems analysis.
Techniques introduced in the 1990s — prototyping, unified modeling language (UML), usage scenarios, and flexible development methodology — are also designed to solve the problems described above.
Exit criteria are criteria or requirements that must be fulfilled to accomplish a specific task or process, as used in some areas of business or science, such as software development. [one]
The term Exit-criteria is often used in "R & D" ("Research and Development"), but this can be applied to any area where Business Process Reengineering is (or can be) applied. The benefits of "business process reengineering" - including the use of terms, as this one can include: understanding goals clearly, using language (and data) carefully when it comes to (or measuring) methods for getting things done, and taking scientific an approach to assessing and improving the methods that are used.
For example, for a Fagan inspection, a low-level document must meet certain criteria, an exit- (as indicated in a high-level document) before the development process can be taken to the next stage.
In the field of telecommunications, when testing new software or hardware for release, a set of test specifications are created to test this new product to ensure that it meets the minimum acceptable operational performance. This test specification will approve the minimum criteria required for the testing process to be be considered complete, and the product is ready for release. IE: Exit from the testing phase of the program.
Eligibility criteria are important yet, in my experience, an aspect of the iterative planning process is often forgotten or underestimated. Acceptance criteria play a very important role because the projects were successful or not based on the ability of the team to satisfy its clients with documented and perceived acceptance criteria. When we clearly define acceptance criteria for the front, we avoid surprises at the end of the sprint, or release, and provide a higher level of customer satisfaction. In other words, we can answer these two important questions: Are we building the right product? And, do we build the right product?
Acceptance criteria are the conditions that a software product must satisfy in order to be accepted by the user, customer, or in the case of system level functionality, the consumer *** of the system.
Acceptance criteria are a set of statements, each with a clear fit / non-fit result, which define functional and non-functional requirements and are applied in Epic, Feature and History Level. The eligibility criteria represent our "Definition Done", and did I mean well done.
We are not talking about horsheoes here, and there is no partial recognition: either the acceptance criteria is met or not.
The trap that I call on my teams to avoid writing acceptance criteria after development has begun. This leads to simply verifying that the functionality of the inline work, rather than verifying that the functionality meets the needs of users and expectations. If we write and revise the acceptance criteria prior to the start of implementation, we are more likely to capture the client’s intent , rather than the reality of development .
Acceptance criteria determine when a work item is complete and works as expected. Acceptance criteria should be clearly stated, in simple language the client will use, without ambiguity as to the expected result. This distinguishes our success testers, as they will take our acceptance criteria and translate them into automated test cases to run as part of our continuous integration of the assembly.
Another trap that I train my teams to avoid is “like a trap. Acceptance criteria should indicate intent, but not a solution (for example,“ The user can approve or reject the account ”and not” the user can click the checkbox to approve the score "). The criteria should be implementation independent, and discuss what is expected, not how the functionality will be implemented.
Considering / If / Then format is a useful way to define eligibility criteria:
Given some preconditions When I do some actions Then I expect some result
When we write acceptance criteria in this format, it not only provides a consistent structure, but we also help determine when testers start and end testing for this particular work item.
It is sometimes difficult to build acceptance criteria using a given, when, then format. In particular, when working with user stories at the system level. In those cases, I found that using the checklist checker works well.
Another advantage to checking control charts is that they are also easy to individually mark as complete as we implement the functionality.
What are some of the problems or methods you found when writing eligibility criteria?
Comments
To leave a comment
Quality Assurance
Terms: Quality Assurance