. Introduction 5
.1 Project Aim 5
.2 Project Hypothesis 5
.3 Project Objective 6
.4 Research Approach 6
.5 Dissertation Structure 6
2. Software Engineering 8
2.1 Purpose of Software Engineering 8
2.2 Motivation for Software Engineering 9
2.3 The beginning 10
2.4 The different stages in software engineering 11
2.4.1 Requirements specification 12
2.4.2 Design and implementation 12
2.4.3 Testing, validation and verification 13
2.5 Summary 14
3. Methodologies, Tools and Techniques 15
3.1 Overview 15
3.2. Rapid Application Development 16
3.2.1 History of RAD 17
3.2.2 Advantage of RAD 17
3.2.3 Disadvantages of RAD 17
3.3 Multiview 17
3.3.1 Five stages in Multiview 17
3.4 Soft System Methodology 19
3.4.1 Stages in SSM 19
3.4.2 Advantage of SSM 19
3.5 SSADM Structured Systems Analysis And Design Method 20
3.5.1 History of SSADM 20
3.5.3 Disadvantage of SSM 21
3.6 Object Orientated 21
3.6.1 Object Orientated Methods 22
Object-Oriented Analysis (OOA) (Coad90), (Coad91) 23
3.6.3 Notation 24
3.6.5 Advantage of O-O 25
3.6.6 Disadvantages of O-O 25
3.7 The Jackson Structured Design(JSD)(Jack83) 25
3.7.1 The JSD steps 25
3.7.2 Advantage of JSD 25
3.7.3 Disadvantage of JSD 26
3.8 Semiotics 26
3.8.1 Semiotics Framework 26
3.8.2 Normbase - Ontological Charting Tool: Prototype Version 30
3.8.3 Advantages of Semiotics 30
3.8.4 Disadvantages of Semiotics 31
3.9 UML 31
3.9.2 History of UML 31
3.9.2 Stages in UML 33
3.9.3Use-Case View 33
3.9.4 Structural (Logical or Static) View. 33
3.9.5 Behavioral (Process, Concurrent,Collaborative, or Dynamic) View. 33
3.9.7 Environment (Deployment or Physical) 34
3.10 My Methodology 34
3.11 Summary 36
Chapter 4. Requirements Specification 37
4.1 The goal of a requirement specification 37
4.2 Challenges when specifying requirements 37
4.4 .Requirements Analysis and Specifications of Case Study 39
Chapter 5 Requirements Elicitation 41
5.1 Overview 41
5.2 Definitions 42
5.3 PROBLEMS IN REQUIREMENTS ELECITATION 45
5.4 Difficulties of Elicitation 46
5.5 Elicitation Techniques 47
5.5.1 Traditional Approaches 47
5.5.2 Group elicitation 47
5.5.3 Representation-based approaches 47
5.5.4 Contextual (Social) Approaches 47
5.5.5 Cognitive approaches 48
5.6 Expressive Power Goal-based Approaches 48
Goal-Directed Strategy 48
5.6.2 Knowledge Acquisition: 52
5.7 Background Reading 53
5.7.1 Advantages of Background Reading 53
5.7.2 Disadvantages 54
5.8 Interviews 54
5.8.1 Types of interviews 54
5.8.2 Interviewing essentials 54
5.8.3 Interview Steps 54
5.8..4 Opening and closing and Following Up the interview 55
5.8.5 Conducting the Interview: Five Easy Steps 55
5.8.6 Advantages 56
5.8.7 Appropriate Situations 56
5.8.8 Disadvantages (Goguen and Linde, 1993, p154. 8) 56
5.9 Scenarios 56
5.9.1 Advantages 57
5.9.2 .Disadvantages 57
5.9.3 Task Models & Scenarios 57
5.10 Implementation of business application with scenario 57
5.10.1 Library case 57
5.10.2 Scenario 58
Ch 6 Modelling 60
6.1 Type of Model 60
Chapter 7 Quality of 00 Modelling 61
7.1 What Makes an 00 Model Good? 62
7.2 Characteristics of 00 Model 63
7.2.1 Size 63
72.2.2 Complexity 63
2.2.3 Coupling 63
7.2.4 Sufficiency 65
7.2.5 Completeness 65
7.2.6 Cohesion 66
7.2.7 Primitiveness 67
7.3.2 Fragility 67
7.3. Immobility 67
7.4 Achieving Quality Model 68
7.5 Class Diagrams 69
7.5.1 Perspectives 69
7.5.2 Associations, attributes and aggregation 70
7.5.3Generalization 71
7.5.4 Constraint Rules 71
When to Use Them 72
7.6 Summary 72
8. Use Case Modelling 73
8.1 Use Cases 73
8.2 Actors 74
8.2.1 Actors Categories 75
8.2.2 Actor Personalities 75
8.3 System Boundary 76
8.4 Stakeholders and their Concerns 76
8.5 Scenarios 77
8.5.1 What are they? How do they relate to use cases? 77
Figure 8.4.3 Renew an Item by an undergraduate Sequence Diagram 77
8.6 Use Case 78
8.6.1. Use Case Description 78
8.6.2 Granularity of Use Cases 78
8.6.3 Summary level use cases: 79
8.6.5 User-goal level use cases 79
8.7 Scope of Use Cases 79
8.7.1 Task 1: Actors 79
8.7.2 Process. Stakeholders 80
8.7.3Process. Use Case Outlines 81
8.7.4 Process. Use Case Bodies 82
8.7.5 Process. UC Structuring 82
8.7.6 Process. Checks 82
8.8 Check List 83
8.9 Use Cases as a Goal-based Approach 85
8.10 Use Cases in UML 85
8.10.1Use Case Model 85
Use Case Diagram 86
8.10.2 Relationships between Use Case 86
8.10.3 Includes Relationship 86
8.10.4 Generalization Relationship 86
8.10.5 Extend Relationship 87
8.11 Lily's Top Ten Use Case Pitfalls 88
8. Implementation 92
8.1 Part One System Design with UML 93
Figure 1.4.1 Borrow an Item Sequence Diagram 110
Figure 1.4.2 Return an Overdue Item Sequence Diagram 111
Figure 1.4.3 Renew an Item by an undergraduate Sequence Diagram 112
Figure 1.4.4 Borrow an Item Component Diagram 113
Figure 1.4.5 Return an Overdue Item Component Diagram 113
Figure 1.4.5 Return an Overdue Item Component Diagram 114
Figure 1.4.6 Renew an Item by an undergraduate Component Diagram 115
.5 State and Activity Diagrams 116
Figure 1.5.1. Reserving a library Item Activity Diagram 117
. Introduction
Problems in requirements modelling and elicitation are dynamic and situational. Expressing requirements and modelling are crucial and have always been difficult. The continuous changes of system requirements cause many kinds of difficult and costly errors trough out the whole life cycle of a system and make most requirements modelling method useless.One way to overcome this is to build a goal based approach and use case modelling that provides thorough understanding of the targeted area. Knowledge and requirements of its structures, stakeholders, roles and responsibilities processes and their relationship with in the organisations are essential. These include all the constraints d business rules that have been built to guide, protect ensure to smooth operations.
Capturing of requirements and modelling of requirements leads to the success of proper specification of business applications. Object-oriented approach is viable and extensive to model the requirements. The software engineering passes through various stages, if business rules changes; UML will be used to model the proper requirements in development phase.
.1 Project Aim
The project develops an approach that will model user requirements, covert into specification and represent them in proper structure, which is useful for modelling and eliciting requirements for the development business information systems.
.2 Project Hypothesis
The project will prove that Object Oriented approach can be used to facilitate its aim. The integration of Ontology, Goal based, interviews ,Use case modelling ,UML approaches provides in depth modelling techniques that is semantically rich. This semantic knowledge and business analysis forms the basis of eliciting requirements and, which is represented by UML. The analysis of use cases provides thorough and rigorous understanding of their intricacy and influence on the modelling requirements, in turn facilitating requirements elicitation.
.3 Project Objective
The objective encompass literature reviews, technique, methodologies formulations, implementation and critical appraisal as follows
> Investigate and analyse issues of software engineering concerning requirements modelling.
> Explore requirements elicitation techniques
> Develop an approach to capture user requirements
> Understanding of OO modelling and UML
> Gather requirements using goal based approach
> Enhancement of use case modelling
> Use Case modelling to represent and model the requirements
> Implement the business application with UML techniques.
.4 Research Approach
The project aim is to formulate an approach by integrating methods that have been tested and proven. It is aimed at concatenating the benefits from each method to optimise the best values each provides. This project is bounded by limited time and restricted access to resources (environment, stakeholders and existing systems).It is not intended to capture quantitative data or observe dynamic changes to variables due to circumstances. The most appropriate method is the case study approach. This approach allows the researcher to deduce and evaluate the research outcome without intervening with organisation activity directly.
.5 Dissertation Structure
The dissertation has been structured into various chapters that guide the readers to various literature reviews, software engineering, requirements elicitations techniques, Object Modelling in capturing requirements, the developed OO approach evaluation against case study and implement with UML. An example from the Library Case study has been used throughout to provide illustrations.
Chapter 2 introduces different stages of software development. The software development requires many phases; user's requirements, software and system requirements, Requirements specification, Testing and validation, prototyping.It also defines the project's interpretations of requirements specification and the scope of its use. In chapter 3 Different modelling methodologies and techniques has been evaluated with DESMET(Tudor 1997) and introduces new methodology which is based on different methodologies especially UML and OO.
Ch 4 defines the requirements specifications concept which will be further integrated into requirements elicitation and modelling.
Ch 5 introduces an integrated approach in capturing user requirements for business application, which is based on background reading, interviewing, ontological goal based approach. It discussed fundamental concepts of requirements elicitations. Chapter 6 highlights the concept of modelling and introduces various aspects of object oriented modelling. It also provides qualities of OO Modelling and Class Diagram.
Ch 7 describes use case modelling for requirements modelling .It discusses the fundamental concepts, the steps in executing the use cases, theory on its deliverable notation and contribution s that can be except from that approach.
Chapter 8 highlights the author's critical appraisal of the Interviewing, goal based approach and use case modeeling, Uml that includes the use case modelling contribution towards requirements modelling and elicitation.
Implantation has been done in chapter 8 .In first implantation ahs been modelled with UML, use case, class diagram, sequence diagram, activity diagram. In the second part of implementation has been done with C++ as an object oriented language
2. Software Engineering
This chapter introduces software engineering. It is necessary to identify the purpose of software engenering ,which will be covered in Section 2.1 and Section 2.3.Section 2.4 describes the different stages involved in software engenering.
2.1 Purpose of Software Engineering
When a large software system is developed, it happens all to often that the system does not fulfil the customers expectations. The software is often delayed, too expensive, unstable and does not provide the functionality that was agreed before the development begun. Furthermore, it is often very expensive to maintain. The aim for software engineering is to remedy these problems. In (Sommerville I.,2000), the following definition of software engineering is given.
Software engineering is an engineering discipline concerned with the practical problems of developing large software systems. It is not just programming nor is it computer science. Software engineers must be professionals who use theory from other disciplines and apply this cost-effectively to solve difficult problems.
The goal of software engineering is to develop a well engineered product, like any other engineering discipline. The only difference being that in software engineering, the product is a large software system. A well-engineered software system should, according to (Sommerville I.,2000), possess the following qualities:
The software should be maintainable. As long-life software is subject to regular change, it should be written and documented so that changes can be made without undue costs.
The software should be reliable. This means that it should perform as expected by users and should not fail more often than is allowed for in its specification.
The software should be efficient. This does not necessarily mean that the last ounce of performance is squeezed out of the system hardware; maximizing efficiency may make the software more difficult to change. Efficiency means that a system should not make wasteful use of system resources such as memory and processor cycles.
The software should offer an appropriate user interface. Much software isnot used to its full potential because its interface makes it difficult to use.
The user interface design must be tailored to the capabilities and background of the system users.
Three other goals of software engineering is to achieve the above within the time given for the project, within the resources allocated and at minimum cost.
2.2 Motivation for Software Engineering
Software engineering is today a very important engineering discipline. It has grown from nothing to that status in a very short time. The main reason for the exceptional growth, both in research and in business, is the increased demands put on software development and products. The reasons for these increased demands are many some examples are listed below.( Boehm B. W.,1981).
* The relationship between software and hardware costs has changed. The increase in software costs and the decreased hardware costs makes cost-effective software development more important than ever.
* Increased computer usage and hence software usage.
* Increased complexity of software systems.
* More critical tasks are handled by computers. For example in medical applications where there is no room for failures.
* The increase in costs for developing software systems makes it necessary to keep the systems a long time. This makes maintenance of the system more important.
* The long-life software systems are increasingly often subject to change.
* The objective of software engineering is to make it easier to meet all of these demands. To enable this a large number of areas needs to be addressed, some examples are:
* To make software development more efficient and thereby cut the costs for software development.
* Provide adequate standards for documenting the development so that maintenance and further development is possible and efficient.
* Provide means to guarantee the reliability of a software product.
* In one sentence, one could say that software engineering aims to transform the mysterious art of programming to an industry, which can meet the demands set by the clients, such as reliability and efficiency.
2.3 The beginning
In the early days of software development there where no guidelines as to how a program should be written. The programs where written either in pure machine-code
or by throwing switches which controlled the different states in the computer.
For a long time, hardware was the most important part of the computer since the programs where relatively simple. As the computers evolved they where able to handle programs which where increasingly complex. It soon became an impossible task to write and maintain these complex programs in something as cumbersome as
Machine code.
The first step towards the current state of software development was taken when the first high-level languages where introduced. Suddenly it was possible to write programs much more complex than before and still understand and maintain them.
Furthermore, since the high level languages where decoupled from the hardware it was no longer necessary to rewrite a program for each different type of computer. All that needed to be done was to run the source code through another compiler.
The introduction of high-level languages also meant that software development became much more efficient in terms of effort. This however, did not mean that the effort spent writing programs decreased. Instead the complexity of the problems increased, the effort kept on increasing and so did the complexity of the programs.
Quite soon after the introduction of the first high-level languages it became clear that it was not enough to be able to read the source code. The programmers could write more complex programs but they were still difficult to understand and to maintain. The main reason for this was that the architecture of the programs was bad. At this point the first structured languages were introduced. It was now possible to write reusable fragments of code and there was a logical way to partition a problem into smaller problems that was supported by the programming languages. This in turn made parallel development more feasible.
When the concepts of structured languages had been introduced and accepted, the first methodical approaches for software development were also introduced. At that time, most of the areas that today are accepted parts of the software engineering discipline were unknown. The main focus of software development was on writing the source code, although some attention was given to testing and designing as well. The methods that were used were primarily focused on design and implementation. The most widely spread was the top-down and the bottom-up design methods. These methods were very important since they not only made it easier to plan and implement a program but also made it possible to use the same methodology in testing and planning a program as was used when implementing it. After this the problems inherent to software development were given more and more attention.
Once the first steps towards what we today call software engineering had been taken, the development has been rapid. For instance, the time spent on different parts of the software development process has shifted. Today coding, previously the most important part (in some cases the only part), is one of the minor parts. Increased time is spent on defining the specifications, documenting the program and testing the program.
Even though much has improved in software development, one thing has not: the demands on the software development has increased more than the improvements made can accommodate.
2.4 The different stages in software engineering
When a software product is developed, there are some stages that the development process almost always can be divided into regardless of what methods are used in the different stages. These stages are:
* Requirements specification
* Design
* Implementation
* Testing & Validation
Fig 2.1 Models of Stages in Software Engineering
(Stiller,E.,Cathei,L.,2002), (Sommerville I.,2000),
In Figure 1 the normal relationship between the different stages is described.
The dashed lines represent reiterations of earlier stages due to errors discovered. The stages above will now be described briefly. The part about requirement specification requires its own chapter and will be described in "4. Requirements Specification". But as context for the description of the other parts a Short explanation of the term "requirements specification" is necessary.
2.4.1 Requirements specification
Requirements specification is the part where all demands on the software are specified. It is the foundation for everything that is done later in the development. Specifics about how the requirements are to be implemented are, in most cases, not discussed in the requirements specification. Only the demands that the client has put on the functionality and the behaviour of the final product are included.
2.4.2 Design and implementation
The design part of software engineering is where the first decisions are made on how the software should be implemented. Sometimes it is necessary to do the design in two different stages. The first stage is to make a high-level design in which the overall partitioning of the problem is done. When the problem is properly divided, the low-level design commences. In the low-level design the problem is divided into even smaller parts and the structure becomes more detailed. In both these processes, it is important to keep from making design or implementation decisions at a lower level than is necessary for the current phase. It is also important that all communication between the different parts is described in full detail at every level. Otherwise, it is impossible to look at the divided parts as separate problems.
When the design is complete and consistent, the implementation phase starts. In most cases the implementation starts before the design is completely finished. As long as the part that is being implemented is fully designed there is no problem. The same thing is true for testing. If a part of the software is implemented that part can often be tested before the rest of the implementation is finished. This is done to facilitate parallel development and thereby cut the development lead time.
2.4.3 Testing, validation and verification
When a software product is developed both the separate parts and the assembled system must be tested to verify that the system fulfils the requirements. The four most widely used techniques for testing are intuitive, exhaustive, statistical and coverage. The most common one (at least for smaller projects) is intuitive testing. The software is tested until the tester believes that the software does not have more errors in it than is acceptable. Often the testing is done with some guidelines as to what functions are vital to the functionality of the program. The second way to test programs, exhaustive testing, is not useful at anything but very small programs. It means that every possible sequence of states in the program is tested. The third way of testing, statistical testing means that tests, which consists of a series of input-sequences, is constructed on basis of some statistical data. This data is typically a profile over expected usage. The fourth common technique for testing is coverage testing. When using this one tries to cover a certain amount of the program. It could be based on:
* Covering some specified or all branches.
* Covering specified parts of or all the code (note that this is not the same as exhaustive since covering all code does not mean the same as covering all states).
* Covering all specified variable limits (when testing outside of limits, it is called negative testing).
* Covering some input-sequences (if the sequences are not based on statistical profiles, this is not the same as the previous approach).
When software is developed it is common that a great deal of effort is spent on testing, but another equally important check is omitted. That check is validation.
Validation means that the final and intermediate products are compared to the client's requirements, this is a continuous process through out the software life cycle. The software can be totally bug-free but if it does not do what the client expects, it is of no use to him. In connection with validation another check is often mentioned, that is verification. Verification is done to make sure that the different phases of the development conforms to the decisions made in earlier phases, and that the result of a certain phase is correct and complete. The difference between verification and validation was described in (Boehm B. W.,1981) with the following questions that they answer:
* Verification: 'Are we building the product right?
* Validation: 'Are we building the right product?
As validation, verification is a continuous process that lasts the entire process.
2.5 Summary
Software engineering is an engineering discipline concerned with the practical problems of developing large software systems .the dvelopment of software passes through different four stages The softwrae engeringing has to follow some methodologies to accomplish these four stages which will be dicusssed in the Chapter 3(Methodolgies ,Tools And Teniques)
3. Methodologies, Tools and Techniques
What is methoology? Why is it important in software engenering and requirements modelling .In this chapter various methodolieg has been discussed .In the overview section conept of methodolgy has been discussed.Advantageas and disadvantageges of evry methodolgy has been given in every section of methodolgy with respect to requirement modelling and software enegenering .
3.1 Overview
It is thus necessary for us to understand the definition of methodology. Avison and Fitzgerald (1995) mentioned that a structured methodology is a collection of procedures, techniques, tools and documentation aids which helps system developers and users in implementing an information system. The methodology consists of phases and sub-phases that include appropriate techniques. A methodology is usually based on some philosophical view.
Yourdon (1992, cited in Tudor and Tudor 1997) aptly defines methodology as a "step-by-step battle plan" for the development and implementation of information systems.
Information system development from definition of (Welke 1983):
"A change process taken with respect to object systems in a set of environments by a development group to achieve or maintain some objectives".
The development of information systems within business organizations requires a framework or method, to guide and control the development process. A number of information systems methodologies have been proposed and published since the early 1970s, to organise and coordinate the development of information systems within the business environment Obviously not all methodologies are the same and it is a general principle that methodologies can be categorized as either 'soft' or 'hard'. A hard methodology will incorporate a greater amount of formal structure within the approach to development Soft methodologies are as rigorous as hard methodologies, but they are not as formally structured as the hard approaches to information systems development
The aims or objectives of any information systems development methodology should encompass some or all of the following.
> To improve the process of information systems development
> To permit the effective monitoring of the development process
> To achieve accurate analysis of business and systems requirements
> To permit the accurate documentation of the analysis and design process
> To allow information systems to be delivered within a required time limit
> To ensure that the benefits outweigh the cost of using the methodology
> To improve the efficiency and effectiveness of the business organisation
> To improve the delivery or achievement of business organisation objectives
> To ensure that the needs of the users are fully satisfied
An information systems methodology is usually based on a philosophical view of the development process, which leads to the use of specific tools and techniques that are deemed appropriate within the environment of the various development methodologies. Some methodologies are very structured and inflexible, while others are more expedient, and often place emphasis on the human aspect of end-user involvement in the process of systems development Information systems development varies in the extent is it of structure present within the methodology. A number of development methodologies will be discussed in next sections
The following sections identify the 7 information systems methodologies and an elaboration of the stages or phases involved in each methodology are also included. Following methodologies will be discussed:
. Rapid Application Development
2. Multiview
3. Soft System Methodology
4. Objected Oriented Approach
5. Semiotics
6. Unified Modelling Language
7. Structured System Analysis and Design Method.
3.2. Rapid Application Development
> RAD is a development life cycle designed to give much faster development and higher quality result than the traditional life cycle.
> It is not a methodology but an approach.
3.2.1 History of RAD
> The methodology, originally called rapid iterative production prototyping (RIPP), was used to develop software within short time scale, utilising small teams of highly qualified and motivated personnel.
> The concept was picked up by (Martin 91) who gave it its current (snappier) acronym, extended its scope, and did much to advertise its potential.
3.2.2 Advantage of RAD
The RAD method has a task list and a work breakdown structure that is designed for speed. However the major difference in RAD is a set of management techniques that are optimised for speed. Among the most important are:
> Prototyping - Prototyping requires an open approach to development, it also requires an emphasis on relationship management and change management.
> Iteration - is a commitment to incremental development based on refinement. Prototyping and iteration go hand in hand.
> Time boxing - is a management technique that focuses attention on delivery above all else. Under a time box scope can change but delivery cannot.
3.2.3 Disadvantages of RAD
> Tools can be expensive and difficult to use
> Needs highly trained and dedicated staff
> Needs high level backing
> Can be pressurised
3.3 Multiview
Multiview is a soft system development approach that borrows many of the ideas of SSM and ETHICS, but incorporates harder tools and techniques as necessary. It is a methodology that, as its name implies, take a multiple view (or perspective) of a system's environment, it takes a view of the human, technical and organisational aspects of information system.
3.3.1 Five stages in Multiview
Analysis of human activity
The stage is closely related to the SSM approach to analysing problem situations.
Steps involved:
> Establish a Weltanschauung view
> Describe the systems requirements using rich pictures
> Establish root definitions
> Establish a conceptual model of activities
> Compare the conceptual model with the rich pictures
> Implement any changes through process of iteration.
Information Modelling
This stage involves the analysis of the entities and functions of the system; this is done through the development of a functional model which decomposes the functions down to understandable levels. Data flow diagrams can also be used to show the sequence of events. This can then be augmented with the development of an entity model through the use of data modelling techniques.
Steps involved:
> Develop a functional model
> Develop an entity model
Analysis and design of the socio-technical aspects .
This stage is influenced by the ETHICS approach information systems development, particularly through user participation and systems stakeholder involvement in the development process, this assess the socio-technical systems alternatives.
Steps involved:
> Establish human requirements
> Establish organisational requirements
> Establish socio-technical goodness of fit
> Assess future socio-technical environment
Design of the human-computer interface.
This stage involves which is often one ofthe primary concerns of most system
Steps involved:
> Technical design of human-computer interface
> Establish the design of input and out mediums.
Design of the technical aspects
This involves the design of technical aspects of the systems, this stage uses the entity model from Information Modelling and the technical requirements from Design of the human-computer interface to establish a technical design to implement test and evaluate the system on a continuous basis.
Step involved:
> Design technical environment
> Implement a technical solution
> System testing and evaluation
> On going systems evaluation.
3.4 Soft System Methodology
> Emphasis on understanding situation in which a perceived problem is thought to lie not in finding a solution.
> Considering the system as a "whole".
3.4.1 Stages in SSM
SSM through various analysis tools i.e. Rich Picture, Root Definition, CATWOE and conceptual diagram attempts to analyse the problem from all perspectives.
> Rich Picture
Represents the views of the people from the organisation and systems they are using with reference to their present situation. It is a pictorial caricature of an organisation and is an invaluable tool for helping to explain what the organisation is about (Avision & Fitzgerald 1997).
> Root Definition
It is a statement which identifies the system, the people, the owner of the system and the organisational context which it is used.
> CATWOE
CATWOE is an acronym for Client, Actor, Transformation, World view, Owner and Environment. The CATWOE is used to validate the root definition.
> Conceptual diagram.
This is base upon the rich picture. The rich picture gives a physical representation of the system, whilst conceptual diagram give an abstract or logical view of the system.
3.4.2 Advantage of SSM
SSM as a methodology can only be as an analysis tool. It gives the developers an insight into the organisations present situation e.g. what the problem themes are and communications between all the different elements.
3.5 SSADM Structured Systems Analysis And Design Method
> Structured systems analysis and design method (SSADM) is a highly structured approach used primarily to develop large-scale information systems for government departments in the United Kingdom.
3.5.1 History of SSADM
The approach was first used in 1981 and is a dataoriented methodology that emphasises data modelling tools and techniques.
SSADM has a number of versions and the latest version is 4.10, which was published in 1990 that includes greater consideration than previous versions of end-users within the process of development
SSADM is probably the best-known structured systems development approach. But it is only really applicable in the situation of major large-scale information systems development SSADM version 4.0 lists seven stages to the development process (labelled 0 through to 6), which are stated below
3.5.2Stages in SSADM
Each stage of the SSADM life cycle is strictly defined along with the outcomes of each stage; these outcomes are often referred to as 'deliverables' within systems vocabulary. SSADM uses its own symbol terminology for data flow diagramming, which is referred to as data flow modelling.
* Feasibility Study
The feasibility stage involves using such techniques as interviews, questionnaires and data flow models of the flow of information documentation.
Steps involved:
> Defining the problem and selecting options
> Creating feasibility report
* Requirement analysis: Investigate current Environment
The investigation of the current environment stage expands upon the feasibility stage by adding detail to the feasibility study.
Steps involved:
> Establish analysis framwork
> Investigate and define requirements
> Investigate current processing
> Investigate current data
> Derive logical view of current services
> Assemble investigation results
* Requirement Analysis: Business system option
A cost-benefit analysis is carried out and only that system options that show greater benefit to cost ratio will be continued and carried forward to the next stage.
Steps involved:
> Define business system options
> Select business system options
> Define requirements.
This stage establishes the full requirements specification and determines the following design stage. It is important in replacing investigation and analysis with specification and design to find 'what will be the requirements of the new or proposed system. This stage will normally involve entity modelling and normalisation of data relationships. Currently, within this stage in version 4.0 is a definition of user roles within the system. In addition, SSADM version 4.0 permits some element of prototyping to be carried out to assess the accuracy of user requirements, particularly in terms of user interface design.
3.5.3 Disadvantage of SSM
SSM is only appropriate to be used at the earliest stages of system development. To develop a fully working system, it is important for a developer to use a hard methodology to show how the data is modelled.
3.6 Object Orientated
> Object-orientation is an approach to analysis and design.
> Object Orientation contrasts with the more structured approaches such as SSADM and JSD.
Comparing the methods
Walker (Walk92) considers the four main criteria that should be considered by an object-oriented method are:
> Abstraction, including rules, guidelines, heuristics for the separation of the problem domain into different abstractions; methods for identifying state, services and interfaces for encapsulating objects; and strategy for abstracting commonality for abstract superclasses.
> Notation and representational verisimilitude, including notation for representing aggregation, inheritance and functional hierarchies, message sending/calling/parameter passing between objects in a seniority hierarchy; representation of autonomous objects and asynchronous message passing; and support for constraint representation and enforcement.
.1 Project Aim 5
.2 Project Hypothesis 5
.3 Project Objective 6
.4 Research Approach 6
.5 Dissertation Structure 6
2. Software Engineering 8
2.1 Purpose of Software Engineering 8
2.2 Motivation for Software Engineering 9
2.3 The beginning 10
2.4 The different stages in software engineering 11
2.4.1 Requirements specification 12
2.4.2 Design and implementation 12
2.4.3 Testing, validation and verification 13
2.5 Summary 14
3. Methodologies, Tools and Techniques 15
3.1 Overview 15
3.2. Rapid Application Development 16
3.2.1 History of RAD 17
3.2.2 Advantage of RAD 17
3.2.3 Disadvantages of RAD 17
3.3 Multiview 17
3.3.1 Five stages in Multiview 17
3.4 Soft System Methodology 19
3.4.1 Stages in SSM 19
3.4.2 Advantage of SSM 19
3.5 SSADM Structured Systems Analysis And Design Method 20
3.5.1 History of SSADM 20
3.5.3 Disadvantage of SSM 21
3.6 Object Orientated 21
3.6.1 Object Orientated Methods 22
Object-Oriented Analysis (OOA) (Coad90), (Coad91) 23
3.6.3 Notation 24
3.6.5 Advantage of O-O 25
3.6.6 Disadvantages of O-O 25
3.7 The Jackson Structured Design(JSD)(Jack83) 25
3.7.1 The JSD steps 25
3.7.2 Advantage of JSD 25
3.7.3 Disadvantage of JSD 26
3.8 Semiotics 26
3.8.1 Semiotics Framework 26
3.8.2 Normbase - Ontological Charting Tool: Prototype Version 30
3.8.3 Advantages of Semiotics 30
3.8.4 Disadvantages of Semiotics 31
3.9 UML 31
3.9.2 History of UML 31
3.9.2 Stages in UML 33
3.9.3Use-Case View 33
3.9.4 Structural (Logical or Static) View. 33
3.9.5 Behavioral (Process, Concurrent,Collaborative, or Dynamic) View. 33
3.9.7 Environment (Deployment or Physical) 34
3.10 My Methodology 34
3.11 Summary 36
Chapter 4. Requirements Specification 37
4.1 The goal of a requirement specification 37
4.2 Challenges when specifying requirements 37
4.4 .Requirements Analysis and Specifications of Case Study 39
Chapter 5 Requirements Elicitation 41
5.1 Overview 41
5.2 Definitions 42
5.3 PROBLEMS IN REQUIREMENTS ELECITATION 45
5.4 Difficulties of Elicitation 46
5.5 Elicitation Techniques 47
5.5.1 Traditional Approaches 47
5.5.2 Group elicitation 47
5.5.3 Representation-based approaches 47
5.5.4 Contextual (Social) Approaches 47
5.5.5 Cognitive approaches 48
5.6 Expressive Power Goal-based Approaches 48
Goal-Directed Strategy 48
5.6.2 Knowledge Acquisition: 52
5.7 Background Reading 53
5.7.1 Advantages of Background Reading 53
5.7.2 Disadvantages 54
5.8 Interviews 54
5.8.1 Types of interviews 54
5.8.2 Interviewing essentials 54
5.8.3 Interview Steps 54
5.8..4 Opening and closing and Following Up the interview 55
5.8.5 Conducting the Interview: Five Easy Steps 55
5.8.6 Advantages 56
5.8.7 Appropriate Situations 56
5.8.8 Disadvantages (Goguen and Linde, 1993, p154. 8) 56
5.9 Scenarios 56
5.9.1 Advantages 57
5.9.2 .Disadvantages 57
5.9.3 Task Models & Scenarios 57
5.10 Implementation of business application with scenario 57
5.10.1 Library case 57
5.10.2 Scenario 58
Ch 6 Modelling 60
6.1 Type of Model 60
Chapter 7 Quality of 00 Modelling 61
7.1 What Makes an 00 Model Good? 62
7.2 Characteristics of 00 Model 63
7.2.1 Size 63
72.2.2 Complexity 63
2.2.3 Coupling 63
7.2.4 Sufficiency 65
7.2.5 Completeness 65
7.2.6 Cohesion 66
7.2.7 Primitiveness 67
7.3.2 Fragility 67
7.3. Immobility 67
7.4 Achieving Quality Model 68
7.5 Class Diagrams 69
7.5.1 Perspectives 69
7.5.2 Associations, attributes and aggregation 70
7.5.3Generalization 71
7.5.4 Constraint Rules 71
When to Use Them 72
7.6 Summary 72
8. Use Case Modelling 73
8.1 Use Cases 73
8.2 Actors 74
8.2.1 Actors Categories 75
8.2.2 Actor Personalities 75
8.3 System Boundary 76
8.4 Stakeholders and their Concerns 76
8.5 Scenarios 77
8.5.1 What are they? How do they relate to use cases? 77
Figure 8.4.3 Renew an Item by an undergraduate Sequence Diagram 77
8.6 Use Case 78
8.6.1. Use Case Description 78
8.6.2 Granularity of Use Cases 78
8.6.3 Summary level use cases: 79
8.6.5 User-goal level use cases 79
8.7 Scope of Use Cases 79
8.7.1 Task 1: Actors 79
8.7.2 Process. Stakeholders 80
8.7.3Process. Use Case Outlines 81
8.7.4 Process. Use Case Bodies 82
8.7.5 Process. UC Structuring 82
8.7.6 Process. Checks 82
8.8 Check List 83
8.9 Use Cases as a Goal-based Approach 85
8.10 Use Cases in UML 85
8.10.1Use Case Model 85
Use Case Diagram 86
8.10.2 Relationships between Use Case 86
8.10.3 Includes Relationship 86
8.10.4 Generalization Relationship 86
8.10.5 Extend Relationship 87
8.11 Lily's Top Ten Use Case Pitfalls 88
8. Implementation 92
8.1 Part One System Design with UML 93
Figure 1.4.1 Borrow an Item Sequence Diagram 110
Figure 1.4.2 Return an Overdue Item Sequence Diagram 111
Figure 1.4.3 Renew an Item by an undergraduate Sequence Diagram 112
Figure 1.4.4 Borrow an Item Component Diagram 113
Figure 1.4.5 Return an Overdue Item Component Diagram 113
Figure 1.4.5 Return an Overdue Item Component Diagram 114
Figure 1.4.6 Renew an Item by an undergraduate Component Diagram 115
.5 State and Activity Diagrams 116
Figure 1.5.1. Reserving a library Item Activity Diagram 117
. Introduction
Problems in requirements modelling and elicitation are dynamic and situational. Expressing requirements and modelling are crucial and have always been difficult. The continuous changes of system requirements cause many kinds of difficult and costly errors trough out the whole life cycle of a system and make most requirements modelling method useless.One way to overcome this is to build a goal based approach and use case modelling that provides thorough understanding of the targeted area. Knowledge and requirements of its structures, stakeholders, roles and responsibilities processes and their relationship with in the organisations are essential. These include all the constraints d business rules that have been built to guide, protect ensure to smooth operations.
Capturing of requirements and modelling of requirements leads to the success of proper specification of business applications. Object-oriented approach is viable and extensive to model the requirements. The software engineering passes through various stages, if business rules changes; UML will be used to model the proper requirements in development phase.
.1 Project Aim
The project develops an approach that will model user requirements, covert into specification and represent them in proper structure, which is useful for modelling and eliciting requirements for the development business information systems.
.2 Project Hypothesis
The project will prove that Object Oriented approach can be used to facilitate its aim. The integration of Ontology, Goal based, interviews ,Use case modelling ,UML approaches provides in depth modelling techniques that is semantically rich. This semantic knowledge and business analysis forms the basis of eliciting requirements and, which is represented by UML. The analysis of use cases provides thorough and rigorous understanding of their intricacy and influence on the modelling requirements, in turn facilitating requirements elicitation.
.3 Project Objective
The objective encompass literature reviews, technique, methodologies formulations, implementation and critical appraisal as follows
> Investigate and analyse issues of software engineering concerning requirements modelling.
> Explore requirements elicitation techniques
> Develop an approach to capture user requirements
> Understanding of OO modelling and UML
> Gather requirements using goal based approach
> Enhancement of use case modelling
> Use Case modelling to represent and model the requirements
> Implement the business application with UML techniques.
.4 Research Approach
The project aim is to formulate an approach by integrating methods that have been tested and proven. It is aimed at concatenating the benefits from each method to optimise the best values each provides. This project is bounded by limited time and restricted access to resources (environment, stakeholders and existing systems).It is not intended to capture quantitative data or observe dynamic changes to variables due to circumstances. The most appropriate method is the case study approach. This approach allows the researcher to deduce and evaluate the research outcome without intervening with organisation activity directly.
.5 Dissertation Structure
The dissertation has been structured into various chapters that guide the readers to various literature reviews, software engineering, requirements elicitations techniques, Object Modelling in capturing requirements, the developed OO approach evaluation against case study and implement with UML. An example from the Library Case study has been used throughout to provide illustrations.
Chapter 2 introduces different stages of software development. The software development requires many phases; user's requirements, software and system requirements, Requirements specification, Testing and validation, prototyping.It also defines the project's interpretations of requirements specification and the scope of its use. In chapter 3 Different modelling methodologies and techniques has been evaluated with DESMET(Tudor 1997) and introduces new methodology which is based on different methodologies especially UML and OO.
Ch 4 defines the requirements specifications concept which will be further integrated into requirements elicitation and modelling.
Ch 5 introduces an integrated approach in capturing user requirements for business application, which is based on background reading, interviewing, ontological goal based approach. It discussed fundamental concepts of requirements elicitations. Chapter 6 highlights the concept of modelling and introduces various aspects of object oriented modelling. It also provides qualities of OO Modelling and Class Diagram.
Ch 7 describes use case modelling for requirements modelling .It discusses the fundamental concepts, the steps in executing the use cases, theory on its deliverable notation and contribution s that can be except from that approach.
Chapter 8 highlights the author's critical appraisal of the Interviewing, goal based approach and use case modeeling, Uml that includes the use case modelling contribution towards requirements modelling and elicitation.
Implantation has been done in chapter 8 .In first implantation ahs been modelled with UML, use case, class diagram, sequence diagram, activity diagram. In the second part of implementation has been done with C++ as an object oriented language
2. Software Engineering
This chapter introduces software engineering. It is necessary to identify the purpose of software engenering ,which will be covered in Section 2.1 and Section 2.3.Section 2.4 describes the different stages involved in software engenering.
2.1 Purpose of Software Engineering
When a large software system is developed, it happens all to often that the system does not fulfil the customers expectations. The software is often delayed, too expensive, unstable and does not provide the functionality that was agreed before the development begun. Furthermore, it is often very expensive to maintain. The aim for software engineering is to remedy these problems. In (Sommerville I.,2000), the following definition of software engineering is given.
Software engineering is an engineering discipline concerned with the practical problems of developing large software systems. It is not just programming nor is it computer science. Software engineers must be professionals who use theory from other disciplines and apply this cost-effectively to solve difficult problems.
The goal of software engineering is to develop a well engineered product, like any other engineering discipline. The only difference being that in software engineering, the product is a large software system. A well-engineered software system should, according to (Sommerville I.,2000), possess the following qualities:
The software should be maintainable. As long-life software is subject to regular change, it should be written and documented so that changes can be made without undue costs.
The software should be reliable. This means that it should perform as expected by users and should not fail more often than is allowed for in its specification.
The software should be efficient. This does not necessarily mean that the last ounce of performance is squeezed out of the system hardware; maximizing efficiency may make the software more difficult to change. Efficiency means that a system should not make wasteful use of system resources such as memory and processor cycles.
The software should offer an appropriate user interface. Much software isnot used to its full potential because its interface makes it difficult to use.
The user interface design must be tailored to the capabilities and background of the system users.
Three other goals of software engineering is to achieve the above within the time given for the project, within the resources allocated and at minimum cost.
2.2 Motivation for Software Engineering
Software engineering is today a very important engineering discipline. It has grown from nothing to that status in a very short time. The main reason for the exceptional growth, both in research and in business, is the increased demands put on software development and products. The reasons for these increased demands are many some examples are listed below.( Boehm B. W.,1981).
* The relationship between software and hardware costs has changed. The increase in software costs and the decreased hardware costs makes cost-effective software development more important than ever.
* Increased computer usage and hence software usage.
* Increased complexity of software systems.
* More critical tasks are handled by computers. For example in medical applications where there is no room for failures.
* The increase in costs for developing software systems makes it necessary to keep the systems a long time. This makes maintenance of the system more important.
* The long-life software systems are increasingly often subject to change.
* The objective of software engineering is to make it easier to meet all of these demands. To enable this a large number of areas needs to be addressed, some examples are:
* To make software development more efficient and thereby cut the costs for software development.
* Provide adequate standards for documenting the development so that maintenance and further development is possible and efficient.
* Provide means to guarantee the reliability of a software product.
* In one sentence, one could say that software engineering aims to transform the mysterious art of programming to an industry, which can meet the demands set by the clients, such as reliability and efficiency.
2.3 The beginning
In the early days of software development there where no guidelines as to how a program should be written. The programs where written either in pure machine-code
or by throwing switches which controlled the different states in the computer.
For a long time, hardware was the most important part of the computer since the programs where relatively simple. As the computers evolved they where able to handle programs which where increasingly complex. It soon became an impossible task to write and maintain these complex programs in something as cumbersome as
Machine code.
The first step towards the current state of software development was taken when the first high-level languages where introduced. Suddenly it was possible to write programs much more complex than before and still understand and maintain them.
Furthermore, since the high level languages where decoupled from the hardware it was no longer necessary to rewrite a program for each different type of computer. All that needed to be done was to run the source code through another compiler.
The introduction of high-level languages also meant that software development became much more efficient in terms of effort. This however, did not mean that the effort spent writing programs decreased. Instead the complexity of the problems increased, the effort kept on increasing and so did the complexity of the programs.
Quite soon after the introduction of the first high-level languages it became clear that it was not enough to be able to read the source code. The programmers could write more complex programs but they were still difficult to understand and to maintain. The main reason for this was that the architecture of the programs was bad. At this point the first structured languages were introduced. It was now possible to write reusable fragments of code and there was a logical way to partition a problem into smaller problems that was supported by the programming languages. This in turn made parallel development more feasible.
When the concepts of structured languages had been introduced and accepted, the first methodical approaches for software development were also introduced. At that time, most of the areas that today are accepted parts of the software engineering discipline were unknown. The main focus of software development was on writing the source code, although some attention was given to testing and designing as well. The methods that were used were primarily focused on design and implementation. The most widely spread was the top-down and the bottom-up design methods. These methods were very important since they not only made it easier to plan and implement a program but also made it possible to use the same methodology in testing and planning a program as was used when implementing it. After this the problems inherent to software development were given more and more attention.
Once the first steps towards what we today call software engineering had been taken, the development has been rapid. For instance, the time spent on different parts of the software development process has shifted. Today coding, previously the most important part (in some cases the only part), is one of the minor parts. Increased time is spent on defining the specifications, documenting the program and testing the program.
Even though much has improved in software development, one thing has not: the demands on the software development has increased more than the improvements made can accommodate.
2.4 The different stages in software engineering
When a software product is developed, there are some stages that the development process almost always can be divided into regardless of what methods are used in the different stages. These stages are:
* Requirements specification
* Design
* Implementation
* Testing & Validation
Fig 2.1 Models of Stages in Software Engineering
(Stiller,E.,Cathei,L.,2002), (Sommerville I.,2000),
In Figure 1 the normal relationship between the different stages is described.
The dashed lines represent reiterations of earlier stages due to errors discovered. The stages above will now be described briefly. The part about requirement specification requires its own chapter and will be described in "4. Requirements Specification". But as context for the description of the other parts a Short explanation of the term "requirements specification" is necessary.
2.4.1 Requirements specification
Requirements specification is the part where all demands on the software are specified. It is the foundation for everything that is done later in the development. Specifics about how the requirements are to be implemented are, in most cases, not discussed in the requirements specification. Only the demands that the client has put on the functionality and the behaviour of the final product are included.
2.4.2 Design and implementation
The design part of software engineering is where the first decisions are made on how the software should be implemented. Sometimes it is necessary to do the design in two different stages. The first stage is to make a high-level design in which the overall partitioning of the problem is done. When the problem is properly divided, the low-level design commences. In the low-level design the problem is divided into even smaller parts and the structure becomes more detailed. In both these processes, it is important to keep from making design or implementation decisions at a lower level than is necessary for the current phase. It is also important that all communication between the different parts is described in full detail at every level. Otherwise, it is impossible to look at the divided parts as separate problems.
When the design is complete and consistent, the implementation phase starts. In most cases the implementation starts before the design is completely finished. As long as the part that is being implemented is fully designed there is no problem. The same thing is true for testing. If a part of the software is implemented that part can often be tested before the rest of the implementation is finished. This is done to facilitate parallel development and thereby cut the development lead time.
2.4.3 Testing, validation and verification
When a software product is developed both the separate parts and the assembled system must be tested to verify that the system fulfils the requirements. The four most widely used techniques for testing are intuitive, exhaustive, statistical and coverage. The most common one (at least for smaller projects) is intuitive testing. The software is tested until the tester believes that the software does not have more errors in it than is acceptable. Often the testing is done with some guidelines as to what functions are vital to the functionality of the program. The second way to test programs, exhaustive testing, is not useful at anything but very small programs. It means that every possible sequence of states in the program is tested. The third way of testing, statistical testing means that tests, which consists of a series of input-sequences, is constructed on basis of some statistical data. This data is typically a profile over expected usage. The fourth common technique for testing is coverage testing. When using this one tries to cover a certain amount of the program. It could be based on:
* Covering some specified or all branches.
* Covering specified parts of or all the code (note that this is not the same as exhaustive since covering all code does not mean the same as covering all states).
* Covering all specified variable limits (when testing outside of limits, it is called negative testing).
* Covering some input-sequences (if the sequences are not based on statistical profiles, this is not the same as the previous approach).
When software is developed it is common that a great deal of effort is spent on testing, but another equally important check is omitted. That check is validation.
Validation means that the final and intermediate products are compared to the client's requirements, this is a continuous process through out the software life cycle. The software can be totally bug-free but if it does not do what the client expects, it is of no use to him. In connection with validation another check is often mentioned, that is verification. Verification is done to make sure that the different phases of the development conforms to the decisions made in earlier phases, and that the result of a certain phase is correct and complete. The difference between verification and validation was described in (Boehm B. W.,1981) with the following questions that they answer:
* Verification: 'Are we building the product right?
* Validation: 'Are we building the right product?
As validation, verification is a continuous process that lasts the entire process.
2.5 Summary
Software engineering is an engineering discipline concerned with the practical problems of developing large software systems .the dvelopment of software passes through different four stages The softwrae engeringing has to follow some methodologies to accomplish these four stages which will be dicusssed in the Chapter 3(Methodolgies ,Tools And Teniques)
3. Methodologies, Tools and Techniques
What is methoology? Why is it important in software engenering and requirements modelling .In this chapter various methodolieg has been discussed .In the overview section conept of methodolgy has been discussed.Advantageas and disadvantageges of evry methodolgy has been given in every section of methodolgy with respect to requirement modelling and software enegenering .
3.1 Overview
It is thus necessary for us to understand the definition of methodology. Avison and Fitzgerald (1995) mentioned that a structured methodology is a collection of procedures, techniques, tools and documentation aids which helps system developers and users in implementing an information system. The methodology consists of phases and sub-phases that include appropriate techniques. A methodology is usually based on some philosophical view.
Yourdon (1992, cited in Tudor and Tudor 1997) aptly defines methodology as a "step-by-step battle plan" for the development and implementation of information systems.
Information system development from definition of (Welke 1983):
"A change process taken with respect to object systems in a set of environments by a development group to achieve or maintain some objectives".
The development of information systems within business organizations requires a framework or method, to guide and control the development process. A number of information systems methodologies have been proposed and published since the early 1970s, to organise and coordinate the development of information systems within the business environment Obviously not all methodologies are the same and it is a general principle that methodologies can be categorized as either 'soft' or 'hard'. A hard methodology will incorporate a greater amount of formal structure within the approach to development Soft methodologies are as rigorous as hard methodologies, but they are not as formally structured as the hard approaches to information systems development
The aims or objectives of any information systems development methodology should encompass some or all of the following.
> To improve the process of information systems development
> To permit the effective monitoring of the development process
> To achieve accurate analysis of business and systems requirements
> To permit the accurate documentation of the analysis and design process
> To allow information systems to be delivered within a required time limit
> To ensure that the benefits outweigh the cost of using the methodology
> To improve the efficiency and effectiveness of the business organisation
> To improve the delivery or achievement of business organisation objectives
> To ensure that the needs of the users are fully satisfied
An information systems methodology is usually based on a philosophical view of the development process, which leads to the use of specific tools and techniques that are deemed appropriate within the environment of the various development methodologies. Some methodologies are very structured and inflexible, while others are more expedient, and often place emphasis on the human aspect of end-user involvement in the process of systems development Information systems development varies in the extent is it of structure present within the methodology. A number of development methodologies will be discussed in next sections
The following sections identify the 7 information systems methodologies and an elaboration of the stages or phases involved in each methodology are also included. Following methodologies will be discussed:
. Rapid Application Development
2. Multiview
3. Soft System Methodology
4. Objected Oriented Approach
5. Semiotics
6. Unified Modelling Language
7. Structured System Analysis and Design Method.
3.2. Rapid Application Development
> RAD is a development life cycle designed to give much faster development and higher quality result than the traditional life cycle.
> It is not a methodology but an approach.
3.2.1 History of RAD
> The methodology, originally called rapid iterative production prototyping (RIPP), was used to develop software within short time scale, utilising small teams of highly qualified and motivated personnel.
> The concept was picked up by (Martin 91) who gave it its current (snappier) acronym, extended its scope, and did much to advertise its potential.
3.2.2 Advantage of RAD
The RAD method has a task list and a work breakdown structure that is designed for speed. However the major difference in RAD is a set of management techniques that are optimised for speed. Among the most important are:
> Prototyping - Prototyping requires an open approach to development, it also requires an emphasis on relationship management and change management.
> Iteration - is a commitment to incremental development based on refinement. Prototyping and iteration go hand in hand.
> Time boxing - is a management technique that focuses attention on delivery above all else. Under a time box scope can change but delivery cannot.
3.2.3 Disadvantages of RAD
> Tools can be expensive and difficult to use
> Needs highly trained and dedicated staff
> Needs high level backing
> Can be pressurised
3.3 Multiview
Multiview is a soft system development approach that borrows many of the ideas of SSM and ETHICS, but incorporates harder tools and techniques as necessary. It is a methodology that, as its name implies, take a multiple view (or perspective) of a system's environment, it takes a view of the human, technical and organisational aspects of information system.
3.3.1 Five stages in Multiview
Analysis of human activity
The stage is closely related to the SSM approach to analysing problem situations.
Steps involved:
> Establish a Weltanschauung view
> Describe the systems requirements using rich pictures
> Establish root definitions
> Establish a conceptual model of activities
> Compare the conceptual model with the rich pictures
> Implement any changes through process of iteration.
Information Modelling
This stage involves the analysis of the entities and functions of the system; this is done through the development of a functional model which decomposes the functions down to understandable levels. Data flow diagrams can also be used to show the sequence of events. This can then be augmented with the development of an entity model through the use of data modelling techniques.
Steps involved:
> Develop a functional model
> Develop an entity model
Analysis and design of the socio-technical aspects .
This stage is influenced by the ETHICS approach information systems development, particularly through user participation and systems stakeholder involvement in the development process, this assess the socio-technical systems alternatives.
Steps involved:
> Establish human requirements
> Establish organisational requirements
> Establish socio-technical goodness of fit
> Assess future socio-technical environment
Design of the human-computer interface.
This stage involves which is often one ofthe primary concerns of most system
Steps involved:
> Technical design of human-computer interface
> Establish the design of input and out mediums.
Design of the technical aspects
This involves the design of technical aspects of the systems, this stage uses the entity model from Information Modelling and the technical requirements from Design of the human-computer interface to establish a technical design to implement test and evaluate the system on a continuous basis.
Step involved:
> Design technical environment
> Implement a technical solution
> System testing and evaluation
> On going systems evaluation.
3.4 Soft System Methodology
> Emphasis on understanding situation in which a perceived problem is thought to lie not in finding a solution.
> Considering the system as a "whole".
3.4.1 Stages in SSM
SSM through various analysis tools i.e. Rich Picture, Root Definition, CATWOE and conceptual diagram attempts to analyse the problem from all perspectives.
> Rich Picture
Represents the views of the people from the organisation and systems they are using with reference to their present situation. It is a pictorial caricature of an organisation and is an invaluable tool for helping to explain what the organisation is about (Avision & Fitzgerald 1997).
> Root Definition
It is a statement which identifies the system, the people, the owner of the system and the organisational context which it is used.
> CATWOE
CATWOE is an acronym for Client, Actor, Transformation, World view, Owner and Environment. The CATWOE is used to validate the root definition.
> Conceptual diagram.
This is base upon the rich picture. The rich picture gives a physical representation of the system, whilst conceptual diagram give an abstract or logical view of the system.
3.4.2 Advantage of SSM
SSM as a methodology can only be as an analysis tool. It gives the developers an insight into the organisations present situation e.g. what the problem themes are and communications between all the different elements.
3.5 SSADM Structured Systems Analysis And Design Method
> Structured systems analysis and design method (SSADM) is a highly structured approach used primarily to develop large-scale information systems for government departments in the United Kingdom.
3.5.1 History of SSADM
The approach was first used in 1981 and is a dataoriented methodology that emphasises data modelling tools and techniques.
SSADM has a number of versions and the latest version is 4.10, which was published in 1990 that includes greater consideration than previous versions of end-users within the process of development
SSADM is probably the best-known structured systems development approach. But it is only really applicable in the situation of major large-scale information systems development SSADM version 4.0 lists seven stages to the development process (labelled 0 through to 6), which are stated below
3.5.2Stages in SSADM
Each stage of the SSADM life cycle is strictly defined along with the outcomes of each stage; these outcomes are often referred to as 'deliverables' within systems vocabulary. SSADM uses its own symbol terminology for data flow diagramming, which is referred to as data flow modelling.
* Feasibility Study
The feasibility stage involves using such techniques as interviews, questionnaires and data flow models of the flow of information documentation.
Steps involved:
> Defining the problem and selecting options
> Creating feasibility report
* Requirement analysis: Investigate current Environment
The investigation of the current environment stage expands upon the feasibility stage by adding detail to the feasibility study.
Steps involved:
> Establish analysis framwork
> Investigate and define requirements
> Investigate current processing
> Investigate current data
> Derive logical view of current services
> Assemble investigation results
* Requirement Analysis: Business system option
A cost-benefit analysis is carried out and only that system options that show greater benefit to cost ratio will be continued and carried forward to the next stage.
Steps involved:
> Define business system options
> Select business system options
> Define requirements.
This stage establishes the full requirements specification and determines the following design stage. It is important in replacing investigation and analysis with specification and design to find 'what will be the requirements of the new or proposed system. This stage will normally involve entity modelling and normalisation of data relationships. Currently, within this stage in version 4.0 is a definition of user roles within the system. In addition, SSADM version 4.0 permits some element of prototyping to be carried out to assess the accuracy of user requirements, particularly in terms of user interface design.
3.5.3 Disadvantage of SSM
SSM is only appropriate to be used at the earliest stages of system development. To develop a fully working system, it is important for a developer to use a hard methodology to show how the data is modelled.
3.6 Object Orientated
> Object-orientation is an approach to analysis and design.
> Object Orientation contrasts with the more structured approaches such as SSADM and JSD.
Comparing the methods
Walker (Walk92) considers the four main criteria that should be considered by an object-oriented method are:
> Abstraction, including rules, guidelines, heuristics for the separation of the problem domain into different abstractions; methods for identifying state, services and interfaces for encapsulating objects; and strategy for abstracting commonality for abstract superclasses.
> Notation and representational verisimilitude, including notation for representing aggregation, inheritance and functional hierarchies, message sending/calling/parameter passing between objects in a seniority hierarchy; representation of autonomous objects and asynchronous message passing; and support for constraint representation and enforcement.
