MAPPING THE IMPACT OF REQUIREMENT CHANGES USING LABELLED TRANSITION SYSTEM FOR REQUIREMENT CHANGE (LTS-RC)

Transcription

1 315 MAPPING THE IMPACT OF REQUIREMENT CHANGES USING LABELLED TRANSITION SYSTEM FOR REQUIREMENT CHANGE (LTS-RC) Martasari Widiastuti *, Daniel Siahaan Informatics Department, Information Technology Faculty, Institute Technology of Sepuluh Nopember Surabaya, Indonesia ABSTRACT Labelled Transition System for Requirement Change (LTS-RC) is a state transition system of requirement changes where transitions of changes in requirements are labeled. Transition labels represent weights of changes dependency between requirements. The states represent requirements as basic elements of system. LTS-RC is used to model software requirement changes. It describes interaction between requirements in certain software system. We use requirement dependencies as variable to determine the direction of edge transition. By using LTS-RC the user is enabled to analyze alternative paths based on an initial requirement that was chosen by stakeholder to be changed. This paper focus on mapping the impact of requirement changes using Labeled Transition System for Requirement Change (LTS-RC). By mapping the impact of requirement changes, it is expected that the stakeholder is assisted to choose changing steps and to validate the cost of changes being implemented. Keywords: Requirement changes, Labelled Transition System for Requirement Change (LTS-RC). 1 INTRODUCTION Requirement changes are complex problem that we need to solve by managing them regularly because they can make another changing. When faced with a single change request that requires a developer to add new functionality to a system or change an existing function, there is always the risk of even the smallest requirement change snowball into a large project. This snowball effect can have several causes. When changing a system requirement, that requirement will likely have dependencies on other requirements, and other requirements will in turn depend on that requirement. When this is the case, a requirement change is not isolated to a single requirement. It can turn into a large project while dealing with the changes that need to be made to satisfy the requirement dependencies. There is also the case that changing a single requirement may introduce a conflict with an existing requirement. In this case, both requirements must be modified so that the new functionality can coexist with the other requirements. If any principle software functions are affected by a single requirement change, then those functions must be changed to ensure the change is successful. Another issue is that of performance. When a single change is made that reduces a quality factor such as CPU performance, then this change may require the hardware components or the system allocation of processes to change [1] [3]. Schneidewind points out that there are numerous risks associated with changing software requirements. Many of these bring about the snowball effect when making a software change. He recommends performing dependency checks among risk factors to determine how a change will affect the various aspects of a system. Once this check is completed, a systematic planned approach can be developed to handle dependencies and properly estimate the cost and schedule requirements of the change [1][3]. LTS-RC is a state transition system of requirement changes where transitions are labeled. Transition labels represent weight of changes dependency between requirements. The states represent requirements as basic elements of system [2]. This paper focus on mapping the impact of requirement changes using Labeled Transition System for Requirement Change (LTS-RC). The paper is organized as follows: Chapter 2 describes about describes about design, FSP formulation, DFD, and s of LTS- RC. Chapter 3 details how visualizations are specified using certain cases study and describes

2 316 4 th International Conference Information & Communication Technology and System how our approach can analyze maps of impact for requirement change. The paper concludes with a discussion and further work. 2 MODEL AND IMPLEMENTATION Chapter 2 describes about design, FSP formulation, DFD, and s of LTS- RC. 2.1 Design of LTS-RC In this section we describe design of model system in LTS-RC tool, begin from domain expert (Figure 1). Domain expert analyze requirement dependencies to model interaction between requirements in certain software system. Knowing data about requirement dependencies we model that data using which ready on LTS- RC tool. To design interaction between requirements or to determine requirement dependencies, domain expert with representation of stakeholder should create workshop or other mechanism such as card sorting workshop, meeting, etc. The aim is helping stakeholder to get validity of data about requirement dependencies or another. LTS-RC tool is easily to analyze alternative path of requirement change based on initial requirement which stakeholders firstly choosed. So that LTS-RC tool can be used as decision support tool to optimally requirement change according to the available resources. After domain expert design the data model then we analyze alternative path formed by requirement dependencies data. The result gives support to map the impact of requirement change deciding available resources. Domain Expert Question aer Rule Analysis of Dependency Model Design Transformation from list requirement and its atribute to of LTS-RC Graphical Model Figure. 1 Design of LTS-RC Model of LTS-RC 2.2 Formulations of LTS-RC Using FSP Rule Requirement Change Map & Alternative Path and Budget LTS-RC model was developed and based on Labeled Transition System (LTS) [2]. A LTS is a state transition system where transitions are labeled [2] [4]. Definition (States and Labels) [4]. We define States as the universal set of states where states π and ε are designated as the error and end states. We define Labels as the universal set of message labels and Labels τ =Labels {τ} where τ is denote an internal component action that is unobservable to other components. Definition (Labeled Transition Systems) [4]. A LTS P is a structure (S, L,, q) where: 1) S States is a finite set of states. 2) L = α(p) {τ} where α(p) Labels is a set of labels that denotes the communicating alphabet of P. 3) (S\{π,ε} L S) defines the labeled transitions between states, and 4) q S is the. The LTS that has π as its only state - ({π}, Labels τ, {}, π) - is referred to as the error LTS, denoted Π. LTS of the form P= ({ε}, L, {}, ε) is referred to as successfully terminated LTS, denoted Σ L. We say that a LTS P is deterministic if there are no transitions labeled with τ and (s, l, s 1 ). And (s, l, s 2 ) implies s 1 =s 2, otherwise it is nondeterministic. In addition we say that a label l is enabled in a state s if there is a state s' such that (s, l, s'). FSP (Finite State Process) is a specification language with well-defined semantics in terms of LTS, which provides a concise way of describing LTS [4]. Each FSP expression E can be mapped onto a finite LTS, we use LTS(E) to denote the LTS that corresponds to it. We now discuss briefly the syntax of FSP [4]. If x and y range over actions, and P and Q range over FSP processes. FSP introduces the following operators [4] : 1) Action prefix : (x P) describes a process that initially engages in the action x and then behaves as described by the auxiliary process P. 2) Choice : (x P y Q) describes a process which initially engages in either x or y, and whose subsequent behavior is described by auxiliary processes P or Q, respectively. 3) Recursion: the behavior of a process may be defined in terms of itself, in order to express repetition.

3 056 Mapping The Impact Of Requirement Changes Using Labelled Transition System For Requirement Change (LTS-RC) Martasari Widiastuti 4) End state END : describes a process that has terminated successfully and cannot perform any more actions. 5) Sequential composition ; : (P;Q) where P is a process with an END state, describes a process that behaves as P and when it reaches the END state of P starts behaving as the auxiliary process Q. 6) Parallel composition : (P Q) describes the parallel composition of processes P and Q. 7) Trace equivalence minimization deterministic : deterministic P describes the minimal trace equivalent process to P. If no terminating traces are proper prefixes of other traces, then it also preserves END states. 8) Strong semantic equivalence minimization minimal : minimal P describes the minimal strong semantic equivalent process to P. Si stem Analyst Designer 1 list of requirement Designing model LTS-RC 2 Creating edge and node edge transition weighted relation data of dependency interaction model of requirement 4 visualization of model Compose the data valid interaction model alternative of budget 7 Budget analysis alternative of path budget requirement list of budget Figure 3. DFD level 1 3 Adding weight of dependency 5 Change requirement requirement change 6 Path analysis 2.3 DFD of LTS-RC Data Flow Diagram (DFD) from LTS-RC tool describes system in LTS-RC that use graphical notation to model the data flow. It begins from DFD level 0, level 1, up to level 2 as sub process from previous process. DFD level 0 describes generally about interaction between process in the system and external entities related to the process. Designer list of requirement data of dependency 0 Designing Model of LTS-RC + visualization of model Figure 2 DFD Levels 0 Si stem Analyst Figure 2 describes relation between process creating design and any entities, such as: designer, system analyst, and user entity. Data list of requirement, dependency of requirement, and visualization of model are related to input and output from process designing model of LTS-RC, entity designer is able to design interaction model of requirement change manually and entity system analysts receive the visualization of model. DFD level 1 depict sub process of creating design in DFD level 0. It describes on Figure 3. Figure 3 is decomposition of process creating LTS-RC design in DFD level 0. From figure 3, we can conclude if list of requirement has been entered by user then requirement database can be analyzed by user to determine requirement dependencies. That requirement dependencies will be modeled to be network model based on namely Label Transition System for Requirement Change (LTS-RC). Designing model can be done in two ways. Firstly, LTS-RC tool automatically creates graphical model of requirement change based on user input. Secondly, users as domain expert or system analyst can directly create graphical model of requirement change by drug the default notation provided LTS-RC tool on default notation template. By Using LTS-RC, it is possible that user clearly know the visualization of interaction between requirements based on data input. 2.4 Graphical Notations of LTS-RC Graphical notations on this LTS-RC tool are new definition to visualize the variables of graphical model. It was detailed in table 1. Notation Description node containing ReqID with optional priority

4 318 4 th International Conference Information & Communication Technology and System as related to path after must priority must priority and related to path after must priority and related to path before optional priority optional priority and related to path after must priority when the directed RegID is smaller Table 1 Graphical Notations of LTS-RC 3 RESULT Chapter 3 details how visualizations are specified using two cases study and describes how our approach can analyze maps of impact for requirement change. We use cases from Functional General Requirement of PhotoBox and Mediboard. They have different characteristic: PhotoBox with its small dependencies and Mediboard with its large dependencies between requirements. For the first case study, we analyze Functional General Requirement of PhotoBox. The input of model is list of requirement with its attributes such as: reqid, description, priority, budget, weight of change dependency. Table 2 shows dependency matrix containing weight of change dependency (%) from FR PhotoBox Table 2 Dependency Matrix of FR PhotoBox [5] The result of LTS-RC model is map of requirement change as bellow: Figure 4. Requirement Change Map of FR PhotoBox Figure 4 shows that modification of FR6 causes changing of another requirement such as: FR8, FR9, and FR10. If stakeholders need to modify requirement FGR6 there are several path as mapping the impact of requirement change. Stakeholders can arbitrary choose an as initial requirement that want to be changed, for example FR6 and LTS-RC automatically shows the mapping of requirement change related to initial state (FR6). Table 3 shows the result of analysis path and budget if stakeholders modify 70%of requirement FR6. Table 3 Alternative Path and Budget PhotoBox The second case study, we analyze Functional General Requirement of Mediboard. Table 4 shows dependency matrix containing weight of change dependency (%) from FR Mediboard

5 056 Mapping The Impact Of Requirement Changes Using Labelled Transition System For Requirement Change (LTS-RC) Martasari Widiastuti Table 4 Dependency Matrix of FR Mediboard [6] For further development, we would like to add more complex variable to model requirement change, use another type of dependencies to model interaction between requirements, and analyze the effectiveness of LTS-RC for tracing some problem in software system. The result of LTS-RC model is map of requirement change as bellow: Figure 5. Requirement Change Map of FR Mediboard Figure 5 shows that modification of FR2 causes changing of another requirement such as: FR1, FR7, FR8, and FR9. If stakeholders need to delete requirement FR2 there are several path as mapping the impact of requirement change. Stakeholders can arbitrary choose an as initial requirement that want to be changed or delete, for example FR2 and LTS-RC automatically shows the mapping of requirement change related to initial state (FR2). Table 3 shows the result of analysis path and budget if stakeholders delete (modify 100%) requirement FR2. Table 4 Alternative Path and Budget Mediboard 4 CONCLUSION We have done modeling of requirements change and mapping their impact using LTS-RC tool. This tool enables user to design interaction model of requirement changes. This tool is expected to assists the stakeholder to choose changing steps and to validate the cost of changes being implemented REFERENCE [1] B.J. Williams, J. Carver, and R.Vaughn, Change Risk Assessment: Understanding Risks Involved in Changing Software Requirements, in The 2006 International Conference on Software Engineering Research and Practice (SERP), Department of Computer Science and Engineering Mississippi State University, 2006, MS [2] M. Widiastuti, and D. Siahaan, Labeled Transition System for Requirement Change (LTS-RC): Pemodelan Perubahan Kebutuhan Perangkat Lunak Berdasarkan Labelled Transition System, Prosiding Seminar Nasional Manajemen Teknologi VII, ISBN: , 2008, pp. C-11-1 to C [3] N.F. Schneidewind, Investigation of the Risk to Software Reliability and Maintainability of Requirements Changes, Proceedings of the IEEE International Conference on Software Maintenance, Florence, 2001, pp [4] S. Uchitel, Incremental Elaboration of Scenario-Based Specifications and Behaviour Models Using Implied Scenarios, Ph.D Thesis, Imperial College of Science, Technology and Medicine, Department of Computing, University of London, 2003 [5] D. Siahaan, Dependency Matrix of PhotoBox Functional General Requirement, Informatics Department, Information Technology Faculty of ITS, Surabaya, Indonesia, 2008 [6] P.D. Sene, Dependency Matrix of Mediboard Functional General Requirement, Informatics Department, Information Technology Faculty of ITS, Surabaya, Indonesia, 2008.