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.

ASRs questionnaire

Architecturally significant requirement (ASR) or not?

1.Users shall have one of two roles that the application must be aware of: a) Internal Company Associate b) Customer

2.Under normal conditions, refreshing the system’s data (links, interactions etc.) shall not require a system restart.

3.The web-service should perform all the processing in a single call, sending the complete call definition and receiving a single response.

4.It must be possible to scale the deployment from an initial 100 geographically dispersed user desktops to 10,000 without an increase in effort/cost for installation and configuration.

5.Queries for ProductId validations that have failed shall be retried six times at an interval of a minute. If the query has failed after the retry, then the alarm and the response from the query shall be logged.

6.The application shall start back-off when the application has network connectivity but fail to connect to the server.

7.In order to avoid truncation, the total number of characters collected as part of the trouble description shall not exceed 900.

8.While the application is in the background (i.e. not ended), the messaging service shall continue to live and operate.

9.Divide the work according to the geographical team distribution so that the teams would be as independent as possible.

10.Interfaces delivered to third party applications shall be expressed independent of programming language (i.e. shall support WSDL). Implementation of services must be distributable across the network.

11.The application shall allow users to handover an active call from cellular network to Wi-Fi. Once handover to Wi-Fi is complete, the cellular call must be dropped automatically.

12.Visibility of system status: The system should always keep users informed about what is going on through appropriate feedback within reasonable time.

13.In general this should be global approach. Don’t preclude countries. The tool set shall support:

  • Multiple countries.
  •  In-county currencies. (Initial potential countries for introduction are US, Canada.)
  • Compute correct taxes.
  • Multiple languages for user interface.
  • Selling restrictions for specific countries.

14.Pages need to be in English and French for Canada
NOTE: Additional languages will be required when expanded globally

15.Users accessing [A-website] from a Partner portal/banner etc. must be tagged accordingly to provide the Partner with the appropriate commission for the sale. Today we use [a 3rd party tool]to support in the affiliate program; another possible vendor could be explored.

16.The ‘middleware’ system will create a SAP idoc file (order type= SD or FD – meaning free of charge, no billing) & transmit it to SAP-I (systematic)

Click ASRs interview summary to have a good look at the results and summary of the interviews. To notice, there were two slightly different questionnaires. Participants A1 to A4 and the BA were interviewed using the first questionnaire. After analyzing their answers, those requirements that participants always gave almost the same views are replaced by new ones. Therefore, participant A5 was given a new set of questionnaire with some new requirements decisions.

One example of the questionnaires, done by one technical lead

One example of the questionnaires, done by one technical lead. The name is blocked.

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.