Considering software architecture concurrently and iteratively with software requirements, has been illustrated as a way to increase productivity and stakeholder satisfaction in the twin peaks model software development process. Because this model exposed only the tip of the iceberg, and lacks of concrete de nitions and techniques, an approach of utilizing this model in the real world has been proposed by applying the concept of the product development process based on Quality Function Deployment. In this paper, we will go further of giving more detail about how to de ne the requirements along with software architecture. In order to provide a method to de ne a robust software architecture but to be adaptable to the presence of changing requirements, we apply layering concept to the software requirements analysis and architectural design.
A software development project typically starts with extracting some software requirements from the stakeholders. After that, the developer team uses those software requirements as the input for architectural design to de ne the architecture of the software system to be built. This process is typical of software development based on the waterfall model.
In such development process, the software requirements have become a constraint in the architectural design process. In this process, rather than developing from the scratch, most projects are adopting one of the well known and explicit architectural patterns, or selecting a software architecture by reusing the already trusted components providing the framework for the software application. However, since this framework also prescribe the capability such as the extensibility of the application, if improperly selected in the architectural design, it might be di cult to x in the latter process. The constraint of architectural design can also impede the changes in the software requirement itself, when the changes cannot be implemented in the already selected architecture. As the result, the stakeholder might not have enough satis ed with the nal product.
Software requirements are the important elements to be considered rst in
software development. Software architecture, which is de ned based on software
requirements, is also the important thing to be thought in order to ful ll the
given requirements at the time the architectural design performed. Software
architecture also needs to have the exibility to deal with future change of software
or user requirements. The twin peaks model has been proposed to emphasize that
developers should equally give status to the speci cation of requirements and
architectures [
Since the result of requirements analysis a ects the overall result of the
nal product, and it is important to ensure customer will be satis ed with the
nal product, we will further discuss the method of requirements analysis. In
our research, we propose the use of Quality Function Deployment (QFD) as a
method to clarify the voices of the customer, and de ne the product quality as
well as the business functions of the product based on them, and take them in
the whole development process of the product [
In this paper, in order to provide a more detail and concrete method in establishing stable software architecture but to have a range of exibility over changing requirements, we apply the concept in layered architectural patterns to the software requirements analysis and architectural design. The concept is hereinafter referred to as the layering concept.
The rest of this paper is organized as follows. Section 2 presents the concept in layered architectural pattern. Section 3 discusses how we apply the layering concept in requirements analysis and architectural design. In the section, we also show how we evaluate the approach using an example. Finally, we conclude this paper in Section 4. 2
The Concept in Layered Architectural Patterns Software architecture is a description of subsystems, components, and relationships among them, required for building a software system. Software architectural design is a process whose purpose is to provide a design for the software that implements and can be veri ed against the requirements.
Among various numbers of software architectures, those that are found
particularly useful for families of systems are often codi ed into architectural
patterns. From several architectural patterns already established [
The layering concept helps to structure applications that can be decomposed
into groups of subtasks in which each group of subtasks is at a particular level
of abstraction. Layers are sorted vertically, where that having the lowest level of
abstraction is placed at the bottom, and that on the uppermost level of
abstraction is placed on the top. The lower layer has less chance of modifying than those
above it. One of software architectural designs applying the layering concept is
the principal 3-layer architecture: presentation, domain, and data source [
capturing user input
business logic
Layer 1 bCaocmkemnudnsiecravtiicoens with the
The principal 3-layer architecture has a di erent level of abstraction in each layer. Starting from the bottom, data source layer has the lowest level of abstraction. It means data source should have the smallest potential to change. Changing in data source may have a big impact to the upper layers. In contrary, changes in the application layer, such as changing the color of display or even changing the user interface from desktop to web-based, do not propagate to the lower levels. However, this layer may have a bigger chance of changing compared to lower levels. 3
Applying Layering Concept to the Requirements Analysis and Architectural Design Software requirements analysis consists of activities including requirements elicitation, requirements analysis, requirements speci cation, validation, and management activities. The requirements analysis activity is the most important step in the overall development process, as in this activity, the requirements will be classi ed. The appropriateness of the classi cation will decide how the requirements would be handled in the architectural design. The software requirements de ned in this activity will in uence how rigid or stable the software architecture will be designed, and at the same time, that will, indirectly, decide how easy to accommodate in the presence of changing requirements. We need a method of classi cation which can give an input to the architectural design whose result is adaptable to the future changing of requirements.
In the previous section, we have discussed how the layering concept
benets to increase the extensibility of software development and the exibility to
accommodate changes in requirements. We propose applying the same concept
in classifying requirements. We consider the volatility or chance of changing of
requirements to be the base of applying the layering concept. There are few
researches studying the volatility of software requirements such as in [
It is stated that some requirements will change during the life cycle of the software, and even during the development process itself. For example, in an online new student admission application, requirements for functions to make the registration online are likely to be less volatile than requirements to support integration of the admission fee payment. The former re ects a fundamental feature in the admission application, while the latter may change as the payment method may vary from manual payment to automatic payment via online banking application which may need a system integration with banking application. It is useful if some estimate of the likelihood that a requirement will change can be made. Flagging potentially volatile requirements can help the software engineer to establish a design that is more tolerated of change.
Fig. 2 shows how we apply the layering concept to the requirements analysis and architectural design. First, the requirements will be sorted based on their degree of volatilities. The sorted requirements then will be used in architectural design, which is in this case, they are mapped into the 3-layer architecture. layered requirements architectural design n i a m o d e c ro u s a t a layered architecture d n o itte a n s e r p higher layer higher level of abstraction higher degree of volatility more chance of changing less chance of changing lower degree of volatility lower level of abstraction lower layer
To illustrate the approach described above, we evaluate it using an
example. The example is taken from the paper introducing the requirements analysis
method using QFD [
Manage Pictures Manage Pictures snDatabase o it c n u F l a n o i itdManage dAAccount s n o it c nDesign Album Layout Automatically FLayout u c i s a B
Register Payment Order Printing Information
obtain ner-grain result.
Conclusions In a standard list of software life cycle processes, such as that in ISO/IEC/IEEE Standard 12207:2008, software design consists of two activities that t between software requirements analysis and software construction. Nuseibeh has already proposed the twin peaks model by giving the equal status of the speci cation of requirements and architecture, and to provide more detail and concrete method, Watanabe et al. has proposed to combine the method of software requirements analysis based on QFD with the twin peaks model.
In this paper, we have proposed applying the layering concept to requirements analysis and architectural design, in order to obtain layered requirements and a layered architecture. This layered structure provides a stable architecture but adaptable in the presence of changing requirements.
Although we have provided illustrations for our approach, we exposed only a concept or likely an idea. More work remains to evaluate the validity of the method and the e ectiveness of the approach in a real project.