This paper describes our practical experiences in setting and working with
requirements for a piece of security software. Principally, it
discusses the conflicts that occurred between the ease of putting the
initial requirements on paper and the difficulty in applying them.
The requirements were not formally specified, but the process of
turning them into code followed our standard software development
process. However, the informality of the requirements was not the
primary source of our conflicts; we believe that ambiguity always
exists, ambiguity leads to assumptions, and assumptions are what lead
to flaws -- some of which may cause security vulnerabilities.
By explaining our journey through the software development process, we
show how seemingly obvious and easily stated requirements lead to
ambiguity, choices, and the need for revisiting specifications
throughout the process. We conclude with some recommendations from
our experiences that we hope will be useful to other practitioners.
Proceedings of the 1st Symposium on Requirementes Engineering for Information Security
Key alpha
kuperman2001ambiguity
Organization
CERIAS and NCSU E-Commerce and ACM
Publisher
CERIAS, Purdue University
Affiliation
Hewlett-Packard and CERIAS, Purdue University
Publication Date
1900-01-01
Keywords
ambiguity, intrusion detection, specifications
BibTex-formatted data
To refer to this entry, you may select and copy the text below and paste it into your BibTex document. Note that the text may not contain all macros that BibTex supports.
