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.

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.

Software Architects as Stakeholders in Requirements Engineering

Stakeholders are the main source of requirements. There are different types of stakeholders, e.g. customers who pay for the product, clients who pay for the development of the product, end-users, policy makers, developers. They have diverse backgrounds, interests, and personal goals. From the definition “stakeholders include anyone with an interest in, or an effect on, the outcome of the product”, two general categories of stakeholders can be seen: stakeholders with an interest, mostly residing in the business / problem world, for instance customers, end-users, who mainly function as the requirements providers that define the product; stakeholders with an effect, mostly residing in the software engineering / solution world, for instance clients, developers, who mainly function as the requirements refiners or constrainers that refine or constrain the product. Although clients also have an interest in the product, their requirements (e.g. time, scope or budget) are more likely to constrain the product rather than define the product.

Conventionally, we have paid more attention on those stakeholders who have an interest in the outcome of the product. Consequently, requirements elicitation is usually user-centred and user-requirements-focused. Users and the like seem to be the main stakeholders involved. However, there is another type of stakeholders that matter as well, especially for the context of enterprise systems where one IT project usually impacts multiple systems. And that type of stakeholder is software architects. They may not be the source of requirements (but sometimes they do, e.g. they may propose certain features maybe because the current technology enables that) but they definitely contribute to requirements by refining them.

To treat software architects as stakeholders and involve them up-front in the requirements phase will benefit the IT project in at least the following ways:

1. Provide an overarching support for Business Analysts, especially when they do not have enough knowledge about the existing IT systems
2. Produce more realistic requirements and less requirements rework later on
3. Better alignment between the existing IT capabilities and the business ask

More on how architects as stakeholder in requirements engineering will be talked about in the follow-up posts.

Architecturally Significant Requirements in Practice: One Case Where ASRs Get Overlooked

In this article I will describe one case in practice where Architecturally Significant Requirements (ASRs) are so important but being overlooked. As a consequence, it brings down product quality and meanwhile increases costs of follow-up projects. The lessons learned include: it is very important to specify and emphasize ASRs in the requirements specification early to ensure the right Architectural Design Decisions (ADDs) be made.

Here is some background information for the case. The company has a Web-Based Application One (WBA1) for indirect customers (resellers and distributors) to quote and order the company’s products and services. WBA1 generates WBA1 Quote and indirect customers can quote with Special bids, Promotions and Programs which is implemented in the Special Bids Application (SBA) and Promotions and Programs Application (PPA). There is another Web-Based Application Two (WBA2) which is recently developed for indirect customers to quote and order the company’s Cloud Services particularly.

Now, there is a new project to enhance the WBA2 for enabling indirect customers to quote with Special Bids, Promotions and Programs. However, WBA2 currently generates its own type of quote which is different from the type of quote generated by WBA1. So WBA2 cannot directly and simply reuse the existing applications SBA and PPA because of its incompatible type of quote. But then, it is also too costly to write another application to deal with them. Besides, duplicating the same functionality will result in difficulties for maintenance. Consequently for the new project, the BA has to explicitly specify and emphasize that all quotes that WBA2 generates must be changed to WBA1 Quote type even though nothing will be changed by this requirement from the user’s perspective. This change of quote type shall also take place in scenarios when changing existing WBA2 Quotes or renewing existing WBA2 orders.

Therefore, this new project contains some rework for a previously-made wrong design decision. To some extent, it is a fix to an “error” made in a previous project. This rework or error could be avoided if the earlier project(s) for WBA2 could specify that “WBA2 shall be able to reuse existing SBA and PPA functionality in future releases” or “WBA2 shall allow indirect customers to quote with Special Bids, Promotions and Programs in future releases”. Thus, by considering this requirement, the solution architect would have had made much better decisions, i.e. “Generate WBA1 Quote for every quote created in WBA2”, at the very beginning.

Requirements Practice: Different Requirements Processes for Different Project Situations

In this article I will describe three different requirements processes that co-exist in one IT department for three different project situations respectively. The three processes distinct from each other in some small ways. Firstly, those who write the requirements documentation are different groups of people. Secondly, there are different levels and amount of user involvement and also IT development team’s involvement. Thirdly, there are different levels of details contained / required in the requirements documents.

To begin with the introduction of the three requirements processes here let me explain some background information. The projects that the IT department works on are mainly in-house development. And the main systems involved include ERP systems and e-Commerce tools used by customers (direct customers, resellers, partners, distributors). Process P1 is the process for IT project prepackaging where the main output contain: a Business Requirements Specification (BRS), a High-Level Design (HLD), a High-Level Estimation (HLE), and also a resource / capacity planning and budget control.

Project situation one: normal IT projects that go through P1 – this type of projects constitutes the majority of all IT works.

Corresponding requirements process and requirements characteristics: Typically, four main stages of work are involved in this process: preparation, requirements workshops, requirements reviews, and sign-off. In the preparation, the main tasks include understanding the project request documentation. Then the requirements workshops are led by the BAs to elicit requirements with various stakeholders (mainly from other departments within the organization, e.g. Sales, Finance, Services, specific application teams – those applications are ones that will be affected by the project). The requirements process is conducted by Team BA (Business Analyst), but in the course of defining requirements, no development team is assigned to that project yet.

For this type of projects, requirements in BRS might end up to be very detailed if

  • the Application Team involved knows very little about the system(s) in scope because then they will ask BAs to specify every detail step by step;
  • or if the business team (e.g. from Services, Finance) know very well about the system(s) in scope because then they would provide so much detailed information to the BAs – they could even do the BAs’ job to specify the requirements…

Or the requirements might be much less-detailed if the application team (usually the technical lead) say that they know very well about the system(s) in scope and they would like BAs to treat those system(s) as black box. Hence it is only those relatively high-level requirements needed to be specified.

Project situation two: Special IT projects that are very important or urgent that could not wait to go through P1 and then will go through a Fast Track.

Corresponding requirements process and requirements characteristics: The process should be similar to the process for project situation one.  And the requirements are done by folks from the Team BA as well. But it seems the business and the BAs are working more closely with the development (to be confirmed this later).

Project situation three: Special IT projects that are based on the Voice of Customers, which are usually small enhancements to current tools and will release in a monthly basis.

Corresponding requirements process and requirements characteristics: The process for doing requirements in this situation looks simpler than the other two types of projects, partly because the scope and volume of requirements are much smaller. Requirements are documented by an individual that is always responsible for this one iterative project but he is not managed by Team BA. He takes over some initial set of requirements (prioritized already) from the folks responsible for the Voice of Customers. Then he works with corresponding stakeholders to discover and decide on requirements details. The resultant requirements documentation is called BRS and is supposed to follow the BRS template. But in reality the real BRS for these projects are very different than those in the other two project situations. There is usually no use case in the BRS and the requirements are much more technical. All too often, there is no one single core application that the BRS will focus on since it is enhancements towards all current tool used by customers. Very often, there is even a developer assigned for each enhancement to be made.

Why to Distinguish Architecturally Significant Requirements

Requirements are decisions that are made about “what does the system do”. Architecturally Significant Requirements (ASRs) are those requirements that “have a measurable impact on the software system’s architecture [1]”. In this sense, requirements are considered from a solution perspective. As a matter of fact, nowadays requirement decision-making is better not to be separated from the solution space.  Here why I think we should distinguish ASRs will be explained from the following two aspects:

Why the traditional and popular distinction of functional requirements and non-functional requirements is not good enough. To address this aspect, at least two points can contribute to that.

Firstly, capturing requirements in terms of functional requirements and non-functional requirement is not enough for architecting. To make architectural decisions, one needs to consider functional requirements and non-functional requirements more or less simultaneously. However, the current practice often separates them in the requirements specification and very often emphasizes functional requirements at the cost of non-functional requirements. Moreover, most of what is in a requirements specification do not impact the architecture while the critical requirements get ignored. Consequently, the resulting specification presents neither adequate information nor good structure to ease architects’ efforts for design.

Secondly, the categorization as functional requirements and non-functional requirements can cause confusions. To begin with, a requirement can belong to both types – interchangeable. For example, “The system shall encrypt all communication data going through the Internet” – this requirement addresses both security concerns and also functionality. Furthermore, both types of requirements can be interleaved. For example, a usability requirement stating that “the system shall provide help within 3 seconds if a user asks for help in a particular context” may very likely raise a functional requirement as “the system shall provide a link to the help subsystem in every user interface”. Last but not the least, both types of requirements share the same set of anchors of influences. Those anchors include conceptual components, layers, the whole or sub system, or technically a concrete class, a method or a set of methods within the same class or across different classes. Those characteristics between functional and non-functional requirements do not provide architects a straight-forward and clear view of requirements that matter for architecting.

What benefits we can get when distinguishing ASRs. So far, I think there are at least two benefits.

Firstly, distinguishing ASRs facilitates the utilization of the relationship between ASRs and Architectural Design Decisions (ADDs) so that advances the co-development of requirements and architecture. Let me explain this here. The changing context today enlarges the overlapping between the problem space and the solution space and hence necessitates better model for software requirements and architecture co-development (For details, please click ).  To better the co-development, the relationship between ASRs and ADDs merits investigation. ADDs are design decisions that determine the architecture of the to-be system(s). Imposed by the changing context, inherited design decisions from earlier versions or legacy systems now become constraints (usually as ASRs) for new projects today. What’s more, a well elaborated requirement often contains design details (i.e. ASRs can be transformed into ADDs easily and smoothly). If a concrete relationship between ASRs and ADDs can be built, then requirements practice and architectural design can be potentially largely improved.

Secondly, distinguishing ASRs is to alert BAs / requirements engineers of this concept and consciously write requirements especially those ASRs in a way that makes requirements better match with what architects really need for architecting. No matter the requirements are functional or non-functional, or ASRs or non-ASRs, they are meant to be implemented. But at least thinking in terms of ASRs and non-ASRs makes the gap between requirements and architecture closer. Besides, there has to be guidance on how to identify ASRs for BAs / requirements engineers – it’s another story.

The concept of architecturally significant requirements has been mentioned for more than ten years. Even though not many researches have been done in this area up to date, not to mention industrial practices, today we enter into a new context that may force us to pay attention to it more than ever. And I hope I could contribute to that a little bit.

Thinking in Requirements Engineering — Elicitation(2/2)

Though many requirements elicitation techniques are proposed, very few of them are widely adopted in industry.  For the nature of requirements, it’s true that no silver bullet exists to solve all types of elicitation problems at once. Hence, some researchers put efforts to find out requirements elicitation selection criteria, where they mainly do empirical studies or systematic review. Most of their findings distinguish elicitation techniques in terms of differences, similarities, advantages and disadvantages. Most important of all, those selection guidance are vaguely given based on situational characteristics. However, among those situational characteristics, none of them, as far as I know, mention the types of stakeholders that might affect the appropriateness of elicitation techniques as well. 

There are many types of stakeholders that should be taken into consideration when eliciting requirements. Those different types of stakeholders play different roles in participating the software development activity. Hence, what they know about, how they access, and what their interests on the software to be built differ from one type of stakeholders to another. In other words, the requirements we aim to get from different groups of stakeholders are supposed to be of inequitable value, different forms and focuses. Therefore, we can apply different elicitation techniques with a particular emphasis on certain aspects of requirements based on what type of the stakeholder is.

To illustrate the above idea, the following are some examples to articulate how to choose techniques and what to consider as targeting outcomes when eliciting requirements from different types of stakeholders. To start requirements elicitation , understanding high-level goals of the project is often necessary to better progress the elicitation process. And those goals mainly from champions (aka.) sponsors, company leaders etc.. As what ‘s wanted from them are goals/expectations of the project – tacit knowledge in their minds, structured interview is a good way to get that. For normal operators, as they are very familiar with the kind of software to be developed, if they have a existing system, participant observation, storytelling, and use cases suit them better, or if it’s an innovative project, focus group, brainstorming and survey would be better. In such cases, the intended requirements we try to discover from them are mainly about functional requirements, usability, maintainability, etc. One more example is for functional beneficiaries, such as interfacing systems, purchasers, they usually look for reliability, scalability etc from the developing software. Questionnaires and meetings with those concerns might be good.

Thinking in Requirements Engineering — Elicitation(1/2)

The last twenty years has witnessed the increasing awareness and recognition of the importance of requirements engineering in software development. And a lot of methods, techniques and principles are proposed by academics to better engineer requirements. However, as a matter of fact, very few of them have been widely adopted in industry. Someprojects even skip requirements engineering entirely or partly, despite of its importance. Moreover, the role of requirements engineering hasn’t been widely accepted in industry as it should be. As a result, the current practice of requirements engineering in industry really seems to fall behind with the current academic research. What causes this big gap between academia and industry is well worth considering and studying.

Requirements engineering, usually regarded as the first phase in the software development, lays the foundation of the software to be built. It’s reported that errors in requirements usually have a bigger influence on the software and cost more to repair than errors made in other phases. Therefore, it’s worthwhile putting great efforts on requirements engineering for developing good software.

However, requirements engineering is very difficult. Requirement is perhaps the most people-oriented and least tangible concept in software development, where it largely depends on the stakeholders and they often change their minds unexpectedly. Besides, practitioners have to distinguish what features/properties the software really needs to have from what the stakeholders want and negotiate with them to resolve any conflicts. There is also a danger of misinterpretation when eliciting requirements from stakeholders, which consequently results in ill-defined or unclear requirements. With those difficulties both in nature and in practice, it’s hard to produce a great requirements specification.
From the above perspective, requirements are important and difficult to obtain accurately. Despite of its inherent difficulty, one of the top requirements problems in practice is the lack of stakeholder input. This problem, to some extent, indicates that current requirements engineering techniques and methods are not suitable or effective to produce good quality requirements, which is due to the low productivity from communications with stakeholders. Different stakeholders hold different views of requirements according to their distinguishing roles and interests for the software to be built. Therefore, requirements need to be understood from different perspectives. Hence, different eliciting strategies should be applied to different groups of stakeholders.