Towards a Framework for Extracting Requirements from Legacy User Interfaces: an Empirical Approach Dr. Naoufel Boulila Siemens Corporate Technology, Munich, Germany,
[email protected]
Abstract Nowadays, a high number of organizations are still using legacy systems which are outdated and difficult to maintain and improve. Among the reasons why these systems are difficult or impossible to improve is the lack of their original requirements specification. These systems however, have very valuable information about the end user needs spread all over the user interfaces. These needs reflect to some extent the stakeholder requirements.
about the undocumented requirements of these systems. In this paper we describe the case study from which we learned how to outline the most important components for a more general solution to address the issue of extracting or deriving requirements from existing and legacy user interfaces II.
MOTIVATION: REQUIREMENTS FOR LEGACY SYSTEMS
We describe an empirical approach including a technical solution to enable the extraction of the functional requirements from existing user interfaces and to produce a requirement specification document according to a well defined template. The empirical approach was applied in an industrial case study. The results serve to build a more general framework solution.
I.
INTRODUCTION
Today many legacy systems using old technologies, including software and hardware that are no longer supported by the vendors, are still being used and need to be modernized and improved. These existing systems lack, among others, the documentation of their requirements. This makes the re-engineering of these systems very difficult, very expensive and might lead to the risk of business interruption. In order to be able to re-engineer these systems, the valuable information such as the requirements behind them is needed. Many of these systems have outdated and difficult-to-use user interfaces. However, these user interfaces include valuable information about the system being used and some rationale behind their functioning. These user interfaces reflect, to some extent, the needs of the stakeholders who funded the development of these systems. Extracting the requirements from existing user interfaces would provide a substantial amount of crucial information
Software developments nowadays are developed according to well defined and a standardized methods and processes as widely spread in the software development companies and as described in the software engineering curricula in the academia. It is well known that during the development process, first the requirement have to be iteratively elicited and well defined then the underlined software or system is developed. User interface design and development needs, for instance, the underlined requirements of the system and in some situation a usability study to be conducted. Legacy and existing systems lacking the documentation of the underlined requirements are difficult or practically impossible to re-engineer and improve. The problem which needs to be addressed is how to extract requirements from the already existing systems and in particular user interfaces. Once an acceptable quality of a requirements specification is generated, the underlined system can be better reengineered and improved. III.
PROBLEM DEFINITION AND CASE STUDY
We had an opportunity to conduct and manage an industrial project consisting in the re-engineering of a legacy software platform. The existing software platform was not fit anymore to cope with the increasing demands of new features from the
different stakeholders and the complexity of the cases managed by the end users of the platform. Consequently there were several main issues to solve. The first issue was to improve the platform itself to cope with the increasing need of its integration into a new environment where newer technology is in place. Several incompatibilities of the software platform prevent its deployment in the new environment. The second issue was that newly defined requirements from various stakeholders including supporting distributed end users over different continents, as well as handling newly emerged threats of the internet security have been emphasized. The new requirements and the requirements originating from the legacy system have to be merged together. The legacy system however had neither available requirements specification nor any documentation providing any rationale behind the software platform and its development. An employee turn-over have made the task even more difficult as he assisted in the development of the previous system in its initial phases. We were confronted with the difficulty of having an old-fashioned but crucial platform to the company where neither specification nor anybody available to describe the requirements that lead to its development. A. Initial empirical method The only means we had to start from was the different user interfaces forms representing in fact some feature or functionality of the software platform. Since the software platform included a rich user interfaces with a high number interactive dialogues, forms, and graphical user interface widgets, we wanted to use as much as possible of the available information to manually extract the most important requirements. As a start we have collected relevant screens available and sorted them into categories. In a next step analyzed each possible user interface, and then derived main components including possible inter-relationships. From there we extracted necessary function of each component and subcomponents of the user interface. In a next step, we modeled these relationships using interface flow
diagrams. Finally, combining these models such as dependency between components and the interface flow diagram produced initial requirements models which were then written down in a document. From this experience we derived a simple approach (shown in fig. 1) that can to some extent be automated to do the manual work we did before. Then in a later step we developed the framework that served in the further development of the requirements document of the legacy system.
Figure 1: Initial empirical approach applied to extract requirements from user interfaces
B. Example from the case study In the following we show a short example as used in the case study. For regulatory reasons we show only partial example from “fig. 2” to “fig. 14”. This an example transformation of user interfaces into requirements models. Figure 2 shows a particular user interface dialogue of the software platform representing a “type of proceeding”. Staring from this user interface dialogue, every widget including labels, pull-down menus, and text forms were extracted and put into a relationship that traces their dependency using a high-level interface flow diagram as show in figure 3. Then a detailed flow diagram (see figure 4) is built to describe the dependency between the widgets and the flow of events which take place when initiating a particular action on a given GUI-widget. In a later step, using a UML activity diagrams we build a near-final model describing more detailed interaction between the components of a given feature such as adding a “new case or proceeding” in this case.
Figure 2: an example user interface used in the case study: UI- Type of proceeding and details
Figure 3: Main Interface Flow Diagram
Figure 4: Detailed Interface Flow Diagram
Figure 5: UML activity diagram describing the “add new case” example.it includes mode detailed interaction between elements of user interface which in turn describes real requirements for the software platform itself
IV.
THE UI-REE FRAMEWORK
The proposed solution consists in a framework called UI-REE (User Interface Requirement REEngineering, (see figure 6, 7, 8) which provides a mechanism to read user interface specifications and to extract from them user and system requirements and transform it to a requirement specification document. The framework was developed after gaining experience from an
industrial project where a legacy software platform had to be re-engineered and improved to cope with today’s challenges and newly defined requirements from various stakeholders. UI-REE is a component-based framework which consists of five main cooperating components including Input, Analysis, Processing, Documentation, and Output (Figure 6 shows a meta-model).
class UI-REE Component Model UI-REE
Input
GUI
UIML
RelationshipDiagram
Analysis
Interface Flow Diagram Processing
RequirementsTraces FunctionalRequirements Documentation RequirementTemplate
UseCaseModel
Ouput RequirementsModel
RequirementsDocument
SequenceDiagramModel
Fig. 6: UI-REE Meta-Model (UML Class Diagram)
Fig. 7: UI-REE framework example input (user interface specification, simple GUI) and the corresponding output (UML models, structured text)
V.
UI-REE FRAMEWORK COMPONENTS
Figure 8: An example of generated use case and requirements text generated
The different framework components are described as follows: A. Input component The input component provides a mechanism to describe the user interface input using the User Interface Markup Language (UIML). UIML is an XML-compliant language. This component can also transform a GUI specification to a standard user interface definition using UIML.
B. Analysis component This component analyses the user interface specification and extracts two main artifacts: Relationship diagram (see “fig. 9” and “fig. 10”): the generated diagram describes the relationship between the various UI elements (called widgets, see “fig. 4”) and therefore it describes the relationship between functions and consequently it describes the relationship between functional requirements. This, in turn, describes the relationship between functional requirements.
interface. The interactions are typically relationships and method calls such as Widget.function (parameters). The function calls are good candidates for functional requirements. For example a function AddNewProductName (NameOfProduct) leads to a functional requirement which states that the “User shall be able to add a product name”.
Fig. 9:Widget dependency
Fig. 10: Widget composition
Interface Flow Diagram (see “fig. 11” and the case study example)
C. Processing (transformation engine) The processing component (see “fig. 12”) provides a transformation engine which takes the output of the Analysis component, i.e. the Relationship and Interface Flow diagrams, and converts these into Requirements Traces and Functional Requirements D. Documentation The Documentation component takes the output of the Processing component, i.e. the requirements traces and the functional requirements and generates a requirements document containing the requirements formulation according to a well-defined template and to the IEEE standard for writing requirements as show in “fig. 6”.
User interface-flow diagrams are typically used for several purposes such as: •
•
to model the interactions that users have with your software, as defined in a single use case to enable the user to gain a high-level overview of the user interface for the underlined application
Fig. 12: The UI-REE framework
Fig. 11: Interface Flow Diagram
These kinds of diagrams are used to define the interactions between the various widgets of the user
VI.
RELATED WORK
Relatively considerable work has been done to modernize the legacy systems by studying the available documents and source codes [1,4]. Main methods used in the industry include screen scrapping, database gateway, XML integration, database replication, CGI integration, objectorientation wrapping, and componentization of legacy systems [3] However, very few of these deal with recovery of legacy systems requirements. For instance the AMBOLS [5, 6, 7] approach deploys a process of requirement recovery which is organized into a series of activities in three stages: Behavior Capture, Dynamic Behavior Modeling, and Requirements Derivation. In the AMBOLS approach, organizational semiotics has been adopted as major theoretical foundation. Organizational semiotics offers a theory to understand business organizations, with or without the computerized information systems. In contrast to the above methods, our approach uses existing software as well as hardware interfaces to derive automatically initial requirements of the existing systems. For a first iteration there is no need to study neither the history nor the business of the organization.
VII.
CONCLUSION
In this paper we presented an initial experiment about the extraction of requirements from user interfaces in an industrial case study using an empirical approach. We presented an evolution of the approach into an initial framework with a premise to extract semiautomatically requirements from legacy user interface systems. In particular, it utilizes existing interfaces to derive the functional requirements, their dependency,
and generate use case and sequence UML models which describe to some extent a greater part of the existing system functionally. The approach developed is gained from an industrial case study where a legacy system had to be re-engineering to cope with newly deployed technology in the environment where the legacy system is installed. The method was tested and has proven its efficiency to an acceptable degree by the customer. Combined with other methods for requirements recovery of legacy systems, it can provide a higher degree of efficiency and acceptance. For future work, we plan to replicate the case study in different industrial domains and assess its efficiency and cost using quantitative methods. The framework is registered and protected under a Siemens disclosure.
References [1]. Ashish, N. and Knoblock, C. (1997) Wrapper Generation for Semi-structured Internet [2]. Sources, ACM SIGMOD, 26, 4, 8-15. [3]. Kecheng Liu Requirements Reengineering from Legacy Information Systems Using Semiotic Techniques Informatics Research Centre, The University of Reading, UK [4]. Comella-Dorda, S., Wallnau, K., Seacord, R. and Robert, J. (2000) A Survey of Legacy System Modernization Approaches, Technical Report CMU/SEI-2000-TN-003, Software Eng. Institute, Carnegie Mellon University [5]. El-Ramly, M., Stroulia, E. and Sorenson, P. (2002) Recovering Software Requirements from System-user Interaction Traces, Proc. 14th Int’l Conf. Software Eng. and Knowledge Eng., Ischia, Italy, 447-454. [6]. Liu, K. (2000) Semiotics in Information Systems Engineering, Cambridge University Press, [7]. Cambridge, UK [8]. Liu, K. (2004) (ed) Virtual, Distributed and Flexible Organisations - Studies in Organisational Semiotics, Kluwer Academic Publishers, Dordrecht [9]. Liu, K and Ong, T. (1999) A Modelling Approach for Handling Business Rules and Exceptions, The Computer Journal, 42(3), 221-231. [10]. Liu, K., Alderson, A. and Qureshi, Z. (1999a) Requirements Recovery of Legacy Systems by Analysing and Modelling Behaviour, Proc. Int’l Conf. Software Maintenance, Oxford, England, 3-12.
