System Analysis and Design

• Describe the six phases of the systems life cycle.

• Discuss how problems or needs are identified  during Phase 1, preliminary investigation.

• Explain how the current system is studied and new requirements are specified in Phase 2, system analysis.

• Describe how a new or alternative information system is designed in Phase 3, systems design.

• Explain how new hardware and software are acquired, developed, and tested in Phase 4, systems development.

• Describe how a new information system is installed and users are trained in Phase 5, systems implementation.

• Describe Phase 6, system maintenance, the systems audit and ongoing evaluation, to see if a new system is doing what it’s
supposed to.

• Describe prototyping and RAD.

Introduction to Life Cycle Models

The trends of increasing technical complexity of the systems, coupled with the need for repeatable and predictable
process methodologies, have driven System Developers to establish system development models or software
development life cycle models.
Nearly three decades ago the operations in an organization used to be limited and so it was possible to
maintain them using manual procedures. But with the growing operations of organizations, the need to
automate the various activities increased, since for manual procedures it was becoming very difficult, slow
and complicated. Like maintaining records for a thousand plus employees company on papers is
definitely a cumbersome job. So, at that time more and more companies started going for automation.

Since there were a lot of organizations, which were opting for automation, it was felt that some standard
and structural procedure or methodology be introduced in the industry so that the transition from manual
to automated system became easy. The concept of system life cycle came into existence then. Life cycle
model emphasized on the need to follow some structured approach towards building new or improved
system. There were many models suggested. A waterfall model was among the very first models that
came into existence. Later on many other models like prototype, rapid application development model, etc
were also introduced.

System development begins with the recognition of user needs. Then there is a preliminary investigation
stage. It includes evaluation of present system, information gathering, feasibility study, and request
approval. Feasibility study includes technical, economic, legal and operational feasibility. In economic
feasibility cost-benefit analysis is done. After that, there are detailed design, implementation, testing and
maintenance stages.

In this session, we'll be learning about various stages that make system's life cycle. In addition, different
life cycles models will be discussed. These include Waterfall model, Prototype model, Object-Oriented
Model, spiral model and Dynamic Systems Development Method (DSDM).

Activities Involved Software Development Life Cycle Model

Problem solving in software consists of these activities:
• Understanding the problem
 • Deciding a plan for a solution

• Coding the planned solution

• Testing the actual program

For small problems these activities may not be done explicitly. The start end boundaries of these activities
may not be clearly defined, and not written record of the activities may be kept. However, for large
systems where the problem solving activity may last over a few years. And where many people are
involved in development, performing these activities implicitly without proper documentation and
representation will clearly not work. For any software system of a non-trival nature, each of the four
activities for problem solving listed above has to be done formally. For large systems, each activity can be
extremely complex and methodologies and precedures are needed to perform it efficiently and correctly.
Each of these activities is a major task for large software projects.

Furthermore, each of the basic activities itself may be so large that it cannot be handled in single step and
must be broken into smaller steps. For example, design of a large software system is always broken into
multiple, distinct design phases, starting from a very high level design specifying only the components in
the system to a detailed design where the logic of the components is specified. The basic activities or
phases to be performed for developing a software system are:

• Requirement Analysis / Determination of System's Requirements

• Design of system

• Development (coding) of software

• System Testing

In addition to the activities performed during software development, some activities are performed after
the main development is complete. There is often an installation (also called implementation) phase,
which is concerned with actually installing the system on the client's computer systems and then testing it.
Then, there is software maintenance. Maintenance is an activity that commences after the software is
developed. Software needs to be maintained not because some of its components "wear out" and need to
be replaced, but because there are often some residual errors remaining in the system which must be
removed later as they are discovered. Furthermore, the software often must be upgraded and enhanced
to include more "features" and provide more services. This also requires modification of the software,
Therefore, maintenance in unavoidable for software systems.

In most commercial software developments there are also some activities performed before the
requirement analysis takes place. These can be combined into a feasibility analysis phase. In this phase
the feasibility of the project is analyzed, and a business proposal is put forth with a very general plan for
the project and some cost estimates. For feasibility analysis, some understanding of the major
requirements of the system is essential. Once the business proposal is accepted or the contract is
awarded, the development activities begin starting with the requirements analysis phase.

Following topics describes the above mentioned phases:

• Preliminary Investigation

• Requirement Analysis / Determination of System's Requirements

• Design of system

• Development (coding) of software

 • System Testing

• Software Maintenance

• Error distribution with phases

Preliminary Investigation
Fig 2.1 shows different stages in the system's life cycle. It initiates with a project request. First stage is the preliminary
analysis. The main aim of preliminary analysis is to identify the problem. First, need for the new or the enhanced
system is established. Only after the recognition of need, for the proposed system is done then further analysis is
possible.
Suppose in an office all leave-applications are processed manually. Now this company is recruiting many
new people every year. So the number of employee in the company has increased. So manual
processing of leave application is becoming very difficult. So the management is considering the option of
automating the leave processing system. If this is the case, then the system analyst would need to
investigate the existing system, find the limitations present, and finally evaluate whether automating the
system would help the organization.

Once the initial investigation is done and the need for new or improved system is established, all possible
alternate solutions are chalked out. All these systems are known as "candidate systems". All the
candidate systems are then weighed and the best alternative of all these is selected as the solution
system, which is termed as the "proposed system". The proposed system is evaluated for its feasibility.
Feasibility for a system means whether it is practical and beneficial to build that system.

Feasibility is evaluated from developer and customer's point of view. Developer sees whether they have
the required technology or manpower to build the new system. Is building the new system really going to
benefit the customer. Does the customer have the required money to build that type of a system? All
these issues are covered in the feasibility study of the system. The feasibility of the system is evaluated
on the three main issues: technical, economical, and operational. Another issue in this regard is the legal
feasibility of the project.

• Technical feasibility: Can the development of the proposed system be done with current
equipment, existing software technology, and available personnel? Does it require new
technology?

• Economic feasibility: Are there sufficient benefits in creating the system to make the
costs acceptable? An important outcome of the economic feasibility study is the cost benefit
analysis.

• Legal feasibility: It checks if there are any legal hassle in developing the system.

• Operational feasibility: Will the system be used if it is developed and implemented? Will
there be resistance from users that will undermine the possible application benefits?

The result of the feasibility study is a formal document, a report detailing the nature and scope of the
proposed solution. It consists of the following:

• Statement of the problem

• Details of findings

• Findings and recommendations in concise form

Once the feasibility study is done then the project is approved or disapproved according to the results of
the study. If the project seems feasible and desirable then the project is finally approved otherwise no
further work is done on it.

Determination Of System's Requirements: Analysis Phase In SDLC

Requirements Analysis is done in order to understand the problem for which the software system is to solve. For
example, the problem could be automating an existing manual process, or developing a completely new automated
system, or a combination of the two. For large systems which have a large number of features, and that need to
perform many different tasks, understanding the requirements of the system is a major task. The emphasis in
requirements Analysis is on identifying what is needed from the system and not how the system will achieve it goals.
This task is complicated by the fact that there are often at least two parties involved in software development - a client
and a developer. The developer usually does not understand the client's problem domain, and the client often does
not understand the issues involved in software systems. This causes a communication gap, which has to be
adequately bridged during requirements Analysis.

In most software projects, the requirement phase ends with a document describing all the requirements.
In other words, the goal of the requirement specification phase is to produce the software requirement
specification document. The person responsible for the requirement analysis is often called the analyst.
There are two major activities in this phase - problem understanding or analysis and requirement
specification in problem analysis; the analyst has to understand the problem and its context. Such
analysis typically requires a thorough understanding of the existing system, the parts of which must be
automated.

Once the problem is analyzed and the essentials understood, the requirements must be specified in the
requirement specification document. For requirement specification in the form of document, some
specification language has to be selected (example: English, regular expressions, tables, or a
combination of these). The requirements documents must specify all functional and performance
requirements, the formats of inputs, outputs and any required standards, and all design constraints that
exits due to political, economic environmental, and security reasons. The phase ends with validation of
requirements specified in the document. The basic purpose of validation is to make sure that the
requirements specified in the document, actually reflect the actual requirements or needs, and that all
requirements are specified. Validation is often done through requirement review, in which a group of
people including representatives of the client, critically review the requirements specification.

Software Requirement or Role of Software Requirement Specification (SRS)

IEEE (Institute of Electrical and Electronics Engineering) defines as,

• A condition of capability needed by a user to solve a problem or achieve an objective;

• A condition or capability that must be met or possessed by a system to satisfy a contract,

standard, specification, or other formally imposed document.

Note that in software requirements we are dealing with the requirements of the proposed system, that is,
the capabilities that system, which is yet to be developed, should have. It is because we are dealing with
specifying a system that does not exist in any form that the problem of requirements becomes
complicated. Regardless of how the requirements phase proceeds, the Software Requirement
Specification (SRS) is a document that completely describes what the proposed software should do
without describing how the system will do it?. The basic goal of the requirement phase is to produce the
Software Requirement Specification (SRS), which describes the complete external behavior of the
proposed software.