Information systems modeling with use cases

Information Systems Modeling with Use Cases
Julijana Linic Vranovina 30, Zagreb, Croatia E-mail: julijana.linic@fina.hr

Inadequate requirements specifications not understandable to users are one of predominant causes of failure in the development of software systems today. The aim is to find a technique understandable to users in order for them to be able to validate these requirements andverify whether these requirements are really what they need. On the other hand, the aim is finding the way of specifying requirements that would be in accordance with modern techniques of developing software systems such as traceability and iterative and incremental development. Use cases are a reliable technique of resolving the problems mentioned.

Abstract.

Keywords. Use cases, Use-casemodel, Requirements, Requirements specification, Requirements techniques, Traceability, Iterative, Software development, Methodologies 1. Introduction
Many studies show that one of the primary challenges of vital importance to any information system development is the ability to elicit the correct and necessary system requirements and specify them in a manner that is understandable to users in orderfor those requirements to be verified and validated [6]. The information technology community has always had problems trying to specify requirements, especially functional requirements, to users [13]. There were tendencies to produce diagrams and specifications that were loaded with terminology and notation resembling a computer code. The traditional ways of expressing functionality to users arerequirements specifications, functional decompositions, data-flow diagrams (DFDs), entity-relationship diagrams (ERDs), prototypes, etc. These modes of expressing functionality of a system are not understandable to users [7]. Traditionally, requirements are specified in lists and expressed in terms of ‘’the system shall’’. The requirements lists provide a

comprehensive catalog of every functionthat the system should perform. In most cases these lists contain duplicate or conflicting requirements. Another attempt to describe functionality of the system is functional decomposition. This method takes the major function of the system, the highest level function and breaks it down to subprocesses, and sub-subprocesses, and so on. When the processes are small enough, they become a program.Functional decomposition is a remnant of the older analysis and design approaches. It is tightly linked to structured systems development, meaning COBOL and mainframes. It is not usable for an application that is Web-based or object-oriented [7]. The world-famous methodologies, like structured techniques and information engineering, have a traditional approach to software development. Their mainartifacts for developing systems are data-flow diagrams and entity-relationship diagrams. In the design phase data-flow diagrams are sometimes called flowcharts. These methodologies are similar because there exist two parallel separated ways of developing software system. These are the process model and the data model. The main difference between the two types of methodologies is that the structuredtechniques are based on processes, i.e. the process model is their primary artifact, while information engineering is based on data, and in this approach the data model is the primary artifact [13]. Data flow diagrams help to show a system as a set of groups of interacting processes. They represent the dynamic view of the system and focus on what happens inside the system. The data flows from oneprocess to another, and then stops in a data store. Entity-relationship diagrams show how the data is stored in an application. They show details of entities, attributes, and relationships. Also, this diagram is used to present a logical data model and dictate the structure of a relational database. Both of the artifacts can be useful in the design phase primarily for non-objected software...