Systems analysis life cycle
A system is collection of computers (subsystems) which integrate with each other to achieve
a clear and a common goal.
Eg: Business system, digesting system, etc.
What is an Information system?
It’s an integration based on hardware, software & live ware to handle the day to day
operation in a more effective way & also to help the management in decision making.
Eg: Banking system, Student Registration system
How to develop an information system?
There are number of methodologies available to develop an information system, each
methodology use a number of steps of spaces to develop an information system.
Stages used to develop a life cycle model.
1. Strategic Study
Strategic study used to determine what information systems are needed to support the
need of the system & what information technology more appropriate to support those
information systems. It’s a company wide study & driven by cooperate business plan & it
defines an ideal strategic for the company.
2. Business Study
Business study is the 1st point at which the business systems are focused of work. Rather
than the business as a whole. There is variety of different method to explore a business
system where it needs to analyses what are the inputs & the outputs of the business
system. Within business study it needs to understand how to do the work & how it is
going to relate to the other systems. The business study is the 1st point at which a formal
project plan will be started.
3. Feasibility Study
Feasibility study is a filamentary investigation for a project. To describe whether it’ll be
cost effective, will realize the benefits that the expected, & be technically feasible.
Feasibility study provides an opportunity to identify risk there fore project can plan to
gain better understanding of the time & resources that’ll be required in the full project so
that a better project plan can be produced.
Feasibility study mainly contribute for feasibility factors
This evaluation determined whether the technology needed for the proposed system is
available & how it can be integrated with the organization. Technical feasibility must
consider weather the existing system can be upgraded to use in the new technology.
This evaluation looks at the financial aspects of the project. It determines whether the
investment needed to implement will be recover. And it also consider weather the project
goals can be achieve within the resource allocate the project.
This determines whether this project violate law in the country or international trade
An evaluation to determine whether the system is operationally acceptable. It also
determines how the proposed system will fit with current operation system.
4. Requirement Analysis
Requirement Analysis is concerned with discovering what the system is required to do.
Some outline requirements are know from the requirement of feasibility study. By these
are know means sufficient to start building new system. This stage utilizes the concepts
of information sources & fact finding techniques.
5. Requirement Specification
This is conceded with converting the requirement analysis stage into a specification that
reflects what the new system is required to do. It involves some further modeling
activities that looks very closely at
The functions that system is required to perform
The data that underlined required system
How data change all the time as a result of events.
6. Logical system Specification
Requirement specification stage defines what the new system is required to do but it does
not mean there is only 1 way in which the requirements could be met. There may be
several technical options that could be adapted which provides the capability by
delivering the required system, therefore system analysis decides & defines what are the
technical option then with the help of business manager select the most appropriate.
7. Logical design
This stage represent fundamental switch in focus that is interested of what is required we
start deciding how the system can be design. The logical design stage broke down the
system into a smaller system where it concentrates how the system will work rather than
too much notice to the technical architecture. This included dialogue design (screen
interface with the user of the system update process) (processors that change the system
data) Inquiry process (The extraction of useful information from the system data). This
stage has a strong involvement with the business manager & the users of the system
8. Physical design
Physical design is the stage where all design decision is made that is dependent on the
physical system architecture. The primary users of the work will be the programmer who
will implement the design within this stage the system is been broken down into logically
independent chunks. Physical design is the 1st point at which practical steps can be taken
to ensure that e performance requirements of e system will be met.
Within the coding stage the programmer simply convert the specification into an
efficient main tan programmer code according to standards using by e organization.
Usually & preferably programmer code is written in short pieces that out simple well
– defined program function. These program units are then integrated to gather.
There are several different forms of testing out of this lot we identify & main testing
Unit testing – testing the smallest program units. This is usually carried out by the
Integrated testing – This is carried out when these logically independent units are
System testing – This testing is performed considering the total system.
Setting out the developed system in the client environment can be defined as
implementation. The implementation stages consist of lot of connected activity.
New computer equipment may be needed
Users may need to be trained.
The new system should be installed on the target computer system.
Data may be needed to transfer from e old system.
The old system & the new system may need to run in parallel for a period to
ensure the new system is performing correctly.
Maintenance stage begins once the implementation is completed the maintenance stage
usually consist of
1. Corrective maintenance putting righting many errors that remain in e system. This
can be either a coding or designing or Requirement error.
2. Perfective maintenance improve the system so that it meets when needs of e
3. Adaptive maintenance – changes that are needed because of the organization or
perhaps legislation has change.
13. Phase Out
Face out occurs when it is how longer feasible to continue using e system the main reason
to face out a system is when maintenance cost of a system have rise to e point that there
more economical alternatives
System development Lifecycle modules
There is a range of different life cycle model which is developed throughout to facilitate
difference types of software project.
1. The waterfall lifecycle model
Code & Test
The waterfall life was the 1st attempt to define a life cycle. Within waterfall lifecycle model
we consider the following assumption
It is possible to divide project activity into disc red isolated stages
Each stage is completed before the next one is started.
Each stage rely on only e information provide by the previous stage
A project plan can be constructer based on mute stones represented by e
completion of each stage.
The above assumption leads to following problems of e waterfalls model.
A waterfall model assumes that all e system is developed at the same time.
Project activities are usually not as clearly defined & discrete as e model implies.
Sometimes it is necessary to repeat or iterate a group of project stages in order to fully
understand or complete e system.
There us a relationship between stages that are not next to each other in the waterfall.
The involvement & exposure of the system to e business manager is not clear with the
The waterfall model mostly concentrates on the stages rather than e final products.
Advantages of the waterfall model
It helps to identify user requirements clearly.
Each phase outcome is included in a documentation therefore it will help to do the
future modifications of the system.
Disadvantages of the waterfall model
All the activities are performed in a strict sequence one phase must be completed
before the next phase is started and no phase can be repeated therefore it is time
consuming approach. If one phase delays it will effect the entire phases of the SDLC.
2. V model
The “V” models fix some of e problems identified in waterfall but not all.
By using e waterfall we identifies e product at the end of each stage.
It also shows how there is a relationship between e problems at e early stages of the
lifecycle & the later stages.
The “V” models mainly concentrate on verification & validation.
Verification – Are we building the product right?
Validation – Are we building the right product?
The “V” model show how verification & validation activity are build in
Eg: Tested system should be based on requirement specification.
specification Project initialization Elevation Product phase-out
Specification Tested system including acceptance & handover Verified system
software design specification
Design Tested software Specification
Database & testing
Module Design Tested software Module Design
Module Design modules Debugged Module
Simple and easy to use.
Each phase has specific deliverables.
Higher chance of success over the waterfall model due to the development of test
plans early on during the life cycle.
Works well for small projects where requirements are easily understood.
Very rigid, like the waterfall model.
Little flexibility and adjusting scope is difficult and expensive.
Software is developed during the implementation phase, so no early prototypes of the
software are produced.
Model doesn’t provide a clear path for problems found during testing phases.
3. Proto typing
As we discussed earlier linier lifecycle model has same serious drawbacks in the real life.
The “V” model although better than e waterfall model but it has few problems still. That
is to identify all e user require on problem & one effective solution is to use proto types
A proto type is simplified sub set of e proposed system that simulates e actual processing
that’ll be done by e real system. Typically it consists of few screen design & reports that
provides just sufficient functionality to allow user to experience how e propose system
might look & feel. Proto types are easy to create specially in windows environment using
Gull there are special tool only for this purpose as well.
Proto types very quickly resolve misunderstanding between business manager &
Proto types make an ideal tool for defining & discussing user interaction.
Users can understand a proto type far easier than most of e standard base of
communicating requirements in e form of models.
Business manager may not understand e purpose of e proto type.
Some proto type are so realistic that they give e impression the project is almost
finished but in the reality we are in e system analysis stage
The effort require to produce a proto type may lead to quality problems as due to
inefficient time management.
Useful in proof of concept or situations where requirements and user's needs are
unclear or poorly specified. The approach is to construct a quick and dirty partial
implementation of the system during or before the requirements phase.
Identify outline Develop Evaluate Specific system
requirements prototype prototype requirements
Validate system system
Use in projects that have low risk in such areas as losing budget, schedule
predictability and control, large-system integration problems, or coping with
information sclerosis, but high risk in user interface design.
Gather requirements Build prototype Validate system
NO Is system YES Deliver
Incremental development Prototyping
In this method system components are incrementally developed and delivered with in
the frame work.
Define system Design the system Specify the system Build the system
deliverables architecture increments increments
System Validate System Integrate Validate
complete Increments Increments
4. Spiral lifecycle model
Template for a spiral round
Objectives – Procure software component catalogue
Constraints – Within a year. must support existing component types Total cost less
than $100, 000
Alternatives – Buy existing information retrieval software, Buy database and develop,
catalogue using database, Develop special purpose catalogue
Risks – May be impossible to procure within constraints, Catalogue functionality may
Risk resolution – Develop prototype catalogue (using existing 4GL and an existing
DBMS) to clarify requirements. Commission consultants report on existing
information retrieval system capabilities. Relax time constraint
Results – Information retrieval systems are inflexible. Identified requirements cannot
be met. Prototype using DBMS may be enhanced to complete system Special purpose
catalogue development is not cost-effective
Plans – Develop catalogue using existing DBMS by enhancing prototype and
improving user interface
Commitment –Fund further 12 month development
Good for large and complex projects
Customer Evaluation allows for any changes deemed necessary, or would allow for
new technological advances to be used
Allows customer and developer to determine and to react to risks at each evolutionary
Direct consideration of risks at all levels greatly reduces problems
Difficult to convince some customers that the evolutionary approach is controllable
Needs considerable risk assessment
If a risk is not discovered, problems will surely occur
5. Dynamic system development methodology (DSDM)
In early 1990s the information technology trade has become more and more aware of
rapid application development which gave some excitant pointers as to how to make the
concept but to use them often meant buying the vendor’s process as well. Because of this
as a block to the growth of successful and fast solution delivery, Dynamic system
development methodology (DSDM) consortium was inaugurated in January 1994 with an
aim of producing a public domain. DSDM first version published in early 1995. Latest
version is 4.2 was published in 2003 by the DSDM consortium.
Feasibility Study; an assessment is made as to whether or not the DSDM approach is
correct for the anticipated project.
Business Study; Provides the foundations on which all subsequent work is based and
provides an understanding of the business and technical constraints. (This study is
intended to be relatively short with the aim to describe a 'first-cut' high level
Functional model; this activity is broadly equivalent to a functional specification, but
expressed using an executable prototype with some documentation support.
Design and build; this activity is refining the functionality to reflect non-functional and
other quality/integrity requirements the detailed designs are as executable prototypes but
with improving quality attributes, supported by essential documentation.
Implement: this activity is applying the product within a series of systems trials
ultimately being accepted in the operational environment.
An importance on testing is so strong that at least one tester is expected to be on each
Designed from the ground up by business people, so business value is identified and
expected to be the highest priority deliverable.
Has specific approach to determining how important each requirement is to iteration.
Sets stakeholder expectations from the start of the project that not all requirements
will make it into the final deliverable.
Probably the most heavyweight project compared in this survey.
Expects continuous user involvement.
Defines several artifacts and work products for each phase of the project; heavier
Access to material is controlled by a Consortium, and fees may be charged just to
access the reference material
6. Rapid Application Development (RAD) Methodology
RAD (rapid application development) proposes that products can be developed faster and of
higher quality by:
Using workshops or focus groups to gather requirements.
Prototyping and user testing of designs.
Re-using software components.
Following a schedule that defers design improvements to the next product version.
Keeping review meetings and other team communication informal.
Buying may save money compared to building
Deliverables sometimes easier to port
Development conducted at a higher level of abstraction
Greatly reduced manual coding
Increased user involvement
Shorter development cycles
Standardized look and feel
Buying may not save money compared to building
Cost of integrated toolset and hardware to run it
Harder to gauge progress
Loss of scientific precision
May accidentally empower a return to the uncontrolled practices of the early days of
Prototype may not scale up, a B-I-G problem
Reliance on third-party components may ...
Requirements may not converge
Standardized look and feel
7. JAD (Joint Application Development)
Who is involved in a JAD?
Sponsor - this is the executive who charters the project, the system owner. They must be
high enough in the organization to be able to make decisions and provide the necessary
resources and support for the project.
Business Users - the intended users of the system being designed. They are here because
of their business expertise. There are two kinds of Business Users; Real End Users and
Big Picture Users.
Real End Users will have to use the new system to do their jobs. Big Picture Users
understand the standards and methodologies of the business functions. It is important to
have both types of users, if you only have Big Picture Users you will end up with a great
theoretical model of how things should work, but it may not work in practice, if you just
have Real End Users, you will get a good system for today, but it may not work a year or
two down the road.
Systems Analysts - Provide non-technical explanations that help other JAD members
understand and fully utilize the technology available. Monitor design for ease of
use/maintenance and adherence to standards. Provide Hardware/software development.
JAD actively involves users and management in the development project.
(Encouraging them to take “ownership” in the project). No of people involve with the
JAD session therefore can get different opinion from them
JAD reduces the amount of time required to develop systems. This is achieved by
replacing traditional, time-consuming one-on-one interviewing of each user and
manager with group meetings. The group meetings allow for more easily obtaining
consensus among the users and managers, as well as resolving conflicting information
When JAD incorporates prototyping as a means for confirming requirements and
obtaining design approvals, the benefits of prototyping are realized.
More people in JAD team meets less time available for all of them to speak
Some people are afraid to speak for fear that they will be criticized.
System Analysis Tool & Techniques
There are several modeling techniques that appear in structured methodology. It’s Important
to have are familiarity with them and how they are used. When conceding SSADM we can
use some of the below techniques as modeling techniques. Basically modeling tools helps to
represent different components in a system. Following are e 2 main modeling techniques
used by e structured methodology
1. Data flow Diagram (DFD)
2. Entity Relationship Diagram (ERD)
Data flow Diagram (DFD)
Data flow diagram shows how data moves in a system & where it’s stored. DFD is one of e
first type of models & they are a fundamental building block of a lot of analysis & designing
2. Data flow
4. External entity
3. Data storage
It shows e major components of e system each process many linked with a number of
different inputs & outputs.
Process identification No Location where the Process
Data flow is represented by an arrow where e arrow heap points the direction a data flow will
be place between 2 symbols of DFDS
Process External Data
Process √ √ √
External Entity √ X X
Data storage √ X X
External entities are components which are outside the system boundary which provide input
of e system or get output from e system. External entities which supply information into e
system are called “source” & e external entities which use e system data are called “sink”
Name of e external entity
Data storages are used as storages in e system. They are referred as files
Data storage No
Data store Name
Data store type
D1 Student file
D – Computer file
M – Manual file
Data flow diagram rules.
There is a set of rules of thumb which followed when drawing DFDS. The rules are
No process can have only input. If an object have only input then that must be an
external entity (sink).
No process can have only output. If an object has only output then it must be an
external entity (source).
Data cannot be move directly from out side to data storage. It needs to move through
Data cannot be moved directly from external entity to another external entity. It needs
to go through a process.
Data flow cannot go directly to e same process.
Data flow to data storage means update
Data flow from data storage means retrieve
When these models used in practical situation some components like External entities & data
storages need to be duplicated. Therefore we can use symbols as follows.
Data flow Diagram levels
It mainly consists of 3 levels.
1 Context diagram (Level 0 DED)
2 Level 1 DFD (Top-level DFD)
3 2nd Level DFD (Level 2 DFD)
Data modeling is a technique for organizing & documenting system data. Entity relationship
diagram (ERD) is one of e common data modeling techniques.
The ERD Diagram is a tool used for designing data models. It is commonly used tool to
present graphical representation on data entities & their relationships. ER Diagrams modeled
data in e same entities in ER Diagram are usually related to objects or events & e
relationships are typically common data associations or links between entities. There fore ER
Diagrams are graphical illustrations use to design data, Objects or events within a system &
their relationship to one another.
Basic Notation & term of ER Diagram
Basic Systems of an ER diagram
Attributes Primary key Primary key
Classes of a person, Place, object & events about which we need to compare & store data are
called as entities
Eg : Student , Book, Course, Department.
Rectangular box symbols represent entities. There can be 2 types of entities
Super type Entity
It is an entity that store attributes that are common to one or more sub entity types
Sub type Entity
Sub type entity is entities that inherit some common attributes from an super entity
type. Sub entity can be represented by a rectangular box separated by a line.
Attributes are the properties of entities & relationships, in other attributes are used to
describe entities & relationship in e ER Diagram. An entity has many attributes therefore, it
needs to identifier. A key is attribute / group of attributes which we can use to identify an
Relationships are e integration with an entity (It specifies what an entity has to do with
another. A diamond symbol is used to represent a relationship in ER Diagram.
Information gathering techniques or fact finding technique
They are interviews, questionnaires, observation record searching, prototyping & sampling.
To use the above fact finding techniques we have to identify fact sources, different types of
information’s are available within a system. These information’s sources provide different
information & require different searching methods to get that information
Most common information sources are
1. System users
2. Existing computer system
3. Forms & documents
5. Procedure manuals or user manuals.
1. System users
Users are categorized in to sections as follows considering typical organization.
Management level users
They are not directly involves with the system unless the system has a major
change. They do allocate resources for the system. They were using this to make
long term decisions.
Supervisor level users
They have to manage operational users and provide information to the
management level. Basically they are concerned with operational efficiency of the
Operational level users
They have direct contact with the system (hands on) & they use the system to day
to day operational of a business
2. Existing computer program
Existing computer program can be use to determine the details of data & the processes
used by the system & the analysis is required to analyse the current user interface & if
possible to maintain the same in the new system as well.
3. Forms & documents
Investigation forms and documents in the system are useful to determined system data
follows and transactions.
Reports are use mostly to identify outputs of the system. These reports can be hourly,
daily monthly or yearly generated.
5. Procedure manuals & user manuals
These are used by system analysis to study user activities & to concentrate on how it is
being handle, which will be important in the system designing stage.(Ensure the latest
updated manuals are examine)
Fact finding technique
Interviewing is the one of the most common method in fact finding. It brings the analysis
into a direct contact with the users where he gets an opportunity to listen to the opinions
(advantages & disadvantages) about the existing system & also to identify the issues &
propose solutions regarding the new system.
Interview is a very effective fact finding techniques. But the main problem is that it
requires a – lot of resources, especially time. So it is very important to plan the interview
before hand & the analysis is required to have considerable amount of skills.
Interviews need a start from the top level management to get permission & also get an
overview idea about the total system. Then the interview process can be move to which
will provide more & more specific details.
Interviews are not required to find out how exactly a system should work, but it needs to
determine the needs of the users that we have to satisfy with a new system.
The success of the interview depends upon the skills of the interviewer & the preparation for
Choose the person who is mostly appropriate for the interview.
Interpersonal relationship between the interviewer & the interviewee
Preparation for the interview
Correct sequences of questions.
Setting a proper date, time, venue & the topic
These factors should include in an interview plan before conducing it. There are 3 types of
questions usually asked in an interview.
Open Questions – General questions that relates with the personal view on the subject.
Closed Questions – Question that is needed direct answer.
Probes Questions – Question that follows with the earlier answer.
Interviews are normally held in an organization in friendly manner. A question should follow
a logical order. When conducting an Analysis or interviewer should process the following
- He should be a good listener
- He should respect user needs & position
- He should try to get the solution from the user rather than being an advisor to him
- He should respect user ideas & suggestions
- He should design the question in a way where he can gather more information from the
An actual interview process consist of 3 faces
Opening face include - introduction, preparation for the interview objects of the interview.
Body of the Interview - Obtain interviews response to the analysis list of question
Conclusion -Summarize the finding & verify the summary 7 arrange the next
interview date if necessary.
Advantages of interview
Results can be produced in a short period of time
Easy to evaluate result
It allows the analysis to look for more feed back from the user
New ideas may arise.
Disadvantages of interview
Cost of preparation is high.
Success of the interview is highly depending on the system analysis skill.
May not be suitable for all satiation.
These are special purpose document that allows the system analysis to collect information
from the user. These document can be produced & distributed to the user (responders)
who can then complete the questionnaire on the own time. Questionnaires allow the
analysis to collect fact from large no. of people.
Advantages of Questionnaires
Most questions can answer quickly.
Response will be given enough time to search the required facts & to answer the
Can gather information form a large set of users.
Responders may provide correct answer because he will not be identify
Disadvantages of Questionnaires
No of respondents often low
No of guarantee that the individual will answer all the questions
Mostly suitable for closed type of questions.
A good questionnaire is difficult to prepare & it’ll take long time.
In this fact finding technique where the system analysis either participating or watching
the activities performed by the user & trying to gather information of the system. Mainly
observation categorized into 2.
Formal Observation – Observation person by him being noticed.
Informal Observation – Observing a person without him being noticed.
This is not an ethical practice.
This observation can be carried out by setting an employee at work or by using video
tapes and cameras.
Advantages of the Observation
The system analysis able to see exactly what is been done
Complex task are sometimes difficult to clearly explain in words. Through observation &
analysis can identify complex task easily
Observation is relatively inexpensive compared with other fact finding techniques
Other techniques usually require more employees and more time.
Observations are sometime used to check the velocity of e data obtained from other fact
Disadvantages of the Observation
While trying to gather information the person has been observed may not act in his
This may involve studying a subset documents or subset of e- activity in the aria in order
to get an impression of the whole activity or document set. It is useful to verify findings
from interviews or the above discussed techniques.
Eg: Studying customer bills & invoices filling orders for an hour peak sampler 3 or 4
class. And observe for a special period of time to get information.
5. Record Searching
Through record searching we can get coordinative information such as volume,
techniques & essential data. This can be used check the estimate made by the user.
Documentation & Coding Standards
Standards are very component when thinking about system development. There are 6
different types of standards.
Industries bodies & Organizations
To come up with good documentation following are key points to be considered with. These
significant requirements need to be managed & implement to gain good quality
A Documentation is useless unless is possible to access. When comes to technical
documentation is novel. Users need to find e required part / appropriate section to
solve the specific problem. A good documentation should have
A clear Structure
Table of contain
A detailed index
Pointers to other relevant documents
To be catalogs
There is no single style that can be used for all documents, all documentation should
be written to use for the profile of expected reader. And impersonal active styles may
be appropriate for a lot of system documentation but user documentation should be
written in a more personal voice & should not assume technical expertise
Documentation is intended to convey information. It can only do this if the reader is
aide to comprehend the complementation is based partly on style but also strongly on
e assumption made by author about e experience & expertise of e user. The writer
should be a very clear idea about what can be assumed about the reader.
Documentation should be viewed as just another product of e development lifecycle.
It means it needs to be subject to full verification & validation process, where we
need to check.
Is this e right think to document?
Is this documentation correct?
Correctness requires testing by means of rearview .No documentation should ever be
release without such a review because even e best documenter make mistakes & they
can rarely find such mistakes them self.
All e products of software development lifecycle are subject to change & this
includes documentation. Extreme can be cause by mixing of different & incomplete
version & program code documentation & any other deliverable. For this reason most
large product uses version control system. This is called as “check – code & check
out is to update e documentation. Therefore e relationship with e product & e
document will be in a consistent level.
A single program functions should be limited to a one page of code.
Variable should be named according to a convention.
Assuming about Hardware should be limited.
All functions should contain an internal document ( comment)
Functions should communicate with rest of the system in a tightly defined manner.
A decision table takes the basic constructs of sequence selection & reparation &
present them as question (condition) & e answer or things to do (actions) in a form of
Condition Stub-In condition stub we list out all the possible conditions for this
situation. One row is used for per condition.
Condition Entries- Here we have to list all the possible combination for the listed
Combination = 2 Conditions
Eg: Condition = 22 = 4(where condition = 2)
Each combination is allocated per column & this need to fill by e notation “Y” or
Action Stub-All e possible actions for e situation is identified. One row is occupied by
Action Entries-As explained in the situation considering e combination of condition
must mark e correct action, by a “X”
Any activity that checks by means of actual execution whether a system or component
behaves in the desired manner. Testing is a costly process but it will add value to system by
increasing reliability or been more suitable to the client environment. It discovers and
rectifies errors. Objective is to find the most cost effective test available to uncover the errors
in the system by ‘breaking ‘it
A good test
A successful test is one that finds a new error
A good test is one that has a higher probability of finding a new error
Make products and adds Quality to them.
Is the process of demonstrating that errors are not present
Show that a program performs its intended functions properly
Is the process of establishing confidence that a program does what it is supposed to do
Types of testing
Unit testing – testing the smallest program units. This is usually carried out by the
Integrated testing – This is carried out when these logically independent units are
integrated.(Top down & bottom up)
System testing – This testing is performed considering the total system.
Acceptance testing – This testing is doing by the system users to accept the system.
Black box testing
White box test