In 1993, The London Ambulance service faced a critical failure. The cause was increased call traffic load, that prevented the system from maintaining location information about the ambulance units triggering a large number of exception messages. LAS’s failure to handle extra load during peak usage is attributed to systems’ missing scalability characteristics.
While discussing the concept of scalability, the questions we usually ask are; what does it mean for a system to be scalable or how do identify a system that lacks scalability? Even though scalability is considered as on of the most important attributes of Software-Intensive systems, it has received relatively less attention from RE research community thus far. Scalability concerns are usually ignored during the requirements elicitation procedure and there is lack of a proper definition and having systematic way of describing a system’s scalability. Typically, Scalability is generally seen something of a concept that is related to system performance and a system is said to be scalable if it has the capability to increase resources to yield a linear (ideally) increase in service capacity. In reality Performance, however, is only one of many aspects of a scalable system, along with many other such as Availability, Reliability, Securability, Manageability etc.
Scalability requirements(defined with respect to other quality goals of the system) should always be defined upfront during the requirements elicitation process. Defining scalability requirements of a complex system is not a trivial task. One major challenge that usually occurs during this step is that scaling of multiple characteristics in the application domain will affect the satisfaction of different, sometimes competing, quality goals. Its imperative that our scalability requirements that are quantifiable, testable and justifiable in the context of higher-level business goals that the system must achieve.
Large-scale systems like YouTube and Google Search need a different approach to scalability requirements. Specifying growth rate and operational costs for these systems is vital for ensuring long-term scalability. Operational costs must grow more slowly than system capacity to be acceptable to stakeholders. Requirements Engineers should have methodology that precisely defines scalability and provides a systematic way of clearly eliciting scalability requirements upfront during the development process, thus preventing catastrophes such as the LAS from happening in the first place. However, existing requirement engineering techniques like goal-oriented approach of KAOS, i* provide generic support for elaborating system requirements and don’t specifically provide a method for dealing with scalability concerns of the system.
Duboc, Rosenblum, and Wicks proposed an extension of the conceptual framework of KAOS to include precise characterizations of scalability goals and requirements. This approach deals with scalability concerns during the goal-obstacle analysis steps of the goal-oriented elaboration process.
To identify obstacles, Duboc et al. suggest three steps: 1) Identify scalability obstacles that may obstruct the satisfaction of the goals; 2) Resolve the obstacles by modifying existing goals, requirements, and expectations, or generating new ones; 3) The resolution of scalability obstacles leads to the identification of scaling assumptions and scalability goals.
A Revised Definition of Scalability: Given a growth rate X (of one or more domain properties), a system is considered scalable if it maintains, over time, the operational costs and user experience to a level that is acceptable to its stakeholders.
The London Ambulance Service failure highlights the importance of addressing scalability concerns during the requirements elicitation process. By adopting a goal-oriented approach and revising the definition of scalability to encompass growth rate and operational costs, large-scale systems can be better prepared for future challenges and ensure long-term sustainability.