About Levels of Requirements – Level of Design Focus

Requirements have level of abstraction, which implies that requirements at a top level usually can be decomposed and refined into requirements at a lower level. Apart from that, there is another dimension about the levels of requirements, and that is the level of design focus.

Specifically, it is conventional and widely accepted that requirements should state the ‘what’ rather than ‘how’; and the main purpose for doing so is to avoid limiting the subsequent design freedom. However, this separation presents a dilemma (Davis, 1993), which is in the same spirit of the later argument, ‘your what is my how’ (Davis, 2003; Whalen, 2013). More specifically, a requirement can be viewed as a design solution. The distinction lies in the perspective of which level of system decomposition the requirement is viewed at, since systems have hierarchical structures and so are requirements. For instance, viewing the user needs as the ‘what’, the decomposed, application-specific hardware or functional requirements can be regarded as the corresponding ‘how’. Subsequently, the functional requirements allocated to a specific component define its ‘what’, the technical design, the ‘how’, and so on. In this sense, a decomposed, lower-level requirement is a solution designed to meet its upper-level requirement(s). Therefore, when requirements are broken down into sub-requirements or parts with more details, these details added by various stakeholders may then be design decisions. Therefore, the detail embodied in a requirement may be in a level as design. Some requirements may have a strong design focus or even are in fact design decisions.

Back in the 90’s with the presence of COTS components and products, Shekaran and Tremlett (1992) observed a phenomenon at the time that RE became more of a design and integration process. This design in their view is the process of decomposition of functionality into subsystems and the subsequent coordination while integration the recomposition of those already-existed subsystems and/or COTS. Regarding that phenomenon, Siddiqi and Shekaran (1996) suggested that design-level artefacts such as COTS components should be considered and handled in the RE process. Consequently, RE involves a “design-like” task to evaluate alternative strategies for realizing requirements (Siddiqi and Shekaran, 1996), such as deciding whether to employ COTS components or to build in-house.

On the contrary, Ralph (2013) expressed his concern of the expanded meaning of the term requirements. He pointed out the current understanding of this term both in practice and in research has drifted away from being compulsory into a much broader and general interpretation. To this respect, he emphasized that design decisions are often mislabelled as requirements. In his view, requirements should indicate those essential and indispensable features without which goals cannot be achieved.

Besides, Weber and Weisbrod (2002) reported that no clear line between user requirements and system requirements is one challenge facing them in the automotive development. To make the distinction clear, user requirements provided by the customer define the problem(s) while system requirements specified by the supplier describe the abstract solutions to those problems. That no clear line between them is challenging because in their domain it is not practical to specify user requirements without bringing up details in the solution space. As a result, they observed several problems such as missing important information or having system requirements in user requirements specification, or requirements engineers not knowing which specification a given requirement should be put into.

Based on the descriptions above, balancing the levels of requirements is problematic. On the one hand, requirements should be specified at an appropriate level of abstraction for / from corresponding stakeholders, such as in the automotive domain user requirements from customers while system requirements from suppliers. Yet on the other hand, some requirements decisions have to be made only after certain design decisions are made. Furthermore, people are often solution oriented and one’s design may be another’s requirements. Consequently, the resulting requirements may contain various design decisions while neglecting the real problem, and thus hamstring the development.

Regarding this issue, it has been suggested for years that requirements engineers or business analysts should be careful that “no design decision should be arbitrarily made which unnecessarily restricts the design freedom of the next phase of the development cycle. This means that the techniques, formats, and means of presenting the requirements must not inadvertently introduce unintentional design choices.” (Alford, 1979).

However, in the field study by Hansen et al. (2009), they found that balancing the levels of requirements remains a critical issue in large software-intensive systems development. This issue then is still worth investigating for improving requirements decision making.


Alford, M. 1979. Software Requirements Engineering Methodology, Wiley Online Library.

Davis, A. M. 1993. Software requirements: objects, functions, and states, Prentice-Hall, Inc.

Davis, A. M. 2003. System phenotypes. Software, IEEE, 20, 54-56.

Ellis-Braithwaite, R., Lock, R., Dawson, R. & King, T. 2015. Repetition between stakeholder (user) and system requirements. Requirements Engineering, 1-24.

Hansen, S., Berente, N. & Lyytinen, K. 2009. Requirements in the 21st century: Current practice and emerging trends. Design requirements engineering: A ten-year perspective. Springer.

Ralph, P. 2013. The illusion of requirements in software development. Requirements Engineering, 18, 293-296.

Shekaran, M. C. & Tremlett, J. F. Reasoning about integration issues during requirements definition: a knowledge-based approach. Proceedings of the Second International Conference on Systems Integration, 15-18 Jun 1992 1992. 229-239.

Siddiqi, J. & Shekaran, M. C. 1996. Requirements Engineering: The Emerging Wisdom. IEEE Software, 13, 15-19.

Weber, M. & Weisbrod, J. Requirements engineering in automotive development-experiences and challenges. IEEE Joint International Conference on Requirements Engineering, 2002 2002. 331-340.

Whalen, M. W. G., Andrew; Cofer, Darren; Murugesan, Anitha; Heimdahl, Mats P. E.; Rayadurgam, Sanjai 2013. Your “What” Is My “How”: Iteration and Hierarchy in System Design. IEEE Software, 30, 54-60.

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>