About Levels of Requirements – Level of Abstraction

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.

 

RAM abstraction levels, reproduced from (Gorschek and Wohlin, 2006)

Figure 1. RAM abstraction levels, reproduced from (Gorschek and Wohlin, 2006)

 

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.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>