REQUIREMENTS TRACEABILITY: A CRITICAL FACTOR IN SUCCESSFUL CONCEPTUAL MODELING
THE VALUE OF TRACEABILITY BETWEEN BUSINESS MODELS AND SYSTEM MODELS IN SUCCESSFUL INFORMATION SYSTEMS DEVELOPMENT
In a bid to improve business performance, organisations have had to deploy various information systems solutions to automate certain business functions. Software developers, using varying development tools develop these systems to meet the organisation's need. These needs are originally presented by stakeholders as business requirements to developers. These requirements must be clearly identified to be able to capture the business domain (Wand and Weber, 2002). Successful information system development depends on these requirements. Proper requirement elicitation is therefore required for successful development, especially for large software development.
However, due to the complex nature of information systems development, most requirements models are inconsistent, ambiguous and lead to low quality and expensive software (Liu et al, 2007). Requirements models of the business or application domain that is being modeled are expressed using conceptual modeling (Wand and Weber, 2002). The real-world domain is perceived as consisting of things, and are classified accordingly based on their relationship in the real-world. A conceptual model is an abstraction of the real-world (Wand et al 1995).
In software engineering, several approaches are in use to represent conceptual models of which the rational unified process (RUP) is the de facto standard (OMG, 2003). RUP is objected-oriented, having several interrelated models that represent different aspects of the system. The iterative process of RUP tends to eliminate inconsistency and ambiguity in conception models. But with several models representing different aspects of the domain, emerges the concern for the need of better traceability between the requirement models and design models developed. A good modeling practise adheres to high quality traceability. This essay evaluates the significance of traceability on conceptual modeling on how it can be enhanced.
The structure of the essay is as follow: after this introduction is a review of theories on business/conceptual modeling in information system development, business process re-engineering, requirement modeling and traceability. An analysis of two research papers is discussed after the review, and is followed by a reflection on the points discussed in the papers. Next is a conclusion on the theories and application of conceptual modeling in practise with regards to traceability.
THEORIES ON CONCEPTUAL MODELING
Current practise in the development of large information systems (IS) necessitates the design of models to capture the business processes of the domain in which the software will be deployed. A proper representation of these processes is obtained by first identifying the different stakeholders and understanding their requirements because these determine the success of the system development process (Holbrook, 1990; Hickey and Davis, 2004; Pitts and Browne, 2007).
Requirement elicitation of stakeholders' needs is a key factor in information systems development. It involves discovering users' needs from their own ontological perspective and representing them as requirement models of the real-world domain (Hickey and Davis, 2004). The different views of stakeholders are obtained through interviews, communication and interaction with the stakeholders, and documented in an iterative manner. An accurate knowledge of the domain is captured via this approach.
Conceptual modeling is used for defining these stakeholders' perspectives in the form of requirement models. According to Shanks et al (2003) and Evermann and Wand (2006), a conceptual model is defined as a representation of stakeholders' perception of the application domain and is the basis for communication and domain understanding between users and developers. It simplifies the complexity of the business domain for better clarity and plays a role similar to what architectural designs convey to architects. Conceptual modeling uses the object-oriented approach to capture things (referred to as objects) in the real-world and their relationships to one another (Wand et al 1999). It is an abstraction of the real-world domain that gives better insight on how it operates. Conceptual models are graphically expressed using conceptual modeling languages.
Although, there are several conceptual modeling languages (CML) in IS development, the unified modeling language (UML) is considered the de-facto standard (OMG, 2003). UML is a graphical object-oriented language for the representing structure and behaviour in business and software modeling. It has several models that are integrated together to capture the business domain. The UML conforms to Wand and Weber's (2002) four elements of conceptual-modeling framework: it has special constructs and rules (referred to as grammar) that provide diagrammatical models (scripts) of the real-world domain (context) governed by certain mapping procedures (method) that dictates how the domain is represented in the model of the domain. Rational unified modeling...
In conceptual modeling, the business models are first represented based on requirements elicitation and then translated to system (or software) models using collaboration diagram (Sergio et al, 2003). UML modeling scripts for business modeling include business use case, business use case description, domain class diagram and business process modeling notation (BPMN) diagrams while scripts for software models include system use case, system use case description, system class diagram and sequence diagram.Business Modeling
Business modeling is a conceptual representation of the business processes of an organisation based on actor's perception (Sergio et al, 2003). Several models are developed to represent aspects of the domain at different levels of abstraction. For instance, a business use case represents observable service offered to the customer by an organisation. According to Sergio et al (2003), a business use case serves as a common reference communication tool for stakeholders and developers, and represents the requirement model provided to the actor in the domain under study. Business use case is usually the starting point in software development life cycle with the unified process.Systems Modeling (Software Modeling)
Systems models are derived from the business models. For instance, systems use cases are developed from business use cases; and system class diagrams are derived from domain class diagrams. System models represent the software system that will be designed to achieve the goals elicited in the business models. The business models (e.g. use case) are mapped to the systems models (e.g. systems use case) which are utilised to define the rationale for software coding of the system. Sergio et al (2003) noted that mapping of business models to the system models is done through the analysis of collaboration diagrams, which shows the interrelationships between objects of the business domain. It is important that objects in the business models are traceable to objects in the resulting system models.Requirement Traceability
However, as the business models are transformed to systems models, there is the challenge of maintaining good requirements traceability in the development process. Requirement traceability (RT) is the ability to maintain relationship between requirement models (business models) and development artefact (systems models) in a forward and backward direction (Gotel and Finkelstein, 1994; Ramesh and Jarke, 2001). RT enables developers to determine if the semantics of software models meet stakeholders' requirements and to make changes where applicable.
Traceability challenge is apparent in large scale IS development where there are several stakeholders with varying requirements and also different development teams working in collaboration to build the IS solution. Resulting software models developed may not consistently map to the original requirements elicited in the business models. This issue could lead to high cost and delays with a likely resultant failure in the software development process cite. High-quality requirements traceability is therefore a key factor in the validation of conceptual models.
Hence, the question is how can requirement traceability be enhanced to better validate the quality of conceptual models in successful IS development? Previous researchers have proposed different approaches to improve traceability: manual and automated approaches (e.g. ONTrace tool by Noll and Riberio, 2007). Two papers are analysed below as case studies to illustrate some of the approaches available.
CASE STUDIES ANALYSIS (BASED ON TWO PAPERS)
Two research papers are utilized to evaluate how requirement traceability or mapping between conceptual models can be improved on. Shanks et al (2003) noted in their work that ontology can be used to validate conceptual models in order to prevent defects in the models and failure to accurately capture the functional requirements of the real-world domain. They highlighted that a valid model has the following four attributes of being accurate, complete, conflict-free and without redundant semantics. They proposed three ontological validation approaches namely: the choice of conceptual modeling grammar, a proper representation of the specific domain, and making sense of ambiguous semantics.
In the other paper by Heindl and Biffl (2005), a value-based requirement tracing (VBRT) approach to traceability was recommended. With the VBRT, requirements traceability differentiates those requirements that are very valuable to trace, from those that are less valuable. From the case study conducted, VBRT took about 35% effort for full requirement tracing by prioritising requirements based on stakeholder value, requirement risk or volatility and tracing cost. This approach is cost-effective and enhances traceability of requirements as they are mapped from business models to software models and to actual software codes.
The VBRT approach is based on five steps: (1) requirement definition, (2) requirement prioritization, (3) packaging of requirements, (4) linking of artefacts and (5) evaluation.
CRITICAL REFLECTION ON THE CASE STUDIES
The two papers approached the issue of requirement traceability from different perspectives. Shanks et al (2003) considered the traceability of requirements based on the expressive power of the modeling language, while Heindl and Biffl (2005) are of the opinion that high-priority requirement models should be traceable in a cost-effective way.
Although the VBRT approach of Heindl and Biffl (2005) focuses more on traceability from software models to actual code, it is also applicable to the initial stage of mapping business models to system models which is the scope of this report. The five steps are discussed below:
- Requirement definition: From the inception, the choice of the modeling language and theories of ontology can help represent the stakeholders' key real-world phenomena (Shanks et al, 2003). Functional and non-functional requirements of stakeholders are documented as text and modeled as business use cases.
- Requirement prioritization: As requirements models are mapped from model to model, it is imperative to ask the question: which requirements are of more priority than the other based on value, risk and effort? An answer to this question will determine requirements that will be represented at the software implementation stage.
- Packaging of requirement: This step is not detailed in Heindl and Biffl's (2005) paper.
- Linking of artefacts: At this stage, the requirements in the business use case and domain class diagrams are respectively mapped to the systems use case and system class diagram. Based on prioritization earlier specified, lower priority requirements may not be included in the mapping. Again, the choice of modeling language is important in this stage to establish link between requirements and artefacts. To enhance consistency and traceability, Sergio et al (2003) suggests the use of the same modeling language for mapping business models to systems models.
- Evaluation: The whole process could be re-assessed to determine opportunities for improvements.
From the case studies, the importance of value-based requirement traceability (VBRT) is elucidated. However, since VBRT is based on human perceptions of the real-world domain, it is subjective and prone to change. What is considered as valuable today, and given a high-value prioritization could be a rejected requirement in a short while, especially as the business environment keeps changing.
Nonetheless, with iterative development practise, a right balance of stakeholders' perspectives and proper representation of the real-world using ontologically validated conceptual models, quality traceability can enhance good conceptual modeling practise. It can also help in software change management, consistency in the mapping of models, and elimination of conflicting requirements.
Conceptual modeling is the bridge between the real-world business domain and the software models for translating complex business requirements to models understandable by all stakeholders. It is critical to the success of any IS implementation especially with developments such as model-driven architecture. The benefits of conceptual modeling can be used in business process re-engineering. Certainly, real value can be derived from conceptual modeling with good modeling practise like accurate requirements traceability.
- De Cesare, S., Lycett, M. and Paul, R.J. (2003) 'Actor Perception in Business use Case Modeling', Communications of AIS, 12, pp. 223-241.
- Evermann, J. and Wand, Y. (2006) 'Ontological Modeling Rules for UML: an Empirical Assessment', Journal of Computer Information Systems, 47, pp. 14-29.
- Gotel, O.C.Z. and Finkelstein, C.W. (1994) 'An analysis of the requirements traceability problem', Requirements Engineering, 1994., Proceedings of the First International Conference on. pp. 94-101.
- Heindl, M. and Biffl, S. (2005) 'A case study on value-based requirements tracing', ESEC/FSE-13: Proceedings of the 10th European software engineering conference held jointly with 13th ACM SIGSOFT international symposium on Foundations of software engineering. New York, NY, USA. ACM, pp. 60-69.
- Hickey, A.M. and Davis, A.M. (2004) 'A Unified Model of Requirements Elicitation', Journal of Management Information Systems, 20(4), pp. 65-84.
- Holbrook, I.,H. (1990) 'A scenario-based methodology for conducting requirements elicitation', SIGSOFT Software Engineering Notes, 15(1), pp. 95-104.
- Liu, H., Shao, W.Z., Zhang, L. and Ma, Z.Y. (2007) 'Detecting overlapping use cases', IET Software, 1(1), pp. 29-36.
- Noll, R.P. and Ribeiro, M.B. (2007) 'Ontological Traceability over the Unified Process', Engineering of Computer-Based Systems, 2007. ECBS '07. 14th Annual IEEE International Conference and Workshops on the. pp. 249-255.
- OMG. (2003) OMG Unified Modeling Language Specification Formal/03-03-01, http://www.omg.org/cgi-bin/doc?formal/03-03-01. (Accessed on 30th November 2009 )
- Pitts, M.G. and Browne, G.J. (2007) 'Improving requirements elicitation: an empirical investigation of procedural prompts', Information Systems Journal, 17(1), pp. 89-110.
- Ramesh, B. and Jarke, M. (2001) 'Toward Reference Models for Requirements Traceability', IEEE Transactions on Software Engineering, 27(1), pp. 58-93.
- Shanks, G., Tansley, E. and Weber, R. (2003) 'Using Ontology to Validate Conceptual Models.', Communications of the ACM, 46(10), pp. 85.
- Wand, Y. and Weber, R. (2002) 'Research Commentary: Information Systems and Conceptual Modeling--A Research Agenda', Information Systems Research, 13(4), pp. 363-376.
- Wand, Y., Storey, V.C. and Weber, R. (1999) 'An Ontological Analysis of the Relationship Construct in Conceptual Modeling', ACM Transactions on Database Systems, 24(4), pp. 494-528.