Lecture 2

Source: PEC IPT Preliminary Course – Samuel Davis & Jacaranda IPT Preliminary Course
IPT Preliminary – Carole Wilson
 Understanding the Problem
 Planning or Making Decisions
 Designing Solutions
 Implementing Solutions
 Testing, Evaluating and Maintaining
 Aims to determine the purpose and requirements of the new
system
 After establishing the requirements, a requirements report is
created
 A system analyst is responsible for analysing the existing system,
determining requirements and then designing the new information
system
 What is a requirement?
Feature, property or behaviour a system must have to achieve its purpose

 Deliverable: Requirements Report

 Interview/survey users of the existing system
 Interview/survey participants
 Analysing the existing system by determining
 How it works
 What it does
 Who uses it
 Primary concern is to fulfil the needs of the users
 Users are people who utilise the information created by the
system
 Interviews and surveys help collect information about user
experiences, problems with the existing system, their needs
and any new ideas that could improve the system
 Participants of the existing system has an understanding of
the part of the system with which they interact
 Participants can identify problems and also have ideas about
solving these problems
 Results of participant surveys/interviews can be used to
create models of the existing system as well as creating the
final requirements report
 Expresses a complete set of requirements for the new system
 This is the most important deliverable from the first stage of
SDLC
 It specifies the inputs and outputs and their relationship to
each other
 It should be understandable to the client as well as have
technical specification for the new system for the developers
 Each party understanding the requirements report is essential
as all subsequent stages of SDLC rely on it
 The process of preparing requirements report is known as
‘requirements analysis’
 Requirements report is the blue print of what the system will do
 When making decisions it is used to determine possible
options and their feasibility
 When designing solutions, the aim is to achieve all the
requirements in it
 Testing and evaluation involve checking whether the
requirements have been met
 Is a working model of an information system, built in order to
understand the requirements of the system
 Aims to confirm, clarify and better understand the requirements
 Accurately simulates the look and behaviour of the final
application using screen mock-ups and sample reports
 Does not contain any real processing
 A sequence of requirements prototypes is produced with each
new prototype as a refinement of the previous version in
response to feedback
 Visual nature of requirements prototypes is important for
confirming understanding
 Final prototype can be used exclusively to refine the
requirements or as the basis for development of the real
system
 Understanding the Problem
 Planning or Making Decisions
 Designing Solutions
 Implementing Solutions
 Testing, Evaluating and Maintaining
 Aims to decide which possible solution, if any, should be
developed and then decide how it should be developed and
managed
 Analyses the feasibility of developing the new system to create
the feasibility study report
 Feasibility study assesses whether a solution is capable of being
achieved using the available resources and meeting the
identified requirements
 May not have a feasible solution to recommend (existing system
will remain)
Deliverable: Feasibility Report
 Financial/economic feasibility

 Technical feasibility

 Operational feasibility

 Scheduling feasibility
 Also known as budgetary, economic or cost feasibility
 Proposed solutions are costed
 Should consider development, training and maintenance
costs
 Can the organisation afford the cost?
 May be done by a financial analyst
 Cost-benefit analysis will examine expenses and income
expected in minute detail
 Covers two areas
 Ability of the users and participants to use the
system
e.g. technical expertise

 Availability of information technology (both

hardware and software)
 Evaluate whether the solution will work in practice
 Considers support for the new system from
management and existing employees
 Should consider possible change in nature of work
 Aims to determine whether the solution can be
completed on time
 Scheduling should include extra time to allow for the
unexpected
 Gantt chart is a useful tool
 Agreed dates are vital
 Should also examine consequences of delays
 There are number of system development approaches
 They can be used in isolation or combined to form a suitable
system development approach
 Different approaches
 Traditional
 Outsourcing
 Prototyping
 Customisation
 Participant development
 Agile method
 Involves very formal step-by-step stages
 Each stage must be completed before
progressing to the next
 Each stage produces detailed deliverables that
become inputs to the next stage
 Also known as structured or waterfall approach
 No opportunity to return to previous stage and
few opportunities to provide ongoing feedback
 Involves using another company to develop parts of the
system or even the complete system
 Cost effective to outsource specialised tasks to an
experienced company than employing new staff or training
existing staff
 Specially done when requiring highly specialised skills that are
not needed when system is operational
 Main aim is to verify and determine the
requirements for a new system
 This approach extends the use of prototype
such that it evolves to become the final
solution
 Iteration through the loop containing
designing, testing & evaluating and
understanding the problem produces
enhancements
 When the prototype successfully meet the
requirements it is ready for
implementation
 This approach is well suited to
development of software components
 When creating a completely new system is economically
unviable, an existing system customised to suit the needs of
the new system
e.g. hotels customising commercial software to suit them

 Involve alterations to the system settings within the hardware

and software
 Same people who use and operate the final system develop the
system
 Speeds up development as users and participants determine the
requirements not requiring to consult widely
 Disadvantages
 User must have sufficient skills to create the system and understand the extent of
their skills
 Generally user developed systems are of lower quality than ones developed
professionally

 Suitable for systems used by developer/user and few others

 Advantageous for small business and home users who cannot afford
professional solution
 Places emphasis on the team developing
the system rather than following predefined
structured development processes
 Does not need detailed requirements and
complex design documentation
 Initially determines the general nature of
the problem, create a basic plan and a
design with minimal details
 Then the initial solution is created and
tested, evaluated and implemented
 The solution is used by users and participants
and provide feedback and make suggestions
about further additions
 These suggestions and feedback become the
focus of next part of the design
 This process repeats many times with each
iteration implementing further functionality
 One main issue is constructing agreements
when outsourcing the development due to
lack of detailed requirements
 Identifies participants
 Includes mechanisms for obtaining their feedback

 Identifies relevant information technology

 Includes hardware and software for the new system

 Identifies data (input) and information (output)

 Documents how and when the data needed for testing is obtained

 Identifies the needs of the users

 When using iterative prototyping and agile methods, project
management techniques and the requirements report must be flexible

 Details the time frame

 Details the subprojects and their time frames