The problems associated with teaching software engineering have been discussed in detail in a previous study (Connolly et al., 2007). Problems specifically associated with teaching requirements collection and analysis are deeply rooted in the lack of definitional conformity to what a requirement is.
The IEEE defines a requirement as “a condition or capability needed by a user to solve a problem or achieve an objective” or “a condition or capability that must be possessed by a system to satisfy a contract standard, specification or other formally imposed document.” A requirement is a statement specifying part of the required functionality of the system. One of the primary reasons that requirement capture and analysis is so problematic and complex is that a requirement can be expressed in different levels of abstraction or complexity. Sommerville (2007) emphasizes “the term requirement is not used in the software industry in a consistent way. In some cases, a requirement is simply a high-level, abstract statement of a service that the system should provide or a constraint on the system. At the other extreme, it is a detailed, formal definition of a system function” (p. 118). To combat the complication encountered by the different levels of abstraction, Sommerville (2007) distinguishes between user requirements and system requirements:
User requirements (requirements of a high level of abstraction) are “statements, in a natural language plus diagrams, of what services the system is expected to provide and the constraints under which it must operate.” (p. 118)
System requirements (requirements of a highly detailed nature describing what the system should do) “set out the system’s functions, services and operational constraints in detail. The system requirements document (sometimes called a functional specification) should be precise. It should define exactly what is to be implemented. It may be part of the contract between the system buyer and the software developers.” (p. 118)