Information system management

Chapter 1: Introduction

1. Project introduction

Project failure is one of the major problems in information system management. It is noted that only 28% of project are completed, within budget and functions are originally specified. Larger management information system projects, between 39% and 49% will be cancelled before the completion of the project. (Standish group 2000) the investigation carried out make it known that deficient requirements, user involvement and errors are major factor contributing to project failure. It is widely discussed in the literature that in order to eliminate failure, initially the project should be designed rationally. This rationality, as Zave (1997) states is the "…requirement engineering (that) is the branch of software engineering concerned with real goals, function and constraint on software system…"

For a project to be successful, it's very important for the analyst to identify the beneficiary within the organisation, identify their needs, and create documentation for analysis, implementation and communication giving the beneficiary an insight of the project and the analyst towards the achievement of clear business objectives. Furthermore the business rules and norm are also expressed with built in flexibility making software adapted to future change in requirement without destructive update and need for malignant change. Ades, Y (2008).

1.0 Project motivations

The main motivation of this project is the candidate's desire for practising "Business Analysis" & "Requirement Analysis" courses taken during the taught part of the MSc study and his great interest in pattern and structure on evaluation of the library circulation systems.
The case study chosen for this project is quite complex and challenging. Thus it promises an in depth understanding the intricate SNF theory, technique use during analysis of norms and even BTS a web base application design to support the rule of semantic design.
Since the system subject to the case study is easily accessible for the candidate, the project is likely to be completed (in the given time frame).
Availability of sources and data makes the project feasible in an academic framework.

1.1 Project Aims and Objectives

This project aims to critically analyse the modelling of an organisation, by evaluating an existing system using the "Greenwich University Library Circulation System" (GULCS) Such as, in this study, the modelling of an organisation will be critically analysed by means of evaluation of an existing system. As a case study GULCS will be utilised. In order to achieve this, an ontological chart which is Semantic Normal Form (SNF) complaint is model, and the model is being implemented into a Business Transaction System (BTS) to test for its functionality and see if it actually solves the problem i.e. the defect being found with the "Talis Prism" an application use by the library system.

An initial research on the GULCS has already started and Greenwich University Library Manager was consulted about the issues regarding to the library application system. This preliminary research has shown some system defects causing major problems for reader. These issues are:

When a missing item is found, the self service machine doesn't recognise it i.e., it does not update the work status but still indicates the item as missing.
When a member place reservation for a work, the application system does not alert the member whether the reservation he/she is placing is an e book, rather the system just continue with the reservation.
The system does not allow reservation of order copies, once a copy is reserved.
The system does not allow the going back or exit after a reservation is being place and save.
If a member has a copy of a work, and he/she decides to place a reservation on that same work again the system allows the member to continue with reservation, instead of cancelling it.
The system does not create a warning message when a reserve work is being issued to the wrong person.
One of the major issues is that finding an item that is being issued to the reserve shelf and the site where it resides.
When a member place a reservation for a work on the library shelf, it is easier for another person to loan the same item and take it out through the self service machine, since it gives priority over a member who has place a reservation for that particular work.
When a member place a reservation for a work, a red flag is usually set on showing that the work is on reservation, which is fine. Nevertheless, after the work has being satisfied if the member comes to collect the item and returns it after the work due date and then decides to renew the item again, the red flag should be set off but it is still set on showing the work is still on reservation.
The system does not send an email when an invoice item is being return to automatic update the record.

Needless to say, further in depth investigation and research may reveal more problems, however, due to time and constraint of the project, the central concern of the project will be parts of the outline system defects above.

Objectives

With the motive to improve the modelling of an organisation by critically evaluating an existing system using the case study (GULCS) the project objective are as follows.

To model an ontological chart following the SNF rules by capturing three of the system defects and implement the model in BTS to test for its functionality and performance. The method that would be illustrated is borrowing of work, placing a reservation and cancelling it.
To some reasonable extent, an attempt to develop a common understanding and mastering the technique of both semantic analysis and norm analysis for requirement elicitation, specification and validation in modelling an organisation.
To study and understand all associated norm analysis by illustrating the perceptual norm associated with the communication act.
To improve my knowledge, understanding and the essence of using BTS technology when implementing specified requirement.

1.2 Project deliverable

To critically analysed the problem area of the existing system i.e. the use case study (GULCS) and model an ontological chart which is Semantic Normal Form (SNF) compliant base on the system and implement the model in Business Transaction System (BTS) a web application design to follow the rule of semantic unit.
To produce detailed documentation of the important of Requirement engineering in software development by analysing on problem with (RE) and processes involve applying method of semantic and norm analysis.
To produce an understanding of the SNF theory.
To carryout a test plan, to test the functionality and performance after the model is being implemented in (BTS) which is use to indentify an inconsistencies in the elicitation process of the project.

1.3 Project scope

The main concern of this project is to focus on the important of (RE) in software development during modelling an organisation, to provide a business solution that could correct the functional defect existing within the (GULCS) and also to capture the pattern of behaviour between agent and affordance, their association and communication acts.

1.4 Project plans

Chapter 2: Literature review

The literature review gives an insight of an organisation by characterising it as a structure of social norms i.e. allowing group of people to act in coordinated way for some purpose and seeing it as information system. It also gives detailed documentation of requirement engineering in system development and explaining the processes involve toward the success of a good project. In this paper the phases that would be analyse are elicitation, specification and the validation process.

Chapter 3: Semantic and Norm analysis

The theory of semantic normal form (SNF) is addressed and detailed analysis method of semantic and norm analysis in modelling an organisation.

Chapter 4: Case study

This is where I introduced the case study (GULCS) after thorough investigation and interviews from the beneficiaries. Detailed documentation of the background of the existing system is study so that the reader can gain some domain knowledge. I also produce an ontological chart that is semantic normal form (SNF) compliant, identify the business norm and then use the procedure of RE using semantic analysis to create problem statement.

Chapter 5: Implementation into the BTS

This is where the implementation is being carried out; the ontological chart that was model is being implemented into the BTS.

Chapter 6: Validation and Testing

I carried out a test plan to test for the functionality and performance of the system in the business transaction system (BTS).

Chapter 7: Conclusion

In this chapter I summarise the whole project and its major finding during the project research and a conclusion was drawn.

Chapter 2: Literature Review

2. Organisation

Organisation is a social system, in which people conform to behave to certain system of norms. These norms can be characterised as behaviour, perception and belief exhibited as organisation habit and pattern of behaviour. It can also be looked at as structure of "social norms" whereby group of individual act together for certain purpose. As stated by Huang (1998) "… the purpose may be little making it impossible for the organisation to maintain its existence, to serve as an arena for the pursuit of its goods and sectional interest of its members…"

2.0 Organisation as information system

From the perspective of information system, agent may engage sign to perform intentional actions. Due to the fact that different functions are being performed within the organisation, some of the organisation functions are high in regularity where rules can be formalised as bureaucracy. The machine based system within an organisation is usually used to automate part of the formal system which in turn is referred to be total part of an organisation. Stamper (1992) names this "organisation onion" and sub divided it into three unit's informal information system, formal information system and technical information system, representing organisational structure.

The organisation onion gives a clear distinction between each layer and good illustration of an organisation.

2.1 Modelling organisation

Modelling organisation as never being so easy, it is always important when modelling an organisation that both the analyst and the stakeholders understand each other as incorrect user requirement or omitted system specification always result in project failure. The analyst must understand the organisation, its function and structure as important component of the system specification are not being notice or rather say it's too difficult to document by the analyst, which worsened case of system documentation and presentation, making the system too technical for system beneficiaries to comprehend. Ades, Y (2008).

Furthermore in analysis and design an effective modelling method must deal with issues in semantic, social aspect and pragmatic, in this paper our focus will be on the "semantic issue" a modelling method which give a good description of an organisation. The semantic issue give a good clarification of the semantic phases by analysing on how the phases can be use to model an effective organisation. Also an effective method must follow the technique for requirement elicitation, analysis, and validation in order to envisage the knowledge of the beneficiaries and system requirements. A detailed discussion and more emphasis would be laid on proper documentation of requirement elicitation, analysis and validation later on this paper.

2.2 Requirement engineering

Requirement engineering (RE) is software development process which is concerned with real world goals, with precise specification of requirement eliciting, analysing and validating stakeholder's objectives. The system analyst uses these processes to improve the situation of an organisation which seems to be in perfect or problematic. Throughout this project the term RE encompass three processes, requirement elicitation which determine the needs of an organisation by identifying its problems, goals and stakeholders, requirement analysis which involve modelling of specification and analysing requirement, requirement validation which certify that the system specification being produce meet with the beneficiaries needs. The output of this processes is the set of requirement which is agreed upon by the stakeholders and the system analyst.

Requirement engineering can be defined "…as the branch of software engineering concerned with real goals, function and constraint on software systems. It also concerned with the relationship of these factors to exact specification of software behaviour, their evolution over time and across software families…" Zave, P (1997).

It was also defined "…as the science and discipline involved with establishing and documentation of software requirements…" Thayer, R and Dofman (1997)

However the requirement engineering (RE) definition that suit the requirement of this paper was defined "…as the systematic process of developing requirement, through iterative process of analysing the problem, documenting the result in a variety of representation format, and checking its accuracy…" Loucopoulos, P. et al. (1995).

This definition was given the best priority because it addresses and cover the three main RE processes that would be looked out in this paper, the needs analysis, documenting and presenting beneficiaries requirement and also acceptance of the system analysis.

2.2.1 The role of requirement engineering in system development

In any software development project, requirement engineering (RE) is major factors that must be considered in order to meet up with stakeholders objectives. The development process in system engineering viewed by Forberg, K. et al. (1992) addressed the design process first, followed by the integration process. It is during the design process that the needs of the stakeholders are being analysed, specify in engineering terms and then divided into specification for several component. It is very important that the design process is broadly view and much iteration is given to the specification before being passed on to the system engineers. The design process specify what is expected of the system, how well it must do it and how it should be tested to validate the performance of the system.

2.2.2 Requirement engineering problem

Despite the important of requirement engineering in software project, RE process are still connected with some problem. According to Frederick, B (1987) the problem with requirement engineering can be sub divided into two categories, which can be seen as "essential" and "accidental". The essential problems as (he) stated are invisibility of software and requirement change while the accidental problems are tools integration and poor documentation which arise during requirement specification of the system. More so the survey carried out by Lubars, M. et al (1993) also found out that the most documentation tools used by most business analyst are word processing, which is wrong choice for tools documentation. To ensure the successfulness of RE in any software developing project, the business analyst should be able to identify all the stakeholders within the organisation, involved the beneficiaries during the early stage of the developing process and also make sure the right tools are use that collate all the engineering process. Requirement management (RM) can best be used in that interest because it easily control all the engineering process, allow management change and maintain requirements accurately in a way that mirror the software specification. RM is a tool that must be use by the analyst during organisation modelling in order to achieve a successful project.

2.2.3 Requirement engineering process

Requirement engineering is the process use to determine what to produce in software developing system. In developing a multi task system, requirement engineering process contribute to the major goal to determine the needs for, and intended behaviour of the system (in) design.

RE process is considered as an important part in housing a software system. According to Brooks, P (1987) when developing a system, the hardest part of it is to understand what to developed, people involved and necessary technique to use, if all these part are being failed the system become cripple and it would be difficult to correct in future. The specification being built in this paper is SNF complaint which allows the benefit of more practical and theoretical foundation with repeated change in the beneficiaries' requirement, and also immune to "malignant changes" changes that involved rewriting software specification. Requirement engineering encompassed three processes in this paper and they are requirement elicitation, requirement specification and requirement validation, more in depth about each processes would be given along the documentation of this project.

Requirement elicitation

Requirement elicitation also known as the negotiation process is the first phase, identify by system analyst in any software development project. This process is about understanding the organisation problem such as the existing system defect within the organisational system that the proposed system under development aims to correct. Requirement elicitation normally makes use of the traditional technique when gathering requirement, technique such as interview, survey, questionnaires and analysis of existing documentation. During this process the participants of the system are also identify, the system analyst, stakeholders and beneficiaries of the system. These three participants play an important role in the elicitation process, lack of good communication or misunderstanding between these participants affect the end documentation of requirement gathering. Linda Macaulay (1996)

Requirement specification

Requirement specification is the second phase in the engineering process; it is during this phase the enterprise modelling, data modelling and the behavioural modelling of the system is being addressed. The documentation produce during the early phase of the engineering process (requirement elicitation) is analyses and models of the system are designed, relating organisation goals.

Requirement validation

Requirement validation is the third phase in the engineering process; it is during this phase the specifications is certified and ensure it meet the beneficiaries' needs. The output of this process is the set of requirement which is agreed upon by the stakeholders and the system analyst. In this paper the specification being model is implemented into the BTS system and its output is validated and tested.

Essay Writing

Resources