This field addresses issues that revolve around getting customers to state exactly what their requirements are. Programs large and small still fail to reach closure on this step, in spite of adequate effort. Other Programs each closure, but do not capture all the requirements. This is perhaps the area of requirements engineering with the highest incidence of malpractice. Software engineers all agree that requirements elicitation is important, yet they uniformly spend too little time performing it.
Requirement elicitation is the only requirements engineering field without a definitive technical solution, yet good informal solutions exist. The lack of technical solutions is expected because the elicitation problem is human in nature. The issue is that the customers often cannot state what the requirements are because they either do not know what they want, are not ready to fully define what they want, or are unable, due to outside influences, to decide what they want. The FAA sidebar above outlines the classic example of this last behavior.
Defines standard
Replaced/Superseded by document(s)
Cancelled by
Amended by
| File | MIME type | Size (KB) | Language | Download | |
|---|---|---|---|---|---|
| Paper-Experiences in Adopting RE paper6.pdf | application/pdf | 270.57 KB | English | DOWNLOAD! |
Provides definitions
Abstract
It has been known since as early as the 1950s that addressing requirements issues improves, the chance of systems development success. In fact, whole software development standards (such as MIL-STD-2167, MIL-STD-2167A, MILSTD-498, and IEEE/EIA 12207) were designed to enforce this behavior for software-intensive systems. Relatively recently (sidebar), a new field of study, requirements engineering, has begun to systematically and scientifically address barriers to the successful use of requirements in systems development.