An Overview Of System Analysis Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Systems are created to solve problems. One can think of the systems approach as an organized way of dealing with a problem. In this dynamic world, the subject System Analysis and Design mainly deals with the software development activities. And we can learn:-

A collection of components that work together to realize some objective forms a system. Basically there are three major components in every system, namely input, processing and output.

In a system the different components are connected with each other and they are interdependent. For example, Human body represents a complete natural system. We are also bound by many national systems such as political system, economic system, educational system and so forth. The objective of the system demands that some output is produced as a result of processing the suitable inputs.

Assignment - Task 01

Understanding the system analysis life Cycle

System Analysis means understanding the details of an existing system or a proposed one and then deciding whether the proposed system is desirable or not and whether the existing system needs improvements. Thus, system analysis is the process of investigating a system, identifying problems, and using the information to recommend improvements to the system.

In this phase, the current system is studied in detail. A person responsible for the analysis of the system is known as analyst.

Functions and purpose of each stage of a system life cycle

In system analysis, the analyst conducts the following activities.

Requirements Analysis

In this step the analyst sums up the requirements of the system from the user and the managers. The developed system should satisfy these requirements during testing phase.

Data Gathering

In this step, the system analyst collects data about the system to be developed. He uses different tools and methods, depending on situation. These are:


Interview is another data gathering technique. The analyst(or project team members) interviews, managers, users/ clients, suppliers, and competitors to collect the information about the system. It must be noted that the questions to be asked from them should be precise, relevant and to the point.

Written Documents

The analyst collects the information/data from written documents available from manual-files of an organization. This method of data gathering is normally used if you want to computerize the existing manual system or upgrade the existing computer based system. The written documentsmay be reports, forms, memos, business plans, policy statements, organizational charts and many others. Thewritten documents provide valuable information about the existing system.


Questionnaires are the feedback forms used to collect Information. The interview technique to collect information is time-consuming method, so Questionnaires are designed to collect information from as many people as we like. It is very convenient and inexpensive method to collect information but sometimes the response may be Confusing or unclear and insufficient.


In addition to the above-mentioned three techniques to collect information, the analyst (or his team) may collect Information through observation. In this collect technique, the working, behavior, and other related information of the existing system are observed. It means that working of existing system is watched carefully.

Data Analysis

After completion of Data Gathering step the collected data about the system is analyzed to ensure that the data is accurate and complete. For this purpose, various tools may be used. The most popular and commonly used tools for data analysis are:

  • DFDs (Data Flow Diagrams)

  • System Flowcharts

  • Connectivity Diagrams

  • Grid Charts

  • Decision Tables etc.

Analysis Report

After completing the work of analysis, the requirements collected for the system are documented in a presentable form. It means that the analysis report is prepared. It is done for review and approval of the project from the higher management. This report should have three parts.

  • First, it should explain how the current system works.

  • Second, it should explain the problems in the existing system.

  • Finally, it should describe the requirements for the new system and make recommendations for future.

The SDLC can be divided into ten phases during which defined IT work products are created or modified. The tenth phase occurs when the system is disposed of and the task performed is either eliminated or transferred to other systems. The tasks and work products for each phase are described in subsequent chapters. Not every project will require that the phases be sequentially executed. However, the phases are interdependent. Depending upon the size and complexity of the project, phases may be combined or may overlap.


To generate a high-level view of the intendedprojectand determine thegoalsof the project. Thefeasibility studyis sometimes used to present the project to upper management in an attempt to gain funding. Projects are typically evaluated in three areas of feasibility: economical, operational or organizational, and technical. Furthermore, it is also used as a reference to keep the project on track and to evaluate the progress of the MIS team.

Requirements gathering and analysis

The goal ofsystems analysisis to determine where the problem is in an attempt to fix the system. This step involvesbreaking downthe system in different pieces and drawingdiagramsto analyze the situation, analyzing project goals, breaking down what needs to be created and attempting to engage users so that definiterequirementscan be defined.

System Analysis


Insystems designfunctions and operations are described in detail, including screen layouts, business rules, process diagrams and other documentation. The output of this stage will describe the new system as a collection of modules orsubsystems.

The design stage takes as its initial input the requirements identified in the approved requirements document. For each requirement, a set of one or more design elements will be produced as a result of interviews, workshops, and/or prototype efforts. Design elements describe the desired software features in detail, and generally include functional hierarchy diagrams, screen layout diagrams, tables of business rules, business process diagrams, pseudo code, and a complete entity-relationship diagram with a full data dictionary.

Build or coding

Modularand subsystemprogrammingcode will be accomplished during this stage. Unit testing and module testing are done in this stage by the developers. This stage is intermingled with the next in that individual modules will need testing before integration to the main project.


The code is tested at various levels insoftware testing. Unit, system and user acceptance testings are often performed. This is a grey area as many different opinions exist as to what the stages of testing are and how much if any iteration occurs. Iteration is not generally part of thewaterfall model, but usually some occur at this stage.

Types of testing:

  • Data set testing.

  • Unit testing

  • System testing

  • Integration testing

  • Black box testing

  • White box testing

  • Regression testing

  • Automation testing

  • User acceptance testing

  • Performance testing

Operations and maintenance

Thedeploymentof the system includes changes and enhancements before the decommissioning or sunset of the system.Maintainingthe system is an important aspect of SDLC. As key personnel change positions in the organization, new changes will be implemented, which will require system updates.


Waterfall Model

The major weakness of the Waterfall Model is that after project requirements are gathered in the first phase, there is no formal way to make changes to the project as requirements change or more information becomes available to the project team. Because requirements almost always change during long development cycles, often the product that is implemented at the end of the process is obsolete as it goes into production. The Waterfall Model is a poor choice for software development projects where requirements are not well-known or understood by the development team. It might not a good model for complex projects or projects that take more than a few months to complete.

Spiral Model

In the Spiral SDLC Model, the development team starts with a small set of requirements and goes through each development phase (except Installation and Maintenance) for those set of requirements. Based on lesson learned from the initial iteration (via a risk analysis process), the development team adds functionality for additional requirements in ever-increasing "spirals" until the application is ready for the Installation and Maintenance phase (production). Each of the iterations prior to the production version is a prototype of the application.

The advantage of the Spiral Model over the Waterfall Model is that the iterative approach allows development to begin even when all the system requirements are not known or understood by the development team. As each prototype is tested, user feedback is used to make sure the project is on track. The risk analysis step provides a formal method to ensure the project stays on track even if requirements do change.

Top-Down Model

A good way to picture the Top-down model is to think of a menu-driven application. The top level menu items would be designed and coded, and then each sublevel would be added after the top level was finished. Each menu item represents a subsystem of the total application.

The Top-down model is a good fit when the application is a new one and there is no existing functionality that can be incorporated into the new system. A major problem with the Top-down

Model is that real system functionality is not added and cannot be tested until late in the development process. If problems are not detected early in the project, they can be costly to remedy later.

Bottom-Up Model

In the Bottom-up SDLC model, the lowest level of functionality is designed and programmed first, and finally all the pieces are integrated together into the finished application. This means that, generally, the most complex components are developed and tested first. The idea is that any project show-stoppers will surface early in the project. The Bottom-up model also encourages the development and use of reusable software components that can be used multiple times across many software development projects. Again, think of a menu driven system where the development starts with the lowest level menu items.

The disadvantage of the Bottom-up model is that an extreme amount of coordination is required to be sure that the individual software components work together correctly in the finished system. Few systems are developed purely from the Bottom-up model.

Hybrid Model

The Hybrid SDLC model combines the top-down and bottom-up models. Using the menu driven application example, the design team primarily works top down, but the development team identifies two types of lower level components to work on at the same time as the high-level components. The first type of low-level component would be existing software modules from other projects that can be reused in the new project. The other type of low-level component that would be developed early in the project would be software components with a high risk of failure. This approach allows the development team to make changes to the system early in the project if problems occur with the high-risk components.

Rapid Prototyping

After a quick requirements gathering phase, a prototype application is built and presented to the application users. Feedback from the user provides a loop to improve or add functionality to the application. Early RAD models did not involve the use of real data in the prototype, but new RAD implementations do use real data.

The advantage of Rapid Prototyping Models is that time-to-market is greatly reduced. Rapid Prototyping skips many of the steps in traditional SDLC models in favor of fast and low-cost software development. The idea is that application software is a "throw-away." If a new version of the software is needed, it is developed from scratch using the newest RAD techniques and tools.

The big disadvantage of the Rapid Prototyping Model is that the process can be to fast, and, therefore, proper testing (especially security testing) may not be done.

The Rapid Prototyping Model is used for graphical user interface (GUI) applications such as web-based applications. Extreme Programming (XP) is a modern incarnation of the Rapid Prototyping Model.

Object-Oriented Model

An important feature of Object-oriented (OO) systems is that software objects represent real-world objects. Objects are derived from Classes, and a class hierarchy allows objects to inherit characteristics from parent classes. This allows software object reuse, less coding, encapsulation of functionality, and many other advantages. A major problem that arose with OO programming is that if the Class hierarchy is not properly designed, all the OO advantages disappear. The object-oriented model attempts to properly define and document the Class hierarchy from which all the system objects are created and object interactions are defined.

The object-oriented SDLC model has these phases that roughly correspond to the traditional SDLC phases noted in brackets:

  1. Object-Oriented Requirements Analysis (OORA) [Design Analysis]: This is where classes of objects and the interaction between them are defined.

  2. Object-Oriented Analysis (OOA) [Design Analysis]: In terms of object-oriented concepts, understanding, and modeling a particular problem within a problem domain.

  3. Object-Oriented Design (OOD) [System Design Specification]: The object is the basic unit of modularity; objects are instantiations of a class.

  4. Object-Oriented Programming (OOP) [Programming and Testing]: Emphasizes the employment of objects and methods rather than types or transformations, as in other programming approaches.

The Object-oriented SDLC model is characterized by its attempt to model real-world entities (such as company, account, and employee) into abstract computer software objects and all the interactions that can take place between those objects.

Assignment - Task 02- a

System Analysis Tools and techniques:

Data Modeling

Data modeling is amethodused to define and analyze data requirementsneeded to support thebusiness processesof an organization. The data requirements are recorded as aconceptual data modelwith associateddata definitions. Actual implementation of the conceptual modelis called alogical data model.

Data modeling is the act of exploring data-oriented structures. Like other modeling artifacts data models can be used for a variety of purposes, from high-level conceptual models to physical data models. From the point of view of an object-oriented developer data modeling is conceptually similar to class modeling. With data modeling you identify entity types whereas with class modeling you identify classes.

Modeling methodologies

  • Bottom-up models are often the result of areengineeringeffort. They usually start with existing data structures forms, fields on application screens, or reports. These models are usually physical, application-specific, and incomplete from anenterprise perspective. They may not promote data sharing, especially if they are built without reference to other parts of the organization.

  • Top-downlogical data models, on the other hand, are created in an abstract way by getting information from people who know the subject area. A system may not implement all the entities in a logical model, but the model serves as a reference point or template.
  • Assignment - Task 02- b

    Entity relationship diagrams

    There are several notations for data modeling. The actual model is frequently called "Entity relationship model", because it depicts data in terms of the entities and relationships described in thedata.An entity-relationship model (ERM) is an abstract conceptual representation of structured data. Entity-relationship modeling is a relational schemadatabase modelingmethod, used insoftware engineeringto produce a type ofconceptual data model(orsemantic data model) of a system, often arelational database, and its requirements in atop-downfashion.

    Several techniques have been developed for the design of data models. While these methodologies guide data modelers in their work, two different people using the same methodology will often come up with very different results. Most notable are:

    • Bachman diagrams

    • Barker's Notation

    • Data Vault Modeling

    • Object-relational mapping

    • Object Role Modeling

    • Relational Model

    Diagramming conventions

    In this method, Entity sets are drawn as rectangles, relationship sets as diamonds. If an entity set participates in a relationship set, they are connected with a line.

    Attribute is drawn as ovals and is connected with a line to exactly one entity or relationship set.

    Cardinality constraints are expressed as follows:

    • a double line indicates aparticipation constraint,totalityorsubjectivity: all entities in the entity set must participate inat least one relationship in the relationship set;

    • an arrow from entity set to relationship set indicates akey constraint, i.e.infectivity: each entity of the entity set can participate inat most onerelationship in the relationship set;

    • a thick line indicates both, i.e.objectivity: each entity in the entity set is involved inexactly onerelationship.

    • an underlined name of an attribute indicates that it is akey: two different entities or relationships with this attribute always have different values for this attribute.


    Dental care is a dentist centre that is planning to implement new software so that they could keep track of their members and the treatments given to them. The software will have following functionalities.

    • To register the new patients to their centre.

    • To store the patient details into the system so they can be used for future reference.

    • To store the details of the doctor and know their availability so that appointments for the patients can be booked.

    • Each patient has been allocated a doctor for the treatment.

    • To store the treatment details like fee and specialist doctor etc.

    • To book the appointment for the patients and record those appointments for future reference.

    • To be able to record the payment details for the patients.

    • To be able to store the details of their treatment plan that has been previously agreed by a dentist.

    • To store the details of the medicines required for treatment.

    E-R Diagram for a Dentist Centre

    Assignment - Task 02- c

    Document Modellinglooks at the inherent structure in documents. It looks not at the structure informattingwhich is the classic realm of word-processing tools, but at the structure in content. Because document content is typically viewed as thead hocresult of a creative process, the art of document modelling is still in its infancy. Document modelling therefore looks at the structures and patterns of the written work, and breaks it down into different options or branches. It then labels the branches and the results. Without effective document modelling, it is difficult to get full value from a document automation initiative, for example, using document assembly software.

    Assignment - Task 03 -a

    Taking into consideration the above Dentist care scenario, following things have been appeared to be investigated:

    1. Method of recording the details of new patients

    2. Whether Dentist centre keeps various details of patients like Patient Name, Age, Gender, Address, Symptoms

    3. Availability of Doctor , and also check whether the patient has been examined by any doctor previously

    4. whether the Treatment details of patient, appointment details of patient for future reference are kept or not

    5. Booking appointments for patients

    Assignment - Task 03- b

    Keeping in view the scenario, various data gathering techniques were used. Information was collected from Dentist care centre staff, their clerk, record keeper, their doctors. Their registers were also investigated, their method of recording patients entries, booking appointments, doctor's fee, treatment details etc. In this step the analyst sums up the requirements of the system from the user and the managers. The developed system should satisfy these requirements during testing phase.

    Data Gathering

    In this step, data has been collected about the system to be developed. Different tools and methods, depending on situation. These are:

    • Interviews

    • Written Documents

    • Questionnaires

    • Observations

    Assignment - Task 03- b

    Documentationis the most often neglected, and most missed, part of thesystemdevelopment process. When deadlines come closer, the corner that is cut first is alwaysdocumentation. This is unfortunate since soliddocumentationis as essential to the overallsystemlife cycle as anything else.

    Gooddocumentationalways processes the following common characteristics:

    1. Easy to comprehend

    2. The information contained must be easy to find

    3. The information must be correct

    4. The information must be complete

    5. The information must be up-to-date

    There are two simple ways to represent the data structure of an application:

    1. Tabular form

    2. Entity - Relationship diagram (ERD)

    Tabular form


    table_name (attribute [{, attribute) ... ]) where the primary key is underlined and the foreign key is asterisked.

    For example:

    Patient (Patient_code, Name, Age, symptoms)

    Doctor (Doctor_id, Doctor_name)

    Appointment (Appt_no, Date, Appt_time,Doctor_id)

    Treatment (Patient_code, Medicine_dtls)

    Assignment - Task 04 -b

    Functional Model of the Scenario

    Afunction modelorfunctional modelinsystems engineeringandsoftware engineeringis a structuredrepresentationof thefunctions,activitiesorprocesseswithin the modeledsystemor subject area.

    A function model, also called anactivity modelorprocess model, is a graphical representation of anenterprise's function within a defined scope. The purposes of the function model are to describe the functions and processes, assist with discovery of information needs, help identify opportunities, and establish a basis for determining product and service costs.

    Assignment - Task 04 -c

    Relations/Tables used in the scenario:

    Study Analysis of Hospital Dentist Problem

    Evidence from various sources indicates that a substantial number of hospitalized patients suffer treatment-caused injuries. Most of these injuries result from errors. Yet physicians and other health professionals have been reluctant to admit and address the problem of errors, both because of feelings of guilt and from the desire to avoid punishment or disapproval by colleagues. Research in cognitive psychology and human factors has shown that most errors result from defects in the systems in which we work. These are failures in the design of processes, tasks, training, and conditions of work that make errors more likely. Meaningful reduction of errors requires correction of these systems failures. Barriers to reduction of errors include the complexity of health care systems, difficulties in information access, tolerance of stylistic practices, and fear of punishment that inhibits reporting. Most institutions also lack effective methods for detecting and quantifying errors. Significant improvements in error reduction will require major commitments by organizational leadership and the recognition that errors are evidence of deficiencies in systems, not deficiencies in people.

    Keeping in view all the above factors, A computerized Dentist hospital Centre record keeping system has been developed. It is just am approach to think about that system taking into account all the material facts and practical requirements which can be applied through System Analysis life cycle. Its been a quite useful and practical approach to develop a system like this. In our problem, first of all a registration process is completed of every new patient and his/her details are stored in database for future use. Then details of the doctor and know their availability so that appointments for the patients can be booked. Each patient has been allocated a doctor for the treatment. Further it store the treatment details like fee and specialist doctor etc. Book the appointment for the patients and record those appointments for future reference. It is also able to record the payment details for the patients and side by side store the details of their treatment plan that has been previously agreed by a dentist.


    A lot of things have come out to me in this whole assignment. For a Dentist Care centre, this system can prove to be very useful as it reduces the manual work and keeps record of each and every thing. Besides recording the patient details, keeping track of appointments, it generates the bills very effectively after calculating all aspects. A due care has been taken to record the medical history of a patient so that patient can be easily given treatment in future according to his previous check ups. Last but not the least; I have done my best for analyzing this system for making it online to a dentist centre.

    References and Bibliography :

    1. Systems Analysis and Designby Gary B. Shelly,Thomas J. Cash man,Harry J. Rosenblatt

    2. System Analysis and Modeling by Amyot, Daniel; Williams, Alan W. (Eds.)

    3. References from World Wide Web