1. Systems Analysis and Design
Unit 1

2. LO1 Understand the different systems life cycles Assessment criteria
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

3. 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.

4. 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.

5. 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

7. 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.

8. 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).

9. There are nine characteristics of a system, namely:
System components/sub-systems:
parts that, when put together, will make up a system.
Inter-related system components:
the level to which the components rely on each other or on other parts of a system.
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.
System purpose:
the main goal/function that a system will perform.

10. System environment: System interface: System constraints:
a system exists within a specific environment; this refers to everything external to a system that could interact with it.
System interface:
the point of contact where a system meets its environment; an interface can also occur between sub-systems.
System constraints:
any limitation that a system might have in terms of capacity, speed or functionality.
System input:
a system takes input from its environment to function.
System output:
a system provides output from received input and returns such to its environment; this marks that a system is achieving its purpose.

12. 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

14. 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.

15. 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.

16. 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.

17. 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.

18. 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.

19. 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.

20. 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.

21. 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.

22. 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.

23. SDLC phases
Products
1. Systems planning and
selection
 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
2. Systems analysis
 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
3. Systems design
 Detailed specifications of all systems elements
4. Systems
implementation and
operation
 Coding
 Documentation
 Training procedures and support capabilities
 New versions or releases of software with associated
updates to documentation, training and support

24. 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.

26. 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

27. 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

28. 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

29. 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.

30. Analysis
Design
Modeling
Testing

31. 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

32. 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)

33. 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

34. 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.

36. 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

37. 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

38. 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

39. 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.

40. 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.

43. 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

44. 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

45. 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

46. 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

47. Test your knowledge Toolbox activities Textbook 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

48. Test your knowledge
List and briefly explain the four phases of the SDLC. Draw a diagram to illustrate the phases.
Identify the components of an information system.
Briefly describe the nine characteristics of a system.
Define decomposition, modularity, coupling and cohesion.
Differentiate between the different life cycle models.

49. Activity

51. Activity