THE SYSTEMS ANALYST
The systems analyst plays a key role in information systems development projects. The systems analyst works
closely with all project team members so that the team develops the right system in an effective way. Systems
analysts must understand how to apply technology to solve business problems. In addition, systems analysts
may serve as change agents who identify the organizational improvements needed, design systems to
implement those changes, and train and motivate others to use the systems.
SYSTEMS ANALYST SKILLS
New information systems introduce change to the organization and its people. Leading a successful
organizational change effort is one of the most difficult jobs that someone can do. Understanding what to
change, knowing how to change it, and convincing others of the need for change require a wide range of skills.
These skills can be broken down into six major categories: technical, business, analytical, interpersonal,
management, and ethical.
Analysts must have the technical skills to understand the organization’s existing technical environment, the
new system’s technology foundation, and the way in which both can be fit into an integrated technical solution.
Business skills are required to understand how IT can be applied to business situations and to ensure that the
IT delivers real business value. Analysts are continuous problem solvers at both the project and the
organizational level, and they put their analytical skills to the test regularly.
Often, analysts need to communicate effectively, one-on-one with users and business managers (who often
have little experience with technology) and with programmers (who often have more technical expertise than
the analyst does). They must be able to give presentations to large and small groups and to write reports. Not
only do they need to have strong interpersonal abilities, but they also need to manage people with whom they
work, and they must manage the pressure and risks associated with unclear situations.
Finally, analysts must deal fairly, honestly, and ethically with other project team members, managers, and
system users. Analysts often deal with confidential information or information that, if shared with others, could
cause harm (e.g., dissent among employees); it is important for analysts to maintain confidence and trust with
all people.
SYSTEMS ANALYST ROLES
As organizations and technology have become more complex, most large organizations now build project teams
that incorporate several analysts with different, but complementary, roles. In smaller organizations, one person
may play several of these roles. Here we briefly describe these roles and how they contribute to a systems
development project.
The systems analyst role focuses on the IS issues surrounding the system. This person develops ideas and
suggestions for ways that IT can support and improve business processes, helps design new business processes
supported by IT, designs the new information system, and ensures that all IS standards are maintained. The
systems analyst will have significant training and experience in analysis and design and in programming.
The business analyst role focuses on the business issues surrounding the system. This person helps to identify
the business value that the system will create, develops ideas for improving the business processes, and helps
design new business processes and policies. The business analyst will have business training and experience,
plus knowledge of analysis and design.
The project manager role ensures that the project is completed on time and within budget and that the system
delivers the expected value to the organization. The project manager is often a seasoned systems analyst who,
through training and experience, has acquired specialized project management knowledge and skills. More will
be said about the project manager in the next chapter.
THE SYSTEMS DEVELOPMENT LIFE CYCLE
The systems development life cycle (SDLC) is the process of determining how an information system (IS) can
support business needs, designing the system, building it, and delivering it to users.
It is important to understand that the SDLC is a process of gradual refinement. The deliverables produced in the
analysis phase provide a general idea what the new system will do. These deliverables are used as input to the
design phase, which then refines them to produce a set of deliverables that describes in much more detailed
terms exactly how the system should be built. These deliverables in turn are used in the implementation phase
to guide the creation of the actual system. Each phase refines and elaborates on the work done previously.
PLANNING
The planning phase is the fundamental process of understanding why an information system should be built
and determining how the project team will go about building it. It has two steps:
1. During project initiation, the system’s business value to the organization is identified—how will it lower
costs or increase revenues? Most ideas for new systems come from outside the IS area (from the marketing
department, accounting department, etc.) in the form of a system request. A system request presents a brief
summary of a business need, and it explains how a system that supports the need will create business value.
The IS department works together with the person or department generating the request (called the project
sponsor) to conduct a feasibility analysis. The feasibility analysis examines key aspects of the proposed project:



The technical feasibility (Can we build it?)
The economic feasibility (Will it provide business value?)
The organizational feasibility (If we build it, will it be used?)
The system request and feasibility analysis are presented to an information systems approval committee
(sometimes called a steering committee), which decides whether the project should be undertaken.
2. Once the project is approved, it enters project management. During project management, the project
manager creates a work plan, staffs the project, and puts techniques in place to help the project team control
and direct the project through the entire SDLC. The deliverable for project management is a project plan that
describes how the project team will go about developing the system.
ANALYSIS
The analysis phase answers the questions of who will use the system, what the system will do, and where and
when it will be used. During this phase, the project team investigates any current system(s), identifies
improvement opportunities, and develops a concept for the new system. This phase has three steps:
1. An analysis strategy is developed to guide the project team’s efforts. Such a strategy usually includes a study
of the current system (called the as-is system) and its problems, and envisioning ways to design a new system
(called the to-be system).
2. The next step is requirements gathering (e.g., through interviews, group workshops, or questionnaires).
The analysis of this information—in conjunction with input from the project sponsor and many other people—
leads to the development of a concept for a new system. The system concept is then used as a basis to develop a
set of business analysis models that describes how the business will operate if the new system were developed.
The set typically includes models that represent the data and processes necessary to support the underlying
business process.
3. The analyses, system concept, and models are combined into a document called the system proposal, which
is presented to the project sponsor and other key decision makers (e.g., members of the approval committee)
who will decide whether the project should continue to move forward. The system proposal is the initial
deliverable that describes what business requirements the new system should meet.
DESIGN
The design phase decides how the system will operate in terms of the hardware, software, and network
infrastructure that will be in place; the user interface, forms, and reports that will be used; and the specific
programs, databases, and files that will be needed. Although most of the strategic decisions about the system
are made in the development of the system concept during the analysis phase, the steps in the design phase
determine exactly how the system will operate. The design phase has four steps:
1. The design strategy must be determined. This clarifies whether the system will be developed by the
company’s own programmers, whether its development will be outsourced to another firm (usually a
consulting firm), or whether the company will buy an existing software package.
2. This leads to the development of the basic architecture design for the system that describes the hardware,
software, and network infrastructure that will be used. In most cases, the system will add to or change the
infrastructure that already exists in the organization. The interface design specifies how the users will move
through the system (e.g., by navigation methods such as menus and on-screen buttons) and the forms and
reports that the system will use.
3. The database and file specifications are developed. These define exactly what data will be stored and
where they will be stored.
4. The analyst team develops the program design, which defines the programs that need to be written and
exactly what each program will do.
This collection of deliverables (architecture design, interface design, database and file specifications, and
program design) is the system specification that is used by the programming team for implementation. At the
end of the design phase, the feasibility analysis and project plan are reexamined and revised, and another
decision is made by the project sponsor and approval committee about whether to terminate the project or
continue.
IMPLEMENTATION
The final phase in the SDLC is the implementation phase, during which the system is actually built (or
purchased, in the case of a packaged software design and installed). This is the phase that usually gets the most
attention, because for most systems it is the longest and most expensive single part of the development
process. This phase has three steps:
1. System construction is the first step. The system is built and tested to ensure that it performs as designed.
Since the cost of fixing bugs can be immense, testing is one of the most critical steps in implementation. Most
organizations spend more time and attention on testing than on writing the programs in the first place.
2. The system is installed. Installation is the process by which the old system is turned off and the new one is
turned on. There are several approaches that may be used to convert from the old to the new system. One of the
most important aspects of conversion is the training plan, used to teach users how to use the new system and
help manage the changes caused by the new system.
3. The analyst team establishes a support plan for the system. This plan usually includes a formal or informal
post-implementation review, as well as a systematic way for identifying major and minor changes needed for
the system.
PROJECT METHODOLOGY OPTIONS
The Systems Development Life Cycle (SDLC) provides the foundation for the processes used to develop an
information system. A methodology is a formalized approach to implementing the SDLC (i.e., it is a list of steps
and deliverables). There are many different systems development methodologies, and they vary in terms of the
progression that is followed through the phases of the SDLC. Here we will review several of the predominant
methodologies that have evolved over time.
WATERFALL DEVELOPMENT
With waterfall development, analysts and users proceed sequentially from one phase to the next. The key
deliverables for each phase are typically voluminous (often, hundreds of pages) and are presented to the
approval committee and project sponsor for approval as the project moves from phase to phase. Once the work
produced in one phase is approved, the phase ends and the next phase begins. As the project progresses from
phase to phase, it moves forward in the same manner as a waterfall. While it is possible to go backward through
the phases (e.g., from design back to analysis), it is quite difficult. (Imagine yourself as a salmon trying to swim
upstream in a waterfall).
Waterfall development methodologies have the advantages of identifying requirements long before
programming begins and limiting changes to the requirements as the project proceeds. The key disadvantages
are that the design must be completely specified before programming begins, a long time elapses between the
completion of the system proposal in the analysis phase and the delivery of system, and testing is treated
almost as an afterthought in the implementation phase. In addition, the deliverables are often a poor
communication mechanism, so important requirements may be overlooked in the volumes of documentation. If
the project team misses an important requirement, expensive post-implementation programming may be
needed. Users may forget the original purpose of the system, since so much time has elapsed between the
original idea and actual implementation. Also, in today’s dynamic business environment, a system that met the
existing environmental conditions during the analysis phase may need considerable rework to match the
environment when it is implemented. This rework requires going back to the initial phase and making needed
changes through each of the subsequent phases in turn.
PARALLEL DEVELOPMENT
The parallel development methodologies evolved to address the lengthy time frame of waterfall development.
Instead of doing the design and implementation in sequence, a general design for the whole system is
performed. Then the project is divided into a series of subprojects that can be designed and implemented in
parallel. Once all subprojects are complete, there is a final integration of the separate pieces, and the system is
delivered.
Parallel development reduces the time required to deliver a system, so changes in the business environment
are less likely to produce the need for rework. The approach still suffers from problems caused by voluminous
deliverables. It also adds a new problem: If the subprojects are not completely independent, design decisions in
one subproject may affect another, and at the project end, integrating the subprojects may be quite challenging.
RAPID APPLICATION DEVELOPMENT (RAD)
Rapid application development is a collection of methodologies that emerged in response to the weaknesses of
waterfall development and its variations. RAD incorporates special techniques and computer tools to speed up
the analysis, design, and implementation phases in order to get some portion of the system developed quickly
and into the hands of the users for evaluation and feedback. CASE (computer-aided software engineering) tools,
JAD (joint application development) sessions, fourth-generation/visual programming languages (e.g., Visual
Basic.NET), and code generators may all play a role in RAD. While RAD can improve the speed and quality of
systems development, it may also introduce a problem in managing user expectations. As systems are
developed more quickly and users gain a better understanding of information technology, user expectations
may dramatically increase and system requirements may expand during the project (sometimes known as
scope creep or feature creep)
RAD - ITERATIVE DEVELOPMENT (PHASED-BASED)
Iterative development breaks the overall project into a series of versions that are developed sequentially. The
most important and fundamental requirements are bundled into the first version of the system. This version is
developed quickly by a mini-waterfall process, and once implemented, the users can provide valuable feedback
to be incorporated into the next version of the system. Iterative development gets a preliminary version of the
system to the users quickly so that business value is provided. Since users are working with the system,
important additional requirements may be identified and incorporated into subsequent versions. The chief
disadvantage of iterative development is that users begin to work with a system that is intentionally
incomplete. Users must accept that only the most critical requirements of the system will be available in the
early versions and must be patient with the repeated introduction of new system versions
RAD - SYSTEM PROTOTYPING
System prototyping performs the analysis, design, and implementation phases concurrently in order to quickly
develop a simplified version of the proposed system and give it to the users for evaluation and feedback. The
system prototype is a “quick and dirty” version of the system and provides minimal features. Following
reaction and comments from the users, the developers reanalyze, redesign, and reimplement a second
prototype that corrects deficiencies and adds more features. This cycle continues until the analysts, users, and
sponsor agree that the prototype provides enough functionality to be installed and used in the organization.
System prototyping very quickly provides a system for users to evaluate and reassures users that progress is
being made. The approach is very useful when users have difficulty expressing requirements for the system. A
disadvantage, however, is the lack of careful, methodical analysis prior to making design and implementation
decisions. System prototypes may have some fundamental design limitations that are a direct result of an
inadequate understanding of the system’s true requirements early in the project.
AGILE DEVELOPMENT
Agile development is a group of programming-centric methodologies that focus on streamlining the SDLC.
Much of the modeling and documentation overhead is eliminated; instead, face-to-face communication is
preferred. A project emphasizes simple, iterative application development in which every iteration is a
complete software project, including planning, requirements analysis, design, coding, testing, and
documentation. Cycles are kept short (one to four weeks), and the development team focuses on adapting to
the current business environment. There are several popular approaches to agile development, including
extreme programming (XP)8, Scrum9, and dynamic systems development method (DSDM).10 Here, we briefly
describe extreme programming.
EXTREME PROGRAMMING emphasizes customer satisfaction and teamwork. Communication, simplicity,
feedback, and courage are core values. Developers communicate with customers and fellow programmers.
Designs are kept simple and clean. Early and frequent testing provides feedback, and developers are able to
courageously respond to changing requirements and technology. Project teams are kept small.
An XP project begins with user stories that describe what the system needs to do. Then, programmers code in
small, simple modules and test to meet those needs. Users are required to be available to clear up questions and
issues as they arise. Standards are very important to minimize confusion, so XP teams use a common set of
names, descriptions, and coding practices. XP projects deliver results sooner than even the RAD approaches,
and they rarely get bogged down in gathering requirements for the system.
For small projects with highly motivated, cohesive, stable, and experienced teams, XP should work just fine.
However, if the project is not small or the teams aren’t jelled, then the likelihood of success for the XP project is
reduced. Consequently, the use of XP in combination with outside contractors produces a highly questionable
outcome, since the outside contractors may never “jell” with insiders. XP requires a great deal of discipline to
prevent projects from becoming unfocused and chaotic. Furthermore, it is recommended only for small groups
of developers (not more than 10), and it is not advised for mission-critical applications. Since little analysis and
design documentation is produced with XP, there is only code documentation; therefore, maintenance of large
systems developed using XP may be impossible. Also, since mission-critical business information systems tend
to exist for a long time, the utility of XP as a business information system development methodology is in doubt.
Finally, the methodology requires considerable on-site user input, something that is frequently difficult to
obtain.
SELECTING THE APPROPRIATE DEVELOPMENT METHODOLOGY
CLARITY OF USER REQUIREMENTS
1. Unclear user requirements pose challenges in understanding and explaining them through discussions and
reports.
2. User interaction with the technology is essential to fully grasp its capabilities.
3. System prototyping and throwaway prototyping are effective approaches for unclear requirements,
providing early prototypes for user testing.
4. Agile development is well-suited when on-site user input is available, enabling iterative development and
incorporating user feedback.
FAMILIARITY WITH TECHNOLOGY
1. Early adoption of unfamiliar technology increases success chances.
2. Lack of familiarity with the base technology raises risks and limits capabilities.
3. Throwaway prototyping is apt for high-risk areas with unfamiliar technology, facilitating design prototypes.
4. Iterative development enables thorough exploration of the technology before finalizing the design.
5. System prototyping is less effective as early prototypes may not fully address complexities, leading to issues
later on.
SYSTEM COMPLEXITY
1. Complex systems require careful analysis and design.
2. Throwaway prototyping is well-suited for detailed analysis and design, while system prototyping is not as
effective.
3. Waterfall methodologies can handle complex systems but may overlook key issues without early user
involvement.
4. Iterative development methodologies enable early user interaction but may result in less emphasis on
comprehensive problem domain analysis.
SYSTEM RELIABILITY
1. System reliability is a crucial factor in system development.
2. The importance of reliability varies across different applications.
3. The V-model is valuable for emphasizing testing when reliability is important.
4. Throwaway prototyping is suitable for high reliability priority, allowing testing of different design
approaches alongside detailed analysis and design.
5. System prototyping is generally not recommended for critical reliability requirements due to the lack of
meticulous analysis and design phases necessary for dependable systems.
SHORT TIME SCHEDULES
1. Short time schedules are ideal for RAD methodologies.
2. Iterative development and system prototyping are excellent choices for quick timelines.
3. Adjustments to functionality can be made based on specific delivery dates.
4. Functionality can be removed from the version or prototype to readjust the schedule if needed.
5. Waterfall-based methodologies are unsuitable for limited time as they lack flexibility for schedule changes.
SCHEDULE VISIBILITY
1. Schedule visibility is a challenge in systems development.
2. Waterfall methodologies hinder schedule assessment as design and implementation happen late.
3. RAD methodologies address this by moving critical design decisions earlier.
4. Early design decisions in RAD aid risk management and expectation alignment.