Specifying Cross-Cutting Requirement Concerns

Geri Georg, Raghu Reddy, Robert France Colorado State University

[georg, raghu, france]@cs.colostate.edu

Abstract. Addressing non-orthogonal software concerns that arise from requirements can significantly contribute to the complexity of developing large systems. Difficulties arise from the need to: locate related requirements, reason about the software concerns they represent, and analyze the impact of changing requirements. We address these issues through the use of requirements aspects. We present a method to identify requ irements aspects from viewpoints , to associate requirements aspects with generic design solutions based on domain experience, and to specify the generic solutions using the UML. We demonstrate these techniques using a smart home controller application. Keywords: cross-cutting concerns, requirements aspects, specification, UML

1 Introduction

Complexity in large systems development can begin as requirements are gathered, analyzed, and synthesized to become the driving forces of system design objectives. During requirements analysis, software concerns are identified. Jackson [14] defines a software concern as anything of interest to a stakeholder. Software concerns may relate to specific system functionality or to other issues. Developers group requirements they perceive as being related to each other into more generalized software concerns such as usability or security. Software concerns may also impose additional requirements on the sy stem. Requirements complexity during the analysis process is driven by the number of: 1) requirements sources (e.g. users, developers, hardware/firmware components, physical environments, etc.), 2) requirements, and 3) interacting software concerns repres ented in the requirements. The related requirements that make up a software concern often come from different requirements sources, so it can be difficult to locate all the requirements related to a particular concern.

Determining the impact of requirements changes on software concerns can also be a complex task, since the requirements related to a particular concern are spread across multiple requirements sources. However, analysis is necessary since requirements changes may cause software concerns to become important in different requirements sources, cause new concerns emerge, or cause new relationships between concerns. The issues of locating related requirements, being able to reason about the software concerns they represent, and being able to analyze the impact of changing them contribute significantly to the complexity faced by the developers of large software systems.

We address these issues through the use of requirements aspects. Requirements aspects are aspects identified during requirements gathering and analysis, and they help structure requirements and related software concerns, in particular concerns that cross-cut the requirements specification. Requirements aspects can be used to structure functional software concerns or non-functional software concerns such as security and maintainability. Requirements aspects can provide a link between requirements and design by providing experienced-based design solutions . Analysis of these potential solutions identifies conflicts between cross-cutting system objectives that are not orthogonal.

In this paper we present an approach to 1) identify requirements aspects from multiple requirements sources , 2) associate requirements aspects with generic experienced-based solutions that address the concern, and 3) specify generic solutions using the UML [23-25]. We also briefly discuss how generic solutions can be analyzed and outline how these solutions can be used in later stages of the development process. The rest of this paper is organized as follows. Section 2 contains a background discussion of requirements and requirements aspects. Section 3 presents a method to identify and use requirements aspects. Section 4 applies this method to a case study under development at Colorado State University. Section 5 presents related work, and in Section 6 we discuss conclusions and future work.

2 Background

Software requirements are derived from many sources. Among these are users of the system, both within the organization building the system, and outs ide organizations that must interact with it. Other requirements sources include system developers and maintainers, firmware or hardware portions of the system that place constraints on the system software, and the business context and physical environment in which the system is used. We term each of these different sources a viewpoint. This notion of a viewpoint generalizes the definition of viewpoints given in Kotonya and Sommerville’s Viewpoint -Oriented Requirements Definition (VORD) technique. VORD defines a viewpoint as a requirements source external to the system that either receives services or provides data or control to services (see [19]). Requirements that are related to each other can be grouped into software concerns that may be related to the system’s required functionality or to other desired system qualities such as availability or security. Software concerns that cross-cut multiple viewpoints are called requirements aspects. We limit the focus of this paper to software concerns related to non-functional system behavior, although the approach presented can also be used for other software concerns that cross -cut multiple viewpoints.

Figure 1 shows the concepts used in the aspect-oriented requirements modeling approach described in this paper. Requirements may be described using different forms. Examples are static structure diagrams (including OCL constraints), text, scenario sequence diagrams, use case diagrams, and state machine diagrams. A requirements document therefore may consist of several different types of

information, both textual and graphical. A single requirement may be associated with any number of viewpoints. Viewpoints can be hierarchical.

Fig. 1 The structure and relation of system requirements and requirements aspects

Requirements aspects are logical groupings of requirements that relate to a software concern, with the added constraint that the requirements must cross-cut two or more viewpoints. Requirements aspects may give rise to additional requirements that are not present in any other viewpoints. T here may be a hierarchical decomposition of requirements aspects. Rashid, et al. [26 ] present a similar structure of viewpoint requirements and requirements aspects.

Requirements aspects related to many non -functional behaviors can be addressed with a set of standard solutions, developed through research and experience, that have been shown to effectively address the software concerns. For example, encryption is a generalized solution to the concern of data privacy when data is traveling over an un-trusted communication medium. Figure 1 shows that standard, or generic, solutions consist of different elements. Common examples are architectural patterns of system structure such as three-tier or blackboard, design patterns , and invariants.

The specification of a generic solution consists of a set of packages, where each package is a collection of elements. The types of element are: 1) a collection of functional design patterns specified as static diagrams and/or behavioral diagrams, 2) architectural patterns, and 3) system constraints. Each collection is specified as a set of templates . Constraints are thus written in terms of the template elements. When the solution is actually applied, it must be instantiated in the context of the software system. Details of this process are beyond the scope of this paper; see [10] for details on instantiation and composition of aspect models.

3 Requirements Aspect-oriented Modeling (RAM) Method

Cross-cutting concerns are often identified directly from textual requirements. It is also necessary to understand the system use-scenarios to determine where and how these concerns affect system behavior. We therefore create static and dynamic diagrams of a requirement model. The static portion of this model consists of a description of the problem concepts and the relations between them represented using UML static diagrams. The behavior diagrams describe the behavior of key concepts identified in the static diagram. We use sequence diagrams to specify these scenarios although activity or state diagrams can also be used. Once we have constructed static and dynamic diagrams we can analyze system requirements and identify cross-cutting, non-functional, concerns.

We group similar requirements into software concerns, and identify requirement aspects as those concerns with requirements that cross-cut multiple viewpoints. Requirements are originally presented at different levels of abstraction. Developers must work to evolve or deco mpose very abstract requirements into more detailed requirements that contain statements of acceptance criteria. A requirement that is very abstract (e.g. “the smart home system must be user-friendly”) must be decomposed into a set of more detailed requirements that contain measurable acceptance criteria (e.g. “a user must be able to program the heating system in the smart home in one minute”). The original and the detailed requirement both deal with the same non-functional concern, usability. Usability can be addressed by best practices developed through experience.

Requirements aspects are analyzed and addressed according to current best engineering practices. Best practices for many concerns have been identified through both research and practical use. They have been used in differing circumstances as patterns for solutions, and through time have been adjusted to meet changing conditions. We take advantage of the expertise already developed in these areas, and utilize their standard solutions.

It must be noted that just because a requirements aspect cross-cuts multiple viewpoints and can be addressed by a generic solution design pattern, that pattern may not become a design aspect. This is because a design aspect cross-cuts the primary modularization of system design, and a generic solution pattern may not. However, if a generic solution pattern cross-cuts sequence diagrams that deal with different areas of the system’s primary functionality, the pattern may cross-cut multiple modules of the design and be a design aspect. Requirements aspects that are best addressed through system structure will not be realized as design aspects. Requirements aspects that are addressed by constraints will remain constraints through the design phase. Examples of each of these generic solution cases are given in the case study described in Section 4.

The overall Requirements Aspect -oriented Modeling (RAM) method is outlined below. Input to the method is a set of viewpoints and their associated requirements.

(1) Group requirements with similar features/properties. The result is a set of software concerns. System designers rely on their expertise and experience to relate requirements to each other and more generalized software concerns.

(2) Identify concerns that cross-cut viewpoints. These are requirements aspects. Identify additional requirements based solely on the requirements aspects.

(3) Associate requirements aspects with generic solutions based on experience in the domain. Generic solutions include architectural patterns, functional patterns, and system constraints.

(4) Add detail to generic solutions as applicable. This can include detailing patterns or making constraints more specific.

Steps 5 and 6 are analysis steps: (5) If applicable, compose generic solution pattern models with design models to

identify interactions and potential conflicts. (6) Use analysis information from step 5 during initial system structuring. If patterns

cross -cut the system modularization, they become design aspects. Constraints identified in step 3 help direct software design, and may be used to ensure that the related software concern is adequately represented in the design.

We demonstrate steps 1-4 of the RAM method in the next section. Steps 5 and 6 use aspect -oriented modeling (AOM) composition and analysis techniques we developed for aspect-oriented design and are not discussed further in this paper. Please see our previous work for a discussion of model composition and conflict analysis [10 -12].

4 Case Study – A Smart Home System

The smart home control system is being used as a research vehicle at Colorado State University and is the basis of a set of design problems used in senior-level classes in the Computer Science Department. The smart home consists of several devices that can be controlled through software, and the system software is responsible for both acquiring data from these devices and controlling them. Devices capable of being part of the system include heating and air conditioning subsystems, a sprinkler subsystem, an alar m system, water heaters, etc.

There are several stakeholder viewpoints represented in the initial system requirements. These include:

• a consumer who configures the smart home system and gets it running • a consumer who analyzes reports generated by the smart home controller,

generally for the purposes of conserving resources • repair personnel called in to fix particular device failures • devices that are part of the smart home system • installation personnel who add new devices to a home

Requirements that result as interaction with ancillary organization include those from:

• emergency response personnel • electric, water, and gas companies who own the meters associated with a home

Sample requirements from two of these stakeholders are given below. The example stakeholders are the consumer who configures the smart home system and the consumer who analyzes reports. Requirements are identified with the stakeholder code and a number. These requirements were chosen from a much larger set of requirements for the purposes of illustration. In some cases the same requirement is present in multiple viewpoints, as demonstrated by requirements CSA -2 and CA-2.

Consumer System Administrator (configures overall system – code is CSA): • system must be easily used by someone not familiar with computers (CSA -1) • multiple user interfaces are needed to accommodate user preferences (CSA -2) • it must be easy to check device configurations (CSA -3) • a configuration has to be coherent (e.g., no air conditioning in the winter) (CSA -4) • configurations and other information presented to the user must reflect the actual

state of the devices controlled by the system (CSA -5)

Consumer Analyzer (analyzes reports to conserve resources – code is CA): • system must be easily used by someo ne not familiar with computers (CA-1) • multiple user interfaces are needed to accommodate user preferences (CA-2) • reports need to suggest ways to save money on electricity, gas, and water (CA-3) • reports must be accurate (CA-4) • reports must be available on demand or automatically (CA-5)

System designers group the requirements given above into generalized software concerns, based on experience. For example, requirements CSA-1, 2, 3 and CA-1, 2, 5 all relate to the software concern of usability. Requirements CSA -4, 5 and CA-4 relate to correctness, and requirements CSA-2 and CA-2, 5 relate to availability. In all three cases the concerns cross-cut multiple viewpoints, so each is a requirements aspect. We will address the usability requirements aspect in detail in the following discussion.

We analyze a requirements model in order to understand how the usability requirements aspect will affect system behavior. A portion of the static diagram for this model is shown in Figure 2, and a use-scenario in Figure 3. We use an interaction diagram to show the use-scenario rather than a use-case diagram in order to show more detail about the interactions. The extra detail allows us to identify locations where a requirements aspect generic solution needs to be applied.

Fig. 2 Portion of the requirements model static diagram for the smart home system

The major classes shown in Figure 2 are two consumer users, the system administrator and an analyst, a controller, a heating sub-system, reports to be analyzed, and storage for device configurations. We define a configuration for the heating sub-system to consist of a target temperature for the home, and a state, either on or off. The current house temperature is also part of this sub-system. The static structure shown in Figure 2 does not include specific device components of the heating sub-system, although these devices (a heater and a fan) are shown in Figure 3.

Figure 3 shows the use-scenario for changing the configuration of the heating system. This scenario is shown as a sequence diagram.

This sequence is initiated when the consumer system administrator chooses the heating system. The system controller gets the configuration of the heating system and the current house temperature. The consumer system administrator requests the controller to show this configuration so it is presented to the user. T he user must decide whether or not to change the configuration. If there are no changes to be made, the sequence is complete. If there are changes to be made, the user may request to view settings used at some other time using getSpecificConfig . In this case the controller must access the configuration storage to obtain the configuration of interest. T he user can decide what changes to make to the configuration and reques t that the controller make them. The controller needs to perform consistency and correctness checks on the proposed configuration, and if it is acceptable, request the heating system to change . If the configuration is in error, then the controller must present an error to the user via showConfigError. Once the heating system has made changes the new configuration can be saved to storage.

Once a requirements aspect has been identified, it may impose additional requirements on the system. For example, in the area of usability, various researchers have described usability as dealing not only with the user interface, but also with a system’s structure and underlying concepts [1, 3, 8, 17]. This description leads to the addition of usability requirements that address concepts such as the user’s ability to learn how to use the system, efficiency at completing tasks, knowledge retention over time, error rate, and overall satisfaction with the system [8]. Different researchers identify slightly different requirements for usability; an alternative definition of usability is the user’s perception of the system’s simplicity, understandability, and ease-of-use [3]. These additional requirements are related to the usability requirements aspect, but not to any other viewpoint in the system. Rashid, et al. [26] also identify requirements that are part of a requirements aspect, and not a stakeholder viewpoint. T he change configuration sequence diagram has three areas where interaction with the user can be designed to address usability requirements: getting input from the user, presenting information to the user, and the mental model used to provide consistency in these actions. In particular the mental model can directly influence usability requirements. For example, when a user’s mental model is compatible with the underlying metaphor of the software, learning, efficiency, retention, and error rate are all positively affected. Satisfaction can be positively affected by compatible metaphors. A consumer metaphor may differ from the metaphor used for other users, such as a heating system installer.

We next identify best practices that address input, output, and metaphor usability requirements. For example, the user input experience can be improved by generic solutions such as remembering previous input choices, making suggestions for input, and performing error checking on the fly. Providing different kinds of input technologies such as graphical, audio, keyboard, and remote capabilities also can improve usability. Output functionality that uses consistent concepts and allows different presentation mediums is also part of a generic solution to usability. Finally, the use of a consistent metaphor that is a simple model employing familiar terminology, and that is consistent across the system is another generic solution [1, 3, 4, 8, 17, 21].

Fig. 3 Sequence diagram to change heating system configuration

Some of these generic solutions can be treated as constraints on the design, for example the consistent use of a metaphor. Sometimes generic solutions are architectural patterns, for example a 2- or 3-tier architecture. The metaphor model is a design pattern . Not all usability generic solutions are needed for every user interaction; they do not all pertain to every use-scenario. We therefore need to be able to specify generic solutions, and also to note where specific solutions will be applied in the system. We achieve this by specifying the generic solutions as UML packages, and annotating the requirements model diagrams with references to them. We specify generic solutions after providing more detail to them. We demonstrate this detailing using the metaphor solution. A metaphor is the mental model a user uses to interact with a system.

We also define the dynamic behavior of the metaphor as translating information that needs to be presented to the user into the terminology and preferred representation for that user, and performing the inverse of this translation for information the user is putting into the system. Constraints associated with the metaphor include the constraint that all user input and output must go through the metaphor, with appropriate translation for different users. This is the informal specification of the metaphor generic solution. We next discuss this generic solution specification according to the notation presented in Section 2. The definition of the metaphor solution can be specified in static diagrams. Since the definition is generic, we use the template notation developed for generic aspects in our AOM research. Dynamic behavior diagrams that specify metaphor operation are specified as template sequence diagrams. Metaphor constraints are specified using natural text. These three items comprise the metaphor generic solution. If architectural structure patterns were also a part of this generic solution they would be specified using the UML architectural notation. Due to space constraints we do not show the complete package notation described in Section 2, but examples of static and behavioral diagrams are pres ented in Figures 4 and 5. Figure 4 shows the major structural roles and relationships between them that are needed to add the generic metaphor solution to an application. The only addition to this static diagram over the metaphor definition discussed above is that of a target which is the ultimate source or sink of the information provided to or from the user. In the smart home system, two different user types might be a consumer and the installer of a heating subsystem. The items that are to be represented during user interactions would be the controller and the elements of the heating subsystem, a thermostat (with its own controller), a heater, and a fan. The terminology would include terms for all of these items in the case of an installer, but perhaps only terms for the smart home controller, heating subsystem, and fan for a consumer. Part of the metaphor terminology mapping would include the fact that the installer concepts of heater and thermostat with its own controller are not part of the consumer concept of a heating subsystem. Each element name in Figure 4 that is preceded by the | symbol may be mapped to a model element in the requirements model when the generic solution is applied to an application. For example, the model element |userType in the metaphor diagram

corresponds to both the consumerSystemAdmin and the consumerAnalyst classes in the smart home requirements model shown in Figure 2. Similarly, the generic solution element |itemsToRepresent corresponds to the heatingSystem class. Finally, the |target generic solution element corresponds to the controller class. A direct communication between a user and the target is prohibited once the metaphor solution has been applied to an application. This is shown using the <<prohibited>> stereotype. OCL statements in Figure 4 constrain relationship multiplicities. When a generic solution is applied to an application it must be instantiated from the template and then composed with the requirements model of the application. Composition follows the same approach as that outlined in our other aspect-oriented modeling work. See [9, 11] for details on AOM composition.

Fig. 4 Static diagram of metaphor pattern

Figure 5 shows the dynamic behavior for user input and output using the generic metaphor solution. The sequence diagrams shown in Figure 5 also use the aspect notation developed in our previous AOM research. Model elements whose names are preceded by the | symbol may be mapped to model elements in the target application requirements sequence diagrams. The first metaphor sequence shows that input from the user is translated by the metaphor and passed onto the target. The output sequence is the inverse of this behavior. For simplicity, we have not detailed the sequence used by the metaphor in the actual translation, which includes the |itemsToRepresent, |representationSet, |terminologySet , and |transformSet elements from the structural diagram shown in Figure 4. The constraints for the metaphor aspect are:

• all input and output between |target and |userType must pass through the metaphor

• the correct terminology must always be used for each user type

• the preferred representation set must always be used for each user type The metaphor generic solution consists of the static and behavioral diagrams shown in Figures 4 and 5, and the constraints noted above. These constraints are specified informally using template elements and constitute the constraint package of the metaphor generic solution. This generic solution is associated with the usability requirements aspect. Other generic solutions can be similarly specified and associated with the usability requirements aspect. Since different generic solutions can be applied to different user interactions, annotations referencing these solutions can be applied to the interactions, and further aid requirements traceability.

We annotate requirements model diagrams with requirements aspect information as follows. An A icon is appended with the defined abbreviation of the requirements aspect . If there is a generic solution that can be applied, an abbreviation of the generic solution is added. This annotation is placed on the requirements model where it is affected by the requirements aspect. For example, we define a usability requirements aspect for the smart home system and give it the abbreviation U. We assign an abbreviation m to the metaphor generic solution. Thus, the annotation for the metaphor solution of the usability requirements aspect is A-U-m. Similarly, A-U-ui, A-U-i, and A-U-o are the annotations for the user interface, input, and output generic solutions.

Fig. 5 Dynamic behavior of the metaphor (a) input behavior and (b) output behavior. The metaphor is a translator between user input and some portion of the target system

All user interactions between consumerSystemAdmin and controller in Fig 3 can be annotated to indicate that the metaphor pattern solution to the usability requirements aspect affects the sequence at these points. In addition, the Fig 3 sequence in controller that presents an error to the user (showConfigError ) is also a point where this pattern needs to be applied. Generic solution information can also be added to the diagram as general constraints. Example constraints for the metaphor pattern are: 1) all input and output between any target and user must go through the metaphor, 2)

the correct terminology must always be used for each user type, and 3) the preferred representation set must always be used for each user type. In cases where a requirements aspect or sub -aspect can be addressed with a design pattern, such as in the case of the metaphor generic solution, this pattern can be composed with the existing requirements model in a similar fashion to that described in our work on design aspect model composition [10-12]. Aspect model composition and subsequent analysis are useful to system architects as part of the process of identifying and mitigating conflicting software concerns at the requirements level.

5 Related Work

Researchers have presented different approaches for identifying/modeling aspects at higher levels of abstraction. Several methods have been proposed for separating concerns at the design level, but very few at the requirements level. Rashid et al. [26, 27] propose an approach for modularizing cross cutting concerns. The approach involves identifying requirements using stakeholders' viewpoints, use cases/scenarios, goals or problem frames. The aim is to establish an approach that can help in conflict resolution and critical trade-offs between concerns before the architecture is derived. The approach basically uses a set of matrices consisting of the viewpoints and concerns represented in XML. The approach is supported by the Aspectual Requirem ents Composition and Decision support tool (ARCaDe). This is very similar to initial steps in our technique, but it does not include the generic solutions that can help in determining how to address the requirements aspect. AOM complements this work by supporting requirements aspect identification, identifying generic solutions to address requirements aspects , composition of generic solutions with requirements models to identify potential conflicts, and traceability between requirements, requirements aspects, and generic solutions. Araujo and Coutinho [2] provide a viewpoint-oriented requirements method for managing crosscutting requirements. This is similar to the approach presented in this paper except that they consider the system as a black-box. The approach described by Araujo and Coutinho only represents use cases, whereas other types of requirements representation may be necessary. Ebert's work [7] gives a set of guidelines for specifying, measuring and tracing quality attributes namely performance, usability, reliability, and maintainability. The work is not rigorous and only shows a set of guidelines. This method does not address the problem of software concern identification. Jacobson [15, 16] describes the development of design aspects based on use-cases, which are then composed to create different views of the system. This work maps directly to program level aspects, using the composition techniques originally developed for AspectJ [18]. Our approach is more general since we deal with software concerns from viewpoints other than end users, we address requirement s that cannot easily be represented as use-cases (e.g. requirements resulting from a business context). Our composition techniques do not impose the assumptions of the AspectJ model and therefore can be used to perform a wider range of compositions (see [10]

for details). We also use analysis to identify conflicts between interacting concerns, and to provide guidance in the resolution of these conflicts. This topic is not addressed in Jacobson’s use-case driven aspect work. Gray et al. [13] use aspects in domain-specific models that target embedded systems specifically. Requirements, architecture and the environment of a system are captured in the form of formal high -level models that allow representation of concerns. The work in this research can complement theirs by providing UML based approach for representing aspects, and making trade-offs. Zarate and Botella [28] use UML to represent non-functional requirements. They use stereotypes, class compartments and stereotyped dependencies to represent the non-functionality aspect and OCL to represent the constraints. The approach shows the representation of different non-functional requirements on a simple set of functionality, but it does not show a way to handle non-functional requirements that cross cut functionalities. The subject-oriented design approach presented by Clarke et al. [5, 6] is a UML based approach similar to the AOM approach used in this research. In the subject-oriented approach every requirement is treated as a subject and a comprehensive design is obtained by composing the views provided by these subjects. Their work is more at the design level and complements our design-level AOM approach. Suzuki and Yamamoto [29 ] propose an extension to UML to support aspects. They describe aspect s as a classifier in the meta-model. Their approach is restricted to design aspects that can be represented as aspects in an aspect -oriented program.

Mylopoulos et al. [20, 21] describe a technique called soft-goals that can be used to decompose requirements. Soft-goals are especially useful for refining the affects of non-funct ional behavior . Direct validation can be provided to show that behaviors represented by soft-goals are present in a specification. Soft-goals are useful in making trade-off decisions during design. Our method does not make trade-off decisions during requirements analysis. Instead we present best practices, and the potential interactions between them, to system architects for their consideration when creating the system architecture. Nuseibeh [22] defines ViewPoints™ as cross -cutting, partial knowledge of the system and its environments from the perspective of different stakeholders. Nuseibeh notes challenges in composing ViewPoints™ and analyzing interactions across them. Our work is complimentary in that we use requirements aspects to locate potential interactions between requirements viewpoints and we have developed composition and analysis techniques to address these interactions.

6 Conclusions and Future Work

The issues of locating related requirements that are spread across the system, determining the software concerns they represent , specifying these concerns in an understandable way, tracing the concerns through design, and analyzing conflicts between non-orthogonal concerns need to be addressed at early stages of software development. We address these issues through the use of requirements aspects. We define requirements aspects as software concerns whose related requirements cross-

cut two or more viewpoints. We presented a method called Requirements Aspect-oriented Modeling (RAM) to identify requirements aspects from viewpoint-based requirements, and to identify best practice design solutions based on domain experience. We specified generic solutions using the UML. A simplified smart home case study that contains cross-cutting concerns was presented. Usability, availability and correctness requirements aspects were identified using the RAM method. We expanded on the usability requirements aspect using the generic solutions based on domain experience. The RAM method allows architects to identify software concerns and their generic solutions at the requirements level, which gives them a better idea about the possible design alternatives. The use of architectural patterns and constraints can result in resolution of conflicts. Although the paper has not shown the traceability to design and composition of usability aspect with the smart home system (which is possible as shown in our earlier design level AOM work), it does provide us with an approach to handle these problems. We plan to further expand the smart home example to identify more requirements aspects and establish a concrete traceability mechanism with our design aspect-oriented modeling. We also intend to identify some architectural patterns and other generic solutions to compose with the sequence diagrams for identification and resolution of conflict resolutions. The work presented in this paper shows that it is possible to identify aspects from requirements, and to track the relation between original requirements and their associated aspects. We are currently working to make the approach more methodical, including the issue of grouping requirements and identifying software concerns from these groupings.

References

1. J. Anderson, F. Fleek, K. Garrity, and F. Drake, "Integrating Usability Techniques Into Software Development," IEEE Software, vol. 18, no. 1, pp. 46-53, 2001.

2. J. Araujo and P. Coutinho, "Identifying Aspectual Use Cases Using a Viewpoint-Oriented Requirements Method," in Early Aspects 2003: Aspect-Oriented Requirements Engineering and Architecture Design Workshop. 2nd International Conference on Aspect -Oriented Software Development. Boston, MA, 2003.

3. S. Becker and F. Mottay, "A Global Perspective on Web Site Usability," IEEE Software, vol. 18, no. 1, pp. 54-61, 2001.

4. L. Chung, B. A. Nixon, E. Yu, and J. Mylopoulos, Non-Functional Requirements in Software Engineering. Boston, Dordrecht, London: Kluwer Academic Publishers, 2000.

5. S. Clarke, "Extending Standard UML with Model Composition Semantics," Science of Computer Programming, vol. 44, no. 1, July, pp. 71-100, 2002.

6. S. Clarke, W. Harrison, H. Ossher, and P. Tarr, "Separating Concerns Throughout the Development Lifecycle," in Proceedings 3rd ECOOP Aspect-Oriented Programming Workshop. ECOOP. Lisbon, Portugal, 1999.

7. C. Ebert, "Dealing with Nonfunctional Requirements in Large Software Systems," Annals of Software Engineering, vol. 3, September, pp. 367-395, 1997.

8. X. Ferre, N. Juristo, H. Windl, and L. Constantine, "Usability Basics for Software Developers," IEEE Software, vol. 18, no. 1, pp. 22-30, 2001.

9. R. France, I. Ray, G. Georg, and S. Ghosh, "An Aspect-Oriented Approach to Design Modeling," IEE Software, to be published.

10. G. Georg, R. France, and I. Ray, "Designing High Integrity Systems Using Apsects," in Proceedings of the 5th IFIP TC-11 WG. 11.5 Working Conference on Integrity and Internal Control in Information Systems (IICIS 2002), 2002.

11. G. Georg, R. France, and I. Ray, "Composing Aspect Models," in 4th AOSD Modeling with UML Workshop. UML 2003. San Francisco, CA, October, 2003.

12. G. Georg, I. Ray, and R. France, "Using Aspects to Design a Secure System." Proceedings of the 8th IEEE International Conference on Engineering of Complex Computer Systems (ICECCS 2002). Greenbelt, MD, 2002.

13. J. Gray, T. Bapty, S. Neema, and J. Tuck, "Handling Cross-Cutting Constraints in Domain-Specific Modelling," Communications of the ACM, vol. 44, no. 10, October, pp. 87-93, 2001.

14. M. Jackson, Problem Frames . Addison-Wesley, 2001. 15. I. Jacobson, “Case for Aspects – Part I”, Software Development Magazine, October, pp 32-

37, 2003. 16. I. Jacobson, “Case for Aspects – Part II”, Software Development Magazine , November, pp

42-48, 2003. 17. N. Juristo, H. Windl, and L. Constantine, "Introducing Usability," IEEE Software, vol. 18,

no. 1, pp. 20-21, 2001. 18. G. Kiczales, E. Hilsdale, J. Hugunin, M. Kersten, J. Palm, W. Griswold, "Getting Started

with AspectJ“, Communications of the ACM , vol. 44, no. 10, October, pp 59-65, 2001. 19. G. Kotonya and I. Sommerville, "Requirements Engineering with Viewpoints," IEE

Software Engineering Journal, vol. 11, no. 1, pp. 5-18, 1998. 20. J. Mylopoulos, L. Chung, and B. Nixon, "Representing and Using Nonfunctional

Requirements: A Process-Oriented Approach," IEEE Transactions on Software Engineering, vol. 18, no. 6, June, pp. 483-497, 1992.

21. J. Mylopoulos, L. Chung, and E. Yu, "From Object-Oriented to Goal-Oriented Requirements Analysis," Communications of the ACM, vol. 42, no. 1, January, pp. 31-37, 1999.

22. B. Nuseibeh, “Crosscutting Requirements”, in Proceedings of the 3rd International Conference on Aspect-Oriented Software Development (AOSD 2004) , Lancaster, UK, 2004.

23. OMG, "Response to the UML 2.0 OCL RfP," 1/7/2003, 2003. 24. OMG, "UML 2.0 Infrastructure Specification," Http://www.omg.org/docs/ptc/03-09-

15.pdf, 9/15/2003, 2003. 25. OMG, "UML 2.0 Superstructure Specification," Http://www.omg.org/docs/ptc/03-08-

02.pdf, 8/2/2003, 2003. 26. A. Rashid, A. Moreira, and J. Araujo, "Modularization and Composition of Aspectual

Requirements." 2nd International Conference on Aspect-Oriented Software Development. Boston, MA: ACM, 2003, pp. 11-20.

27. A. Rashid, P. Sawyer, A. Moreira, and J. Araujo, "Early Aspects: A Model for Aspect-Oriented Requirements Engineering." IEEE Joint International Conference on Requirements Engineering. Essen, Germany, 2002, pp. 199-202.

28. G. Salazar-Zarate and P. Botella, "Use of UML for Non-Functional Aspects." 13th International Conference Software and Systems Engineering and Their Applications (ICSSEA 2000). Paris, France, 2000.

29. J. Suzuki and Y. Yamamoto, "Extending UML with Aspects: Aspect Support in the Design Phase," in Proceedings 3rd ECOOP Aspect-Oriented Programming Workshop. ECOOP. Lisbon, Portugal, 1999.