Downloaded 31 times
Uploaded byRa'Fat Al-Msie'deen
Requirements validation - requirements engineering
This document discusses requirements validation and techniques for validating requirements. It defines requirements validation as checking that requirements define the system the customer wants. Validation is important because fixing requirements errors later is very costly. The document describes various checks that can be performed on requirements like validity, consistency, completeness, and verifiability. It also outlines techniques for validation like requirements reviews, prototyping, and test-case generation. Finally, it notes that validating requirements is difficult and some problems may still be found after validation.
More Related Content
Similar to Requirements validation - requirements engineering
Requirements validation - requirements engineering
- 1. Chapter 1 –Requirements Engineering Requirements Engineering Mutah University Faculty of IT, Department of Software Engineering Dr. Ra’Fat A. AL-msie’deen https://sites.google.com/site/ralmsideen/ rafatalmsiedeen@mutah.edu.jo 1
- 2.
- 3. Requirements validation Requirementsvalidation is the process of checking that requirements define the system that the customer really wants. It overlaps with elicitation and analysis, as it is concerned with finding problems with the requirements. Requirements validation is critically important because errors in a requirements document can lead to extensive rework costs when these problems are discovered during development or after the system is in service. 3
- 4. Requirements validation …cont. The cost of fixing a requirements problem by making a system change is usually much greater than repairing design or coding errors. A change to the requirements usually means that the system design and implementation must also be changed. Furthermore, the system must then be retested. 4
- 5. Requirements validation …cont. Concerned with demonstrating that the requirements define the system that the customer really wants. Requirements error costs are high so validation is very important Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error. 530/10/2014
- 6. Requirements checking Duringthe requirements validation process, different types of checks should be carried out on the requirements in the requirements document. These checks include: Validity checks These check that the requirements reflect the real needs of system users. Because of changing circumstances, the user requirements may have changed since they were originally elicited. 6
- 7. Requirements checking …cont. During the requirements validation process, different types of checks should be carried out on the requirements in the requirements document. These checks include: Consistency checks Requirements in the document should not conflict. That is, there should not be contradictory constraints or different descriptions of the same system function. 7
- 8. Requirements checking …cont. During the requirements validation process, different types of checks should be carried out on the requirements in the requirements document. These checks include: Completeness checks The requirements document should include requirements that define all functions and the constraints intended by the system user. 8
- 9. Requirements checking …cont. During the requirements validation process, different types of checks should be carried out on the requirements in the requirements document. These checks include: Realism checks By using knowledge of existing technologies, the requirements should be checked to ensure that they can be implemented within the proposed budget for the system. These checks should also take account of the budget and schedule for the system development. 9
- 10. Requirements checking …cont. During the requirements validation process, different types of checks should be carried out on the requirements in the requirements document. These checks include: Verifiability To reduce the potential for dispute between customer and contractor, system requirements should always be written so that they are verifiable. This means that you should be able to write a set of tests that can demonstrate that the delivered system meets each specified requirement. 10
- 11. Requirements checking …cont. Validity. Does the system provide the functions which best support the customer’s needs? Consistency. Are there any requirements conflicts? Completeness. Are all functions required by the customer included? Realism. Can the requirements be implemented given available budget and technology Verifiability. Can the requirements be checked? 11
- 12. Requirements validation techniques A number of requirements validation techniques can be used individually or in conjunction with one another: Requirements reviews The requirements are analyzed systematically by a team of reviewers who check for errors and inconsistencies. 12
- 13. Requirements validation techniques… cont. A number of requirements validation techniques can be used individually or in conjunction with one another: Prototyping This involves developing an executable model of a system and using this with end-users and customers to see if it meets their needs and expectations. Stakeholders experiment with the system and feed back requirements changes to the development team. 13
- 14. Requirements validation techniques… cont. A number of requirements validation techniques can be used individually or in conjunction with one another: Test-case generation Requirements should be testable. If the tests for the requirements are devised as part of the validation process, this often reveals requirements problems. If a test is difficult or impossible to design, this usually means that the requirements will be difficult to implement and should be reconsidered. Developing tests from the user requirements before any code is written is an integral part of test-driven development. 14
- 15. Requirements validation techniques… cont. Requirements reviews Systematic manual analysis of the requirements. Prototyping Using an executable model of the system to check requirements. Test-case generation Developing tests for requirements to check testability. 1530/10/2014
- 16. Abstract analysis ofrequirements You should not underestimate the problems involved in requirements validation. Ultimately, it is difficult to show that a set of requirements does in fact meet a user’s needs. Users need to picture the system in operation and imagine how that system would fit into their work. It is hard even for skilled computer professionals to perform this type of abstract analysis and harder still for system users. 16
- 17. Requirements changes &requirements problems As a result, you rarely find all requirements problems during the requirements validation process. Inevitably, further requirements changes will be needed to correct omissions and misunderstandings after agreement has been reached on the requirements document. 17
- 18. Requirements reviews Regularreviews should be held while the requirements definition is being formulated. Both client and contractor staff should be involved in reviews. Reviews may be formal (with completed documents) or informal. Good communications between developers, customers and users can resolve problems at an early stage. 1830/10/2014
- 19. Review checks Verifiability Is the requirement realistically testable? Comprehensibility Is the requirement properly understood? Traceability Is the origin of the requirement clearly stated? Adaptability Can the requirement be changed without a large impact on other requirements? 1930/10/2014
- 20. Reference - TextBook: Software Engineering (l0th Edition) - by Ian Sommerville. Addison Wesley, 2015, ISBN-10: 0137035152. Chapter 4. 20
- 21. Chapter 1 –Requirements Engineering Requirements Engineering Mutah University Faculty of IT, Department of Software Engineering Dr. Ra’Fat A. AL-msie’deen https://sites.google.com/site/ralmsideen/ rafatalmsiedeen@mutah.edu.jo 21