This Article 
 Bibliographic References 
 Add to: 
Effectively Defining "Shall Not" Requirements
May/June 2010 (vol. 12 no. 3)
pp. 46-53
Jeffrey Voas, SAIC, Arlington
Phillip Laplante, The Pennsylvannia State University, Malvern

The authors review how to define a set of "negative requirements," or hazards, starting with elicitation and discovery of shall-not requirements through system integration and testing using a process called hazard mining.

1. J. Voas, "Software Hazard Mining," Proc. IEEE Symp. Application-Specific Systems and Software Eng. Tech. (ASSET'99), IEEE CS Press, 1999, pp. 180–184.
2. T. Kletz, By Accident…A Life Preventing Them, PFV Publications, 2000.
3. R. O'Neil, "Pennsylvania's 'No Jake Braking' Signs," OLR Research Report #004-R-0515, 1 July 2004;
4. M. Hsueh, T.K. Tsai, and R.K. Iyer, "Fault Injection Techniques and Tools," Computer, vol. 30, no. 4, 1997, pp. 75–82.
5. J. Voas and G. McGraw, Software Fault Injection: Inoculating Programs against Errors, John Wiley & Sons, 1998.
6. S.K. Park and K.W. Miller, "Random Number Generators: Good Ones Are Hard to Find," Comm. ACM, vol. 31, no. 10, 1988, pp. 1192–1201.
7. J. Voas et al., "Predicting How Badly 'Good' Software Can Behave," IEEE Software, vol. 14, no. 4, 1997, pp. 73–83.

Index Terms:
Methodologies, tools, Specification, real-time systems, process, General, Automatic synthesis, General, Automatic synthesis, Requirements/Specifications, Requirements Analysis, Requirements Elicitation,
Jeffrey Voas, Phillip Laplante, "Effectively Defining "Shall Not" Requirements," IT Professional, vol. 12, no. 3, pp. 46-53, May-June 2010, doi:10.1109/MITP.2009.87
Usage of this product signifies your acceptance of the Terms of Use.