Requirements have multiple levels of abstraction. For instance, Wiegers (2000) proposed a three-level structure of requirements, i.e. business requirements, user requirements, and functional requirements. Among the three levels, requirements started from a high level evolve from business requirements which concern about the business rationales and business cases. On the basis of that, user requirements are derived such as use cases, describing business processes or tasks from the user perspective. Finally, at the last level, functional requirements articulate the specific system behaviours which are the traditional “shall” statements.
In a more precise manner, Gorschek and Wohlin (2006) presented a Requirements Abstraction Model (RAM). It comprises four levels of requirements, i.e. product level, feature level, function level, and component level. Figure 1 illustrates this model. To be specific, the product level requirements are the most abstract and goal-like; and they are similar to product strategies and organizational strategies. Next, the feature level requirements are features of the intended product which should be a general description of the feature itself without details of the needed functions. Then the functional level focuses on the functional requirements (functions or actions) and non-functional requirements. Requirements at this level should be descriptive, detailed and complete enough. Finally, the component level requirements are very detailed as on the brink of solution design, i.e. how to solve something. Thus, requirements at the component level are likely to contain design decisions, focusing more on HOW than on WHAT.
Gorschek, T. & Wohlin, C. 2006. Requirements Abstraction Model. Requirements Engineering, 11, 79-101.
Wiegers, K. E. 2000. When telepathy won’t do: Requirements engineering key practices. Cutter IT Journal, 13, 9-15.