System Analysis and design

1. Chapter 3
Projects Planning/Selection Phase of SDLC
SDLC – Planning & Selection Phase
The Planning and Selection phase of the SDLC consists of a number of activities.
They are as follows:
 Needs Identification/Problem Definition
 Generation of alternative solutions
 Feasibility Study
 Preparation of Proposal/Baseline Project Plan
Each of these areas is outlined below.
The major deliverable from this phase is:
 The proposal (also known as Baseline Project Plan or Statement of Work or Statement of Requirements).
The Proposal includes information about all of the following:
 The Terms of Reference
 Project goal
 Scope
 Constraints
 A description of the proposed solution, at a conceptual level
 If a feasibility study was carried out, it includes a brief description of the alternatives considered, and why they were rejected
 The project plan - at a high level, showing the estimated timings, resources and schedules for the project

2. Needs Identification/Problem Definition
The first step is to identify a need for a system. The identified need can be the result of:
 finding shortcomings or problems in an existing system or process
 a requirement to provide information and/or reports from existing systems
 new features required in an existing system
 a new idea for which an information system is required
 a requirement to improve efficiency in the organization
 compulsory standards or benchmarks imposed by an external organization e.g. a government
 Needing to keep up with competitors.
Project identification and Initiation
 Unplanned System Requests
- Traditionally system owners and users initiate system projects as they are closer to the organizational activities
that need improvement
- Alternatively, systems analysts work on possible system improvements
- Both these can be called as unplanned system requests which are further screened and prioritized by a steering
committee of system owners.
 Planned System Requests
- Is the result of one of the following earlier projects

3.  An information System strategy plan examines the plan as whole to identify areas with greater return
 A business process redesign analyses a series of business processes to eliminate redundancy and
bureaucracy and to improve efficiency.
 Planned or unplanned, the force for most projects is some combinations of problems, opportunities or
directives
 Problems - are undesirable situations that prevent the organization from fully achieving its purpose, goals,
and/or objectives.
 Opportunities - are chances to improve the organization even in the absence of specific problems.
 Directives - are new requirements that are imposed by management, government, or some external influence.
 These problems, opportunities and directives can be generalized as PIECES
 P the need to improve performance
 I the need to improve information (and data)
 E the need to improve economics, control costs, or increase profits
 C the need to improve control or security
 E the need to improve efficiency of people and processes
 S the need to improve service to customers, suppliers, partners, employees, etc
 This is also known as establishing the project goal or problem definition.

4. Project Selection
 In a given organization, it is likely that many possible systems development projects may be identified at a
given time.
 The amount of resources available will mean that not all of the projects can be undertaken.
 In that case, it is necessary to select those projects most likely to yield benefits for the organization, given the
available resources.
 In larger organizations, this process of identification and selection tends to be more formal and rigorous and
may be part of an overall, higher-level planning process.
 In a smaller organization, the process may be informal, and may allow more independence for individual
departments and managers to select the projects with which they wish to continue.
The follow are some of the factors or criteria that are used to select projects:
 Perceived and real needs
 Existing and available resources
 List of potential and ongoing projects
 Current business conditions
 Evaluation criteria
 In addition to these, the perspectives of the decision-makers will influence the selection.

5. Generation of Alternative Solutions
 For an identified need, there are often several possible solutions.
 It is not always best to use the first suggested solution that comes up.
 Sometimes the solution is obvious, sometimes it is necessary to think about alternative solutions.
 Possible ways of doing this are:
1. Brainstorming – gather various people from the organization into one room, and get them all to talk and
think about possible ways of solving the problem. Such meetings should be facilitated i.e. there should be a
facilitator whose role it is to control the meeting, ensure the agenda is covered, ensure all attendees get to
contribute and ensure that all suggestions and discussions are documented.
2. Look at existing systems – internally or in other organizations, if possible.
Define Scope & Constraints
Defining Scope
 The project scope must be defined during this phase.
 The purpose of defining the scope is to define the boundary of the system and the project.
 The scope shows what aspects of the system will and will not be included in the project.

6.  To help to define the scope, the Systems Analyst should attempt to find answers to the following questions:
1) What units of the organization (business departments, functions and/or divisions) may use or be affected by
the proposed system?
2) What existing systems might the proposed system need to interact with, or which existing systems might be
changed by the proposed system?
3) Who, inside or outside the organisation, cares about the proposed system?
4) What functions, or capabilities, will the system include and what will it not be able to do?
Scope Creep
 Defining the scope at this stage will help to eliminate scope creep during the life cycle of the project. Scope
creep occurs when new functionality or requirements are added to the system later during the cycle (e.g. during
Analysis or Design). Often, these additions are small in size, but they can significantly impact the cost and
resources for the project. Many small additions could cause the project to be completed late or over budget.
 Sometimes it is necessary to increase the scope during the life of the project (e.g. if an essential function was
omitted during the needs identification) but generally it is preferable to try to keep scope creep to a minimum.
 Clearly defining the scope at this stage helps to make all involved people aware of what is and is not included.

7. Constraints
 Any factors that will limit the proposed solution or system should be documented at this stage. These are constraints
on the system. Constraints fall into the categories listed below:
1) Schedule – e.g. the new system must be in operation by March 17th
2004.
2) Cost – e.g. the budget for the new system is Birr100,000 so the total cost cannot exceed this amount
3) Technology – e.g. the organizations already has MS Access and the new system must use this database package, or
the application must run on Windows XP.
4) Policy – e.g. a particular method of accounting must be used
Feasibility Study
 In some cases, there may be a number of alternative solutions to be considered.
 It is then necessary to choose one as the most suitable solution. It is best to investigate as many alternatives as
possible to ensure that the best possible solution is selected.
This process is called the Feasibility Study.
 At this stage, the solutions considered need only be at a conceptual level. This means that it should give just a broad
idea of what the solution is, so that users and analysts can estimate if the solution can work and how much it is likely
to cost.
 There are a number of different areas which may need to be examined in terms of the feasibility of the project. These
are listed in Table 1 below. Note that it is not always necessary to examine all of these areas. Economic feasibility is
probably the most used, as it is always important to determine if a project will cost more than it will yield or save.

8. Areas for Feasibility Study
Economic feasibility
 Concerned with assessing the financial benefits and costs associated with the project. To do this, it is necessary
to quantify the monetary value of the costs and benefits of the project. This is also called a cost-benefit
analysis.
 Benefits and costs can be tangible or intangible.
 Tangibles are items which can be quantified in monetary terms and with certainty.
 Examples: equipment costs, staff/personnel costs, materials costs, conversion costs, training costs.
 Intangibles are items for which a value cannot be precisely determined, and where the value may be the result
of subjective judgement.
Examples: how much money is saved by completing a project earlier, or by providing new information to decision-
makers?
 The sum value of all the costs identified for the project gives the cost of the system.
 The sum value of all the benefits identified for the project gives the benefit of the system.
 These are then used to determine if the project is economically feasible.
 There are two methods of doing this – the payback method and the present value method

9. Operational feasibility
 Concerned with determining if the new system will be accepted by the organization, so that the objectives of
the system can be achieved. Answers to questions such as the following are required:
- Will the new system fit in with existing operations/systems?
- Will peoples’ jobs need to change or will they need retraining in order to use the new system?
- Are the members of staff happy to use the new system?
Technical feasibility
− Is the technology needed for the proposed system available; has it been proven (e.g. well used by other
organizations) and is there adequate support available for it?
− Is it possible to integrate the technology with the existing technical infrastructure in the organization and is the
necessary technical equipment available?
− Does the IT team have the expertise necessary to develop, build and maintain using the technology?
Schedule feasibility
− Are the deadlines for the project reasonable/achievable? The answer to this question must take into
consideration factors such as the skills of the IT team, and the availability of staff and other resources.
− In some cases, there may be a fixed deadline e.g. imposed by a government for a new regulation or dictated by
business needs such as the launch of a new product.

10. Legal & Contractual feasibility
 In some cases, there may be legal issues to consider. For example, many countries now have data protection
laws, designed to protect consumers from misuse of data held about them by organizations.
 Other areas include copyright laws and financial reporting standards.
Project Planning
 The activity of project planning takes place throughout the life cycle. It involves tracking the project progress
as well as revising the plan to take account of events as they occur. In many organisations, there is a specific job
role for project planning – the Project Manager (PM).
 In this phase, it is not possible to produce a detailed project plan – because there is not yet enough detailed
information about requirements. However, it is possible to produce a plan that shows the estimated timings for
each phase of the project.
 The ability to accurately estimate the times for each activity is a skill that is acquired with experience of
systems development projects. It is difficult to estimate the times required if you have not got experience of
carrying out each activity.
 The table below is an example of a high-level project plan.
 where possible, the responsible person or team should also be assigned to each task
 dates for starting each activity can be assigned, to show when the project is likely to be completed – note that
some activities must finish before the next one begins, while others can begin before the previous one has
finished. This is because there are dependencies between activities

11. Prepare Proposal
 The major deliverable from this phase is a document that provides all the information discovered during the
above activities.
 The name of the document and the format and content of it vary from one organization to another.
 In an organization where the IT/IS department carries out systems development for other departments, the
document acts as an agreement as to what the problem is, what the proposed solution is and what are the scope
and constraints for the proposed system.
 In the case where an outside supplier is providing the systems development service, this document acts as an
agreement between the supplier of the system/project and the customer. In this case, the document may need to
be more detailed – as it forms the basis of a legal agreement between the two parties, and a contract may also be
signed.
 The document may also be called a Baseline Project Plan or a Statement of Work or a Statement of
Requirements. The exact content and amount of detail in the document depends on the organization and the
participating parties.
 The document also includes project-planning information, such as:
 Schedule, at a high level (approximate timings for each of the subsequent phases)
 Estimated time of completion
 Resources required (people and equipment)

12.  The Proposal document will usually have sections for the following:
 Introduction – an overview of the project, and its objective.
 Scope & Constraints – describe the scope of the project, in words and/or with diagrams, and what constraints have been
identified.
 Proposed Solution – describe the proposed solution at a conceptual level; if a feasibility study was carried out, the rejected
solutions can be mentioned also, along with reasons for rejecting them.
 Schedule – indicate the estimated schedule for the project, showing also the estimated resources required to achieve the
completion date.
How to write a proposal
 Background of the Study
 Background of the Organization
 Statement of the problem
 Objectives of the Project
− General Objective of the Project
− Specific Objectives of the Project
 Methodology and Tools
− Data Collection Techniques- Interview, Observation, Document Analysis
− System Development Approach
− System Development Tools

13.  Scope of the Project
 Constraints of the Project
 Alternative Solutions
 Feasibility Study
− Legal Feasibility
− Economic Feasibility
− Technical Feasibility
− Operational Feasibility
 Proposed Solutions
 Significance of the Project
 Beneficiary of the Project
 Specifications for the Project
− Hardware requirements
− Software requirements
 Overall Cost Estimation
− Hardware Cost Estimation
− Software Cost Estimation
 Schedule of the Project

14.  System analysis
 Detailed Study of the Existing System
 Overview of the New System
 Input and Output of the New System
 Requirement Analysis
 User Requirements
− Functional Requirements
− Non-functional Requirements
 System Analysis Methods
 System Analysis Models
− Use Case Diagram
− Use Case Identification
− Use Case Description
− Sequence Diagram
− Activity Diagram
− Class Diagram
− Deployment Diagram
− Collaboration Diagram
− Component Diagram

15.  Implementation
 System design
 Testing
− Unit Testing
− Integration Testing
− Acceptance Testing
− System Testing
− Maintenance
− Evaluation
− Installation
− Sample Code
 User Interfaces
 Conclusion
 Recommendation