Systems Analysis and Design
Unit 1
• LO1
Understand the different systems life cycles
• Assessment criteria
• AC1.1 Evaluate the different systems life cycle models
• AC1.2 Discuss the importance of following a procedural/staged life cycle in a
systems investigation
• Learning objectives
• After studying this unit, you should be able to:
•
•
•
•
•
Understand the different SDLC phases
Understand the different systems life cycle models
Identify the different systems life cycle models
Evaluate the different systems life cycle models
Explain the importance of following a procedural/staged life cycle
Information systems analysis and design
• Information systems analysis and design focus on the interaction
between related entities while developing an effective information
technology solution.
• There is no one single methodology that will ensure success during
information systems development, however,
• using tools and techniques available to us will enhance our chances
of successfully completing a systems development project.
• Example
• A library is in need of a system that will keep track of all books that
are currently booked out as well as who booked them out.
• Another example is organisations that often purchase off-the-shelf
software. Such software, however, cannot always be customised or
does not necessarily fit the needs of the organisation fully.
Components of information systems
• Information systems consist of the following components:
• Application software
• Hardware software
• System software
• Documentation and training material
• System roles and responsibilities
• System controls
• System users
• One of the aims of information systems development is to assist
understanding the software engineering process .
• This process leads to the creation of information systems.
Definition and characteristics of systems
• As stated previously, no one system can perform all functionality
required by an organisation.
• Organisations make use of various types of information
system in different departments.
• For example, a system that keeps track of student results is separate
from a system that manages lecturer payroll.
• A system involves components and business procedures that are
related in some way, and, which, when they work together, reach a
designed outcome (Valacich [et al.], 2011:3).
• There are nine characteristics of a system, namely:
1. System components/sub-systems:
•
parts that, when put together, will make up a system.
2. Inter-related system components:
•
the level to which the components rely on each other or on other parts
of a system.
3. System boundaries:
•
•
•
•
a system is developed to satisfy a set of requirements that meet a
specific organisational need.
Each system has limitations, known as ‘system boundaries’.
Simply put, to identify system boundaries, one must look at what
should be included in a system and what belongs outside such.
Everything inside a system will have to be planned, designed and
developed.
4. System purpose:
•
the main goal/function that a system will perform.
5. System environment:
•
a system exists within a specific environment; this refers to everything
external to a system that could interact with it.
6. System interface:
•
the point of contact where a system meets its environment; an interface
can also occur between sub-systems.
7. System constraints:
•
any limitation that a system might have in terms of capacity, speed or
functionality.
8. System input:
•
a system takes input from its environment to function.
9. System output:
•
a system provides output from received input and returns such to its
environment; this marks that a system is achieving its purpose.
Decomposition
• Decomposition entails breaking a system up into smaller, more
manageable components that may constitute a system by itself.
• These broken down systems are referred to as ‘sub-systems’.
• The main reason for performing decomposition is to focus on
particular parts of a system.
• Decomposition allows a systems analyst to do the following:
•
•
•
•
Break a system into smaller, more manageable sub-systems
Focus the attention on one specific area in a system
Focus on a part of a system that is relevant to a specific group of users
Build sub-systems independently from one another
Modularity
• Modularity is the result of decomposition; it refers to the
divided system pieces (modules) that exist.
• For example, looking at the components of the MP3 player, we can
see how decomposition makes it easy to understand an overall
system.
Coupling
• Coupling means that sub-systems are dependent on each other.
• If one sub-system should fail, the others will also fail or have difficulty
functioning properly.
• For example, without a battery, the MP3 player will not function at
all; without a hard drive sub-system, the MP3 player will switch on
but will not be able to store any music.
Cohesion
• Cohesion refers to the extent to which a sub-system will perform a
single function.
• For example, storing music on a hard drive refers to a single function.
The systems development life cycle (SDLC)
• The SDLC forms the basis for any information systems development
project.
• The four main phases of the SDLC will be discussed in detail in the
sections to follow.
• In order to remain competitive, a business must keep its systems up
to date.
• The SDLC refers to a process of understanding exactly how an
information system will be able to support the requirements of an
organisation.
• As each system is developed, it progresses through the specific life
cycle.
• A life cycle refers to the time from the beginning of a systems
project to the implementation and maintenance of such.
• This includes the time that the system will be operational as well as
the time needed to develop and implement such.
• How the different phases/levels relate to one another depends on
which life cycle model is used.
• Each model will employ phases, even if they are called something
different; some models might even combine phases to occur
simultaneously or add additional phases to ensure that a system’s
outcomes are met.
Phase 1: systems planning and selection
• The systems planning and selection phase begins with a formal request to
the Information Technology (IT) Department that describes a problem or
desired change that an organisation might need.
• This request is called a ‘systems request’.
• A systems request can originate from any department within an organisation
and may be very significant or small.
• The main questions answered during this phase are why a system should be
built and how the team will go about building such.
• The purpose of this phase is to perform a preliminary investigation to
identify the nature and scope of the problem or requested change.
• A very important part of this investigation is to perform a systems
feasibility study.
• Another important process is to perform a SWOT analysis: the purpose of a
SWOT
analysis is to determine the strengths (S), weaknesses (W), opportunities (O)
and threats (T) of a proposed system.
Phase 2: systems analysis
• The purpose of the systems analysis phase is to draw and build
logical models of the proposed system.
• It is concerned with discovering what the new system should be able
to do. (Requirements specification)
• At the end of this phase, a systems analyst should propose
alternative replacement systems for the given request, outlining the
requirements, costs and benefits.
Phase 3: systems design
• The purpose of the systems design phase is to create a draft of the
system that will satisfy all of the documented requirements given by
an organisation for the new system.
• During this stage, data designs, user interfaces, input and output
designs and systems architecture are identified and created.
• It is essential that the first three phases of the SDLC are understood
and correct before the construction of a system can begin.
Phase 4: systems implementation and
operation
• The system is now constructed according to the systems design
specifications.
• It is important that each section is checked to verify that it meets the
requirements as identified previously.
• Regardless of the approach being used, the method is the same:
programs are written, tested and documented.
• At the end of this phase, the system is ready for use.
• The final preparations include converting current organisational data
to the new system’s files, training users and performing the change
over to the new system.
SDLC phases
1. Systems planning and
selection
2. Systems analysis
3. Systems design
4. Systems
implementation and
operation
Products
Priorities for systems and projects
Architecture for data, networks, hardware and information
systems management
Detailed work plans for selected projects
Specifications of systems scope
Systems justification or business case
Description of current systems
General recommendations on how to fix, enhance or
replace current systems
Explanations of alternative systems and justification for
chosen alternatives
Acquisition plans for new technology
Detailed specifications of all systems elements
Coding
Documentation
Training procedures and support capabilities
New versions or releases of software with associated
updates to documentation, training and support
Waterfall Model
• The Waterfall Model is a traditional methodology based on a series
of steps that should be addressed in sequence when building
information systems.
• The order of the steps is predefined with a review at the end of each
step.
• The model requires that each step be completed before moving on to
the next step.
• Where the requirements have been well defined and the
development methods well understood, the Waterfall Model allows
for forecasting project completion times.
• Advantages
•
•
•
•
•
•
Easy to understand, easy to use
Provides structure to inexperienced staff
Milestones are well understood
Sets requirements stability
Good for management control (plan, staff, track)
Works well when quality is more important than cost or schedule
Quality
Cost
Time
• Disadvantages
•
•
•
•
All requirements must be known upfront
Deliverables created for each phase are considered frozen – inhibits flexibility
Can give a false impression of progress
Does not reflect problem-solving nature of software development –
iterations of phases
• Integration is one big bang at the end
• Little opportunity for customer to preview the system
• When to use the waterfall model:
•
•
•
•
•
Requirements are very well known
Product definition is stable
Technology is understood
New version of an existing product
Porting an existing product to a new platform
Prototyping
• Prototyping is a strategy related to information systems
development, in which a scaled-down system or portion of a system
is created in a short time, tested and improved upon in several steps.
• A prototype is an initial version of a system that is developed quickly
to test the effectiveness of the overall design being used to solve a
particular problem.
Analysis
Testing
Design
Modeling
• Advantages:
•
•
•
•
•
•
•
Customers can “see” the system requirements as they are being gathered
Developers learn from customers
A more accurate end product
Unexpected requirements accommodated
Allows for flexible design and development
Steady, visible signs of progress produced
Interaction with the prototype stimulates awareness of additional needed
functionality
• Disadvantages
• Tendency to abandon structured program development for “code-and-fix”
development
• Bad reputation for “quick-and-dirty” methods
• Overall maintainability may be overlooked
• The customer may want the prototype delivered
• Process may continue forever (scope creep)
• When to use the prototyping model
•
•
•
•
•
•
Requirements are unstable or have to be clarified
As the requirements clarification stage of a waterfall model
Develop user interfaces
Short-lived demonstrations
New, original development
With the analysis and design portions of object-oriented development
Spiral Model
• The Spiral Model is a non-linear model; it contains features from both
the Waterfall Model and prototyping.
• It adds a new element called ‘risk analysis’.
• The Spiral Model goes through all of its stages many times before a
system is released.
• Advantages
•
•
•
•
•
•
•
Provides early indication of insurmountable risks, without much cost
Users see the system early because of rapid prototyping tools
Critical high-risk functions are developed first
The design does not have to be perfect
Users can be closely tied to all life cycle steps
Early and frequent feedback from users
Cumulative costs assessed frequently
• Disadvantages
• Time spent for evaluating risks too large for small or low-risk projects
• Time spent planning, resetting objectives, doing risk analysis and prototyping
may be excessive
• The model is complex
• Risk assessment expertise is required
• Spiral may continue indefinitely
• Developers must be reassigned during non-development phase activities
• May be hard to define objective, verifiable milestones that indicate readiness
to proceed through the next iteration
When to use the spiral model
•
•
•
•
•
•
•
•
When creation of a prototype is appropriate
When costs and risk evaluation are important
For medium to high-risk projects
Long-term project commitment unwise because of potential changes to
economic priorities
Users are unsure of their needs
Requirements are complex
New product line
Significant changes are expected
Joint application development (JAD)
• JAD is a structured process, in which users, managers and systems
analysts work together for several days in a series of intensive
meetings to specify or review systems requirements.
Rapid application development (RAD)
• RAD is a team-based technique that is used to speed up the systems
development process.
• It produces a working system, which is very similar to prototyping.
• The fundamental principle of RAD is to delay producing detailed
systems design documents until user requirements are understood.
• Requirements planning phase (a workshop utilising structured
discussion of business problems)
• User description phase – automated tools capture information from
users
• Construction phase – productivity tools, such as code generators,
screen generators, etc. inside a time-box (“Do until done”)
• Cutover phase -- installation of the system, user acceptance testing
and user training
• Advantages
• Reduced cycle time and improved productivity with fewer people means
lower costs
• Time-box approach mitigates cost and schedule risk
• Customer involved throughout the complete cycle minimises risk of not
achieving customer satisfaction and business needs
• Focus moves from documentation to code (WYSIWYG).
• Uses modeling concepts to capture information about business, data, and
processes
• Disadvantages
•
•
•
•
•
Accelerated development process must give quick responses to the user
Risk of never achieving closure
Hard to use with legacy systems
Requires a system that can be modularized
Developers and customers must be committed to rapid-fire activities in an
abbreviated time frame
• When to use RAD
•
•
•
•
•
•
•
Reasonably well-known requirements
User involved throughout the life cycle
Project can be time-boxed
Functionality delivered in increments
High performance not required
Low technical risks
System can be modularised
Test your knowledge
• Toolbox activities
• Individual exercise 1
• Group exercise 1
• Research task 1
• Textbook activities
• Chapter 1: match the terms and definitions
• Chapter 1: review questions
• Chapter 1: Pine Valley Furniture case study
Test your knowledge
1. List and briefly explain the four phases of the SDLC. Draw a
diagram to illustrate the phases.
2. Identify the components of an information system.
3. Briefly describe the nine characteristics of a system.
4. Define decomposition, modularity, coupling and cohesion.
5. Differentiate between the different life cycle models.
Activity
Activity