Experiences in the Adoption of Requirements Engineering

Keywords Experiences in the Adoption of Requirements Engineering
Standards groups

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.

Date published
Document type
technical white paper
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!
File attachments

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.

Visit also