1 ACM SIGSOFT Software Engineering Notes vol 25 no 2 March 2000 Page 40 Abstract A Complementary Approach to Requirements Engineering --Software Architecture Orientation Hong Mei Software Production Research, Bell Labs, Naperville, IL 60566, USA Software Engineering Lab, Peking University, Beijing , PRC This paper presents the idea of Software Architecture Oriented Requirements Engineering, a complementary approach to existing requirements engineering processes and methods. The main objective is to introduce concepts and principles of software architecture into requirement analysis and requirement specification, supporting requirement reuse, traceability between requirement specifications and system design, and consistency in the whole software development process more effectively. The paper views connectors as the first-class entities in the problem space, not just in the soluti~ space as most of current research on software archite6tu~e dolws, hence the connector recognition and specification are same important as component recognition and specification in requirements engineering. Based on this idea, the paper presents a new sottware development process and corresponding requirements engineering process, gives some guidelines for connector recognition, and borrows the notations of software architecture description to specify the functional and behavioural requirements at a high abstraction level. It must be pointed out that the approach presented in this paper is not a substitute for existing ones, but a complement to them from another perspective and at a different abstraction level. Keywords: Requirements Engineering, Software Architecture, Connector, Component t. Introduction It is common sense that requirements engineering is an important phase in software engineering. In the last two decades, research on requirements engineering has made much progress, many systematic approaches have been presented and applied in software development practice. Because of the development of soilware production technology, including requirements engineering technology, the improvement in software productivity and quality is visible. But we must confess that there is a far way to reach what we really expect. Further research is needed. Requirements engineering is a complex research field, which consists of context, groundwork, acquisition, modelling & specification, analysis, measurement, and communication & documentation, etc . Of course, all the aspects are important. But from the view of the following stage, software design, it is natural that more attentions are paid to modelling & specification. A consistent, complete, precise, and understandable specification is the basic premise for the following development activities. Keeping the traceability between requirement specifications and design, and the consistency in basic concepts between these two stages are the effective means to support quality and productive development. Looking back on the development of software development methodology, it is not difficult to find that keeping the traceability and the consistency in concepts between requirements and designs always are the goals that we pursue. For example, as we know, structured methodology originated in later 1960s in conjunction with the development of structured programming. Hitherto, there exist a lot of structured methods. But for each method, the traceability between structured analysis (SA) and structured design (SD) must be built. So, researchers have developed some techniques to map mechanically Data Flow Diagram (DFD) to Module Structure Chart (MSC) and to facilitate tracking forward or backward between structured requirement specifications and structured designs. DFD and MSC are two main tools widely used in SA and SD. Nevertheless, the differences between the basic concepts and principles of DFD and MSC make a gap between SA and SD, even there exist some automatic transformation~ from DFD to MSC. It is this gap that is viewed as one of the weaknesses of structured methods. In the last decade, the objectoriented (OO) methodology has become a prevalent paradigm to software development. One of the main benefits of OO p~digm is that it cured the symptom that the structured paradigm did not. The development of OO methodology is similar to the development of structured methodology. It originated from objectoriented programming. But because Object-Oriented Atmlysis (OOA) and Object-Oriented Design (OOD) use the uniform basic concepts and principles, the mapping between OO requirement specifications and OO design is natural and direct. Also, keeping traceability is easy and transformation could be done mechanically. The lessons learnt from the development of software development methodology are: new ideas and technologies usually oriiginate and are applied at the later stages in the software life cyclle, and eventually will be introduced into the early stages; the more uniform the concepts and principles used in software development are, the better and more powerful the methodology is. Recently, more and more researchers pay their attentions to the research on software architecture (SA, in the rest of this paper, the acronym SA stands for Software Architecture). SA has begun to emerge as a new and important research field for software engineering circle. There exists a consensus that for any larlge software system, its gross structure--that is, its high-level organisation of computational elements and interactions between those elements--is a critical aspect of design [21 . It is widely accepted that SA is a very important product and software archtecting is a necessary phase in software life cycle. There is n doubt that SA, as an important design concept, will certainly ira. pact the software development methodology and process, inchid. ing requirements engineering. Actually, some resear,zh ha,,
2 ACM SIGSOFT Software Engineering Notes vol 25 no 2 March 2000 Page 41 pointed out that SA "can serve as the key milestone in the entire software life cycle process". SA's "support of the needs of system engineers, customers, developers, users, and maintainers, also implies that it is involved in all phases of the software and system life cycle" . Therefore, it is natural and reasonable introducing SA concepts into requirements engineering. We can imagine, if we use conventional method to produce requirement specifications, it is relatively difficult for us to establish the mapping relationships between the requirement specifications and SA which is the product of the following phase--software architecting. On the other hand, from the views of reuse, we argue that it is also necessary to introduce SA concepts and principles into the requirement analysis and specifications. Requirement specifications also are important reusable assets. As we know, something is reusable if and only if it has reusable value in substance and has reusable possibility in its representation. SA improves reusability from two aspects. On the one hand, it lets us to explore and identify reusable assets. On the other hand, it gives us the means to make these reusable assets could be reused by other users. Introducing SA concepts into requirements engineering at least can let us organise requirement specifications in a constructive structure and a more reusable form. This paper tries to introduce concepts and principles of software architecture into the requirement analysis and specification, supporting requirement reuse, traceability between requirement specifications and system design, and consistency in whole software development process more effectively. The main idea is to view connectors as the first-class entities in the problem space, not just in the solution space (so far, most Of research on SA just views connectors as the first-class entities in the design space. We argue that it is not enough), hence the connector recognition and specification as the same important activity as component recognition and specification in requirements engineering. The paper presents a new software development process and corresponding requirements engineering process, gives some guidelines for conhector recognition, and borrows the notations of software architecture description to specify the functional and behavioural requirements at a high abstraction level. This is a complementary approach to existing requirements engineering processes and methods. We can call it Software Architecture Oriented Requirements Engineering. The rest of this paper is organised as follows. Section 2 gives a brief introduction to software architecture and a discussion about connector, viewing connectors as first-class entities in problem space. Section 3 presents a software architecture-based development process. Section 4 discusses how to achieve SA-oriented requirement analysis and specification; a set of guidelines is given. Section 5 concludes the paper and lists some future research issues. 2. Software Architecture and Connector For large, complex software system, the design of the overall system structure, that is, software architecture, is a critical design problem. This is why SA has become a focus for research. But unfortunately, to date there is no standard, universally-accepted definition of software architecture. SA has been defined in various ways, some important definitions arc as follows: it is a structure composed of components, and rules characterising the interaction of these components , it consists of elements, form and rationale, it consists of components, connectors and configuration, it is a structure which comprises software components, the externauy visible properties of those components, and the relationships among them, or it is a collection of software and system components, connections, and constraints, a collection of system stakeholders' need statements, and a rationale . However, from these definitions, we can at least conclude a common core-- components and connectors (connections or interactions). Actually, for any system, components and connectors are the main entities which constitute the system. In fact, any software system has architecture, even no architecture design was made or the architecture was not documented explicitly. For these systems, the architectures are hidden in the systems (in source code or executable code). We can identify the components in a system, which are the modules composing the system. But it is relatively difficult to identify independent connectors, because the connections between components are sc~er~ ~!hardwritten) in those modules. It is natural, for this kin"d of systems, there are some inherent flaws. One is that reusing the components... in these systems is difficult. Another is that the evolution and maintenance of these systems are difficult. Obviously, due to the lack of sound architectures, the development of this kind of systems probably had spent more time and efforts, and left more bugs. Research and practice of SA aim at making the architecture of a system explicit, dealing with at a higher-level the design issues such as gross organisation and control structure, assignment of functionality to computational units, and high-level interactions between these units . One of the most important contributions of SA research is making the connectors explicit, viewing conhectors as the first-class entities in the system. Making connectors, which formerly were hidden and scattered in the modules of system, explicit and independent provides a means to view, design system and reason system behaviors and properties at a higher abstraction level, to design and implement more reusable components, and even to reuse some connectors. Now there are many connectors which have been identified and studied, such as procedure call, data sharing, file I/0, RPC, RTScheduler, PLBundler, pipes, event broadcast, client-server protocols, etc  . Also there is some research involved in user-defined connectors  and composition of connectors . This kind of research just treats connectors as first-class entities in the design phase, that is, viewing connector as a design concept. But actually, in the problem space, there exist connectors too. It is necessary to introduce connector concept into the modelling of problem space and view connectors as the first-class entities in the requirement specifications, giving them equal position as components in problem space. In component-based software development, components are the main entities which exist in whole life cycle process and are used in requirement specifications, system designs and executable programs. Here we argue that we should treat connectors in same way. Let us look at a simple example, producer-consumer application.
3 ACM SIGSOFT Software Engineering Notes vol 25 no 2 March 2000 Page 42 Based on the analysis to the problem space, it is easily to identify Producer and Consumer as two components, each encapsulating a set of coherent functionality. Now we study the interactions between these two components from the perspective of user requirements. In reality, there exist many different interaction modes due to different cases. Following are some possibilities: 1) Producer produces one product, then sends it to Consanner and gets receipt, Consumer consumes it. In this case, there is a synchronisation between active Producer and passive Consumer, and the sequence of products is kept, that is~ first produced, first consumed. 2) Consumer sends request to Producer, waits the product and gets it, then consumes it. In this case, there is a synchronisation between passive Producer and active Consumer, and the sequence of products is kept, that is, first produced, first consumed. 3) Producer produces products and piles them up somewhere continuously, Consumer gets products from the same place and consumes them continuously, no receipt nor request is needed. In this case, Producer and Consumer work relatively independently, no sequence of products is kept, and losing products is possible. 4) Producer produce product and store it into a warehouse, Consumer gets product from warehouse and consumes it. In this case, whether the warehouse has some functionality and how complex its functionality are will be a key factor for requirement analysis and specification, what can be determined are that Producer and Consumer work independently, and losing products is not permitted. From above cases, we can see that these actually are 4 different connections between Producer and Consumer. These are connections between components in the problem space, not in the solution space. So, this is a requirement problem, not a design problem. This example just shows that it is necessary to make the connections between components in the problem space explicit. In requirement specifications, explicit connection specifications let the documentation have sound structures, supporting reuse and traceability more effectively. Using components and connectors as the main constituents for requirement specifications, we can document requirement specifications in the uniform way with SA, forming a consistent development process. Connectors in problem space will be refined or implemented in design space. Of course, for any connector in problem space, there exist many different kinds of implementation in design. For example, in above 4 connections, connection 1 and 2 could be implemented by using message passing (procedure call), pipes, event broadcast or RPC, connection 3 by data sharing or file I/O. For case 4, the situation may be somewhat complicated. In the simplest case, we can use data sharing too. But if the warehouse has some functionality such as simple management of products, then we can not use some primitive or simple connectors to implement it, the user-defined connector is needed. In the more complicated case, the warehouse has powerful management functions. In essence, the warehouse has become an important functional unit, hence, it is not simply a connection, it virtually is a component in the system. In this case, the system specifications will consist of 3 components and 2 connectors. This case shows that the identification of components and connectors in the problem space is determined by the application requirements. Now we have made the connectors become a concept tn;ed in every life-cycle phase. It is this concept, along with the concept of components, that forms a uniform means to specify the artifacts in the development process, and further sets a foundation for a consistent SA-oriented software development method. The connectors can be divided into 3 classes according to different phases. There are connectors in problem space, connectors in design space, and connectors in final executable system. Following are some dtiscussions on these 3 classes of connectors: Connectors in problem space: This class of connectors is identified from the user requirement definitions. In fact, these connectors specify the interaction protocols between components. We can divide relatively these connecto~ into two categories--complex and simple. The simple connectors are those whose interaction protocols are relatively simple, so they can be refined or implemented by some existing conhectors in design space. For example, one simple connector may just specify a data-passing protocol. It can be implemented easily by pipes, data sharing, or even procedure call in design. The complex connectors are those which can not be implemented directly by existing connectors in design, hence, user-defined connectors are needed. Of course, in requirement specifications, we are not concerned the difference. We just identify and specify them. The implementation is a design-decision problem. Connectors in design space: This class of connectors is the refinement or implementation of the problem-space connectors. According to their forms, they can be divided into userdefined connectors and primitive connectors (some commonaccepted ones such as pipes, data sharing, etc). A userdefined connector may specify a complex protocol, so it is possible that it will be modelled by a set of objects. According to their roles in design, these connectors can be divided into real connectors and artificial connectors. The former are those which are the direct implementation of some problemspace connectors. The later are those which are come ur with in the design phase just from software's view (they arc brought in due to the existence of some artificial component~ that are introduced at the design phase and have no dire~ corresponding components in the problem space), noll corre. sponding to some problem-space connectors. Connectors in final system: This class of connector,,; is th~ final implementation of connectors in design. Design con. nectors can be implemented in two ways. For most user. defined connectors, they are implemented in concrete pro. gram modules. So, these connectors are independent entitiez in system. We can call them user-implemented connectors For those primitive connectors, their implementation depenc on the infrastructure provided by the platform, such as fa cilities provided by programming language, OS, and som~ middieware. They are called infrastructure-based comaectors From the view of user programs, these connectors do nc
4 ACM SIGSOFT Software Engineering Notes vol 25 no 2 March 2000 Page 43 have independent forms. By the way, we should point out that in general sense, connectors are some special kind of components. The key difference is that components are computational units and connectors are communication units. Both are important constituents in system. 3. A Software Architecture based Development Process Traditional software development processes usually do not con- sider deeply the design issues on the architectural level. But if we view software architecture as an important artifact, even as the reference model in the whole life-cycle, we must adapt the development process so that it suits SA-based software development. As a basic agreement, many people think that an architecting phase is needed, which will be after requirement analysis and before design. In Figure 1, a new version of waterfall model for process is shown. ~equirement~architecting~ Design ~ Coding ~ Testing ~Maintenanc~ Figurel. New version of waterfall model Based on our discussion above, we argue that although this model takes account of the architecture design, it is not enough to stress the importance of architecture and to describe a SA-centred process, especially how to specify requirements in terms of SA concepts. When we will begin the architecting phase? Can we just do architecting after requirements engineering ends? In our opinions, Software architecture is at a higher abstraction level, therefore the architecture design does not needed to know all detailed requirement specifications, just some higher level specifications are enough. On the other hand, it is necessary to specify the requirements at a higher level in term of SA concepts, and it is also nec- essary to get feedback from architects to guide detailed requirement analysis and specification. Based on this idea, we present a SA-based process model as shown in Figure 2. Because supporting reuse is one of our goals, this process model is combined with OO paradigm. There are three reasons for this choice. Firstly, OO has become the prevalent paradigm in software development. Secondly, OO provides more technical support to reuse. Thirdly, main component standards (such as CORBA, COM/DCOM, and EJB) are based on OO paradigm. Of course, combining non-oo paradigm into this process is also possible. r Requirements $A-oriented ~ Software ] Analysis [~ [ Architecting \/ \\ Object-oriented ~ requirements Anal)'sis Object-oriented Software ~ Implementation Testing Maintenance Design Figure 2. A SA-based Software Process Model This model is a variant of the waterfall model too. The main differences are in the Requirements and Design phases. From the viewpoint of the modem software engineering, requirements and design are very important phases in the software life-cycle. In this model, SA and OO concepts are used uniformly throughout the entire software development process, especially SA, used as the reference model for each phase in the life-cycle. Two new phases, SA-oriented requirement analysis and SA design, are introduced into the conventional development process. They focus on system properties at a higher level of abstraction. In substance, this model is not a substitute to conventional model, but an enhancement or modification. Following are the brief descriptions of every phase in this model, mainly focusing on activities and artifacts in each phase. SA-orientcd requirement analysis: Main activities include determining the boundary of the problem space, identifying the system users and their responsibilities, exploring the overall external behaviors from user's perspective, identifying components and connectors, specifying the components and connectors, producing SA-oriented higher level requirement specification, checking the specifications. These activities are conducted iteratively. The feedback from the following phases will also lead to a new iteration. The artifact in the phase is SA-oriented requirement specifications, including component specifications and connector specifications. This artifact will be used as the basis for software architecting and further OO analysis. Also, it is a very useful complement to conventional requirement documentation from a higher level perspective. Software Architecting: In this phase, SA-oriented require-
5 ACM SIGSOFT Software Engineering Notes vol 25 no 2 March 2000 Page 44 merit specifications are refined in the architectural design of system, and some overall design decisions are made. Main activities include studying the SA-oriented requirement specifications, refining components and connectors in the problem space, creating necessary artificial components and connectors, producing software architecture design (including dynamic and static models), building mapping relationships between requirement specifications and SA, checking SA, presenting some hints for OOA and some constraints for OOD. The artifact in this phase is the SA design of the system, which is the reference model for the system development. Object-oriented requirement analysis: In this phase, based on the higher level requirement specifications produced in the early requirements phase, and some heuristics from architecting phase, detailed and complete requirement specifications are made. The main activities in this phase are similar to those in conventional OOA. The only difference is that, in the early requirements phase, the problem space has been partitioned properly, hence in this phase, we do OOA to every subsystem (a component or a set of components, along with relevant connectors), then integrate the results into a final documentation. The artifact in this phase is the final requirement specifications, consisting of various models used by conventional OOA plus the higher level specifications produced by SA-oriented analysis. Object-oriented software design: In the phase, based on the SA design and detailed requirement specifications, the detailed and complete design of system is made. The main activities in this phase are similar to those in conventional OOD. The artifact in this phase is the system design, consisting of various models from different perspectives. It is the refinement and implementation of SA and to requirement specifications and is used to guide system implementation. In this phase, designers should try their best to reuse existing components, connectors, design patterns, and frameworks. Implementation: In this phase, coding is made according to the system design, including implementation of components and conncetors, and system integration. Testing: In this phase, testing of the system is conducted, including class testing, component testing, connector testing and integration testing. Maintenance: In this phase, system is maintained and evolved, keeping the almost same software architecture. 4. Software Architecture Oriented Requirement Analysis and Specification In last section, we have presented a SA-based software development process whose main features are SA-centred development support and SA-oriented requirement analysis. In this section, we will focus on the discussion of SA-oriented requirement analysis and specification. The objective of this phase is to generate system's SA-oriented requirement specifications at a higher level of abstraction. The main activities are listed as follows: Determine the boundary of the problem space Identify the system users and their responsibilities Explore the overall external behaviors from user's perspective Identify components and connectors Specify the components and connectors Produce SA-oriented higher level requirement specific~itions Check the specifications These activities are conducted iteratively. Following are brief descriptions of these activities. As we mentioned, our appreach is just a modification and a complement to conventional approach, so we do not describe all activities in details. Only those new ideas are discussed. Determine the boundary of problem space For any requirement analysis method, determining boundary is always the first step and an important step. So, here the traditional techniques and tools are useful. Identify the system users and their responsibilities This is an important step. By identifying the users of the system and their responsibilities, we can figure out the relationskips between system and outside easily. It is helpful for us to explore system functions and behaviors, and to partition the system into subsystems or components. Explore the overall external behaviors from user's perspective In this step, we view the system as a black box.and explore its overall behaviors from different views, according to different user's perspectives. It will produce a top-level model of 10de system. Use Case method  is an effective means for this step. For each user, relevant use cases are identified. Then all use cases are analysed, conflicts and consistencies are solved, and finally all use cases are divided into some groups, in each group use cases are coherent. Grouping of use cases is a good guide to partition the system. Identify components and connectors Based on the information obtained from the early steps, we starl to identify the components and connectors in the problem space, then divide them into different subsystems. Following is a set oj guidelines to identify these entities: Study the context where the software system will be used. Organisational units and physical equipment are candidate,, for components. Connections and relationships betweer these entities are candidates for connectors. Study the overall external behaviors of the system. Eacl0 group of use cases manifests some external behavior, the entities in the system which involved in the provision of thal behavior are candidates for components. Connections and relationships between these entities are candidates tbr con. nectors. If some entity in the problem space has relatively independ.
6 ACM SIGSOFT Software Engineering Notes vol 25 no 2 March 2000 Page 45 ent functionality, which is constituent of system functionality, then that entity may be considered as a component. If it has much dependency on other entities to achieve its functionality, it should be considered as an object which will be combined with other objects to form a component. The difference between components and connectors is that components are the computational units which provide some functions or behavior, and connectors are just the interactions between components, which do not have direct contribution to some external behaviors. If some computational entity has very simple functions and these functions do not have direct contribution to the external behaviors, then it may be considered as an object, or even as a connector. If some connector represent a complex interaction protocol, then it may be considered as a component. Based on the dependencies between components, all components are divided into different subsystems. One subsystem may contain one or more components. Refine the top-level use case diagram, checking the necessity of identified components and connectors. In this step, some techniques used to identify subjects or subsystems in conventional OO analysis may be useful. Specify the components and connectors In this step, every component and connector are specified independently, in order to support potential reuse. Existing IDLs (Interface Description Languages), ADLs (Architecture Description Languages), STC (State Transition Chart), and use case diagram are useful tools to specify components and connectors. Some nonfunctional specifications may be adhered to these specifications. Produce SA-oriented high-level requirement specifications In this step, we will combine the specifications of components and connectors to form overall specifications for system requirements. Existing ADLs are the best tools to achieve this goal. Some nonfunctional specifications may be contained. Check the specifications In this step, we will check some properties of the SA-oriented requirement specifications, including completeness, consistency, and deadlock freeness, etc. Some techniques for SA checking may be useful here. 5. Conclusion In this paper, a complementary approach to requirements engineering is presented. The key ideas are viewing sorware architecture as the reference model in the software development process, viewing connectors as the first-class entities in the problem space, and introducing the SA concepts and principles into the requirement specifications at a higher-level abstraction. A SA-based software development process is presented and discussed, and a special attention is paid to SA-oriented requirement analysis and specification. We argue that this approach will be helpful to support requirement reuse, traceability between re- quirement specifications and system design, and consistency in whole software development process. This approach can be combined with existing software development methods, especially the OO methods to provide more effective development support. We must confess that this paper is just an elementary research. But we do believe that the idea is useful, and this approach will work. Hence further research will be necessary. The main research issues are as follows: Providing a complete and consistent SA-centred software development methodology, including a set of guidelines to guide the development activities, a more formally defined process model, and relevant tools and notations, etc. Combined with the research on SA, exploring the composition of components at different abstraction levels. Using this approach experimentally in the practical projects to get evaluations. Acknowledgements This effort gets support from Bell-Labs China and Software Production Research of Bell-Labs while the author works at Software Production Research Department. The author would like to thank David Weiss for his useful comments and suggestions on the draft. References  Finkelstein, A. Requirements Engineering: a review and research agenda, in Proc 1 st Asian & Pacific Software Engineering Conference, (IEEE CS Press)  David Garlan and Mary Shaw, An Introduction to SoRware Architecture, In Advances in Software Engineering and Knowledge Engineering, Volume 1, World Scientific Publishing Company,  Dewayne E. Perry and Alexander L. Wolf, Foundations for the Study of Software Architecture, ACM SIGSOFT Software Engineering Notes, 17(4),  Cristina Gacek, Ahmed Abd-Allah, Bradford Clark, and Barry Boehm, On the Definition of Soft'ware System Architecture, ICSE 17 Sottware Architecture Workshop,  A.K. Jones, The Maturing of Software Architecture, Software engineering Symposium, Software Engineering Institute, Pittsburgh, August  Bass, Clements, and Kazman. SoRware Architecture in Practice, Addison-Wesley 1997  Robert Allen and David Garlan, Formalizing Architectural Connection, ICSE 16, Italy, May,  Robert Allen and David Garlan, Beyond Definition/Use: Architectural Interconnection, Workshop on Interface Definition Languages, Oregon, January,  M. Shaw, R. Deline, D.V. Klein, T.L Ross, D.M. Young, and G. Zelesnik, Abstractions for Software Architecture and Tools to Support Them, IEEE Transactions on Software Engineering, April  David Garlan, Higher-Order Connectors, Workshop on Compositional Software Architectures, Monterey, CA, January  I. Jacobson, et al, Object-Oriented Sottware Engineering, A Use Case Driven Approach, Addison-Wesley, 1992.