Requirements errors are deficiencies in requirements documentation that can hinder software development if not addressed. There are several types of requirements errors, including errors of omission, commission, clarity/ambiguity, and performance. Requirements errors are costly to fix and can negatively impact stakeholders if the resulting software does not meet real user needs. It is better to prevent requirements errors through techniques like joint application development, quality function deployment, prototyping, requirements inspections, and ensuring domain understanding and stakeholder participation during the requirements engineering process.

1. 1
Requirements Errors
Lecture # 14

2. 2
Today’s Topics
• Requirements errors
• Addressing requirements errors

3. 3
Requirements Errors

4. 4
Requirements Error/Defect
• A deficiency in the requirements
quality that can hamper software
development

5. 5
Requirements Errors - 1
• Errors and omissions find their way in
different requirements documents
• If not removed, requirements errors
usually flow downstream into design,
code, and user manuals

6. 6
Requirements Errors - 2
• It is difficult to detect requirements
errors once they flow downstream
• Requirements errors are most
expensive to eliminate

7. 7
Software Development Process
software
requirements
preliminary
design
detailed
design
coding
unit
testing
integration
testing
system
testing
delivery
production
deployment
maintenance
and
enhancement
software
system test
planning
integration
test
planning
unit test
planning
1
2
3
4
5
6
7 8
9
10
11
12
MIL-STD-2167A

8. 8
Types of Requirements Errors
• Errors of omission
• Errors of commission
• Errors of clarity and ambiguity
• Errors of speed and capacity

9. 9
Errors of Omission
• Errors of omission are most common
among requirements errors
• Domain experts easily forget to convey
domain knowledge to requirements
engineers, because they consider that
to be obvious and implicit

10. 10
Errors of Clarity and Ambiguity
• Second most common errors are those
of clarity and ambiguity
• Primarily, because natural languages
(like English) are used to state
requirements, while such languages are
themselves ambiguous
• For example: object

11. 11
Errors of Commission
• Errors of commission can also find
their way into the requirements
documents

12. 12
Performance Errors
• Performance, that is errors of speed
and capacity, are also found in
requirements
• Primarily, these occur due to
conflicting understanding or competing
needs of different stakeholders

13. 13
Negative Impact of Requirements
Errors - 1
• The resulting software may not satisfy
user’s real needs
• Multiple interpretations of
requirements may cause disagreements
between customers and developers,
wasting time and money, and perhaps
resulting in lawsuits

14. 14
Negative Impact of Requirements
Errors - 2
• Negative impact on humans
– Unsatisfied customers and developers
– Lack of interest in automation of
processes
– Blame game

15. 15
Addressing Requirements Errors
• Prevention
• Removal

16. 16
Prevention vs. Removal
• For requirements errors, prevention is
usually more effective than removal
• Joint application development (JAD),
quality function deployment (QFD), and
prototyping are more effective in defect
prevention
• Requirements inspections and prototyping
play an important role in defect removal

17. 17
Defect Prevention - 1
• Don’t let defects/errors become part of
the requirements document or
requirements model in the first place
• How is it possible?
• Understanding application domain and
business area is the first step in defect
prevention

18. 18
Defect Prevention - 2
• Training in different requirements
engineering activities (elicitation, analysis
and negotiation, specification, and
validation) is also very important for defect
prevention
• Allocating enough time to conduct
requirements engineering activities also is
very important in this regard

19. 19
Defect Prevention - 3
• Willing and active participation of
stakeholders in different activities of
requirements engineering. That is why
JAD is very useful in defect prevention
as far as requirements errors are
concerned

20. 20
Defect Prevention - 4
• An overall commitment to quality and
emphasis on using documented
processes is also a very important
• An overall commitment to process
improvement

21. 21
Summary
• Introduced the concept of requirements
errors and types of requirements errors
• Discussed the impact of requirements
errors
• Discussed error prevention in
requirements

22. 22
References
• ‘Requirements Engineering: Processes
and Techniques’ by G. Kotonya and I.
Sommerville, John Wiley & Sons,
1998
• Software Quality: Analysis and
Guidelines for Success by Capers
Jones