Concrete Requirements

The raison d’être of a software architecture is to promote the reasoning about the system. To do so two aspects should be addressed: (1) concrete requirements; and (2) precise properties associated with the architecture elements and relations.

To describe concrete requirements we have to avoid vague references to the performance of a system or its ability to deal with change. To strive for concreteness, a good rule of thumb is to associate a functional behaviour with the non-functional quality. For instance, when a student is executing a course enrolment’s transaction it should not take more then 1 second. In this case we state what is the particular functionality and the level of quality it requires, complete in less than 1 second. But, is this specification concrete enough? Well, it depends. It is the architect’s role to ask questions to verify it. Does the enrolment functionality occurs more often in a particular period? Suppose that the stakeholders tell him that there is an enrolment period where most of the enrolments occurs. Then, he can ask how many enrolments occur during this period. With this fresh information the software architect may restate the requirement to: during the one week enrolment period, where up to 40000 enrolments occur, each enrolment should not take more than 1 second.

Consider now that by asking questions the architect comes out with a slightly different requirement: during the first 3 hours of the enrolment period the system should be able to process half of the total number enrolments. What is the difference between these two requirements? The first focus on the latency, how long does it take to the system to execute an enrolment request, whereas the latter expresses the throughput of the system, the number of operations it can perform per unit of time.

What could be the impact of these requirements in the architecture? Performance requirements based on latency drives the architectural design of interactive systems, which try to reduce the response time to user requests, while throughput requirements may result in batch systems, that make a more efficient use of resources at the price of an unfair response to users, some may get their results much faster than others, without any apparent reason but for the internal scheduling the systems does of its resources.

Consider a connector through which the client component, that the student uses, interacts with the server component that executes the enrolment requests. The properties of this connector may help us to reasoning how the architecture can fulfil the requirements.

To support the first requirement we can caracterize the connector as a synchronous request/reply connector, that delivers requests to the server component in a first come first served (FCFS) order, to support the interactive behavior. Additionally, it is necessary to ensure that the computational power of the component server is sufficient to guarantee the required latency, for instance by specifying the hardware necessary to execute the component.

The throughput quality may drive the architecture design to also have a synchronous request/reply connector that does an explicit queueing of requests and includes a scheduling policy which serve request in an optimized way. For instance, it may group requests for the same course such that it is not necessary to do several round trips between the database component, where information is persistently stored, and the server component, and have low granularity transactions, which reduzes the synchronization overhead. Note that the connector needs to be synchronous because the student expects a confirmation of the success of her request. Additionally, this example also illustrates that it is possible to implement a request/reply synchronous connector with internal asynchronous mechanisms, a queue and one worker task executing a scheduling algorithm.