Orthogonal Defect Classification-A Concept for In-Process Measurements
IEEE Transactions on Software Engineering - Special issue on software measurement principles, techniques, and environments
Proceedings of the Conference on The Future of Software Engineering
A case study in root cause defect analysis
Proceedings of the 22nd international conference on Software engineering
Erroneous Requirements: A Linguistic Basis for Their Occurrence and an Approach to Their Reduction
SEW '01 Proceedings of the 26th Annual NASA Goddard Software Engineering Workshop
Operational anomalies as a cause of safety-critical requirements evolution
Journal of Systems and Software
Empirical Analysis of Safety-Critical Anomalies During Operations
IEEE Transactions on Software Engineering
Empirical Analysis of Safety-Critical Anomalies During Operations
IEEE Transactions on Software Engineering
Ongoing Requirements Discovery in High-Integrity Systems
IEEE Software
Automatically discovering properties that specify the latent behavior of UML models
MODELS'10 Proceedings of the 13th international conference on Model driven engineering languages and systems: Part I
Automatically exploring how uncertainty impacts behavior of dynamically adaptive systems
ASE '11 Proceedings of the 2011 26th IEEE/ACM International Conference on Automated Software Engineering
Trace queries for safety requirements in high assurance systems
REFSQ'12 Proceedings of the 18th international conference on Requirements Engineering: foundation for software quality
| Hi-index | 0.00 |
This paper describes the role of requirements discovery during the testing of a safety-critical software system. Analysis of problem reports generated by the integration and system testing of an embedded, safety-critical software system identified four common mechanisms for requirements discovery and resolution during testing: (1) Incomplete requirements, resolved by changes to the software, (2) Unexpected requirements interactions, resolved by changes to the operational procedures, (3) Requirements confusion by the testers, resolved by changes to the documentation, and (4) Requirements confusion by the testers, resolved by a determination that no change was needed. The experience reported here confirms that requirements discovery during testing is frequently due to communication difficulties and subtle interface issues. The results also suggest that "false positive" problem reports from testing (in which the software behaves correctly but unexpectedly) provide a rich source of requirements information that can be used to reduce operational anomalies in critical systems.