SYSTEMS DEVELOPMENT TOOLS AND TECHNIQUES

In addition to understanding business operations, systems analyst must know how to use a
variety of techniques, such as modeling, prototyping, and computer-aided systems engineering
tools to plan in a team environment, where input from users, managers, and IT staff contributes
to the system design.

MODELING
Modeling produces a graphical representation of a concept or process that systems developers
can analyze, test, and modify.
A system analyst can describe and simplify an information system by using a set of business,
data, object, network, and process models.
A business model, or requirements model, describes the information that a system must
provide. A data model describes data structure and design; An object model describes objects,
which combine data and processes; A network model describes the design and protocols of
telecommunications link and a process model describes the logic that programmers use to
write code modules.
Although the models might appear to overlap, they actually work together to describe the
same environment from different points of view.

PROTOTYPING
Prototyping tests system concepts and provides an opportunity to examine input, output, and
user interfaces before final decisions are made. A prototype is an early working version of an
information system.
Just as an aircraft manufacturer tests a new design in a wind tunnel, systems analysts
construct and study information systems prototypes. A prototype can serve as an initial model
that is used as benchmark to evaluate the finished system, or the prototype itself can develop
into the final version of the system. Either way, prototyping speeds up the development
process significantly.
A possible disadvantage of prototyping is that important decisions might be made too
early, before business or IT issues are understood thoroughly. A prototype based on careful fact
finding and modeling techniques, however can be an extremely valuable tool.

COMPUTER-AIDED SYSTEM ENGINEERING (CASE) TOOLS

Computer-aided systems engineering (CASE), also called computer-aided software engineering,
is a technique that uses powerful software, called CASE Tools, to help system s analyst’s
develop and maintain information systems.

CASE tools provide an overall framework for systems development and support a wide variety
of design methodologies, including structured analysis and object-oriented analysis.
Because CASE tools make it easier to build an information system, they boost its productivity
and improves the quality of the finished product.

In addition to traditional CASE tools, system developers often use project management tools,
such as Microsoft Project, and special –purpose charting tools, such as Microsoft Visio. A
system analyst’s can use Visio to create many different types of diagrams, including block
diagrams, building plans, forms and charts, maps, network diagrams, and organization charts.

1
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
 SYSTEMS ANALYSIS METHODS
Qn. Differentiate between systems analysis and systems design.

 Systems analysis: it is a problem-solving technique that decomposes a system into

its component pieces for the purpose of studying how well those component parts
work and interact to accomplish their purpose.

Systems design: a complementary problem-solving technique to systems analysis that

reassembles a system’s component pieces back into a complete system
Stages of systems analysis
 Fact finding
 Understanding the current system
 Produce the data flow diagrams
 Identify the user requirements
 Interpret the user requirements
 Agree with the objectives of the user
 Collect the data from the current system

SYSTEMS ANALYSIS PHASES

1. Scope Definition Phase
• Is the project worth looking at?
2. Problem Analysis Phase
• Is a new system worth building?
3. Requirements Analysis Phase
• What do the users need and want from the new system?
4. Logical Design Phase
• What must the new system do? THE PHASE MUST EXPLAIN WAT THE SYSTEM
MUST DO.
5. Decision Analysis Phase
• What is the best solution?

Key Terms for Scope Definition Phase

Steering body – a committee of executive business and system managers that studies and
prioritizes competing project proposals to determine which projects will return the most value
to the organization and thus should be approved for continues systems development.
• Also called a steering committee.
Project charter – the final deliverable for the preliminary investigation phase. A project
charter defines the project scope, plan, methodology, standards, and so on.
• Preliminary master plan includes preliminary schedule and resource assignments
(also called a baseline plan).
• Detailed plan and schedule for completing the next phase of the project.

Key Terms of the Problem Analysis Phase

 Cause-and-effect analysis – a technique in which problems are studied to determine

their causes and effects.
In practice, effects can be symptomatic of more deeply rooted problems which, in turn,
must be analyzed for causes and effects until the causes and effects do not yield symptoms of
other problems.
 Context Diagram – a pictorial model that shows how the system interacts with the
world around it and specifies in general terms the system inputs and outputs.
 Objective – a measure of success. It is something that you expect to achieve, if given
sufficient resources.
• Reduce the number of uncollectible customer accounts by 50 percent within the
next year.
2
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
 • Increase by 25 percent the number of loan applications that can be processed
during an eight-hour shift.
• Decrease by 50 percent the time required to reschedule a production lot when a
workstation malfunctions.

 Constraint – something that will limit your flexibility in defining a solution to your
objectives. Essentially, constraints cannot be changed.
• The new system must be operational by April 15.
• The new system cannot cost more than $350,000.
• The new system must be web-enabled.
• The new system must bill customers every 15 days.

Key Terms of Requirements Analysis Phase

 Functional requirement – a description of activities and services a system must

provide.
• inputs, outputs, processes, stored data
 Nonfunctional requirement – a description of other features, characteristics, and
constraints that define a satisfactory system.
• Performance, ease of learning and use, budgets, deadlines, documentation,
security, internal auditing controls
 Use case – a business scenario or event for which the system must provide a defined
response. Use cases evolved out of object-oriented analysis; however, their use has
become common in many other methodologies for systems analysis and design

 Time boxing – a technique that delivers information systems functionality and

requirements through versioning.
1. The development team selects the smallest subset of the system that, if fully
implemented, will return immediate value to the systems owners and users.
2. That subset is developed, ideally with a time frame of six to nine months or less.
3. Subsequently, value-added versions of the system are developed in similar time
frames.

NOTE 1 -A mandatory requirement is one that must be fulfilled by the minimal system,
version 1.0
NOTE2- A desirable requirement is one that is not absolutely essential to version 1.0. It may
be essential to the vision of a future version.

Key Terms of Decision Analysis Phase

• Technical feasibility – Is the solution technically practical? Does our staff have the
technical expertise to design and build this solution?
• Operational feasibility – Will the solution fulfill the users’ requirements? To what
degree? How will the solution change the users’ work environment? How do users feel
about such a solution?
• Economic feasibility – Is the solution cost-effective?
• Schedule feasibility – Can the solution be designed and implemented within an
acceptable time period?

SYSTEM ANALYSIS APPROACHES

There are two major approaches of system analysis and can be summarized as below.

1. Model driven approach (has 3 types)

 Structured analysis
 Information engineering
 Object oriented analysis
2. Accelerated systems analysis (has two types)
 Discovery prototyping
3
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
  Rapid architected analysis

MODEL DRIVEN APPROACH IN DETAILS

This is a problem-solving approach that emphasizes the drawing of pictorial system models to
document and validate both existing and/or proposed systems. Ultimately, the system model
becomes the blueprint for designing and constructing an improved system.
Model – a representation of either reality or vision. Since “a picture is worth a thousand
words,” most models use pictures to represent the reality or vision.

TYPES OF MODEL DRIVEN APPROACH

 STRUCTURED ANALYSIS
It is a systematic approach, which uses graphical tools that analyze and refine the objectives of
an existing system and develop a new system specification which can be easily understandable
by user.

Structured analysis uses a set of processes models to describe a system graphically. Because it
focuses on processes that transform data in useful information, structured analysis is called a
process-centered technique.
In addition to modeling the processes, structured analysis includes data organization and
structure, relational database design and user interfaces issue.
Process modeling identifies the data flowing into a process, the business rules that transform
the data, and the resulting output data flow.
ATTRIBUTES OF STRUCTURED ANALYSIS
It has following attributes:
 It is graphic which specifies the presentation of application.
 It divides the processes so that it gives a clear picture of system flow.
 It is logical rather than physical i.e., the elements of system do not depend on vendor or
hardware.
 It is an approach that works from high-level overviews to lower-level details.

Key tools/models of Structured Analysis

During Structured Analysis, various tools and techniques are used for system development.
They are:
 Data Flow Diagrams
 Data Dictionary
 Decision Trees
 Decision Tables
 Structured English
 Pseudo code

4
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
Data Flow Diagrams (DFD) or Bubble Chart
 It shows the flow of data between various functions of system and specifies how the
current system is implemented.
 It is an initial stage of design phase that functionally divides the requirement
specifications down to the lowest level of detail.
 Its graphical nature makes it a good communication tool between user and analyst or
analyst and system designer.
 It gives an overview of what data a system processes, what transformations are
performed, what data are stored, what results are produced and where they flow.

Basic Elements of DFD

DFD is easy to understand and quite effective when the required design is not clear and the
user wants a notational language for communication. However, it requires a large number of
iterations for obtaining the most accurate and complete solution

The following table shows the symbols used in designing a DFD and their significance:

Symbol Name Symbol Meaning

Square Source or Destination of Data

Arrow Data flow

Circle Process transforming data flow

Open Rectangle Data Store

Types of DFD
DFDs are of two types: Physical DFD and Logical DFD. The following table lists the points that
differentiate a physical DFD from a logical DFD.
Physical DFD Logical DFD

It is implementation dependent. It It is implementation independent. It

shows focuses
Which functions are only on the flow of data between
performed. processes.

It provides low level details of It explains events of systems and

hardware, data
software, files, and people. required by each event.

It depicts how the currentsystem It shows how business operates; not

how
operates and how a system will be
the system can be implemented.
Implemented.

Data Dictionary

A data dictionary is a structured repository of data elements in the system. It stores the
descriptions of all DFD data elements that is, details and definitions of data flows, data stores,
data stored in data stores, and the processes.
5
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
A data dictionary improves the communication between the analyst and the user. It plays an
important role in building a database. Most DBMSs have a data dictionary as a standard
feature. For example, refer the following table:

Sr. No. Data Name Description No. of Characters

1 ISBN ISBN Number 10

2 TITLE Title 60

3 SUB Book Subjects 80

4 ANAME Author Name 15

Decision Trees

Decision trees are a method for defining complex relationships by describing decisions and
avoiding the problems in communication. A decision tree is a diagram that shows alternative
actions and conditions within horizontal tree framework. Thus, it depicts which conditions to
consider first, second, and so on.

Decision trees depict the relationship of each condition and their permissible actions. A square
node indicates an action and a circle indicates a condition. It forces analysts to consider the
sequence of decisions and identifies the actual decision that must be made.

The major limitation of a decision tree is that it lacks information in its format to describe what
other combinations of conditions you can take for testing. It is a single representation of the
relationships between conditions and actions.

Decision Tables

Decision tables are a method of describing the complex logical relationship in a precise manner
which is easily understandable.
 It is useful in situations where the resulting actions depend on the occurrence of one or
several combinations of independent conditions.
 It is a matrix containing row or columns for defining a problem and the actions.

Structured English

Structure English is derived from structured programming language which gives more
understandable and precise description of process. It is based on procedural logic that uses
6
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
construction and imperative sentences designed to perform operation for action.

 It is best used when sequences and loops in a program must be considered and the
problem needs sequences of actions with decisions.
 It does not have strict syntax rule. It expresses all logic in terms of sequential decision
structures and iterations.

For example, see the following sequence of actions:

if customer pays advance then

Give 5% Discount
Else
if purchase amount >=10,000 then
if the customer is a regular customer
then Give 5% Discount
else No Discount

Pseudocode

A pseudocode does not conform to any programming language and expresses logic in plain
English.
 It may specify the physical programming logic without actual coding during and after the
physical design.
 It is used in conjunction with structured programming.
 It replaces the flowcharts of a program.

Guidelines for Selecting Appropriate Tools

Use the following guidelines for selecting the most appropriate tool that would suit your
requirements:

 Use DFD at high or low level analysis for providing good system documentations.
 Use data dictionary to simplify the structure for meeting the data requirement of the
system.
 Use structured English if there are many loops and actions are complex.
 Use decision tables when there are a large number of conditions to check and logic is
complex.
 Use decision trees when sequencing of conditions is important and if there are few
conditions to be tested.

 INFORMATION ENGINEERING
Information engineering ( IE) or information engineering methodology ( IEM ) is a software
engineering approach to designing and developing information systems . It can also be
considered as the generation, distribution, analysis and use of information in systems.
Information engineering involves an architectural approach for planning, analyzing, designing,
and implementing applications. It focuses on structure of stored data and uses entity
relationship diagram as its key model.
Information engineering has many purposes, including organization planning, business re-
engineering, application development, information systems planning and systems re-
engineering.

 OBJECT –ORIENTED ANALYSIS

In the object-oriented approach, the focus is on capturing the structure and behavior of
information systems into small modules (objects) that combines both data and process. The
main aim of Object Oriented Design (OOD) is to improve the quality and productivity of system
analysis and design by making it more usable.

7
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
The result is a set of software objects that represent actual people, things, transaction, and
events. Using an O-O programming language, a programmer then writes the code that creates
the objects.
In analysis phase, OO models are used to fill the gap between problem and solution. It performs
well in situation where systems are undergoing continuous design, adaption, and maintenance.
It identifies the objects in problem domain, classifying them in terms of data and behavior.
The OO model is beneficial in the following ways:
 It facilitates changes in the system at low cost.
 It promotes the reuse of components.
 It simplifies the problem of integrating components to configure large system.
 It simplifies the design of distributed systems.

Elements of Object-Oriented System

Let us go through the characteristics of OO System:

 Objects An object is something that is exists within problem domain and can be
identified by data (attribute) or behavior. All tangible entities (student, patient) and
some intangible entities (bank account) are modeled as object.
 Attributes They describe information about the object.
 Behavior It specifies what the object can do. It defines the operation performed on
objects.
 Class A class encapsulates the data and its behavior. Objects with similar meaning and
purpose grouped together as class.
 Methods: Methods determine the behavior of a class. They are nothing more than an
action that an object can perform.
 Message A message is a function or procedure call from one object to another. They are
information sent to objects to trigger methods. Essentially, a message is a function or
procedure call from one object to another.

Features Of Object-oriented System

An object-oriented system comes with several great features which are discussed below.

 Encapsulation
Encapsulation is a process of information hiding. It is simply the combination of process and
data into a single entity. Data of an object is hidden from the rest of the system and available
only through the services of the class. It allows improvement or modification of methods used
by objects without affecting other parts of a system.

 Abstraction
It is a process of taking or selecting necessary method and attributes to specify the object. It
focuses on essential characteristics of an object relative to perspective of user.

 Relationships
All the classes in the system are related with each other. The objects do not exist in isolation,
they exist in relationship with other objects.
There are three types of object relationships:
 Aggregation It indicates relationship between a whole and its parts.
 Association In this, two classes are related or connected in some way such as one class
works with another to perform a task or one class acts upon other class.
 Generalization The child class is based on parent class. It indicates that two classes are
similar but have some differences.
 Inheritance

8
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
Inheritance is a great feature that allows to create sub-classes from an existing class by
inheriting the attributes and/or operations of existing classes.
 Polymorphism and Dynamic Binding
Polymorphism is the ability to take on many different forms. It applies to both objects and
operations. A polymorphic object is one who true type hides within a super or parent class.

In polymorphic operation, the operation may be carried out differently by different classes of
objects. It allows us to manipulate objects of different classes by knowing only their common
properties.

Structured Approach Vs. Object-Oriented Approach

The following table explains how the object-oriented approach differs from the traditional structured approach:
Structured Approach Object oriented approach

It works with Top-down approach. It works with Bottom-up approach.

Program is divided into number

of Program is organized by having number of
sub modules or functions. classes and objects.

Function call is used. Message passing is used.

Software reuse is not possible. Reusability is possible.

Structured design programming

usually Object oriented design programming done
left until end phases. concurrently with other phases.

Structured Design is more suitable

for off shoring.
It is suitable for in-house development.

It shows clear transition from design

to Not so clear transition from design to
implementation. implementation.

It is suitable for real time system, It is suitable for most business

embedded system and projects
where applications, game development projects,
objects are not the most useful level
of which are expected to customize or
abstraction. extended.

Class diagram, sequence diagram, state

DFD &E-R diagram model the data. chart diagram, and use cases all
contribute.

In this, projects can be managed In this approach, projects can be difficult

easily
to manage due to uncertain transitions
due to clearly identifiable phases.
between phase.

Unified Modeling Language (UML)

UML is a visual language that lets you to model processes, software, and systems to express
9
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
the design of system architecture. It is a standard language for designing and documenting a
system in an object oriented manner that allow technical architects to communicate with
developer.

It is defined as set of specifications created and distributed by Object Management Group. UML
is extensible and scalable.

The objective of UML is to provide a common vocabulary of object-oriented terms and

diagramming techniques that is rich enough to model any systems development project from
analysis through implementation.
UML +-is made up of:
 Diagrams: It is a pictorial representations of process, system, or some part of it.
 Notations: It consists of elements that work together in a diagram such as connectors,
symbols, notes, etc.

Operations Performed on Objects

The following operations are performed on the objects:

 Constructor/Destructor: Creating new instances of a class and deleting existing

instances of a class.
For example, adding a new employee.

 Query: Accessing state without changing value, has no side effects. For
example, finding address of a particular employee.
 Update: changes value of one or more attributes & affect state of object
For example, changing the address of an employee.

Uses of UML
UML is quite useful for the following purposes:
 Modeling the business process
 Describing the system architecture
 Showing the application structure
 Capturing the system behavior
 Modeling the data structure
 Building the detailed specifications of the system
 Sketching the ideas
 Generating the program code

ACCELERATED SYSTEMS ANALYSIS APPROACH IN DETAILS

Accelerated systems analysis approach emphasizes the construction of prototypes to more
rapidly identify business and user requirements for a new system.
A prototype is a small-scale, incomplete, but working sample of a desired system.

Accelerated systems analysis approach is of 2 types

 Discovery prototyping
 Rapid architected analysis

Discovery prototyping – a technique used to identify the users’ business requirements by

having them react to a quick-and-dirty implementation of those requirements.
Advantages
• Prototypes cater to the “I’ll know what I want when I see it” way of thinking
that is characteristic of many users and managers.
• Disadvantages
• Can become preoccupied with final “look and feel” prematurely
• Can encourage a premature focus on, and commitment to, design

10
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
 Users can be misled to believe that the completed system can be built
•
rapidly using prototyping tools
Rapid architected analysis – an approach that attempts to derive system models (as
described earlier in this section) from existing systems or discovery prototypes.
Reverse engineering – the use of technology that reads the program code for an existing
database, application program, and/or user interface and automatically generates the
equivalent system model.

FEASIBILITY STUDY
Feasibility Study can be considered as preliminary investigation that helps the management to
take decision about whether study of system should be feasible for development or not.

 It identifies the possibility of improving an existing system, developing a new system,

and produce refined estimates for further development of system.

 It is used to obtain the outline of the problem and decide whether feasible or appropriate
solution exists or not.
 The main objective of a feasibility study is to acquire problem scope instead of solving
the problem.

 The output of a feasibility study is a formal system proposal act as decision document
which includes the complete nature and scope of the proposed system.

Steps involved Feasibility Analysis

The following steps are to be followed while performing feasibility analysis:

1. Form a project team and appoint a project leader.

2. Develop system flowcharts.
3. Identify the deficiencies of current system and set goals.
4. Enumerate the alternative solution or potential candidate system to meet goals.
5. Determine the feasibility of each alternative such as technical feasibility, operational
feasibility, etc.
6. Weight the performance and cost effectiveness of each candidate system.
7. Rank the other alternatives and select the best candidate system.
8. Prepare a system proposal of final project directive to management for approval.

Types of Feasibilities

Economic Feasibility
 It is evaluating the effectiveness of candidate system by using cost/benefit analysis
method.
 It demonstrates the net benefit from the candidate system in terms of benefits and costs
to the organization.
 The main aim of Economic Feasibility Analysis (EFS) is to estimate the economic
requirements of candidate system before investments funds are committed to proposal.
 It prefers the alternative which will maximize the net worth of organization by earliest
and highest return of funds along with lowest level of risk involved in developing the
candidate system.

Technical Feasibility
 It investigates the technical feasibility of each implementation alternative.
 It analyzes and determines whether the solution can be supported by existing
technology or not.
 The analyst determines whether current technical resources be upgraded or added it
that fulfill the new requirements.
 It ensures that the candidate system provides appropriate responses to what extent it
11
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
 can support the technical enhancement.

Operational Feasibility
 It determines whether the system is operating effectively once it is developed and
implemented.

 It ensures that the management should support the proposed system and its working
feasible in the current organizational environment.

 It analyzes whether the users will be affected and they accept the modified or new
business methods that affect the possible system benefits.

 It also ensures that the computer resources and network architecture of candidate
system are workable.

Behavioral Feasibility
 It evaluates and estimates the user attitude or behavior towards the development of new
system.
 It helps in determining if the system requires special effort to educate, retrain, transfer,
and changes in employee’s job status on new ways of conducting business.

Schedule Feasibility
 It ensures that the project should be completed within given time constraint or schedule.
 It also verifies and validates whether the deadlines of project are reasonable or not.

SOFTWARE PROJECT MANAGEMENT

A project is well-defined task, which is a collection of several operations done in order to
achieve a goal (for example, software development and delivery).
x-tics of a project
 has a unique and distinct goal.
 Project is not routine activity or day-to-day operations.
 Project comes with a start time and end time.
 Project ends when its goal is achieved hence it is a temporary phase in the lifetime of an
organization.
 Project needs adequate resources in terms of time, manpower, finance, material and
knowledge-bank.
Software Project
A Software Project is the complete procedure of software development from requirement
gathering to testing and maintenance, carried out according to the execution methodologies, in
a specified period of time to achieve intended software product.
Project management activities may include:
Project selection
Project Planning
Scope Management
Project Estimation
Project scheduling
Project Risk Management
Project Execution & Monitoring
Configuration Management
Managing people

12
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
1. PROJECT SELECTION
What is Project Selection?
Project Selection is a process to assess each project idea and select the project with the highest
priority. Projects are still just suggestions at this stage, so the selection is often made based on
only brief descriptions of the project. As some projects will only be ideas, you may need to
write a brief description of each project before conducting the selection process.
Selection of projects is based on:
 Benefits: A measure of the positive outcomes of the project. These are often described
as "the reasons why you are undertaking the project
 Feasibility: A measure of the likelihood of the project being a success, i.e. achieving its
objectives. Projects vary greatly in complexity and risk. By considering feasibility when
selecting projects, it means the easiest projects with the greatest benefits are given
priority.
Note: A detailed review of a project's feasibility is conducted in the Feasibility Study Stage.
Why Project Selection?
 Lack of enough resources. Often you will have a number of suggested projects but not
enough resources, money or time to undertake all of the projects.
 Priority. Project selection is considered according to the needs and priorities of the
organization. By following the Project Selection Stage you will follow a step by step
objective method for prioritizing projects - this can be used to explain to stakeholders
the reasoning behind why you selected a particular project.
 Experience and expertise. If your organization has limited experience in conducting
eradications then it is recommended to concentrate on a small number of projects,
ideally one project at a time, until the people in your organization have developed the
skills and experience. Grow capacity and build up to undertaking multiple projects at any
one time. Do the easy projects first. Work towards the most difficult and rewarding
projects. Use the easy projects to help answer questions/solve issues for the more
difficult projects. Use the best opportunities to learn.
 Project selection helps the organisation owners to provide a process to compare the
importance of the available projects and select the most suitable project to undertake.
The benefits of completing the Project Selection are:
A transparent and documented record of why a particular project was selected
A priority order for projects, that takes into account their importance and how achievable the
project is
Who Should Be Involved?
 Agency Management: Set selection criteria to ensure the selection process aligns with
agency strategies. Selection processes are often run as a management initiative before
the implementing Project Manager is assigned.
 Stakeholders: Stakeholder participation at the start of a project creates strong
community ownership and support, and increases the chances of a successful outcome.
Stakeholder input should be included at the ideas stage; consult widely as you are
developing the ideas for projects as the community will be the source of many of the
best project ideas. Stakeholders must be informed of the outcome of the Project
Selection Stage.
 Project Manager: Involving the Project Manager in the Project Selection process will help
build ownership in the project and support a successful project in the long run.
Project selection issues:
 Resource scarcity. As a result the project selected may be substandard or lacking some
features as a result of limited resources.
 Lack of sufficient software specific expertise. The project selected must fit the expertise
of the company’s workers. If it is too hard for them to operate with it, it may not serve its
purpose well.
13
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
  Infrastructure issues. Bigger projects require well organized, big and standardized
infrastructure.
 Third party integration and interface issues. Many software developers no longer develop
standalone software. There is therefore need for third party integration, making it more
complex for project managers because the undergo pressure to increase their
knowledge and experience with other software that may integrate and interface with the
one they are implementing.
 Some selected software require quality testing and bug fixes in numerous software
iterations.

2. PROJECT PLANNING:
Software project planning is task, which is performed before the production of software actually
starts. It is there for the software production but involves no concrete activity that has any
direction connection with software production; rather it is a set of multiple processes, which
facilitates software production.
• Developing a realistic project plan is essential to gain an understanding of the resources
required, and how these should be applied.
• Types of plan:
– Software development plan.
The central plan, which describes how the system will be developed.
– Quality assurance plan.
Specifies the quality procedures & standards to be used.
– Validation plan.
Defines how a client will validate the system that has been developed.
– Configuration management plan.
Defines how the system will be configured and installed.
– Maintenance plan.
Defines how the system will be maintained.
– Staff development plan.
Describes how the skills of the participants will be developed.

Structure of Development Plan

1. Introduction
brief intro to project — references to requirements specifications
2. Project organisation
intro to organizations, people, and their roles
3. Risk Analysis
what are the key risks to the project?
4. Hardware and software resources
what h/ware and s/ware resources will be required for the project and when?
5. Work breakdown
the project divided into activities, milestones, deliverables; dependencies between tasks etc
6. Project schedule
actual time required — allocation of dates
7. Reporting and progress measurement mechanisms to monitor progress.

3. SCOPE MANAGEMENT.
It defines the scope of project; this includes all the activities and processes that need to be
done in order to make a deliverable software product. Scope management is essential because
it creates boundaries of the project by clearly defining what would be done in the project and
what would not be done.
4. PROJECT ESTIMATION.

14
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
 For an effective management, accurate estimation of various measures is a must. With correct
estimation, managers can manage and control the project more efficiently and effectively.
Project estimation may involve the following:
- Software size estimation: Software size may be estimated either in terms of KLOC (Kilo
Line of Code) or by calculating number of function points in the software.
- Effort estimation: The managers estimate efforts in terms of personnel requirement and
man-power required to produce the software. For effort estimation
- Time estimation: Once size and efforts are estimated, the time required to produce the
software can be estimated.
- Cost estimation: This might be considered as the most difficult of all because it depends
on more elements than any of the previous ones. For estimating project cost, it is
required to consider: -Size of software, Software quality, Hardware, Additional software
or tools, licenses, skilled personnel with task-specific skills, Travel involved, etc.

Project Estimation Techniques

Project manager can estimate the listed factors using two broadly recognized techniques –
 Decomposition Technique:
This technique assumes the software as a product of various compositions. There are two main
models:-
- Line of Code Estimation is done on behalf of number of line of codes in the software
product.
- Function Points Estimation is done on behalf of number of function points in the software
product.
2. Empirical Estimation Technique
This technique uses empirically derived formulae to make estimation. These formulae are
based on LOC or FPs.
5. PROJECT SCHEDULING
Project Scheduling in a project refers to roadmap of all activities to be done with specified order
and within time slot allotted to each activity.
Project managers tend to define various tasks, and project milestones and they arrange them
keeping various factors in mind.
For scheduling a project, it is necessary to:
a) Break down the project tasks into smaller, manageable form.
b) Find out various tasks and correlate them.
c) Estimate time frame required for each task.
d) Divide time into work-units.
e) Assign adequate number of work-units for each task.
f) Calculate total time required for the project from start to finish.

6. PROJECT RISK MANAGEMENT

Risk management involves all activities pertaining to identification, analyzing and making
provision for predictable and non-predictable risks in the project. Risk may include the
following:
 Experienced staff leaving the project and new staff coming in.
 Change in organizational management.
 Requirement change or misinterpreting requirement.
 Under-estimation of required time and resources.
 Technological changes, environmental changes, business competition.
Risk Management Process
The following activities are involved in risk management process:
 Identification - Make note of all possible risks, which may occur in the project.
15
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
 Categorize - Categorize known risks into high, medium and low risk intensity as per their
possible impact on the project.
 Manage - Analyze the probability of occurrence of risks at various phases. Make plan to
avoid or face risks. Attempt to minimize their side-effects.
 Monitor - Closely monitor the potential risks and their early symptoms. Also monitor the
effects of steps taken to mitigate or avoid them.

7. PROJECT EXECUTION & MONITORING

In this phase, the tasks described in project plans are executed according to their schedules.
Execution needs monitoring in order to check whether everything is going according to the
plan.
Monitoring is observing to check the probability of risk and taking measures to address the risk
or report the status of various tasks.
These measures include -
 Activity Monitoring - All activities scheduled within some task can be monitored on
day-to- day basis. When all activities in a task are completed, it is considered as
complete.
 Status Reports - The reports contain status of activities and tasks completed within a
given time frame, generally a week. Status can be marked as finished, pending or work-
in- progress etc.
 Milestones Checklist - Every project is divided into multiple phases where major tasks are
performed (milestones) based on the phases of SDLC. This milestone checklist is
prepared once every few weeks and reports the status of milestones.
8. CONFIGURATION MANAGEMENT
Configuration management is a process of tracking and controlling the changes in software in
terms of the requirements, design, functions and development of the product.
Generally, once the SRS is finalized there is less chance of requirement of changes from user. If
they occur, the changes are addressed only with prior approval of higher management, as
there is a possibility of cost and time overrun.
Baseline
Baseline is a measurement that defines completeness of a phase.
A phase of SDLC is assumed over if it baselined. A phase is baselined when all activities
pertaining to it are finished and well documented. If it was not the final phase, its output would
be used in next immediate phase.
Configuration management is a discipline of organization administration, which takes care of
occurrence of any change (process, requirement, technological, strategical etc.) after a phase
is baselined. CM keeps check on any changes done in software.

REASONS FOR IMPLEMENTING NEW SYSTEMS

 To improve business performance
 To make employee jobs easier
 To ensure reporting/ regulatory compliance
 To integrate systems across multiple locations
 To replace an old system with a better and modernized one
 To position a company for growth
 To improve customer service.
 To standardize global business operations.
 To reduce working capital, operational expenses.
 To improve decision making.

SYSTEM/SOFTWARE GOALS AND EXPECTATIONS

Key goals include;

16
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
  System functionality. Any system should be able to operate and meet all functional
requirements. Should be able to solve problems for which it was created.
 Usability. The system should be very easy to use and easy to learn.
 Efficiency. It should be able to perform all activities very efficiently and effectively.
 Simplicity.

SELECTING AN APPROPRIATE SYSTEM DEVELOPMENT MOTHODOLOGY.

There are many development methodologies in place like water fall, agile, Spiral Model, V-
Model, Big Bang Model, etc. A project manager has go to take into account different aspects
while choosing an appropriate development methodologies depending on the following factors:
 Requirements: The requirements of the system determines what methods should be
used to develop it. Some methods have affordable requirements and others don’t.

 Cost. The selection may depend on how much it will cost the system project manager to
develop. Therefore, the methodology must be cost effective.

 High success rate of the end product . The methodology selected must be able to
produce the most efficient software product that is affordable and easy to use.

 Modification. The chosen methodology must be able to allow modification in case there
some changes that are necessary changes to be implemented. (Versioning).

 Nature of the system to be developed. Some methodologies are good for small projects
and not big projects. The content of the project will determine the suitable methodology
to be used. If the nature of the software is incremental, agile methods are better.

 The size of the team for whom the project is developed. For small teams, where team
members can easily communicate with each other, agile methods are used. On the other
hand, for the bigger teams, plan driven process models are used.

PRELIMINARY PROJECT ASSESSMENT AND ACCEPTANCE

The Preliminary Project Assessment (PPA) is a preliminary process that evaluates moderate to
large projects before development applications are filed. Before any project is accepted, two
documents must be prepared and approved by the company/customer before the project is
approved for further development (PLANNING PHASE).
 Business case
 Project charter.

Business case.
A business case is a document that is written to convince a decision maker to approve the
action of developing a project. It captures the reasoning for initiating a project or a task.
The main objective of the business case is to identify the requirements of an organization and
propose strategies to meet them.
Whereas a project proposal focusses on why you want a project and contains an outline of the
project like business vision, business need, expected benefits and others, a business case
outlines the why, what, how and who aspects necessary to decide if it is worth continuing the
project or not.

A business case should set out the benefits gained from carrying out a project charter. Benefits
need not only be in terms of finance such as revenue, cost reduction, etc., but also the benefit
that the customer receives.
Following are the characteristics of a good business case:
 The reasons of undertaking the project.
 The benefits gained from undertaking the project now.
 The consequences of not doing the project.
17
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
  The factors that would conclude that it fits the business goals.
Why business case?
Preparing the business case involves an assessment of:
 Business problem or opportunity
 Benefits
 Risks involved
 Costs involved
 Impact on the operations of the company
 Organizational capabilities to deliver the project outcomes.

Business Case Format

A business case normally includes the following elements
Business Case Title − the Topic of proposal
Executive Summary − description of the proposal
Current Process − the procedures currently in operation
Reason to Change − profits that will be brought by the changes
Risks − factors that company needs to watch out for
Options − any alternative procedures that can be implemented
Option Comparison − Risk vs. Profit analyses of all options
Recommendation − the final option to implement, after changes
Action − the necessary steps to implement the changes
Approval Requested − what actions need approval from whom

PROJECT CHARTER
Project Charter refers to a statement of objectives, scope and participants in a project. This
statement also sets out detailed project goals, roles and responsibilities, identifies the main
stakeholders, and the level of authority of a project manager.
It acts as a guideline for future projects as well as an important material in the organization's
knowledge management system.
The project charter is a short document that would consist of new offering request or a request
for proposal. This document is a part of the project management process, which is required by
Initiative for Policy Dialogue (IPD) and Customer Relationship Management (CRM).
The Role of Project Charter
Following are the roles of a Project Charter:
 It documents the reasons for undertaking the project.
 Outlines the objectives and the constraints faced by the project.
 Provides solutions to the problem in hand.
 Identifies the main stakeholders of the project.
Benefits of Project Charter
Following are the prominent benefits of Project Charter for a project:
 It improves and paves way for good customer relationships.
 Project Charter also works as a tool that improves project management processes.
 Regional and headquarter communications can also be improved to a greater extent.
 By having a project charter, project sponsorship can also be gained.
 Project Charter recognizes senior management roles.
 Allows progression, which is aimed at attaining industry best practices.
Elements in Project Charter
Since project charter is a project planning tool, which is aimed at resolving an issue or an
opportunity, the below elements are essential for a good charter project.
 Identity of the project.
 Time: the start date and the deadline for the project.
 People involved in the project.

18
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
  Outlined objectives and set targets.
 The reason for a project charter to be carried out, often referred to as 'business case'.
 Detailed description of a problem or an opportunity.
 The return expected from the project.
 Results that could be expected in terms of performance.
 The expected date that the objectives is to be achieved.
 Clearly defined roles and responsibilities of the participants involved.
 Requirement of resources that will be needed for the objectives to be achieved.
 Barriers and the risks involved with the project.
 Informed and effective communication plan.

Causes of project failure

Here are just some of the most common causes of project failure:
1. Poorly defined project scope
2. Inadequate risk management
3. Failure to identify key assumptions
4. Project managers who lack experience and training
5. No use of formal methods and strategies
6. Lack of effective communication at all levels
7. Key staff leaving the project and/or company
8. Poor management of expectations
9. Ineffective leadership
10. Lack of detailed documentation
11. Failure to track requirements
12. Failure to track progress
13. Lack of detail in the project plans
14. Inaccurate time and effort estimates
15. Cultural differences in global projects

PROJECT REQUIREMENTS ANALYSIS AND SPECIFICATIONS

REQUIREMENTS ANALYSIS
The process of studying and analyzing the customer and the user needs to arrive at a definition
of the problem domain and system requirements.
Requirements analysis is the first stage in the systems engineering process and software
development process.
Requirements can be functional and non-functional.
• Objectives
• Discover the boundaries of the new system (or software) and how it must interact with its
environment within the new problem domain
• Detect and resolve conflicts between (user) requirements
• Negotiate priorities of stakeholders
• Prioritize and triage requirements
• Elaborate system requirements, defined in the requirement specification document, such that
managers can give realistic project estimates and developers can design, implement, and test.
• Classify requirements information into various categories and allocate requirements to sub-
systems
• Evaluate requirements for desirable qualities
 Understand how to create a requirements definition.
 Become familiar with requirements analysis techniques.
 Understand when to use each requirements analysis technique.

19
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
 Understand how to gather requirements using interviews, JAD sessions, questionnaires,
document analysis, and observation.

TYPES OF REQUIREMENTS

1. FUNCTIONAL REQUIREMENTS
These define a function of a system/project or its components, where a function is described as
a specification of behavior between outputs and inputs.
Functional requirements may involve calculations, technical details, data manipulation and
processing, and other specific functionality that define what a system is supposed to
accomplish.
Functional requirements are supported by non-functional requirements (also known as "quality
requirements"), which impose constraints on the design or implementation (such as
performance requirements, security, or reliability).
2. Non-functional requirement
A non-functional requirement (NFR) is a requirement that specifies criteria that can be used to
judge the operation of a system, rather than specific behaviors. They are contrasted with
functional requirements that define specific behavior or functions.

DIFFERENCE BETWEEN FUNCTIONAL & NON FUNTIONAL REQUREMENTS

Generally, functional requirements are expressed in the form "system must do

<requirement>," while non-functional requirements take the form "system shall be
<requirement>."
The plan for implementing functional requirements is detailed in the system design, whereas
non-functional requirements are detailed in the system architecture.
Functional requirements specify particular results of a system. This should be contrasted with
non- functional requirements, which specify overall characteristics such as cost and reliability.
Functional requirements drive the application architecture of a system, while non-functional
requirements drive the technical architecture of a system.
3. Operational requirements.
These will define the basic need and, at a minimum, answer the questions posed in the
following listing:
 Operational distribution or deployment: Where will the system be used?
 Mission profile or scenario: How will the system accomplish its mission objective?
 Performance and related parameters: What are the critical system parameters to accomplish
the mission?
 Utilization environments: How are the various system components to be used?
 Effectiveness requirements: How effective or efficient must the system be in performing its
mission?
Operational life cycle: How long will the system be in use by the user?
Environment: What environments will the system be expected to operate in an effective
manner?

4. Performance Requirements
The extent to which a mission or function must be executed; generally measured in terms of
quantity, quality, coverage, timeliness or readiness. During requirements analysis, performance
(how well does it have to be done) requirements will be interactively developed across all
identified functions based on system life cycle factors; and characterized in terms of the degree
of certainty in their estimate, the degree of criticality to system success, and their relationship
to other requirements.

6. Design Requirements
The “build to,” “code to,” and “buy to” requirements for products and “how to execute”
requirements for processes expressed in technical data packages and technical manuals.
20
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
USE CASES
A use case in software and systems engineering refers to a list of actions or event steps
typically defining the interactions between a role ( known in UML as actor) and a system to
achieve a goal. The role/actor can be human or other external system.

ELEMENTS OF USE CASE.

There are 3 basic elements that make up a use case.
 Actors/roles: these are the type of users that interact with the system.
 System: use cases capture functional requirements that specify the intended behavior of
the system.
 Goals: use cases are typically by a user to fulfil goals describing the activities and
variants involved in attaining a goal.

Use cases are modeled using unified modeling language and are represented by ovals
containing the names of the use case. Actors are represented using lines with the name of the
actor written below the line. To represent an actor's participation in a system, a line is drawn
between the actor and the use case. Boxes around the use case represent the system
boundary.
Characteristics associated with use cases are:
 Organizing functional requirements.
 Modeling the goals of system user interactions.
 Recording scenarios from trigger events to ultimate goals.
 Describing the basic course of actions and exceptional flow of events
 Permitting a user to access the functionality of another event
The steps in designing use cases are:
 Identify the users of the system
 For each category of users, create a user profile. This includes all roles played by the
users relevant to the system.
 Identify significant goals associated with each role to support the system. The system’s
value proposition identifies the significant role.
 Create use cases for every goal associated with a use case template and maintain the
same abstraction level throughout the use case. Higher level use case steps are treated
as goals for the lower level.
 Structure the use cases
 Review and validate the users

USE CASE DIAGRAMS

Use case diagrams (UCDs) are used in the process of software system design for modeling
functional requirements. The system is considered as a black-box, where only external features
are taken into account.
The objective of UCDs is identify system users, user requirements, and how the user interacts
with the system. The model consists of actors and use cases.

A. Actor
Actor is an external entity working with the software
system, so that actor is not part of the system, but it is a
generator of input stimulus and data for the system.
Actor models a group of real users, whereas all members
of the group work with the system by the same way.
Therefore, actor represents a role of the user in the
system.

B. Use Case
An important part of functional requirements analysis is

21
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
to identify sequences of interaction between actors and modeled system. The sequence of
interactions is modeled by a use case. The use case describes a main sequence of interactions
and is invoked (its execution starts) by input stimulus from the actor.
A use case diagram at its simplest is a representation of a user's interaction with the system
that shows the relationship between the user and the different use cases in which the user is
involved. A use case diagram can identify the different types of users of a system and the
different use cases and will often be accompanied by other types of diagrams as well.
Application
While a use case itself might drill into a lot of detail about every possibility, a use-case diagram
can help provide a higher-level view of the system. It has been said before that "Use case
diagrams are the blueprints for your system". They provide the simplified and graphical
representation of what the system must actually do.
Due to their simplistic nature, use case diagrams can be a good communication tool for
stakeholders. The drawings attempt to mimic the real world and provide a view for the
stakeholder to understand how the system is going to be designed.
The purpose of the use case diagrams is simply to provide the high level view of the system
and convey the requirements in layman's terms for the stakeholders. Additional diagrams and
documentation can be used to provide a complete functional and technical view of the system.

Use case diagram symbols and notation

Use cases: Horizontally shaped ovals that represent the different uses that a user might have.

Actors: Stick figures that represent the people actually employing the use cases.

Associations: A line between actors and use cases. In complex diagrams, it is important to
know which actors are associated with which use cases.
System boundary boxes: A box that sets a system scope to use cases. All use cases outside
the box would be considered outside the scope of that system
Packages: A UML shape that allows you to put different elements into groups. Just as with
component diagrams, these groupings are represented as file folders

MODELING REQUIREMENTS WITH USE CASE

Use-case modeling – the process of modeling a system’s functions in terms of business
events, who initiated the events, and how the system responds to those events.
• Use-case modeling has roots in object-oriented modeling.
• Gaining popularity in non-object development environments because of its
usefulness in communicating with users.
• Compliments traditional modeling tools.
Benefits of Use-Case Modeling
• Provides tool for capturing functional requirements.
• Assists in decomposing system into manageable pieces.
• Provides means of communicating with users/stakeholders concerning system
functionality in language they understand.
• Provides means of identifying, assigning, tracking, controlling, and managing system
development activities.
• Provides aid in estimating project scope, effort, and schedule.
• Aids in defining test plans and test cases.
22
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
 • Provides baseline for user documentation.
• Provides tool for requirements traceability.
• Provides starting point for identification of data objects or entities.
• Provides specifications for designing user and system interfaces.
• Provides means of defining database access requirements.
• Provides framework for driving the system development project.

System Concepts for Use-Case Modeling

Use case – a behaviorally related sequence of steps (scenario), both automated and manual,
for the purpose of completing a single business task.
• Description of system functions from the perspective of external users in
terminology they understand.
Use-case diagram – a diagram that depicts the interactions between the system and
external systems and users.
• graphically describes who will use the system and in what ways the user expects
to interact with the system.
Use-case narrative – a textual description of the business event and how the user will
interact with the system to accomplish the task.

Types of Actors
 Primary business actor
• The stakeholder that primarily benefits from the execution of the use case.
• e.g. the employee receiving the paycheck
 Primary system actor
• The stakeholder that directly interfaces with the system to initiate or trigger the
business or system event.
• e.g. the bank teller entering deposit information
 External server actor
• The stakeholder that responds to a request from the use case.
• e.g. the credit bureau authorizing a credit card charge
 External receiver actor
• The stakeholder that is not the primary actor but receives something of value from
the use case.
• e.g. the warehouse receiving a packing slip

RELATIONSHIPS IN USE CASE DIAGRAMS

There can be five relationships in use case diagrams

 Association between actor and use case
 Generalization of an actor
 Extend between two use cases
 Include between two use cases
 Generalization of a use case

1. Association between actor and use case

This one is straightforward and present in every use case diagram. Few things to note.
 An actor must be associated with at least one use case.
 An actor can be associated with multiple use cases.
 Multiple actors can be associated with a single use case.

23
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
2. Generalization of an Actor
Generalization of an actor means that one actor can inherit the role of the other actor. The
descendant inherits all the use cases of the ancestor. The descendant has one or more use
cases that are specific to that role. Let’s expand the previous use case diagram to show the
generalization of an actor.

3. Extend relationships between two use cases

As the name implies it extends the base use case and adds more functionality to the system.
Here are few things to consider when using the << extend >> relationship.
 The extending use case is dependent on the extended (base) use case . In the
below diagram the “Calculate Bonus” use case doesn’t make much sense without the
“Deposit Funds” use case.
 The extending use case is usually optional and can be triggered conditionally. In
the diagram, you can see that the extending use case is triggered only for deposits over
10,000 or
when the age
is over 55.
 The
extended
(base) use
case must
be
meaningful
on its own .
This means it
should be
independent
and must not
rely on the
behavior of
the extending
use case.

24
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
4. Include Relationship Between Two Use Cases
Include relationship show that the behavior of the included use case is part of the including
(base) use case. The main reason for this is to reuse the common actions across multiple use
cases. In some situations, this is done to simplify complex behaviors. Few things to consider
when using the <<include>> relationship.
 The base use case is incomplete without the included use case.
 The included use case is mandatory and not optional.

5. Generalization of a Use Case

This is similar to the generalization of an actor. The behavior of the ancestor is inherited by the
descendant. This is used when there is common behavior between two use cases and also
specialized behavior specific to each use case.
For example, in the previous banking example, there might be a use case called “Pay Bills”.
This can be generalized to “Pay by Credit Card”, “Pay by Bank Balance” etc.

The Process of Requirements Use-Case Modeling

25
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
  Objective is to elicit and analyze enough requirements information to prepare a model
that:
• Communicates what is required from a user perspective.
• Is free of specific details about how system will be implemented.
 To effectively estimate and schedule project, may need to include preliminary
implementation assumptions.
 Steps
• Identify business actors.
• Identify business use cases.
• Construct use-case model diagram.
• Documents business requirements use-case narratives.
Step 1: identify Business Actors
 When looking for actors, ask the following questions:
• Who or what provides inputs to the system?
• Who or what receives outputs from the system?
• Are interfaces required to other systems?
• Are there events that are automatically triggered at a predetermined time?
• Who will maintain information in the system?
 Actors should be named with a noun or noun phrase

Step 2: Identify Business Requirements Use Cases

Business Requirements Use Case - a use case created during requirements analysis to
capture the interactions between a user and the system free of technology and implementation
details.

During requirements analysis, strive to identify and document only the most
•
critical, complex, and important use cases, often called essential use cases.
 When looking for use cases, ask the following questions:
• What are the main tasks of the actor?
• What information does the actor need from the system?
• What information does the actor provide to the system?
• Does the system need to inform the actor of any changes or events that have
occurred?
• Does the actor need to inform the system of any changes or events that have
occurred?
 Use cases should be named with a verb phrase specifying the goal of the actor (i.e.
Submit Subscription Order)

Step 3: Construct Use-Case Model Diagram

26
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
Step 4: Document Business Requirements Use-Case Narratives
• Document first at high level to quickly obtain an understanding of the events and
magnitude of the system.
• Then expand to a fully-documented business requirement narrative.
• Include the use case’s typical course of events and its alternate courses.

USE CASES AND PROJECT MANAGEMENT

 Use-case model can drive entire development effort.
 Project manager or systems analyst uses business requirements use cases to estimate
and schedule the build cycles of the project.
• Build cycles are scoped on the basis of the importance of the use case and the
time it takes to implement the use case.
 To determine importance of use cases, will create:
• Use-case ranking and evaluation matrix
• Use-case dependency diagram

Use-Case Ranking and Priority Matrix

 In most projects, the most important use cases are developed first.

Use-case ranking and priority matrix – a tool used to evaluate use cases and determine
their priority.
• Evaluates use cases on 1-5 scale against six criteria.
1. Significant impact on the architectural design.
2. Easy to implement but contains significant functionality.
3. Includes risky, time-critical, or complex functions.
4. Involves significant research or new or risky technology.
5. Includes primary business functions.
6. Will increase revenue or decrease costs.

Below is a sample of use-case ranking and priority matrix

27
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
Use-Case Dependency Diagram
Use-case dependency diagram – graphical depiction of the dependencies among use cases.

• Provides the following benefits:

• Graphical depiction of the system’s events and their states enhances
understanding of system functionality.
• Helps identify missing use cases.
• Helps facilitate project management by depicting which use cases are more
critical.

Requirements Analysis Techniques

Requirements analysis is the tasks that an analyst performs to structure and organize
requirements, specify and model requirements and designs, validate and verify information,
identify solution options that meet business needs, and estimate the potential value that could
be realized for a solution option.
Below are some of the requirements techniques among the very many .

Acceptance and Evaluation Criteria

Acceptance criteria are used to define the requirements, outcomes, or conditions that must be
met in order for a solution to be considered acceptable to key stakeholders. Evaluation criteria
are the measures used to assess a set of requirements in order to choose between multiple
solutions. The Acceptance and Evaluation Criteria technique can apply at all levels of a project,
from high-level to a more detailed level.
Scope Modeling
Scope models are commonly used to describe the boundaries of control, change, a solution, or
a need. They may also be used to delimit any simple boundary. Scope models are typically
28
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
represented as a combination of diagrams, matrices, and textual explanations. Two of the most
common scope diagrams are the Context Diagram (shown below) or a Use Case Diagram.

Process Modeling
Process models describe the sequential flow of work or activities. A business process model
describes the sequential flow of work across defined tasks and activities through an enterprise
or part of an enterprise. A system process model defines the sequential flow of control among
programs or units within a computer system.
A program process flow shows the sequential execution of program statements within a
software program. A process model can also be used in documenting operational procedures.

Processes can be depicted using a variety of diagrams and techniques including:

Capability & Process Text Template, Functional Decomposition Diagram, Flowcharts, User
Story, Use Case Diagram, Use Case Description and Prototype.
Use Cases and Scenarios
Use cases describe the interactions between the primary actor, the solution, and any secondary
actors needed to achieve the primary actor’s goal. Use case diagrams are a graphical
representation of the relationships between actors and one or more use cases supported by the
solution.

29
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
A scenario describes just one way that an actor can accomplish a particular goal. Scenarios are
written as a series of steps performed by actors or by the solution that enable an actor to
achieve a goal. A use case describes several scenarios.
User Stories
User stories capture the needs of a specific stakeholder and enable teams to define features of
value to a stakeholder using short, simple documentation. They can serve as a basis for
identifying needs and allow for the prioritizing, estimating, and planning of solutions.
A user story is typically a sentence or two that describes who has the need addressed by the
story, the goal the user is trying to accomplish, and any additional information that may be
critical to understanding the scope of the story.
Data Modeling
A data model describes the entities, classes or data objects relevant to a domain, the attributes
that are used to describe them, and the relationships among them to provide a common set of
semantics for analysis and implementation.

System Requirements Specification (SRS)

System Requirements Specification (SRS) (also known as a Software Requirements ) is a
document or set of documentation that describes the features and behavior of a system or
software application. It includes a variety of elements that attempts to define the intended
functionality required by the customer to satisfy their different users.
In addition to specifying how the system should behave, the specification also defines at a
high- level the main business processes that will be supported, what simplifying assumptions
have been made and what key performance parameters will need to be met by the system.
Main Elements
Depending on the methodology employed (agile vs waterfall) the level of formality and detail in
the SRS will vary, but in general an SRS should include a description of the functional
requirements, system requirements, technical requirements, constraints, assumptions and
acceptance criteria. Each of these is described in more detail below:

30
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
  Business Drivers - This section describes the reasons why the customer is looking to
build the system.
 Business Model - This section describes the underlying business model of the customer
that the system will need to support. This includes such items as the organizational
context, current-state and future-state diagrams, business context, key business
functions and process flow diagrams. This section is usually created during the functional
analysis phase.
 Functional and System Requirements – This section usually consists of a hierarchical
organization of requirements, with the business/functional requirements at the highest-
level and the detailed system requirements listed as their child items.
 Business and System Use Cases – This section usually consists of a UML use case
diagram that illustrates the main external entities that will be interacting with the
system together with the different use cases (objectives) that they will need to carry out.
 Technical Requirements - This section is used to list any of the "non-functional"
requirements that essentially embody the technical environment that the product needs
to operate in, and include the technical constraints that it needs to operate under. These
technical requirements are critical in determining how the higher-level functional
requirements will get decomposed into the more specific system requirements.
 System Qualities - This section is used to describe the "non-functional" requirements
that define the "quality" of the system. These items are often known as the "-ilities"
because most of them end in "ility". They included such items as: reliability, availability,
serviceability, security, scalability, maintainability.
 Constraints and Assumptions - This section will outline any design constraints that
have been imposed on the design of the system by the customer, thereby removing
certain options from being considered by the developers. Also this section will contain
any assumptions that have been made by the requirements engineering team when
gathering and analyzing the requirements. If any of the assumptions are found to be
false, the system requirements specification would need to be re-evaluated to make sure
that the documented requirements are still valid.
 Acceptance Criteria - This section will describe the criteria by which the customer will
"sign-off" on the final system. Depending on the methodology, this may happen at the
end of the testing and quality assurance phase, or in an agile methodology, at the end of
each iteration. The criteria will usually refer to the need to complete all user acceptance
tests and the rectification of all defects/bugs that meet a pre-determined priority or
severity threshold.

SYSTEMS DEVELOPMENT LIFECYCLE DELIVERABLES

A deliverable in software development concept refers to any tangible or non-tangible human
effort (good or service) provided by developer to a customer. A deliverable describes the
progress of the project. It can be prepared at each stage of development completed until a final
project is finalized. In software development, it recognized to be a good practice for all tasks in
all development life cycles/stages to have deliverables.

 PLANNING
• Project Charter & Business Case
• Form CORE project team
• Project Managers “Big 13”
 ANALYSIS
• Needs /Requirements analysis
• Specifications analysis
• Feasibility Study
• Conceptual design
31
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
  DESIGN
• Physical design “Prototypes”
• Construction –Develop and/or Purchase
• System testing
• User acceptance testing
 IMPLEMENTATION
• System integration & testing
• Post-implementation audit, maintenance & support

SYSTEM DEVELOPMENT METHODOLGIES

 Systems development is the process of developing information systems through
successive phases in an orderly way.”
 System development methodology is a recommended collection of phases;
procedures; rules; techniques; tools; documentation; management, and training to
improve the quality of a software development effort.
OR: A formalized approach or series of steps of system development process.

 Interchangeable Terms
 Systems Analysis & Design Methodology
 Systems Development Methodology
 Software Development Methodology
IMPRTANCES OF SDM

To students;
 Preparation for future role as a business manager
 Bridging the gap between IT & Business through education
Software evolution;
 Acceptable speed & cost for development
 Traceable time schedule for development process
 High Quality
 Longevity—used/maintained over a long period of time
 Accommodate the changing requirements of the user
 Compliance

The following are common systems development methodologies;

 Water fall model
 Spiral model
 Iterative model
 Rapid Application Development (RAD)
 Joint Application Development (JAD)

1. Water fall model basic concepts

The Waterfall model is the earliest SDLC approach that was used for software development.
The waterfall Model illustrates the software development process in a linear sequential flow.
This means that any phase in the development process begins only if the previous phase is
complete. In this waterfall model, the phases do not overlap.
Waterfall approach was first SDLC Model to be used widely in Software Engineering to ensure
success of the project. In "The Waterfall" approach, the whole process of software development
is divided into separate phases. In this Waterfall model, typically, the outcome of one phase
acts as the input for the next phase sequentially.

32
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
 Requirement Gathering and analysis − All possible requirements of the system to be
developed are captured in this phase and documented in a requirement specification
document.
System Design − the requirement specifications from first phase are studied in this phase
and the system design is prepared. This system design helps in specifying hardware and
system requirements and helps in defining the overall system architecture.
Implementation − With inputs from the system design, the system is first developed in
small programs called units, which are integrated in the next phase. Each unit is developed and
tested for its functionality, which is referred to as Unit Testing.
Integration and Testing − All the units developed in the implementation phase are
integrated into a system after testing of each unit. Post integration the entire system is tested
for any faults and failures.
Deployment of system − Once the functional and non-functional testing is done; the
product is deployed in the customer environment or released into the market.
Maintenance − There are some issues which come up in the client environment. To fix those
issues, patches are released. Also to enhance the product some better versions are released.
Maintenance is done to deliver these changes in the customer environment.
All these phases are cascaded to each other in which progress is seen as flowing steadily
downwards (like a waterfall) through the phases. The next phase is started only after the
defined set of goals are achieved for previous phase and it is signed off, so the name "Waterfall
Model". In this model, phases do not overlap.
ADVANTAGES OF WATER FALL MODEL
Some of the major advantages of the Waterfall Model are as follows.
1. Simple and easy to understand and use
2. Easy to manage due to the rigidity of the model. Each phase has specific deliverables
and a review process.
3. Phases are processed and completed one at a time.
4. Works well for smaller projects where requirements are very well understood.
5. Clearly defined stages.
6. Well understood milestones.
7. Easy to arrange tasks.

The major disadvantages of the Waterfall Model are as follows −

1. It does not allow much reflection or revision. Once an application is in the testing stage,
it is very difficult to go back and change something that was not well-documented in the
previous stage.
2. No working software is produced until late during the life cycle.
3. High amounts of risk and uncertainty.
4. Not a good model for complex and object-oriented projects.
5. Poor model for long and ongoing projects.

33
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
 6. Not suitable for the projects where requirements are at a moderate to high risk of
changing. So, risk and uncertainty is high with this process model.
7. It is difficult to measure progress within stages.
8. Cannot accommodate changing requirements.
9. Adjusting scope during the life cycle can end a project.

2. SPIRAL MODEL
The spiral model is similar to the incremental model, with more emphasis placed on risk
analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and
Evaluation. A software project repeatedly passes through these phases in iterations (called
Spirals in this model). The baseline spiral, starting in the planning phase, requirements are
gathered and risk is assessed. Each subsequent spirals builds on the baseline spiral.
Planning Phase: Requirements are gathered during the planning phase. Requirements like
‘BRS’ that is ‘Bussiness Requirement Specifications’ and ‘SRS’ that is ‘System Requirement
specifications’.
Risk Analysis: In the risk analysis phase, a process is undertaken to identify risk and
alternate solutions. A prototype is produced at the end of the risk analysis phase. If any risk is
found during the risk analysis then alternate solutions are suggested and implemented.
Engineering Phase: In this phase software is developed, along with testing at the end of
the phase. Hence in this phase the development and testing is done.
Evaluation phase: This phase allows the customer to evaluate the output of the project to
date before the project continues to the next spiral.

Diagram of Spiral model:

Advantages of Spiral model:

 High amount of risk analysis hence, avoidance of Risk is enhanced.
 Good for large and mission-critical projects.
 Strong approval and documentation control.
 Additional Functionality can be added at a later date.
 Software is produced early in the software life cycle.
Disadvantages of Spiral model:
 Can be a costly model to use.
 Risk analysis requires highly specific expertise.
 Project’s success is highly dependent on the risk analysis phase.
 Doesn’t work well for smaller projects.
When to use Spiral model:
 When costs and risk evaluation is important
 For medium to high-risk projects
34
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
  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 (research and exploration)
3. ITERATIVE MODEL
In the Iterative model, iterative process starts with a simple implementation of a small set of
the software requirements and iteratively enhances the evolving versions until the complete
system is implemented and ready to be deployed.
An iterative life cycle model does not attempt to start with a full specification of requirements.
Instead, development begins by specifying and implementing just part of the software, which is
then reviewed to identify further requirements. This process is then repeated, producing a new
version of the software at the end of each iteration of the model.
Iterative Model - Design
Iterative process starts with a simple implementation of a subset of the software requirements
and iteratively enhances the evolving versions until the full system is implemented. At each
iteration, design modifications are made and new functional capabilities are added. The basic
idea behind this method is to develop a system through repeated cycles (iterations) and in
smaller portions at a time (incremental).
The following illustration is a representation of the Iterative and Incremental model −

SDLC Iterative Model

Iterative and Incremental development is a combination of both iterative design or iterative
method and incremental build model for development. "During software development, more
than an iteration of the software development cycle may be in progress at the same time." This
process may be described as an "evolutionary acquisition" or "incremental build" approach."
In this incremental model, the whole requirement is divided into various builds. During each
iteration, the development module goes through the requirements, design, implementation and
testing phases. Each subsequent release of the module adds function to the previous release.
The process continues till the complete system is ready as per the requirement.
The key to a successful use of an iterative software development lifecycle is vigorous validation
of requirements, and verification & testing of each version of the software against those
requirements within each cycle of the model. As the software evolves through successive
cycles, tests must be repeated and extended to verify each version of the software.

Iterative Model - Application

Like other SDLC models, Iterative and incremental development has some specific applications
in the software industry. This model is most often used in the following scenarios −
 Requirements of the complete system are clearly defined and understood.
 Major requirements must be defined; however, some functionalities or requested
enhancements may evolve with time.
 There is a time to the market constraint.

35
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
  A new technology is being used and is being learnt by the development team while
working on the project.
 Resources with needed skill sets are not available and are planned to be used on
contract basis for specific iterations.
 There are some high-risk features and goals which may change in the future.

4. JOINT APPLICATION DEVELOPMENT

Joint application development (JAD) is a process originally meant for the development of
computer systems, but it can be applicable to other types of development also. It is an
approach of ensuring accuracy between project scope definition and delivery through
continuous collaboration with the stakeholders.
These interactions form the core of JAD development process and lifecycle. It is a modern
means of collecting and analysing software requirements that are discussed on series of
meetings and workshops between business and the technical teams. These series of meetings
and workshops are known as JAD SESSIONS.
JAD is more prevalent in agile delivery environments in which software products are developed
and shipped in short cycles based on agreements between the commercial and technical
stakeholders on what is known as minimum viable product (MVP).
In other words, anytime there is a need for business representatives and the technology teams
to deliberate and develop synergy on issues around product development or testing
requirements, JAD session becomes necessary. In what is largely dependent on the size of the
development project, the session may last for few hours to a day or even weeks in some cases.
JAD approach is to allow project executives and the representatives of the customer to identify
and appoint a trained facilitator whose role is to support project delivery. While the facilitator
helps in driving the projects, key decisions have to be taken by the executive sponsors. Other
key stakeholders include the subject matter expert who are responsible for turning customer's
requirements into technology-powered solution, and the documentation expert whose role is to
clarify the points of discussions and to document them effectively during the JAD sessions. The
facilitator serve as the central link between different stakeholders for the purpose of initializing
and driving the JAD workshops and sessions.

Phases of Joint application development Methodology

we can now discuss some of the stages and steps

involved in the development process.
• Define Objectives: The facilitator, in
collaboration with other key stakeholders, defines
the objectives and agenda items and distribute them
to participants for review. The objectives include the

36
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
purpose of the session, scope of project, its expected outcome, as well as participants of
application development.
• Session preparation: This is often the sole responsibility of the facilitator who is expected
to gather all relevant information and sent to participants ahead of time. The facilitator is also
expected to carry out some research at this stage in order to get better insight into the
objectives of the JAD sessions as it relates to the project at hand and an organization as a
whole. The logistics for the session needs to the arranged and planned, things such as venue
and time of the session need to be identified and communicated to the participants in due
course.
 Conducting and facilitating the actual session.
The success of the meeting depends on good planning and the competence of the facilitator to
see through completion to all goals until a definite conclusion is reached.
 Follow up documentation.
Preparing and circulating the final document that incorporates the decisions made is
important, for otherwise the purpose of the meeting would fritter out. The scribe or modeler
prepares the design document, gets approval from the executive sponsor, and circulates it to
everyone involved.

5. RAPID APPLICATION DEVELOPMENT (RAD)

RAD (Rapid Application Development) model is based on prototyping and iterative
development with no specific planning involved.
Rapid Application Development focuses on gathering customer requirements through
workshops or focus groups, early testing of the prototypes by the customer using iterative
concept, reuse of the existing prototypes (components), continuous integration and rapid
delivery.
In the RAD model, the functional modules are developed in parallel as prototypes and are
integrated to make the complete product for faster product delivery. Since there is no detailed
preplanning, it makes it easier to incorporate the changes within the development process.
RAD projects follow iterative and incremental model and have small teams comprising of
developers, domain experts, customer representatives and other IT resources working
progressively on their component or prototype. The most important aspect for this model to be
successful is to make sure that the prototypes developed are reusable.
RAD Model Design
RAD model distributes the analysis, design, build and test phases into a series of short,
iterative development cycles.
Following are the various phases of the RAD Model: −
 Business Modeling
The business model for the product under development is designed in terms of flow of
information and the distribution of information between various business channels. A complete
business analysis is performed to find the vital information for business, how it can be
obtained, how and when is the information processed and what are the factors driving
successful flow of information.
 Data Modeling
The information gathered in the Business Modeling phase is reviewed and analyzed to form
sets of data objects vital for the business. The attributes of all data sets is identified and
defined. The relation between these data objects are established and defined in detail in
relevance to the business model.
 Process Modeling
The data object sets defined in the Data Modeling phase are converted to establish the
business information flow needed to achieve specific business objectives as per the business
model. The process model for any changes or enhancements to the data object sets is defined
37
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
in this phase. Process descriptions for adding, deleting, retrieving or modifying a data object
are given.
 Application Generation
The actual system is built and coding is done by using automation tools to convert process and
data models into actual prototypes.
 Testing and Turnover
The overall testing time is reduced in the RAD model as the prototypes are independently
tested during every iteration. However, the data flow and the interfaces between all the
components need to be thoroughly tested with complete test coverage. Since most of the
programming components have already been tested, it reduces the risk of any major issues.
The following illustration describes the RAD Model in detail.

RAD Model - Application

RAD model can be applied successfully to the projects in which clear modularization is possible.
If the project cannot be broken into modules, RAD may fail.
The following pointers describe the typical scenarios where RAD can be used –
 RAD should be used only when a system can be modularized to be delivered in an
incremental manner.
 It should be used if there is a high availability of designers for modeling.
 It should be used only if the budget permits use of automated code generating tools.
 RAD SDLC model should be chosen only if domain experts are available with relevant
business knowledge.
 Should be used where the requirements change during the project and working
prototypes are to be presented to customer in small iterations of 2-3 months.

THE ADVANTAGES OF THE RAD

 Changing requirements can be accommodated.
 Progress can be measured.
38
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
  Iteration time can be short with use of powerful RAD tools.
 Productivity with fewer people in a short time.
 Reduced development time.
 Increases reusability of components.
 Quick initial reviews occur.
 Encourages customer feedback.
 Integration from very beginning solves a lot of integration issues.

THE DISADVANTAGES OF THE RAD

 Dependency on technically strong team members for identifying business requirements.
 Only system that can be modularized can be built using RAD.
 Requires highly skilled developers/designers.
 High dependency on modeling skills.
 Inapplicable to cheaper projects as cost of modeling and automated code generation is
very high.
 Management complexity is more.
 Suitable for systems that are component based and scalable.
 Requires user involvement throughout the life cycle.
 Suitable for project requiring shorter development times.

DATA PROCESSING SYSTEMS

A data processing system is a combination of machines, people, and processes that for a set of
inputs produces a defined set of outputs.
The inputs and outputs are interpreted as data, facts, information, depending on the
interpreter's relation to the system. A common synonymous term is “information system".
A data processing system may involve some combination of:
 Conversion- converting data to another form or Language.
 Validation – Ensuring that supplied data is "clean, correct and useful."
 Sorting – "arranging items in some sequence and/or in different sets."
 Summarization – reducing detail data to its main points.
 Aggregation – combining multiple pieces of data.
 Analysis – the "collection, organization, analysis, interpretation and presentation of
data.".
 Reporting – list detail or summary data or computed information.

Types of data processing systems

1. By application area
 Scientific data processing
Scientific data processing "usually involves a great deal of computation (arithmetic and
comparison operations) upon a relatively small amount of input data, resulting in a small
volume of output."
 Commercial data processing
Commercial data processing "involves a large volume of input data, relatively few
computational operations, and a large volume of output." Accounting programs are the
prototypical examples of data processing applications. Information Systems (IS) is the field that
studies such organizational computer system
2. By service type
 Transaction processing systems
 Information storage and retrieval systems
 Command and control systems
 Computing service systems

39
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
  Process control systems
 Message switching systems

CENTRALISED AND DECENTRALISED SYSTEMS

A decentralized system in systems theory is a system in which lower level components operate
on local information to accomplish global goals.
The global pattern of behavior is an emergent property of dynamical mechanisms that act upon
local components, such as indirect communication, rather than the result of a central ordering
influence (see centralized system).
Centralized versus decentralized systems
A centralized system is one in which a central controller exercises control over the lower-level
components of the system directly or through the use of a power hierarchy (such as instructing
a middle level component to instruct a lower level component). The complex behavior
exhibited by this system is thus the result of the central controller's "control" over lower level
components in the system, including the active supervision of the lower level components.
A decentralized system, on the other hand, is one in which complex behavior emerges through
the work of lower level components operating on local information, not the instructions of any
commanding influence. This form of control is known as distributed control, or control in
which each component of the system is equally responsible for contributing to the global,
complex behavior by acting on local information in the appropriate manner.
Self-organization
Decentralized systems are intricately linked to the idea of self-organization —a phenomenon in
which local interactions between components of a system establish order and coordination to
achieve global goals without a central commanding influence.

SOFTWARE PROTOTYPING IN DETAILS

Software prototyping is the activity of creating prototypes of software applications, i.e.,
incomplete versions of the software program being developed A prototype typically simulates
only a few aspects of, and may be completely different from, the final product.
Purpose
 The purpose of a prototype is to allow users of the software to evaluate developers'
proposals for the design of the eventual product by actually trying them out, rather than
having to interpret and evaluate the design based on descriptions.
 To provide an understanding of the software's functions and potential threats or issues.
 To be used by end users to describe and prove requirements that have not been
considered, and can be a key factor in the commercial relationship between developers
and their clients.

STEPS INVOLVED
The process of prototyping involves the following steps.
1. Identify basic requirements
Determine basic requirements including the input and output information desired. Details, such
as security, can typically be ignored.
2. Develop initial prototype
The initial prototype is developed that includes only user interfaces.
3. Review
The customers, including end-users, examine the prototype and provide feedback on potential
additions or changes.
4. Revise and enhance the prototype
Using the feedback both the specifications and the prototype can be improved. Negotiation
about what is within the scope of the contract/ product may be necessary. If changes are
introduced then a repeat of steps #3 and #4 may be needed.
40
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
Dimensions of prototypes
 Horizontal prototype
A common term for a user interface prototype is the horizontal prototype. It provides a broad
view of an entire system or subsystem, focusing on user interaction more than low-level
system functionality, such as database access.
USES OF HORIZONTAL PROTOTYPES
Horizontal prototypes are useful for:
- Confirmation of user interface requirements and system scope.
- Demonstration version of the system to obtain buy-in from the business.
- Develop preliminary estimates of development time, cost and effort.
 Vertical prototype
A vertical prototype is an enhanced complete elaboration of a single subsystem or function. It
is useful for obtaining detailed requirements for a given function, with the following benefits:
- Refinement of database design.
- Obtain information on data volumes and system interface needs, for network sizing and
performance engineering.
- Clarify complex requirements by drilling down to actual system functionality.
Types of prototyping
Software prototyping has many variants. However, all of the methods are in some way based
on two major forms of prototyping:
 Throwaway prototyping
 Evolutionary prototyping.
Throwaway prototyping
Also called close-ended prototyping. Throwaway or rapid prototyping refers to the creation of a
model that will eventually be discarded rather than becoming part of the final delivered
software.
After preliminary requirements gathering is accomplished, a simple working model of the
system is constructed to visually show the users what their requirements may look like when
they are implemented into a finished system.
It involves creating a working model of various parts of the system at a very early stage, after a
relatively short investigation. The method used in building it is usually quite informal, the most
important factor being the speed with which the model is provided. The model then becomes
the starting point from which users can re-examine their expectations and clarify their
requirements.
When this goal has been achieved, the prototype model is 'thrown away', and the system is
formally developed based on the identified requirements.

WHY USING THROAWAY PROTOTYPING?

 It can be done quickly and users can get quick feedback.
 It is cost-effective since it helps to identify weaknesses early and make changes quickly.
 It has ability to construct interfaces that the users can test.

Summary: In this approach the prototype is constructed with the idea that it will be discarded
and the final system will be built from scratch. The steps in this approach are:
1. Write preliminary requirements
2. Design the prototype
3. User experiences/uses the prototype, specifies new requirements
4. Repeat if necessary
5. Write the final requirements

41
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
Evolutionary prototyping
Evolutionary prototyping (also known as breadboard prototyping) is quite different from
throwaway prototyping. The main goal when using evolutionary prototyping is to build a very
robust prototype in a structured manner and constantly refine it.
The reason for this approach is that the evolutionary prototype, when built, forms the heart of
the new system, and the improvements and further requirements will then be built.
When developing a system using evolutionary prototyping, the system is continually refined
and rebuilt. This technique allows the development team to add features, or make changes
that couldn't be conceived during the requirements and design phase.
Evolutionary prototypes have an advantage over throwaway prototypes in that they are
functional systems. Although they may not have all the features the users have planned, they
may be used on an interim basis until the final system is delivered.
Other types
Incremental prototyping
- The final product is built as separate prototypes.
- At the end, the separate prototypes are merged in an overall design. By the help of
incremental prototyping the time gap between user and software developer is reduced.
Extreme prototyping
- Extreme prototyping as a development process is used especially for developing web
applications.
- Basically, it breaks down web development into three phases, each one based on the
preceding one.
- The first phase is a static prototype that consists mainly of HTML pages. In the second
phase, the screens (user interfaces) are programmed and fully functional using a
simulated services layer. In the third phase, the services are implemented.
Advantages of prototyping
• Reduced time and costs: Prototyping can improve the quality of requirements and
specifications provided to developers. Because changes cost exponentially more to
implement as they are detected later in development, the early determination of what
the user really wants can result in faster and less expensive software.
• Improved and increased user involvement: Prototyping requires user involvement
and allows them to see and interact with a prototype allowing them to provide better
and more complete feedback and specifications. Because of user involvement, the final
product is more likely to satisfy the user's desire for look, feel and performance.
Disadvantages of prototyping
• Insufficient analysis: The focus on a limited prototype can distract developers from
properly analyzing the complete project. This can lead to overlooking better solutions,
preparation of incomplete specifications or the conversion of limited prototypes into
poorly engineered final projects that are hard to maintain.
• User confusion of prototype and finished system: Users can begin to think that a
prototype, intended to be thrown away, is actually a final system that merely needs to
be finished or polished. (They are, for example, often unaware of the effort needed to
add error-checking and security features which a prototype may not have.) .
• Developer misunderstanding of user objectives: Developers may assume that
users share their objectives (e.g. to deliver core functionality on time and within budget),
without understanding wider commercial issues. For example, user representatives
attending Enterprise software (e.g. PeopleSoft) events may have seen demonstrations of
"transaction auditing" (where changes are logged and displayed in a difference grid
view) without being told that this feature demands additional coding and often requires
more hardware to handle extra database accesses.
42
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES
 • Developer attachment to prototype: Developers can also become attached to
prototypes they have spent a great deal of effort producing; this can lead to problems,
such as attempting to convert a limited prototype into a final system when it does not
have an appropriate underlying architecture
• Excessive development time of the prototype: A key property to prototyping is the
fact that it is supposed to be done quickly. If the developers lose sight of this fact, they
very well may try to develop a prototype that is too complex. When the prototype is
thrown away the precisely developed requirements that it provides may not yield a
sufficient increase in productivity to make up for the time spent developing the
prototype.
• Expense of implementing prototyping: the startup costs for building a development
team focused on prototyping may be high.

PROJECT MONITORING AND CONTROL

What is Project Monitoring?

Project Monitoring refers to the process of keeping track of all project-related metrics including
team performance and task duration, identifying potential problems and taking corrective
actions necessary to ensure that the project is within scope, on budget and meets the specified
deadlines

Why is Project Monitoring important?

 It facilitates correct and informed decision making at management level.

 Helps to detect project loopholes early enough and gives direction on how to solve them.
 It supports project quality improvement and maintanance.
 It helps to assess if project progres is being achieved or not

WAYS OF PROJECT MORNITORING

 Real-time monitoring of team performance

With automated task monitoring,one can monitor how everything is going, including what the
team is working on, which team members are stuck on a task or what other tasks need to be
done to move forward with the project.

 Regular status and progress reports

The report displays the amount of time the assignee has spent on a task and predicts how
much more is needed to complete the entire project so you can identify existing issues and
make timely adjustments to get things back on track.

 Providing recommendations and suggestions

This includes predicting the probability of tasks going overdue or missing its deadline and
provide valuable advice on how you can get the team to work together to prevent this from
happening.

 Ensuring that recommended actions are implemented

43
SYSTEMS ANALYSIS & DESIGN ALEX MWEBAZE OWN NOTES