System analysis and_design

Rizwan ShaikhRizwan Shaikh
INDEXINDEX
Sr.NoSr.No TopicTopic PagePage
No.No.
1.1. Introduction To SAD.Introduction To SAD. 1-71-7
2.2. Approaches To System DevelopmentApproaches To System Development 8-238-23
3.3. Analysis :Investigating SystemAnalysis :Investigating System
RequirementsRequirements
24-3324-33
4.4. Feasibility AnalysisFeasibility Analysis 34-4434-44
5.5. Modeling System RequirementsModeling System Requirements 45-6545-65
6.6. DesignDesign 66-8666-86
7.7. Designing Input, Output And UserDesigning Input, Output And User
InterfaceInterface
87-9087-90
8.8. TestingTesting 91-10391-103
9.9. Implementation And MaintenanceImplementation And Maintenance 104-112104-112
10.10. DocumentationDocumentation 113-118113-118
11.11. Software DocumentsSoftware Documents 119-122119-122
12.12. Question AnswerQuestion Answer 123-127123-127
13.13. University Question PapersUniversity Question Papers 128-129128-129

1.Introduction To System Analysis And Design1.Introduction To System Analysis And Design
 System :
A system is an organized relationship among functioning components/units.
It is an orderly grouping of interrelated components linked together to achieve a specific
objective.
It exists because it is designed to achieve one or more objectives.
E.g.: Payroll system, Computer system, Business system (Organization).
 Super System :
A system that is made up of sub-systems or smaller systems is called a super system.
 Characteristics Of A System:
1. Organization
a. It implies the structure and order of a system.
b. It is the arrangement of components that helps to achieve a given objective.
E.g. (I) In a business system, the hierarchical relationship starting with the management
(super system) at the top, leading downwards to the departments (sub systems) represents
the organization structure.
E.g. (II) In a computer system, there are input devices, output devices, a processing unit,
storage devices linked together to work as a whole to produce the required output from the
given input.
2. Interaction
Interaction refers to the manner in which each component of a system functions with other
components of a system.
E.g.: There must be interaction between (i) the purchase dept and the production dept (ii)
the payroll dept and the personnel dept (iii) CPU with the I/O devices.
3. Interdependence
a. Interdependence defines how different parts of an organization are dependent on one
another.
b. They are coordinated and linked together according to a plan (i.e., the output of one
subsystem may be the input of another subsystem).
2

E.g.: User -> Analyzer -> Programmer -> User/Operator. Here, a system is designed for
the user, but it requires an analyzer to analyze it, and then it requires coding by the
programmer and testing by the user.
4. Integration
a. Integration refers to the completeness of a system.
b. It means that subsystems of a system work together within a system even though
each subsystem performs its own unique function.
5. Central Objective
The objective of a system as a whole is of more importance as compared to the objectives
of any of its individual subsystem.
 Elements Of A System:
1. Input/Output
a. One of the major objectives of a system is to produce output that has some value to the
user using given input.
b. Input: It is the data or information which is entered into the system.
c. Output: It is the outcome after processing the input.
2. Processor
a. It is an element of the system that performs the actual transformation of input into
output.
b. It may modify the input partially or completely.
3. Control
a. The control element guides the system.
b. It is a decision-making subsystem that controls the pattern of activities related to the
input, processing and output.
E.g.: The management is the decision-making body that controls the activities of an
organization, just as the CPU controls the activities of the Computer System.
4. Environment
It is the surroundings in which a system performs.
E.g.: The users and vendors of a system work form the environment of that system.
3

5. Boundaries
a. A system should be defined by its boundaries i.e. limits that identify components and
processes related to the system.
E.g.: The limitation of the payroll system can only calculate salary.
b. An Automation Boundary is a boundary that separates manual processes from
automated processes.
E.g.: Entering basic code for salary is a manual process while the actual calculation
of the salary is an automated process.
6. Feedback
a. It implies user’s response to a system.
b. It provides valuable information about what improvements and updates can be applied
to the system.
 Difference Between S/W System Development & Other System Development :
The Software Systems Development is different from other types of systems development.
The major factors which widen these differences are as follows :-
a. The Software is an intangible product. It is to be conceived only conceptually until a
very later stage of system development viz. the coding stage.
b. Almost every software system being developed in the world is different from its
predecessors in many aspects. Some of the aspects that change quite often are the
business domain, the technology domain, and the process of software development.
c. As a result of the above, it is very rare to find a software systems development
professional working on very similar software development projects consecutively for a
long time. In fact, if the developer was not required to work on a variety of software
systems development projects, (s)he should introspect to assess his/her progress in
the career and if needed, plan to improve future career opportunities at the earliest.
d. The technological evolutions are much faster in software systems development area for
last three decades, than any other area. The rate obsolescence is also very high. This
has a major impact not only on the number of new software architectures evolving
4

each year, but also the underlying “process” of developing software systems is also
evolving at equally fast rate.
Organization :
An organization consists of interrelated departments.
E.g.: Marketing Dept, Production Dept, and Personnel Dept.
Org -> Management -> Dept
Component :
A component may be a physical component or a managerial step.
The wheels, engine, etc. of a car are examples of Physical components.
Planning, organizing, controlling activities are examples of Managerial steps.
A component may also be classified as simple or complex.
A simple computer with one Input device and one Output device is an example of a simple
component.
A network of terminals linked to a mainframe is an example of a complex component.
Information System:
An information system is a collection of interrelated components which input data, process
it and produce the
output required to complete the given task.
 Types Of Information Systems :
1. Transaction Processing System :
The information system that captures or records the transactions affecting a
system/organization.
E.g.: Organizations have financial packages tracking their financial activities.
2. Management Information System (MIS):
This information system uses information captured by the Transaction Processing System
for purposes like planning, controlling.
E.g. (I) An entire day’s transaction that is compiled by the Transaction Processing
System can be documented into MIS reports.
5

E.g. (II) Cell Phone companies have a billing department which keeps track of very call
received or made using the MIS.
3. Executive Information System (MIS):
This information system provides information for executives for planning economic
forecast.
E.g.: Constant stock updates given by news channels.
4. Communication Support System :
This support system allows employees, customers, clients to communicate with one
another.
E.g.: Employees of an organization can e-mail each other. Some organizations have
specially allotted e-mail addresses for their employees of various departments as also their
clients and customers.
5. Decision Support System (DSS) :
Decision – emphasis decision making in problem situation, not information processing,
retrieval, or reporting.
Support – requires computer-aided decision situations with enough “structure” to permit
computer support.
System – accentuates the integrated nature of problem solving, suggesting a combined
“man”, machine, and decision environments.
 SYSTEM ANALYSIS AND DESIGN
System is an orderly grouping of interdependent components linked together according to
a plan to achieve a specific objective.
System analysis and design refers to the process of examining a business situation with
the intent of improving it through better procedures and methods.
System development can generally be thought of as having two major components :
(1)Systems analysis and (2)Systems design.
Systems design is the process of planning a new business system or one to replace or
complement an existing system but before this planning can be done, the old system must
6

be thoroughly understood and determine how computers can best be used (if at all) to
make its operation more effective.
System Analysis is the process of gathering and interpreting facts, diagnosing problems
and using the information to recommend improvements to the system.
This is the job of the system analyst.
 THE MULTIFACETED ROLE OF THE ANALYST
1. Change Agent/Agent of change :
Persuader (the mildest form of intervention)
Imposer (the most severe intervention)
Catalyst (in between the above two types)
The goal is to achieve acceptance of the candidate system with a minimum of
resistance.
2. Investigator and monitor
Investigator – Information is gathered and put together and studied to determine why
the present system does not work well and what changes will correct the problem.
Monitor – the analyst must monitor programs in relation to time, cost and quality.
Time is the most important, if time “gets away” project is delayed and eventually cost is
increased.
7

3. Architect:
Architect – function as liaison between the clients abstract design requirements and
the contractor’s detailed building plan.
Analyst – The user’s logical design requirements and the detailed physical system
design.
As architect, the analyst also creates a detailed physical design of candidate systems.
He/she aids users in formalizing abstract ideas and provides details to build the end
product - the candidate system.
4.Psychologist
Analyst plays the role of a psychologist in the way he/she reaches people, interprets
their thoughts, assesses their behavior, and draws conclusions from these interactions.
Understanding interventional relationships is important.
5.Salesperson:
Selling change
Selling ideas
Selling the system takes place at each step in the system life cycle.
Sales skills and persuasiveness are crucial to the success of the system.
6.Motivator
Candidate system must be well designed and acceptable to the user.
System acceptance is achieved through user participation in its development, effective
user training and proper motivation to use the system.
Motivation is obvious during the first few weeks after implementation.
If the user’s staff continues to resist the system then it becomes frustrating.
7.Politician
Diplomacy & finesse in dealing with people can improve acceptance of the system.
Politician must have the support of his/her constituency, the analyst’s goal to have the
support of the user’s staff.
He/she represents their thinking and tries to achieve their goals through
computerization.
 REQUIREMENTS OF A GOOD SYSTEMS ANALYST:
8

System Analyst :
A person who conducts a methodical study and evaluation of an activity such as a
business to identify its desired objectives in order to determine procedures by which these
objectives can be gained.
The various skills that a system analyst must posses can be divided into two categories
1) Interpersonal skills
2) Technical skills
Interpersonal skills deal with relationships and the interface of the analyst with people in
business.
Technical skills focus on procedures and techniques for operations analysis, systems
analysis, and computer science.
 Interpersonal skills include:
1. Communication :
He/she must have the ability to articulate and speak the language of the user, a “flare”
for mediation, and a knack for working with virtually all managerial levels in the
organization.
2. Understanding:
Identifying problems and assessing their ramifications. Having a group of company
goals and objectives and showing sensitivity to the impact of the system on people at
work.
3. Teaching:
Educating people in use of computer systems, selling the system to the user and giving
support when needed.
4. Selling:
Selling ideas and promoting innovations in problem solving using computers.
 Technical skills include:
1. Creativity:
9

Helping user’s model ideas into concrete plans and developing candidate systems to
match user requirements.
2. Problem solving:
Reducing problems to their elemental levels for analysis, developing alternative
solutions to a given problem, and delineating the pros and cons of candidate systems.
3. Project management:
Scheduling, performing well under time constraints, coordinating team efforts, and
managing costs and expenditures.
4. Dynamic interface:
Blending technical and non-technical considerations in functional specifications and
general design.
5. Questioning attitude and inquiring mind:
Knowing the what, when, why, where, who and how a system works.
6. Knowledge of the basics of the computer and the business
function :
The above skills are acquired by a system analyst through his/her education,
experience and personality.
 Educational Background Of System Analyst :
1. He/she must have knowledge of systems theory and organization behavior.
2. Should be familiar with the makeup and inner workings of major application areas such
as financial accounting, personnel administration marketing and sales, operations
management, and model building and production control.
3. Competence in system tools and methodologies and a practical knowledge of one or
more programming and data base languages.
4. Experience in hardware and software specification which is important for selection.
 Personal Attributes Of System Analyst :
10

1. Authority:
The confidence to tell people what to do. Project management and to get the team to
meet deadlines is the result of this quality.
2. Communication Skills:
Ability to articulate and focus on a problem area for logical solution.
3. Creativity :
Trying ones own ideas. Developing candidate systems using unique tools or methods.
4. Responsibility:
Making decisions on ones own and accepting the consequences of these decisions.
5. Varied skills:
Doing different projects and handling change.
****************
myitbrains@gmail.com
11

2.Approaches To Software System Development2.Approaches To Software System Development
1. Structured Approach
2. Object-Oriented Approach
3. Information Engineering Approach
 Structured Approach :
Structured Approach is made up of three techniques :
(1) Structured Programming :
• A structured program is a program that has one beginning, one end, and each step in
program execution consists of one of the three programming constructs: (a) A
sequence of program statements (b) A decision where one set of statements executes,
or another set of statements executes (c) A repetition of a set of statements.
• Top down Programming divides complex programs into a hierarchy of program
modules, where each module is written using the rules of structured programming, and
may be called by its top-level boss module as required.
• Modular Programming : If the program modules are separate programs working
together as a system (and not part of the same program), then these programs are
organized into a top-to-bottom hierarchy; in that case, if multiple programs are involved
in the hierarchy, then the arrangement is called modular programming.
(2) Structured Design, together call SADT i.e. Structured Analysis &
Design Techniques
• Definition: Structured Design is a technique that provides guidelines for deciding what
the set of programs should be, what each program should accomplish, and how the
programs should be organized into a hierarchy.
• Principles: Program Modules should be (a) loosely coupled i.e. each module is
as independent of the other modules as possible and thus easily changeable and (b)
highly cohesive i.e. each module accomplishes a clear task.
12

• User Interface Design is done in conjunction with Structured Design.
• Structure Chart: It is a graphical model showing hierarchy of program modules
produced in structured design.
(3) Structured Analysis :
• Definition: Structured Analysis is a technique that helps define what the system needs
to do (processing requirements), what data the system needs to store and use (data
requirements), what inputs and outputs are needed, and how the functions work
together overall to accomplish required tasks.
• Data Flow Diagram (DFD): It is a graphical model showing inputs, processes, storage,
outputs of a system produced in structured analysis.
• Entity Relationship Diagram (ERD): It is a graphical model of the data needed by the
system, including entities about which information is stored and the relationships
among them, produced in structured analysis.
 Weaknesses of Structured Approach :
Structured Approach makes processes the focus rather than the data.
 Object-Oriented Approach :
• Definition: Object-Oriented Approach to system development is an approach that
views an information system as a collection of interacting objects that work together to
accomplish a task.
• Object: It is a programmatic representation of a physical entity, that can
respond to messages.
13

• Object-Oriented Analysis: It involves defining all types of objects that do
work in the system, and showing how the objects interact to complete required tasks.
• Object-Oriented Design: It involves defining all additional types of objects
necessary to communicate with people and devices in the system, redefining each type
of object so it can be implemented with a specific language or environment.
• Object-Oriented Programming: It involves writing statements in a programming
language to define what each type of object does, including the messages the objects
send to each other.
• Class: It is a collection of similar objects, and each class may have specialized
subclasses, and/or a generalized superclass.
•Class Diagram: It is a graphical model that shows all the classes of objects in the
system-oriented approach.
Advantages Of Object-Oriented Approach :
(a) Naturalness (looks at the world in terms of tangible objects and not complex
procedures) &
(b) Reuse (classes can be used again and again whenever they are needed).
 Drawbacks Of Object-Oriented Approach :
Since it is drastically different from the traditional approach, it is sometimes difficult to
understand.
 Information Engineering Approach
• Definition: Information Engineering Approach is a system development approach that
focuses on strategic planning, data modeling, and automated tools.
14

• Advantage over Structured Approach: More rigorous and complete than Structured
Approach and the focus is more on data than on processes.
• Strategic Planning: It defines all information systems the organization needs to conduct
its business, using the Architecture Plan.
• Architecture Plan: This plan defines business functions and activities the system needs
to support, the data entities about which the system needs to store information, and
the technological infrastructure the organization plans to use to support the
information system.
• Process Dependency Diagram: It focuses on which processes are dependent on
other processes.
• CASE Tool: It helps automate work by forcing the analyst to follow the I.E.
Approach (sometimes at the expense of flexibility).
 System Development Life Cycle :
The System Development Life Cycle (SDLC) is a method of System Development
that consists of 5 phases: Planning, Analysis, Design, Implementation, and Support. The
first four phases of Planning, Analysis, Design and Implementation are undertaken during
development of the project, while the last phase of Support is undertaken post-completion
of the project. Each phase has some activities associated with it, and each activity may
have some tasks associated with it.
1. Planning Phase
Following are the activities of the Planning Phase:
i] Define the Problem
- Meeting the Users
- Determine scope of Problem
- Define System capabilities
ii] Confirm Project Feasibility :
- Identify intangible costs & benefits
- Estimate tangible, developmental, & operational costs
- Calculate NPV, ROI, Payback
- Consider technical, cultural, schedule feasibility of the Project
15

iii] Plan Project Schedule (Chart out a complete project schedule, including the activities
and tasks of each phase.)
iv] Staff the Project (Provide required staff, such as the Analysts, the Programmers, the
End-Users, etc.)
v] Launch the Project (Begin actual work on the Project)
2. Analysis Phase :
Following are the activities of the Analysis Phase:
i] Gather information
- Meet the User to understand all aspects of the Problem
- Obtain information by observing business procedures, asking questions to user,
studying existing documents, reviewing existing systems, etc.
ii] Define System Requirements (Review & analyze obtained information and structure it
to understand requirements of new system, using graphical tools.)
iii] Build Prototype for Discovery of Requirements (Build pieces of System for Users to
review)
iv] Prioritize Requirements (Arrange requirements in order of importance)
v] Generate & Evaluate alternatives (Research alternative solutions while building
system requirements.)
vi] Review recommendations with Management (Discuss all possible alternatives with
Management and finalize best alternative)
2. Design Phase :
Following are the activities of the Design Phase:
i] Design & Integrate Network (Understand Network Specifications of Organization, such as
Computer equipment, Operating Systems, Platforms, etc.)
ii] Design Application Architecture
- Design model diagrams according to the problem
- Create the required computer program modules
iii] Design User Interfaces (Design the required forms, reports, user screens, and decide on
the sequence of interaction.)
iv] Design System Interface (Understand how the new system will interact with the existing
systems of the organization)
16

v] Design & Integrate Database (Prepare a database scheme and implement it into
the system) .
vi] Build Prototype for Design Details (Check workability of the proposed design
using a prototype.)
vii] Design & Integrate System Controls (Incorporate facilities such as login and
password protection to protect the integrity of the database and the application
program.)
3. Implementation Phase :
Following are the activities of the Implementation Phase:
i] Construct Software Components (Write code for the design, using programming l
languages such as Java, VB, etc.)
ii] Verify & Test Software (Check the functionality of the software components.)
iii] Build Prototype for Tuning (Make the software components more efficient using a
prototype, to make the system capable of handling large volumes of transaction.)
iv] Convert Data (Incorporate data from existing system into new system and make sure it
is updated and compatible with the new system.)
v] Train & Document (Train users to use the new system, and prepare the documentation.)
vi] Install Software (Install the software and make sure all components are running properly
and check for database access.)
4. Support Phase :
Following are the activities of the Support Phase:
i] Provide support to End-Users (Provide a helpdesk facility and training programs, to
provide support to end users.)
ii] Maintain & Enhance new System (Keep the system running error-free, and
provide upgrades to keep the system contemporary.)
 Classic Lifecycle Model :
This model is also known as the waterfall or linear sequential model. This model demands
a systematic and sequential approach to software development that begins at the system
17

level and progresses through analysis, design, coding testing and maintenance. Figure 1.1
shows a diagrammatic representation of this model.
The life-cycle paradigm incorporates the following activities:
System engineering and analysis : Work on software development begins by
establishing the requirements for all elements of the system. System engineering and
analysis involves gathering of requirements at the system level, as well as basic top-level
design and analysis. The requirement gathering focuses especially on the software. The
analyst must understand the information domain of the software as well as the required
function, performance and interfacing. Requirements are documented and reviewed with
the client.
Design: Software design is a multi-step process that focuses on data structures, software
architecture, procedural detail, and interface characterization. The design process
translates requirements into a representation of the software that can be assessed for
quality before coding begins. The design phase is also documented and becomes a part of
the software configuration.
18

Coding: The design must be translated into a machine-readable form. Coding performs
this task. If the design phase is dealt with in detail, the coding can be done mechanically.
Testing : Once code is generated, it has to be tested. Testing focuses on the logic as well
as the function of the program to ensure that the code is error free and that o/p matches
the requirement specifications.
Maintenance : Software undergoes change with time. Changes may occur on account of
errors encountered, to adapt to changes in the external environment or to enhance the
functionality and / or performance. Software maintenance reapplies each of the preceding
life cycles to the existing program.
The classic life cycle is one of the oldest models in use. However, there are a few
associated problems.
Some of the disadvantages are given below.
1. Real projects rarely follow the sequential flow that the model proposes. Iteration always
occurs and creates problems in the application of the model.
2. It is difficult for the client to state all requirements explicitly. The classic life cycle
requires this and it is thus difficult to accommodate the natural uncertainty that occurs
at the beginning of any new project.
3. A working version of the program is not available until late in the project time span. A
major blunder may remain undetected until the working program is reviewed which is
potentially disastrous.
In spite of these problems the life-cycle method has an important place in software
engineering work. Some of the reasons are given below.
1. The model provides a template into which methods for analysis, design, coding, testing
and maintenance can be placed.
2. The steps of this model are very similar to the generic steps that are applicable to all
software engineering models.
19

3. It is significantly preferable to a haphazard approach to software development.
 Prototype Model :
Often a customer has defined a set of objectives for software, but not identified the detailed
input, processing or output requirements. In other cases, the developer may be unsure of
the efficiency of an algorithm, the adaptability of the operating system or the form that the
human-machine interaction should take. In these situations, a prototyping approach may
be the best approach. Prototyping is a process that enables the developer to create a
model of the software that must be built. The sequence of events for the prototyping model
is illustrated in figure 1.2. Prototyping begins with requirements gathering. The developer
and the client meet and define the overall objectives for the software, identify the
requirements, and outline areas where further definition is required. In the next phase a
quick design is created. This focuses on those aspects of the software that are visible to
the user (e.g. i/p approaches and o/p formats). The quick design leads to the construction
of the prototype. This prototype is evaluated by the client / user and is used to refine
requirements for the software to be developed. A process of iteration occurs as the
prototype is ‘tuned’ to satisfy the needs of the client, while at the same time enabling the
developer to more clearly understand what needs to be done.
20

The prototyping model has a few associated problems.
Disadvantages:
1. The client sees what is apparently a working version of the software unaware that in the
rush to develop a working model, software quality and long-term maintainability is not
considered. When informed that the system must be rebuilt, most clients demand that
the existing application be fixed and made a working product. Often software
developers are forced to relent.
2. The developer often makes implementation compromises to develop a working model
quickly. An inappropriate operating system or language may be selected simply
because of availability. An inefficient algorithm may be used to demonstrate capability.
Eventually the developer may become familiar with these choices and incorporate them
as an integral part of the system.
Although problems may occur prototyping may be an effective model for software
engineering. Some of the advantages of this model are enumerated below.
21

Advantages:
1. It is especially useful in situations where requirements are not clearly defined at the
beginning and are not understood both by the client and the developer.
2. Prototyping is also helpful in situations where an application is built for the first time with
no precedents to be followed. In such circumstances, unforeseen eventualities may
occur which cannot be predicted and can only be dealt with when encountered.
 Spiral Model :
The spiral model in software engineering has been designed to incorporate the best
features of both the classic life cycle and the prototype models, while at the same time
adding an element of risk-taking analysis that is missing in these models. The model,
represented in figure 1.3, defines four major activities defined by the four quadrants of the
figure :
• Planning : Determination of objectives, alternatives and constraints.
• Risk analysis : Analysis of alternatives and identification or resolution of risks.
• Engineering : Development of the next level product.
• Customer evaluation : Assessment of the results of engineering.
An interesting aspect of the spiral model is the radial dimension as depicted in the figure.
With each successive iteration around the spiral, progressively more complete versions of
the software are built. During the first circuit around the spiral, objectives, alternatives and
constraints are defined and risks are identified and analyzed. If risk analysis indicates that
there is an uncertainty in the requirements, prototyping may be used in the engineering
quadrant to assist both the developer and the client. The client now evaluates the
engineering work and makes suggestions for improvement.
At each loop around the spiral, the risk analysis results in a ‘go / no-go’ decision. If risks
are too great the project can be terminated.
In most cases however, the spiral flow continues outward toward a more complete model
of the system, and ultimately to the operational system itself. Every circuit around the spiral
22

requires engineering that can be accomplished using the life cycle or the prototype models.
It should be noted, that the number of development activities increase as activities move
away from the center of the spiral.
Like all other models, the spiral model too has a few associated problems, which are
discussed below.
Disadvantages :
• It may be difficult to convince clients that the evolutionary approach is controllable.
• It demands considerable risk assessment expertise and relies on this for success.
• If major risk is not uncovered, problems will undoubtedly occur.
• The model is relatively new and has not been as widely used as the life cycle or the
prototype models. It will take a few more years to determine efficiency of this process
with certainty.
This model however is one of the most realistic approaches available for software
engineering. It also has a few advantages, which are discussed below.
23

Advantages :
• The evolutionary approach enables developers and clients to understand and react to
risks at an evolutionary level.
• It uses prototyping as a risk reduction mechanism and allows the developer to use this
approach at any stage of the development.
• It uses the systematic approach suggested by the classic life cycle method but
incorporates it into an iterative framework that is more realistic.
• This model demands an evaluation of risks at all stages and should reduce risks before
they become problematic, if properly applied.
 Component Assembly Model :
24

Object oriented technologies provide the technical framework for a component based
process model for software engineering. This model emphasizes the creation of classes
that encapsulate both data and the algorithms used to manipulate the data. The
component-based development (CBD) model incorporates many characteristics of the
spiral model. It is evolutionary in nature, thus demanding an iterative approach to software
creation. However, the model composes applications from pre-packaged software
components called classes. The engineering begins with the identification of candidate
classes. This is done by examining the data to be manipulated, and the algorithms that will
be used to accomplish this manipulation. Corresponding data and algorithms are packaged
into a class. Classes created in past applications are stored in a class library. Once
candidate classes are identified the class library is searched to see if a match exists. If it
does, these classes are extracted from the library and reused. If it does not exist, it is
engineered using object-oriented techniques. The first iteration of the application is then
composed. Process flow moves to the spiral and will ultimately re-enter the CBD during
subsequent passes through the engineering activity.
Advantages :
• The CBD model leads to software reuse, and reusability provides software engineers
with a number of measurable benefits.
• This model leads to a 70% reduction in development cycle time and an 84% reduction
in projection cost.
Disadvantages :
• The results mentioned above are inherently dependent on the robustness of the
component library.
25

There is little question in general that the CBD model provides a significant advantage for
software engineers.
 Rapid Application Development(RAD) Model :
Rapid Action Development is an incremental software development process model that
emphasizes an extremely short development cycle. The RAD model is a high-speed
adaptation of the linear sequential model in which rapid development is achieved by using
component-based construction.
If requirements are well understood and project scope is constrained, the RAD model
enables a development team to create a fully functional system within 60-90 days. Used
primarily for information system applications, the RAD approach encompasses the
following phases :
26

• Business modeling : The information flow among business functions is modeled so
as to understand the following:
i) The information that drives the business process .
ii) The information generated.
iii) The source and destination of the information generated.
iv) The processes that affect this information.
• Data modeling : The information flow defined, as a part of the business-modeling
phase is refined into a set of data objects that are needed to support the business. The
attributes of each object are identified and the relationships between these objects are
defined.
27

• Process modeling: The data objects defined in the previous phase are transformed
to achieve the information flow necessary to implement a business function. Processing
descriptions are created for data manipulation.
• Application generation : RAD assumes the use of fourth generation techniques
Rather than using third generation languages, the RAD process works to reuse existing
programming components whenever possible or create reusable components. In all
cases, automated tools are used to facilitate construction.
• Testing and turnover: Since RAD emphasizes reuse, most of the components have
already been tested. This reduces overall testing time. However, new components must
be tested and all interfaces must be fully exercised.
In general, if a business function can be modularized in a way that enables each function
to be completed in less than three months, it is a candidate for RAD. Each major function
can be addressed by a separate RAD team and then integrated to form a whole.
Advantages :
• Modularized approach to development
• Creation and use of reusable components
• Drastic reduction in development time
Disadvantages :
• For large projects, sufficient human resources are needed to create the right number
of RAD teams.
• Not all types of applications are appropriate for RAD. If a system cannot be
modularized, building the necessary components for RAD will be difficult.
• Not appropriate when the technical risks are high. For example, when an application
makes heavy use of new technology or when the software requires a high degree of
interoperability with existing programs.
 Incremental Model :
28

This model combines elements of the linear sequential model with the iterative philosophy
of prototyping. The incremental model applies linear sequences in a staggered fashion as
time progresses. Each linear sequence produces a deliverable increment of the software.
For example, word processing software may deliver basic file management, editing and
document production functions in the first increment. More sophisticated editing and
document production in the second increment, spelling and grammar checking in the third
increment, advanced page layout in the fourth increment and so on. The process flow for
any increment can incorporate the prototyping model. When an incremental model is used,
the first increment is often a core product. Hence, basic requirements are met, but
supplementary features remain undelivered. The client uses the core product. As a result
of his evaluation, a plan is developed for the next increment. The plan addresses
improvement of the core features and addition of supplementary features. This process is
repeated following delivery of each increment, until the complete product is produced. As
opposed to prototyping, incremental models focus on the delivery of an operational product
after every iteration.
Figure 1.6 The Incremental Model.
29

Advantages Of Incremental Model :
1. Particularly useful when staffing is inadequate for a complete implementation by the
business deadline.
2. Early increments can be implemented with fewer people. If the core product is well
received, additional staff can be added to implement the next increment.
3. Increments can be planned to manage technical risks. For example, the system may
require availability of some hardware that is under development. It may be possible to
plan early increments without the use of this hardware, thus enabling partial
functionality and avoiding unnecessary delay.
 Extreme Programming(XP) :
• The most widely used agile process, originally proposed by Kent Beck.
• XP Planning :
 Begins with the creation of “user stories”.
 Agile team assesses each story and assigns a cost.
 Stories are grouped to for a deliverable increment
 A commitment is made on delivery date
 After the first increment “project velocity” is used to help define subsequent delivery
dates for other increments.
30

• XP Design :
 Follows the KIS principle.
 For difficult design problems, suggests the creation of “spike solutions”—a design
prototype.
 Encourages “refactoring”—an iterative refinement of the internal program design.
• XP Coding :
 Recommends the construction of a unit test for a store before coding commences
 Encourages “pair programming”.
• XP Testing :
 All unit tests are executed daily.
 “Acceptance tests” are defined by the customer and executed to assess customer
visible functionality.
 Format Method Model :
31

1. The formal methods model encompasses a set of activities that leads to formal
mathematical specification of computer software.
2. Formal methods enable a software engineer to specify, develop, and verify a computer-
based system by applying a rigorous mathematical notation.
3. When formal methods are used during development, they provide a mechanism for
eliminating many of the problems that are difficult to overcome using other software
engineering paradigms. Ambiguity, incompleteness, and inconsistency can be
discovered and corrected more easily, not through adhoc review but through the
application of mathematical analysis.
4. When formal methods are used during design, they serve as a basis for program
verification and therefore enable the software engineer to discover and correct errors
that might go undetected.
5. The formal methods model offers the promise of defect-free software.
Drawbacks Of Format Method Model :
1. The development of formal models is quite time consuming and expensive.
2. Because few software developers have the necessary background to apply formal
methods, extensive training is required.
3. It is difficult to use the models as a communication mechanism for technically
unsophisticated customers.
*****************
32

3.Analysis : Investigating System Requirements3.Analysis : Investigating System Requirements
 Introduction :
The requirement analysis task is a process of discovery, refinement, modeling and
specification. The software scope is refined in detail. Models of the required
information, control flow, operational behavior and data content are created. Alternative
solutions are analyzed and allocated to various software elements.
Both the developer and the customer take an active role in requirements analysis and
specification. The customer attempts to reformulate a sometimes, unclear concept of
software function and performance into concrete detail. The developer acts as interrogator,
consultant and problem-solver.
• Requirement analysis is a software engineering task that bridges the gap between
system level software allocation and software design.
• It enables the system engineer to specify software function and performance, indicate
software’s interface with other system elements and establish design constraints that
the software must meet.
• It allows the software engineer to refine the software allocation and build models of the
process, data and behavioral domains that will be treated by software.
• It provides the software designer with a representation of information and function that
can be translated into data, architectural and procedural design.
• It also provides the developer and the client with the means to assess quality once the
software is built.
The principles of requirement analysis call upon the analyst to systematically
approach the specification of the system to be developed. This means that the analysis
has to be done using the available information. Generally, all computer systems are looked
upon as information processing systems, since they process data input and produce a
useful output.
33

The logical view of a system gives the overall feel of how the system operates. Any system
performs three generic functions: input, output and processing. The logical view focuses on
the problem-specific functions. This helps the analyst to identify the functional model of the
system. The functional model begins with a single context level model. Over a series of
iterations, more and more functional detail is provided, until all system functionality is
represented.
They physical view of the system focuses on the operations being performed on the data
that is either taken as input or generated as output. This view determines the actions to be
performed on the data under specific conditions. This helps the analyst to identify the
behavioral model of the system. The analyst can determine an observable mode of
behavior that changes only when some event occurs.
Examples of such events are:
i) An internal clock indicating some specified time has passed.
ii) A mouse movement.
iii) An external time signal.
 What are System Requirements?
• System Requirements are the functions that our system must perform.
• During planning, the Analyst defines system capabilities, during analysis, the
Analyst expands these into a set of system requirements.
• There are two types of System Requirements:
 Functional : activities that a system must perform with respect to the organisation.
 Technical : operational objectives related to the environment, hardware, and
software of the organization.
• In functional requirements, for example, if a Payroll System is being developed, then it
is required to calculate salary, print paychecks, calculate taxes, net salary etc.
34

• In technical requirements, for example, the system may be required to support multiple
terminals with the same response time, or may be required to run on a specific
operating system.
 Sources of System Requirements
The Stakeholders :
• The Stakeholders of the System are considered as the primary source of information for
functional system requirements.
• Stakeholders are people who have an interest in the successful implementation of your
system.
• There are three groups of stakeholders: (a) Users who use the system on a daily basis
(b) Clients who pay for and own the system (c) Technical staff i.e. the people who must
ensure that the system operates in the computing environment of the organization.
• The analyst’s first task during analysis is to (a) identify every type of stakeholder and (b)
identify the critical person from each type (group) of stakeholders.
User Stakeholders :
• User Stakeholders are identified into 2 types: (a) Vertical and (b) Horizontal.
• Horizontal implies that an analyst needs to look at information flow across departments
or functions.
• For example, a new inventory system may affect multiple departments, such as
sales, manufacturing, etc, so these departments need to be identified, so as to collect
information relevant to them.
35

• Vertical implies that an analyst needs to look at information flow across job levels, such
as clerical staff, middle management, executives, etc.
• Each of these users may need the system to perform different functions with respect to
themselves.
• A Transaction is the single occurrence of a piece of work or an activity done in an
organization.
• A Query is a request for information from a system or from a database.
 Analysis tasks :
All analysis methods are related by a set of fundamental principles:
• The information domain of the problem must be represented and understood.
• Models that depict system information function and behavior should be developed.
• The models and the problem must be partitioned in a manner that uncovers detail in a
layered or hierarchical fashion.
• The analysis process should move form essential information to implementation detail.
Software requirement analysis may be divided into five areas of effort:
i) Problem recognition :
Initially, the analyst studies the system specification and the software project plan. Next
communication for analysis must be established so that problem recognition is ensured.
The analyst must establish contact with management and the technical staff of the
user/customer organization and the software development organization. The project
manager can serve as a coordinator to facilitate establishment of communication paths.
The objective of the analyst is to recognize the basic problem elements as perceived by
the client.
36

ii) Evaluation and synthesis :
Problem evaluation and synthesis is the next major area of effort for analysis. The analyst
must evaluate the flow and content of information, define and elaborate all software
functions, understand software behavior in the context of events that affect the system,
establish interface characteristics and uncover design constraints. Each of these tasks
serves to define the problem so that an overall approach may be synthesized.
iii) Modeling :
We create models to gain a better understanding of the actual entity to be built. The
software model must be capable of modeling the information that software transforms the
functions that enable the transformation to occur and the behavior of the system during
transformation. Models created serve a number of important roles:
• The model aids the analyst in understanding the information, function and behavior
of the system, thus making the requirement analysis easier and more systematic.
• The model becomes the focal point or review and the key to determining the
completeness, consistency and accuracy of the specification.
• The model becomes the foundation for design, providing the designer with an
essential representation of software that can be mapped into an implementation
context.
iv) Specification :
There is no doubt that the mode of specification has much to do with the quality of the
solution. The quality, timeliness and completeness of the software may be adversely
affected by incomplete or inconsistent specifications.
Software requirements may be analyzed in a number of ways. These analysis techniques
lead to a paper or computer-based specification that contains graphical and natural
language descriptions of the software requirements.
v) Review :
37

Both the software developer and the client conduct a review of the software requirements
specification. Because the specification forms the foundation of the development phase,
extreme care is taken in conducting the review.
The review is first conducted at a macroscopic level. The reviewers attempt to ensure that
the specification is complete, consistent and accurate. In the next phase, the review is
conducted at a detailed level. Here, the concern is on the wording of the specification. The
developer attempts to uncover problems that may be hidden within the specification
content.
 Fact-Finding Methods:
Fact-finding techniques are used to identify system requirements, through comprehensive
interaction with the users using various ways of gathering information.
There are six methods of Information Gathering which are as follows :
1. Distribute & Collect Questionnaires :
• Questionnaires enable the project team to collect information from a large
number of stakeholders conveniently, and to obtain preliminary insight on their
information needs.
• This information is then used to identify areas that need further research using
document reviews, interviews, and observation.
• Questionnaires can be used to answer quantitative questions, such as “How many
orders do you enter in a day?”
• Such questions are called closed-ended questions i.e. questions that have
simple, definitive answers and do not invite discussion or elaboration.
• They can be used to determine the user’s opinion about various aspects of a
system (say, asking the user to rate a particular activity on a scale of 1-5).
• Questionnaires, however, do not provide information about processes, work-
flow, or techniques used.
38

• Questions that illicit a descriptive response are best answered using
interviews, or observation.
• Such questions that encourage discussion and elaboration are called open-
ended questions.
2. Review Existing Reports, Forms, and Procedure Descriptions :
• Two advantages of reviewing existing documents and documentation:
 To get a better understanding of processes
 To gain knowledge about the industry or the application that needs to be
studied.
• An analyst requests for and reviews procedural manuals, and work descriptions, in
order to understand business functions.
• Documents and reports can also be used in interviews, where forms and reports
are used as visual aid, and working documents are used for discussion.
• Discussion can center on use of each form, its objective, distribution, and
information content.
• Forms already filled-out with real information ensure a correct understanding of the
fields and data content.
• Reviewing existing documentation of existing procedures helps identify business
rules, while written procedures also help in discovering discrepancies and
redundancies in the business processes.
• It is essential to ensure that the assumptions and business rules derived from
existing documentation are accurate.
39

3. Conduct Interviews & Discussions with Users :
• Interviewing stakeholders is considered the most effective way to understand
business functions and rules, though it is also the most time-consuming and
resource-expensive.
• In this method, members of the project team (system analysts) meet with individual
groups of users, in one or multiple sessions in order to understand all processing
requirements through discussion.
• An effective interview consists of three parts: (a) Preparing for the interview (b)
Conducting the interview and (c) Following up the interview.
• Before an Interview:
 Establish objective of interview (what do you want to accomplish
through this interview?)
 Determine correct user(s) to be involved (no. of users depends on the
objective)
 Determine project team members to participate (at least 2)
 Build a list of questions and issues to be discussed
 Review related documents and materials (list of specific questions, open and
closed ended)
 Set the time and location (quiet location, uninterrupted)
 Inform all participants of objective, time, and locations (each participant
should be aware of objective of the interview)
• During an Interview:
 Dress appropriately (show good manners)
40

 Arrive on time (arriving early is a good practice, if long interview, prepare for
breaks)
 Look for exceptions and error conditions (ask “what if” questions, ask
about exceptional situations)
 Probe for details (ensure complete understanding of all procedures and
rules)
 Take thorough notes (handwritten note-taking makes user feel that what he
has to say is important to you)
 Identify and document unanswered items or open questions (useful for
next interview session)
• After an Interview:
 Review notes for accuracy, completeness, and understanding (absorb,
understand, document obtained information)
 Transfer information to appropriate models and documents (create models
for better understanding after complete review)
 Identify areas that need further clarification (keep a log of unanswered
questions, such as those based on policy questions raised by new system,
include them in next interview)
 Send thank-you notes if appropriate

41

4. Observe Business Processes & Work-flow :
• Observing business procedures that the new system will support are an excellent
way to understand exactly how the users use a system, and what information they
need.
• A quick walkthrough of the work area gives a general understanding of the layout of
the office, the need and use of computer equipment, and the general workflow.
• Actually observing a user at his job provides details about the actual usage of the
computer system, and how the business processes are carried out in reality.
• Being trained by a user and actually performing the job allows one to
discover the difficulties of learning new procedures, the importance of an
easy-to-use system, and drawbacks of the current system that the new system
needs to address.
• It must be remembered that the level of commitment required by different processes
varies from one process to another.
• Also, the analyst must not be a hindrance to the user.
5. Build Prototypes :
• Building a prototype implies creating an initial working model of a larger, more
complex entity.
• Types of prototypes: throwaway, discovery, design, evolving prototypes.
• Different phases of the SDLC require different prototypes.
• The Discovery Prototype is used in the Planning & Analysis phases to test feasibility
and help identify processing requirements.
42

• The Development Prototype is used in the design, coding and implementation
phases, to test designs, effectiveness of code and workability of software.
• Discovery prototypes are usually discarded after the concept has been tested, while
an Evolving prototype is one that grows and evolves and may eventually be used as
the final, live system.
• Characteristics of Prototypes:
 A prototype should be operative i.e. a working model, that may provide lock-
and-feel but may lack some functionality.
 It should be focused on a single objective, even if simple prototypes are being
merged into a single large prototype.
 It should be built and modified easily and quickly, so as to enable
immediate modification if approach is wrong.
6. Conduct Joint Application Design (JAD) Sessions :
• JAD is a technique used to expedite the investigation of system requirements.
• Usually, the analysts first meet with the users and document the discussion through
notes & models (which are later reviewed).
• Unresolved issues are placed on an open-items list, and are eventually
discussed in additional meetings.
• The objective of this technique is to compress all these activities into a shorter
series of JAD sessions with users and project team members.
• During a session, all of the fact-finding, model-building, policy decisions, and
verification activities are completed for a particular aspect of the system.
• The success of a JAD session depends on the presence of all key stakeholders and
their contribution and decisions.
43

• Validate The Requirements / Requirements Validation :
• Requirements validation is a critical step in the development process, usually during
requirements engineering or requirements analysis. Also at delivery (client acceptance
test).
•
• Requirements validation criteria:
 Complete : All possible scenarios, in which the system can be used, are
described, including exceptional behavior by the user or the system.

 Consistent : There are no two functional or nonfunctional requirements that
contradict each other.

 Unambiguous : Requirements can not be interpreted in mutually exclusive ways.

 Correct : The requirements represent the client’s view.
More Requirements validation criteria :
 Realistic : Requirements can be implemented and delivered.
 Verifiable : Requirements can be checked.
Needs an exact description of the requirements
Problem with requirements validation :
 Requirements change very fast during requirements elicitation.
Tool support for managing requirements :
• Store requirements in a shared repository
• Provide multi-user access
• Automatically create a system specification document from the repository.
• Allow for change management.
44

• Provide traceability throughout the project lifecycle.
 Structured Walkthroughs :
1. A structured walkthrough is a planned review of a system or its software by persons
involved in the development effort.
2. The participants are generally at the same level in the organization: that is , they are
analysts or programmer-analysts.
Typically department managers for marketing or manufacturing are not involved in the
review even though they may be the eventual recipients of the system.
3. Sometimes structured walkthroughs are called ‘Peer Reviews’ because the participants
are colleagues at the same level in the organization.
Characteristics :
1. The purpose of walkthroughs is to find areas where improvement can be made in the
system or the development process.
2. A walkthrough should be viewed by the programmers and analysts as an opportunity to
receive assistance, not as an obstacle to be avoided or tolerated.
3. The review session does not result in the correction of errors or changes in
specifications. Those activities remain the responsibility of the developers. Hence the
emphasis is constantly on review, not repair.
4. The individuals who formulated the design specifications or created the program code
are as might be expected, part of the review team.
5. A moderator is sometimes chosen to lead the review, although many organizations
prefer to have the analyst or designer who formulated the specifications or program
45

lead the session, since they have greater familiarity with the item being reviewed. In
either case, someone must be responsible for keeping the review focused on the
subject of the meeting.
6. A scribe or recorder is also needed to capture the details of the discussion and the
ideas that are raised.
Since the walkthrough leader or the sponsoring programmers or analysts may not be
able to jot down all the points aired by the participants, appointing another individual to
take down all the relevant details usually ensures a more complete and objective
record.
7. The benefits of establishing standards for data names, module determination, and data
item size and type are recognized by systems managers. The time to start enforcing
these standards is at the design stage.
Therefore, they should be emphasized during walkthrough sessions.
8. Maintenance should also be addressed during walkthroughs. Enforcing coding
standards, modularity, and documentation will ease later maintenance needs.
9. It is becoming increasingly common to find organizations that will not accept new
software for installation until it has been approved by software maintenance teams. In
such an organization, a participant from the quality control or maintenance team should
be an active participant in each structured walkthrough.
10.
(i) The walkthrough team must be large enough to deal with the subject of the review
in a meaning way, but not so large that it cannot accomplish anything.
(ii) Generally no more than 7 to 9 persons should be involved , including the individuals
who actually developed the product under review, the recorder, and the review
leader.
11.
a. As a general rule, management is not directly involved in structured walkthrough
sessions. Its participation could actually jeopardize the intent of the review team
from speaking out about problems they see in project.
b. Because management is often interpreted to mean evaluation.
46

c. Managers may feel that raising many questions, identifying mistakes or suggesting
changes indicates that the individual whose work is under review is incompetent/
d. It is best to provide managers with reports summarizing the review session rather
than to have them participate.
e. The most appropriate type of report will communicate that a review of the specific
project or product was conducted, who attended, and what action the team took. It
need not summarize errors that were found, modifications suggested, or revisions
needed.
12. Structured reviews rarely exceed 90 minutes in length.
13.The structured walkthrough can be used throughout the systems development process
as a constructive and cost-effective management tool, after the detailed investigation
(requirements review), following design (design review), and during program
development (code review and testing review).
*****************
47

4.Feasibility Analysis4.Feasibility Analysis
A feasibility study is a preliminary study undertaken to determine and document a
project's viability. The results of this study are used to make a decision whether to proceed
with the project, or table it. If it indeed leads to a project being approved, it will - before the
real work of the proposed project starts - be used to ascertain the likelihood of the project's
success. It is an analysis of possible alternative solutions to a problem and a
recommendation on the best alternative. It, for example, can decide whether an order
processing be carried out by a new system more efficiently than the previous one.
A feasibility study could be used to test a new working system, which could be used because
:
• The current system may no longer suit its purpose,
• Technological advancement may have rendered the current system obsolete,
• The business is expanding, allowing it to cope with extra work load,
• Customers are complaining about the speed and quality of work the business provides,
• Competitors are now winning a big enough market share due to an effective integration
of a computerized system.
Within a feasibility study, seven areas must be reviewed, including those of a Needs
Analysis, Economics, Technical, Schedule, Organizational, Cultural, and Legal.
1. Operational Feasibility :
It involves the following two tests:
• Understanding whether the problem is worth solving and whether the solution to the
problem will work out, by analyzing the following criteria: (PIECES)
(a) Performance (b) Information (c) Economy (d) Control (e) Effectiveness (f)
Service.
• Getting the management's and end-users' views on the solution by analyzing
the following:
(a) Will the current working environment change?
(b) How do the end users feel about their role in the new system?
(c) Would the end-users resist the new system?
48

2. Organizational & Cultural Feasibility :
• The new system must fit into the work-environment of the organization.
• It must also fit with the culture of the organization.
• It should not depart dramatically, from existing norms.
• It has to deal with issues such as:
 Low computer literacy
 Perceived loss of control by staff or management
 Fear of change of job responsibility
 Reversal of longstanding work procedures
 Fear of loss of job due to increased automation
• It essentially involves identifying factors that might prevent the effective use of the
new system, thus resulting in loss of business benefits.
• Such factors can be tackled with high user involvement during the system's
development and well-planned training procedures and proper orientation after the
system's completion.
3. Technical Feasibility :
• This involves testing the proposed technological requirements and the available
expertise.
• A company may implement new technology in the new system, or upgrade the
technology of an existing system.
• In some cases, the scope and approach of the project may need to be
changed to restructure and reduce the technological risk.
• When the risks are identified, the solutions may include conducting additional
training, hiring consultants, hiring more experienced employees.
• A realistic assessment will help identify technological risks early and permit
correctivemeasures to be taken.
4. Schedule Feasibility :
49

• It involves assessing if the project can be completed according to the proposed
project schedule.
• Every schedule requires many assumptions and estimates about the project, as the
needs and scope of the system may not be known at this stage.
• Sometimes, a project may need to be completed within a deadline given by the upper
management.
• Milestones should be developed within the project schedule to assess the ongoing
risk of the schedule slipping.
• Deadlines should not be considered during project schedule construction, unless they
are absolute.
5. Resource Feasibility :
• The availability of resources is a crucial assessment in terms of project feasibility.
• The primary resource consists of the members of the team.
• Development projects require the involvement of system analysts, system
technicians, users.
• Three risks are involved here:
(a) Required people may not available to the team when needed.
(b) People who are assigned, may not have the necessary skills.
(c) People already working on the project may leave midway.
• Also, adequate computer resources, physical facilities, and support staff are
valuable resources.
• Delays in making these resources can affect the project schedule.
50

6. Economic Feasibility :
• Economic feasibility consists of two tests:
(a) do the anticipated benefits exceed the projected cost of development?
(b) does the organization have adequate cash flow to fund the project?
• The new system must increase income, either through cost saving, or by
increased revenues.
• The economic feasibility of a system is usually assessed using one of the following
methods:
(a) Cost/Benefit Analysis.
(b) Calculation of the Net Present Value (NPV)
(c) Payback Period, or Breakeven Point
(d) Return on Investment
 Cost estimation :
Software cost estimation is a continuing activity, which starts at the proposal stage and
continues through the lifetime of the project. There are several different techniques
of software cost estimation. They are:
i) Expert judgment :
One or more experts on the software development techniques to be used, and on the
application domain, are consulted. They each estimate a project cost and the final cost is
arrived at by consensus.
ii) Estimation by analogy :
This technique is applicable when other projects in the same application domain have been
completed. The cost of a new project is estimated by analogy with these
completed projects.
iii) Parkinsonís law :
51

It states that work expands to fill the time available. In software costing, it means that the
cost is determined by available resources rather than by objective assessment.
iv) Pricing to win :
The software cost is estimated to be whatever the customer has available to spend on the
project. The estimated effort depends on the customerís budget and not on the software
functionality.
v) Top-down estimation:
A cost estimate is established by considering the overall functionality of the project and
how that functionality is provided by interacting functions. Cost estimates are made on the
basis of logical function rather than component implementation of the function.
52

vi) Bottom-up estimation :
The cost of each component is estimated. All these costs are added to produce a final cost
estimate.
 Cost/Benefit Analysis
It is the analysis used to compare costs and benefits to see whether the investment in the
development of a new system will be more beneficial than costly.
Cost And Benefits Categories :
• In developing cost estimates for a system, we need to consider several cost elements.
• Following are the types of costs that are analyzed :
 Hardware Costs : Costs related to actual purchases or leasing of computers and
peripheral devices.
 Personnel Costs : Costs including staff salaries and benefits (staff includes
system analysts, programmers, end-users, etc.).
 Facility Costs: Costs involved in the preparation of the physical site where the
computer system will be operating (wiring, flooring, air conditioning, etc.).
 Developmental Costs: Costs involved in the development of the system
(hardware costs, personnel costs, facility costs).
 Operating Costs : Costs incurred after the system is put into production i.e. the
day-to-day operations of the system (salaries of people using the application, etc.).
• A system is also expected to provide benefits.The first task is to identify each benefits
and then assign a monetary value to it for cost/benfit analysis.
• Benefits may be tangible and intangible or direct and indirect.The two major benefits
are as follows :
53

 Improving performance : The performance category emphasis improvement in the
accuracy of or access to information and easier access to the system by the
authorised users.
 Minimizing the cost of processing : Minimizing costs through an efficient system-
error control or reduction of staff – is a benefit that should be measured and
included in cost/benefit analysis.
 Procedure For Cost/Benefit Determination :
There is a difference between expenditure and investment . We spend to get what we need
, but we invest to realise a return on the investment.Building a computer-based system is
an investment .Costs are incurred throughout its life cycle.Benefits are realized in the form
of reduced operating costs, improved corporate image, staff efficiency or revenue.
Cost/Benefit Analysis is a procedure that gives a picture of the various costs, benefits
and rules associated with a system.
The determination of the cost and benefits entails the follwing step :
1. Identify the costs and benefits pertaining to a given project.
2. Categorize the various costs and benefits for analysis.
3. Select a method of evaluation.
4. Interpret the result of the analysis.
5. Take action.
1. Costs And Benefits Identification :
• Certain costs and benfits are more easily identifiable than others.For example, direct
costs, such as the price of a hard disk, are easily identified from company invoice
payments or canceled checks.
• Direct benefits offeten relates one-to-one to direct costs, especially savings from
reducing cost in the activity in question.
54

• Other direct costs and benefits, however may not be well defined, since they
represent estimated costs or benefits that have some uncertainity.An example of
such costs is reserve for bad debt. It is a discerned real cost, although its exact
amount is not so immediate.
• A Category of costs or benefits that is not easily discernible is opportunity costs and
opportunity benefits.
• These are the costs or benefits forgone by selecting one alternative over another.
They do not show in the organization’s account and therefore are not easy to
identify.
2. Classification of Cost and benefits :
The next step in cost and benefit determination is to categorize costs and benefits.
They may be tangible or intangible , direct or indirect , fixed or variable.
Let us review each category.
55

3. Select Evaluation Method :
56

When all financial data have been identified and broken down into cost categories, the
analyst must select a method of evaluation.Several method are avaiable.
The Common are as follows :
i.] Net Benefit Analysis :
• Net Benefit simply involves subracting total costs from total benfits.
• It is easy to calculate, easy to interpret, and easy to present.
• The main drawback is that it does not account for the time value of money and
does not discount future cash flow.
Cost/Benefit Year
0
Year
1
Year
2
Total
Costs $-1,000 $-2,000 $-2,000
Benefits 0 650 4,900 5,550
Net benefits $-1,000 $-1,350 $-2,900 $550
Above table illustrates the use of net benefit analysis. Cash flow amounts are shown for
three time period : Period 0 is the present period followed by two succeeding periods. The
negative numbers represent cash outlays. A cursory look at the numbers shows that net
benefit is $550.
The time value of money is extremly important in evaluation processes.Let us explain
what it mean.If you were faced with an opportunity that generates $3000 per year, how
much would you be willing to invest? Obiviously , you’d like to invest less than the $3000.
To earn the same money five years from now, the amount of investment woul be even
less. What is suggested here is that money has a time value. Today’s dollar and
tommorow’s dollar are not the same.The time lag accounts for the time value of money.
The time value of money is usually expressed in the form of interest on the funds
invested to realize the future value.Assuming compounded interest, the formula is :
F=P(1+i)^n
Where
F= Future value of an investment.
P= Present value of the investment.
i = Interest rate per compounding period.
57

n = Number of years.
For example, $3000 invested in Treasury notes for three years at 10% interest would have
a value at maturity of :
F=$3000(1+0.10)^3
=3000(1.33)
=$3993
ii.] Present Value Analysis :
• In developing long-term projects, it is often dificult to compute today’s costs with the
full value of tomorrow’s benefits.Certain investments offer benefit periods that vary
with different projects.
• Present Value analysis controls for these problems by calculating costs and benefits
of the system in terms of today’s value of the investment and then comparing across
alternatives.
• A critical factor to consider in computing present value is a discount rate equivalent
to the forgone amount that the money could earn if it were invested in a different
projects.It is similar to the opportunity cost of the funds being considered for the
project.
• Example : Suppose that $3000 is to be invested in a microcomputer for our safe
deposit tracking system and the average annual benefit is $1500 for the four year
life of the system.The investment has to be made today, whereas the benefits are in
the future.We compare present values to the future values by considering the time
value of the money to be invested.The amount that we are willing to invest today is
determined by the value of the benefits at the end of a given period(year).The
amount is called the present value of the benefit.
To compute the present value, we take the formula for future value(F=P/(1+i)^n) and
solve for the present value(P) as follows :
P=F/(1+i)^n
So the present value of $1500 invested at 10% interest at the end of the fourth year
is : P=1500/(1+0.10)^4
=1500/1.61
=$1027.39
58

That is, if we invst $1027.39 today at 10% interest , we can expect to have $1500 in
4 years.This calculation can be represented for each year where a benefit is
expected.
Year
Estimated
Future
Value
Discount
Rate ®
Present
Value©
Cumulative
Prsent Value of
Benefits
1 $1500 X 0.908 = $1363.63 $1363.63
2 $1500 X 0.826 = $1239.67 $2603.30
3 $1500 X 0.751 = $1127.82 $3731.12
4 $1500 X 0.683 = $1027.39 $4758.51
® 1[(1+i)^n]
© P=F[(1+i)^n]
iii.] Net Present Value (NPV) Calculation :
• The present value of rupee/dollar (currency) benefits and costs for investments such
as a new system.
• Two concepts are involved:
 All benefits and costs are calculated in terms of today's rupee/dollar (currency)
values,i.e. present values.
 Benefits and costs are combined to give a net value.
• It essentially tells you how much should be invested today, in order to achieve
a predetermined amount of benefit at a predetermined later point in time.
• The following two terms hold great importance in this calculation:
 Discount rate: It is the annual percentage rate that an amount of money is
discounted to bring it to a present value.
 Discount factor: It is the accumulation of yearly discounts based on the discount
rate.
• Formula: If Present value is PV, amount received in future is FV, discount interest rate
is i, discount factor is F, and number of years is n :
59

• For example, if the future amount is Rs. 1500, and the number of years is 4, at say
10% discount rate, then the present value can be calculated as:
i.e. today, the investment should be 1024.5, to get 1500 after 4 years.
iv.] Payback Period/Breakeven Period Calculation :
• The payback period is the period at which rupee/dollar (currency) benefits
offset the rupee/dollar (currency) costs.
• It is the point in time, when the increased cash flow exactly pays off the
costs of development and operation.
• When the net value becomes positive, that is the year in which payback occurs.
• Consider the following table:
60

v.] Return on Investment (ROI) Calculation :
• Return on investment is a measure of the percentage gain received from an
investment such as a new system.
• Similar to interest rate, this calculation is meant to ensure that costs and benefits
are exactly equal over a specified time period.
• This time period can be the expected life of the investment, or it could be an arbitrary
period.
• It is the measure of the percent gain received from an investment.
• Formula : If Estimated time period Benefits is EB, Estimated time period Costs is EC,
then ROI = (EB - EC)/EC Here, EC is the sum of developmental costs (DC) and
total present value of costs (PC).
• If EB = 60,00,000; DC = 12,00,000; PC = 9,00,000
ROI = [60,00,000 – (12,00,000 + 9,00,000)] / (12,00,000 + 9,00,000)
185%
4. Interpret Results of the Analysis And Final Action :
• When the evaluation of the project is complete, the results have to be interpreted.
This entails comparing actual results against a standard or the result of an alternative
investment.
• The interpretation phase as well as the subsequent decision phase are subjective,
requiring judgement and intuition.
• Depending on the level of uncertainty, the analyst may be confronted with a single
known value or a range of values.
61

• In either case, simpler measures such as net benefit analysis are easier to calculate
and present than other measures, although they do not discount future cash flows.
• The decision to adopt an alternative candidate system can be highly subjective ,
depending on the analyst’s or end user’s confidence in the estimated costs and
benefits and the magnitude of the system.
In summary , cost/benefits analysis is a tool for evaluating projects rather than a
replacement of the decision maker.In real-life business situations, whenever a choice
among alternatives is considered, cost/benefits is an important tool.
Like any tool, however it has problems :
 Valuation problems : Intangible costs and benefits are difficult to quantify and tangible
costs are generally more pronounced than tangible benefits.In most cases, then, a
project must have substantial intangible benefits to be accepted.
 Distortion problems : There are two ways of distorting the results of cost/benefit
analysis.One is the intentional favoritism of an alternative for political reasons.The
second is when data are incomplete or missing from the analysis.
 Completeness problems : Occasionally an alternative is overlooked that compromises
the quality of the final choice.furthermore, the costs related to cost/benefit analysis may
be on the high side or not enough costs may be considered to do a complete
analysis.In either case, the realibility of the final choice is in doubt.
 List of Deliverables :
When the design of an information system is complete the specifications are documented
in a form that outlines the features of the application. These specifications are termed as
the ‘deliverables’ or the ‘design book’ by the system analysts.
No design is complete without the design book, since it contains all the details that must be
included in the computer software, datasets & procedures that the working information
system comprises.
The deliverables include the following:
1. Layout charts :
62

Input & output descriptions showing the location of all details shown on reports,
documents, & display screens.
2. Record layouts :
Descriptions of the data items in transaction & master files, as well as related database
schematics.
3. Coding systems :
Descriptions of the codes that explain or identify types of transactions, classification, &
categories of events or entities.
4. Procedure Specification :
Planned procedures for installing & operating the system when it is constructed.
5. Program specifications :
Charts, tables & graphic descriptions of the modules & components of computer
software & the interaction between each as well as the functions performed & data
used or produced by each.
6. Development plan :
Timetables describing elapsed calendar time for development activities; personnel
staffing plans for systems analysts, programmers, & other personnel; preliminary
testing & implementation plans.
7. Cost Package :
Anticipated expenses for development, implementation and operation of the new
system, focusing on such major cost categories as personnel, equipment,
communications, facilities and supplies.
*****************
63

5.Modeling : System Requirements5.Modeling : System Requirements
 Overview Of Model :
• What is a model ? A model is a representation of some aspect of the system to be
built.
• What is its purpose ?
 A model helps an analyst clarify and refine the design of the system.
 It also helps in describing the complexity of the information system.
 It provides a convenient way of storing information about the system in a
readily understandable form.
 It helps communication between the analyst and the programmer (i.e. members of
the project team).
 It also assists in communication between the project team and the system users
and stakeholders.
 It can be used as documentation by a future development team, while maintaining
or enhancing the system.
 Types of Models :
The type of the model is based on the nature of the information being represented.
It includes :
1. Mathematical Model :
• A Mathematical Model is a series of formulae that describe the technical
aspects of a system.
• Such models are used to represent precise aspects of the system, that can be
best represented through formulae or mathematical notations, such as equations and
functions.
• They are useful in expressing the functional requirements of scientific and
engineering applications, that tend to compute results using elaborate mathematical
algorithms.
• They are also useful for expressing simpler mathematical requirements in
business systems, such as net salary calculation in a payroll system.
64

2. Descriptive Model :
• Descriptive models are required for narrative memos, reports, or lists that describe
some aspects of the system.
• This model is required especially because there is a limitation to what information can
be defined using a mathematical model.
• Effective models of information systems involve simple lists of features, inputs, outputs,
events, users.
• Lists are a form of descriptive models that are concise, specific, and useful.
• Algorithms written using structured English or pseudocode are also considered
precise descriptive models.
3. Graphical Models :
• Graphical Models include diagrams and schematic representations of some
aspect of a system.
• They simplify complex relationships that cannot be understood with a verbal
description.
• Analysts usually use symbols to denote various parts of the model, such as external
agents, processes, data, objects, messages, connections.
• Each type of graphical model uses unique and standardized symbols to represent
pieces of information.
 Data Flow Diagram :
• A Data Flow Diagram (DFD) is also known as a Process Model. Process Modeling is
an analysis technique used to capture the flow of inputs through a system (or group of
processes) to their resulting output.
• A Data Flow Diagram is a graphical system model that shows all the main requirements
for an information system.
• It involves representation of the following:
 Source (External agent)/ Destination (External agent) : A person or organisation
that lies outside the boundary of a system and provides inputs to the system or
accepts the system’s output.
65

 Process/Activity : A process is an algorithm or procedure that transforms data
input into data output.
 Data store : A place where data is held, for future access by one or more
processes.
 Data Flow : An arrow in a DFD that represents flow of data among the processes
of the system, the data stores, and the external agents.
• All processes are numbered to show proper sequence of events.
 DFD Syntax :
 Reading Data Flow Diagram (DFD) :
66

Level of Abstraction :
• Many different types of DFDs are produced to show system requirements.
• Some may show the processing at a higher level (a general view), while others may
show the processing at a lower level (a detailed view).
• These differing views are referred to as levels of abstraction.
• Thus Levels of Abstraction can be defined as a modelling technique that breaks the
system into a hierarchical set of increasingly more detailed models.
• The higher level DFDs can be decomposed into separate lower level detailed DFDs.
Context Diagram :
• A Context Diagram is a Data Flow Diagram that describes the highest view of a system.
• It summarizes all processing activities within the system into a single process
representation.
• All the external agents and data flow (into and out of the system) are shown in
one diagram, with the whole system represented as a single process.
• It is useful for defining the scope and boundaries of a system.
• The boundaries of a system in turn help identify the external agents, as they lie outside
the boundary of the system.
• The inputs and outputs of a system are also clearly defined.
• NOTE : Data stores are not included.
67

• The Context level DFD process take 0 as the process number, while the numbering in
the 0 Level DFD starts from 1.
DFD Fragments :
• A DFD fragment is a DFD that represents system response to one event within a single
process.
• Each DFD fragment is a self-contained model showing how the system responds to a
single event.
• The main purpose of DFD fragments is to allow the analyst to focus attention on just
one part of the system at a time.
• Usually, a DFD fragment is created for each event in the event list (later made into an
event table).
Physical & Logical DFDs :
• If the DFD is a physical model, then one or more assumptions about the
implementation technology are embedded in the DFD.
• If the DFD is a logical model, then it assumes that the system will be implemented
using perfect technology.
• Elements that indicate assumptions about implementation technology are:
 Technology-specific processes (E.g.: Making copies of a document)
 Actor-specific process names (E.g.: Engineer checks parts)
 Technology- specific or actor-specific process orders.
 Redundant processes, data flows, and files
• Physical DFDs are sometimes developed and used during the last stages of analysis or
early stages of design.
• Physical DFDs serve one purpose, and that is to represent one possible
implementation of the logical system requirements.
Creating Data Flow Diagram :
1. Integrating Scenario Description -
• DFDs start with the use cases and requirements definition
• Generally, the DFDs integrate the use cases
68

• Names of use cases become processes
• Inputs and outputs become data flows
• “Small” data inputs and outputs are combined into a single flow
2. Step In Building DFD -
1. Build the context diagram
2. Create DFD fragments for each use case
3. Organize DFD fragments into level 0 diagram
4. Decompose level 0 processes into level 1 diagrams as needed; decompose level 1
processes into level 2 diagrams as needed; etc.
5. Validate DFDs with user to ensure completeness and correctness
3. Creating The Context Diagram –
• Draw one process representing the entire system (process 0)
• Find all inputs and outputs listed at the top of the use cases that come from or go to
external entities; draw as data flows
• Draw in external entities as the source or destination of the data flows.
• Example –
4. Creating DFD Fragments –
69

• Each use case is converted into one DFD fragment
• Number the process the same as the use case number
• Change process name into verb phrase
• Design the processes from the viewpoint of the organization running the system.
• Add data flows to show use of data stores as sources and destinations of data
• Layouts typically place
• processes in the center
• inputs from the left
• outputs to the right
• stores beneath the processes.
• Example –
5.Creating Level 0 Diagram –
• Combine the set of DFD fragments into one diagram
• Generally move from top to bottom, left to right
70

• Minimize crossed lines
• Iterate as needed
• Example –
Creating Level 1 Diagram (And Below ) -
• Each use case is turned into its own DFD
• Take the steps listed on the use case and depict each as a process on the level 1 DFD
• Inputs and outputs listed on use case become data flows on DFD
• Include sources and destinations of data flows to processes and stores within the DFD
• May also include external entities for clarity.
• When to stop decomposing DFDs?
Ideally, a DFD has at least three processes and no more than seven to nine.
71

 Basic rules for Process Modeling/DFD :
1. A series of data flows always starts or ends at an external agent and starts or ends at a
data store. Conversely, this means that a series of data flows can not start or end at a
process.
2. A process must have both data inflows and outflows.
3. All data flows must be labeled with the precise data that is being exchanged.
4. Process names should start with a verb and end with a noun.
5. Data flows are named as descriptive nouns.
6. A data store must have at least one data inflow.
7. A data flow can not go between an external agent and a data store, but a process must
be in between.
8. A data flow can not go between to external agents, but a process must be in between.
9. A data flow can not go between to data stores, but a process must be in between.
10.External agents and data flows can be repeated on a process model in order to avoid
lines crossing, but do not repeat processes.
 Evaluating DFD Quality :
• A high-quality set of DFDs is identified by its readability, internal consistency, and
accurate representation of system requirements.
• Some important terms :
 Information overhead : It is an undesirable condition that occurs when too
much when information is presented to a reader at one time.
 Rule of 7 ± 2 : It is a rule of model design that limits the number of model
components or connections among components to not more than nine, and not
less than five.
 Minimization of interfaces : It is a principle of model design that seeks
simplicity by minimizing the number of interfaces or connections among model
components.
 Structured English :
72

• Structured English describes procedures. The procedure may be a process in a DFD.
• Structure English is the marriage of English language with the syntax and structured
programming.
• Thus structured English aims at getting the benefits of both the programming logic and
natural language.
• Program logic helps to attain precession while natural language helps in getting the
convenience of spoken languages.
• Structured English can be specified as a process specification tool.
• The two building blocks of Structured English are
(1) Structured logic or instructions organized into nested or grouped procedures, and
(2) Simple English statements such as add, multiply, move, etc. (strong, active, specific
verbs).
Five conventions to follow when using Structured English :
1. Express all logic in terms of sequential structures, decision structures, or iterations.
2. Use and capitalize accepted keywords such as: IF, THEN, ELSE, DO, DO WHILE, DO
UNTIL, PERFORM
3. Indent blocks of statements to show their hierarchy (nesting) clearly.
4. When words or phrases have been defined in the Data Dictionary, underline those
words or phrases to indicate that they have a specialized, reserved meaning.
5. Be careful when using "and" and "or" as well as "greater than" and "greater than or
equal to" and other logical comparisons.
Example Of Structured English :
A bank will grant loan under the following conditions 1. If a customer has an account with
the bank and had no loan outstanding, loan will be granted. 2. If a customer has an
account with the bank but some amount is outstanding from previous loans then loan will
be granted if special approval is needed. 3. Reject all loan applications in all other cases.
The Structured English for above example would be as follows :
IF customer has a Bank Account
73

THEN
IF Customer has no dues from previous account
THEN Allow loan facility
ELSE
IF Management Approval is obtained
THEN Allow loan facility
ELSE Reject
ELSE Reject
• Decision Table :
• Decision tables are a precise yet compact way to model complicated logic.
• Decision tables, like if-then-else and switch-case statements, associate conditions with
actions to perform. But, unlike the control structures found in traditional programming
languages, decision tables can associate many independent conditions with several
actions in an elegant way.
• Decision Tables are useful when complex combinations of conditions, actions, and
rules are found or you require a method that effectively avoids impossible situations,
redundancies, and contradictions.
Structures Of Decision Table :
• Decision tables are typically divided into four quadrants, as shown below
The Four Quadrants
Conditions Condition alternatives
Actions Action entries
• Each decision corresponds to a variable, relation or predicate whose possible values
are listed among the condition alternatives.
• Each action is a procedure or operation to perform, and the entries specify whether (or
in what order) the action is to be performed for the set of condition alternatives the entry
corresponds to.
74

• Many decision tables include in their condition alternatives the don't care symbol, a
hyphen. Using don't cares can simplify decision tables, especially when a given
condition has little influence on the actions to be performed.
• In some cases, entire conditions thought to be important initially are found to be
irrelevant when none of the conditions influence which actions are performed.
• Aside from the basic four quadrant structure, decision tables vary widely in the way the
condition alternatives and action entries are represented.
• Some decision tables use simple true/false values to represent the alternatives to a
condition (akin to if-then-else), other tables may use numbered alternatives (akin to
switch-case), and some tables even use fuzzy logic or probabilistic representations for
condition alternatives.
• In a similar way, action entries can simply represent whether an action is to be
performed (check the actions to perform), or in more advanced decision tables, the
sequencing of actions to perform (number the actions to perform).
Example Of Decision Table :
The limited-entry decision table is the simplest to describe. The condition alternatives are
simple boolean values, and the action entries are check-marks, representing which of the
actions in a given column are to be performed.
A technical support company writes a decision table to diagnose printer problems based
upon symptoms described to them over the phone from their clients.
Printer Troubleshooter
Rules
Conditions
Printer does not print Y Y Y Y N N N N
A red light is flashing Y Y N N Y Y N N
Printer is unrecognized Y N Y N Y N Y N
Actions Check the power cable X
75

System analysis and_design

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie System analysis and_design

Ähnlich wie System analysis and_design (20)

Mehr von Tushar Rajput

Mehr von Tushar Rajput (12)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

System analysis and_design