System Analysis
Dr Edmore Chikohora
Namibia University of Science & Technology
Lecture I: Requirements Engineering
• Systems requirements
• Gathering Requirements
 Gathering Requirements Through Interviews
 Gathering Requirements Using Other Techniques
 Gathering Requirements in Agile Projects
• Representing Requirements
• Validating and Verifying Requirements
Requirements Engineering
System requirement:
A characteristic or feature that must be included in an information system to
satisfy business requirements and be acceptable to users
Requirements engineering:
Composed of three main activities:
i. Gathering requirements: understanding the problem
ii. Representing requirements: describing the problem
iii. Validating and verifying requirements: agreeing upon the problem
Types of Requirements
Functional requirements
A statement of the services a system should provides.
Examples:
• The website shall report online volume statistics every four hours and hourly
during peak periods.
• The inventory system shall produce a daily report showing the part number,
description, quantity on hand, quantity allocated, quantity available, and unit
cost of all sorted by part number.
• The system must provide logon security at the operating system level and at
the application level.
Types of Requirements
Non-Functional requirements
A statement of operational system constraints. AKA quality attributes.
Examples:
• Data entry screens must be uniform, except for background color, which can
be changed by the user.
• The system must support 25 users online simultaneously.
• Response time must not exceed four seconds.
• The system must be operational 7 days a week, 365 days a year.
• The system should work on Windows and Mac platforms.
Activity 1
Requirements present numerous challenges to the Systems Analyst.
List and discuss any Five (5) most important requirements challenges Systems
Analysts face during system project implementation.
Systems Development Techniques
System developers or development team uses different techniques to
achieve best results at the end of the project.
There are three(3) most popular techniques used in systems
development, ie.
i. Joint Application Development (JAD)
ii. Rapid Application Development (RAD) and
iii. Agile methods
JAD
A popular fact-finding technique that brings
users into the development process as
active participants.
The end product of JAD is a requirements
model
JAD Participants and Roles:
• A JAD team usually meets over a period of
days or weeks in a special conference room to
analyze the existing system, obtain user input
and expectations, and document user
requirements for the new system.
• The table describes some typical JAD
participants and their roles.
JAD
Advantages and Disadvantages:
• Compared with traditional methods, JAD is more expensive
• It can be cumbersome if the group is too large relative to the size of the project.
• Many companies find, however, that JAD allows key users to participate effectively in
the requirements engineering process.
• When users participate in the systems development process, they are more likely to
feel a sense of ownership in the results and support for the new system.
• When properly used, JAD can result in a more accurate statement of system
requirements, a better understanding of common goals, and a stronger commitment
to the success of the new system.
RAD
Attributes:
• A team-based technique that speeds up information systems development
and produces a functioning information system.
• Like JAD, RAD uses a group approach but goes much further.
• The end product of RAD is the new information system, hence RAD is a
complete methodology, with a four-phase life cycle that parallels the
traditional SDLC phases
• RAD relies heavily on prototyping and user involvement
• The project team uses CASE tools to build the prototypes and create a
continuous stream of documentation.
RAD Phases & Activities
RAD
Advantages and Disadvantages:
• The primary advantage is that systems can be developed more quickly with
significant cost savings.
• A disadvantage is that RAD stresses the mechanics of the systems itself and
does not emphasize the company’s strategic business needs.
• The risk is that a system might work well in the short term, but the corporate
and long-term objectives for the system might not be met.
• Another potential disadvantage is that the accelerated time cycle might allow
less time to develop quality, consistency and design standards.
Agile methods
Attributes:
• Attempt to develop a system incrementally by building a series of prototypes and constantly
adjusting them to user requirements.
• As the agile process continues, developers revise, extend, and merge earlier versions into the final
product.
• An agile approach emphasizes continuous feedback and each incremental step is affected by what
was learned in the prior steps.
• Scrum is another agile approach. The name comes from the rugby term scrum, where team
members lunge at each other to achieve their objectives.
• In a Scrum session, agile team members play specific roles, including colorful designations such as
pigs or chickens. (Note: These roles are based on the old joke about the pig and chicken who
discuss a restaurant where ham and eggs would be served. Pigs role would require a total
commitment, Chicken’s role would only be a contribution).
• In the agile world:
- The Pigs include the product owner, the facilitator, and the development team, while
- The chickens include users, other stakeholders and managers.
Agile methods
Advantages:
• Agile methods are very flexible and efficient in dealing with change.
• They stress team interaction and reflect a set of community-based values.
• Frequent deliverables constantly validate the project and reduce risk.
Disadvantages
• Team members need a high level of technical and interpersonal skills.
• Lack of structure and documentation can introduce risk factors, such as
blurring of roles and responsibilities, and loss of corporate knowledge.
• The overall project may be subject to significant change in scope as user
requirements continue to evolve during the project.
Lecture II: Gathering Requirements
• Gathering requirements is the first step in the requirements
engineering process. AKA requirements elicitation or fact-finding
• The systems analyst uses various techniques to gather requirements
such as:
-
Interviews,
Document review,
Observation,
Surveys,
Questionnaires,
Sampling and
Research.
Gathering Requirements
Sample questions during requirements elicitation as the focus shifts
from the current system to the proposed system.
Interview Process
Definition:
A planned meeting during which the analyst obtains information from another person.
The Interview Process
• Commences after identifying the information needed, as described in the previous
questions.
• Each interview consists of seven steps as follows:
1.
2.
3.
4.
5.
6.
7.
Determine the people to interview.
Establish objectives for the interview (purpose of interview).
Develop interview questions (open/ closed ended questions).
Prepare for the interview (Appointments, time your questions).
Conduct the interview.
Document the interview (write notes).
Evaluate the interview (make a reflection).
Other Techniques
•
•
•
•
Document review,
Observation,
Surveys,
Questionnaires
- Used to get information from a large number of people
• Brainstorming
- Structured/ unstructured
• Sampling
Random, Targeted, stratified, systematic.
• Research.
Using Agile methods
Agile methods use the following tools to gather requirements:
• Features,
- AKA an epic, that is a simple high-level statement of a requirements.
- Has a descriptive name, an estimate of its size in terms of derived requirements and a
priority (eg: collection of user stories).
• User stories,
- Represent more fine-grained requirements (ie. User roles, actions, and goals).
• Scenarios,
- A real-world example of how users will interact with the system. A scenario describes
a particular set of steps taken or events.
• Storyboards.
- A simple graphic organizer that helps systems analysts visualize the status of a project
Requirements Representation
This is meant to Keep accurate records of interviews, facts, ideas, and
observations.
The following are tools an Analyst can use:
• Natural languages
• Diagrams
• Models
Natural Languages
This format uses unstructured natural language, that is,
plain English to represent requirements.
• Requirements represented in unstructured natural
language can be stored in a simple file, in a database
that may facilitate searching its contents, or in an Excel
spreadsheet.
• Requirements represented as structured natural
language can be stored on a simple index card.
• The Volere shell from the Atlantic Systems Guild
Diagrams
Analysts use diagrams to help users, managers and IT professionals
understand the design of a system.
Three most commonly used diagrams are:
1. Functional Decomposition Diagram (FDD):
- A top-down representation of a function or process
2. Business Process Model (BPM):
- Represents one or more business processes, eg. Booking an airline ticket.
3. Data flow diagram (DFD)
- Shows how a system stores, processes and transforms data.
Diagrams
1. DFD
DFD shows how books are added
and removed in a library system
2. FDD
FDD shows a library system with four
top-level functions
3. PDM
PDM shows the processes involved
in an order processing system
Models
• Models provide a more formal representation of system requirements
using diagrams
• They can be drawn using CASE tools.
• The Unified Modeling Language (UML) is the most widely used modeling
technique for visualizing and documenting software systems design.
• UML uses object-oriented design concepts, but it is independent of any
specific programming language
• UML provides various graphical tools such:
- Use case diagrams and
- Sequence diagrams.
Use Case Diagram (UCD)
• A UCD visually represents the
interaction between users and
the information system.
• In a use case diagram, the user
becomes an actor, with a
specific role that describes how
he or she interacts with the
system.
• The system becomes the Use
Case
The UCD shows a Sales system,
where the actor is a customer and
the use case is a credit card
validation system
UCD with many Actors
The diagram shows a student
records system, with several
use cases and actor
Sequence Diagrams (SD)
• A SD shows the timing of interactions
between objects as they occur.
• A systems analyst might use a
sequence diagram to show all possible
outcomes or focus on a single scenario.
• Sequence diagram shows a credit card
validation process, discussed in
previous slide.
• Umlet
Activity I
Attempt the following questions:
1. What is the relationship between user stories and features in agile
projects?
2. Traceability is an important requirements attribute. It’s one of the
things that should be checked when performing V&V of the system
requirements. Describe how you would manually check traceability
for an existing system and list a few features of a CASE tool that you
think would help you with the task.
Lecture III: Data & Process Modelling
Content:
•
•
•
•
•
•
•
•
Logical Versus Physical Models
Data Flow Diagrams
Data Flow Diagram Symbols
Drawing Data Flow Diagrams
Drawing a Context Diagram
Drawing Lower-Level DFDs
Data Dictionary
Process Description Tools in Modular Design
Logical vs Physical Models
Logical model
Shows what the system must do, regardless of how it will be implemented physically.
Physical model
Later, in the systems design phase, Physical model is built that describes how the
system will be constructed.
Four-model approach
Its an approach that develops:
• Logical & physical models of the current system and
• Logical & Physical model of the new system.
• It provides a clear picture of current system functions before any modifications or
improvements are made. (A major benefit)
Data Flow Diagrams
A DFD uses various symbols to
show how the system
transforms input data into
useful information
DFD Symbols
A process receives input data and
produces output that has a different
content, form, or both.
Combined Data flow & Process
symbols
?
Why is the diagram above
incorrect?
Drawing a DFD
Guidelines for drawing a DFD:
• Draw the context diagram so it fits on one page.
• Use the name of the information system as the process name in the context
diagram. eg: Student Registration System.
• Use unique names within each set of symbols. eg. Entity names, data flow
names to avoid mix-up/ confusion.
• Do not cross lines. One way to achieve that goal is to restrict the number of
symbols in any DFD.
• Provide a unique name and reference number for each process.
Context Diagram (CD)
• A CD is a top-level view of an
information system that shows
the system’s boundaries and
scope.
• To draw a context diagram, start
by placing a single process
symbol in the center of the page
• The symbol represents the entire
information system, and it is
identified as process 0
Context diagram for an order system
Drawing DFD
DFD for the Order System showing different
levels
Activity II
Case Study:
You are the IT director at Big Ten University.
As part of a training program, you decide to
draw a DFD that includes some obvious
mistakes to see whether your newly hired
junior analysts can find them. You came up
with the diagram 0 DFD as shown.
Based on the rules explained earlier in the
lecture:
1. Identify the mistakes in the DFD
2. Explain the mistakes and suggest
corrections
Object Modelling
•
•
•
•
•
•
•
•
•
Object-Oriented Analysis
Objects
Attributes
Methods
Messages
Classes
Relationships Among Objects and Classes
The Unified Modeling Language (UML)
Tools
Object Oriented Analysis (OOA)
• Describes an information system by identifying things called objects.
• Object represents a real person, place, event, or transaction. eg: when
a patient makes an appointment to see a doctor, the patient is an object, the
doctor is an object, and the appointment itself is an object.
• An Object Model is a product of OOA, a popular approach that sees a
system from a viewpoint of the objects themselves.
Objects
A message is a command that
tells an object to perform a
certain method.
Example of a parent object
Example of a child object
Objects & Classes - Relationship
Relationships
• Enable objects to communicate and interact as they perform business
functions and transactions required by the system.
• Describe:
i.
ii.
iii.
What objects need to know about each other
How objects respond to changes in other objects and
The effects of membership in classes, super-classes, and sub-classes.
• Some relationships are stronger than others and the strongest relationship is
called inheritance
Inheritance
UML.
Use Case:
Represents the steps in a specific business
function or process.
A use case diagram showing the processes at
an auto service department.
Class Diagram:
Shows the object classes and relationships
involved in a use case
A Class diagram for a sales order use case
(Note: Attributes and methods omitted for clarity
UML
State Transition Diagram:
shows how an object changes from one state to
another, depending on events that affect the object.
Sequence diagram for the ADD NEW STUDENT
use case
Activity Diagram:
Shows actions & events as they occur
An activity diagram showing the actions and events
involved in withdrawing cash from an ATM.
Activity III:
You are an IT consultant and you are asked to create a new system for a
small real estate brokerage firm. You have no experience with OOA and
you decide to try it.
• How will you begin?
• How will the tasks differ from structured analysis?
Lecture IV: Development Strategies
Contents:
•
•
•
•
•
•
•
Traditional Versus Web-Based Systems Development
Evolving Trends
In-House Software Development Options
Offshoring
Software as a Service
Selecting a Development Strategy
Completion of Systems Analysis Tasks
Software Acquisition
Traditional methods:
• Inhouse development (develop software from within org.)
• Purchase a software package (with/ out modification)
• Hire consultants to perform the work (Outsourcing).
Contemporary methods:
• Application Service Providers (ASP)
• Web-hosted software options and firms that offer a variety of enterprise-wide
software solutions.
Traditional vs Web-based Software Acquisition
Traditional
Web-Based:
• Compatibility issues, including existing hardware and
software platforms and legacy system requirements,
influence systems design.
• Systems are developed and delivered in an Internet-based
framework such as .NET
• Systems are designed to run on local and wide-area
company networks.
• Systems often utilize Internet links and resources, but webbased features are treated as enhancements rather than
core elements of the design.
• Development typically follows one of three main paths: inhouse development, purchase of a software package with
possible modification, or use of outside consultants.
• Scalability can be affected by network limitations and
constraints.
• Internet-based development treats the web as the platform, rather
than just a communication channel.
• Web-based systems are easily scalable and can run on multiple
hardware environments.
• Large firms tend to deploy web-based systems as enterprise-wide
software solutions for applications such as customer relationship
management, order processing, and materials management.
• Web-based software treats the software application as a service
that is less dependent on desktop computing power and resources.
• Many applications require substantial desktop computing
power and resources.
• When companies acquire web-based software as a service rather
than a product they purchase, they can limit in-house involvement
and have the vendor install, configure, and maintain the system by
paying agreed-upon fees.
• Security issues usually are less complex than with webbased systems, because the system operates on a private
company network, rather than the Internet.
• Web-based software usually requires additional layers, called
middleware, to communicate with existing software and legacy
systems.
• Web-based solutions open more complex security issues that
should be addressed.
Inhouse Software Development
• A company can choose to develop its
own systems (make/ build). called a
make or buy, or build or buy, decision.
The company’s IT department makes,
builds the software.
• or Purchase (buy) a software package
from a vendor/ supplier .
• Sometimes an organization can buy and
possibly customize a software package.
• Many factors influence this decision, the
most important consideration is the Total
Cost of Ownership (TCO).
Make or Buy Decision
Outsourcing
• The transfer of information systems development, operation or maintenance to an
outside firm that provides these services for a fee, on a temporary or long-term basis.
i.
ii.
Application Service Provider (ASP) - firms that delivers a software application or access to an
application by charging a usage or subscription fee (SaaS).
Internet Business Services (IBS) – firms that provide powerful web-based support for
transactions such as order processing, billing, and customer relationship management, etc.
Issues & Concerns:
• Handing over sensitive organization’s data to an external service provider and trust the provider to
maintain security, confidentiality and quality.
• Outsourcing relieves a company of the responsibility of adding IT staff in busy times and
downsizing when the workload lightens.
• Raises employee concerns about job security. Talented IT people usually prefer positions where
the firm is committed to in-house development
• The solution can be only as good as the outsourcing firm that provides the service
Offshoring
• AKA Offshore outsourcing or global outsourcing, refers to the
practice of shifting IT development, support and operations to other
countries.
Issues & Concerns:
• The main reason for offshoring is the same as domestic outsourcing: To lower
bottom-line costs attract quality work from experts.
• Possible economic impact (forex payments, lack local development )
• Project control, security issues, disparate cultures and communication
challenges.
Selecting a Software Development Strategy
• Selecting the best development strategy is an important decision that
requires companies to consider multiple factors.
• The systems analyst has an important role to play in this decisionmaking process.
• Multiple factors should be considered, In particular:
i.
Analyzing the costs and benefits of each development alternative (A key to
providing objective data to management).
ii. A cost-benefit checklist can help guide this analysis
Analyzing Cost & Benefits
• Financial analysis tools are used to analyze costs/ benefits incurred in each
strategy.
• The Systems Analyst’s Toolkit describes three popular tools:
i.
Return on Investment (ROI) - A percentage rate that compares the total net
benefits (the return) received from a project to the total costs (the investment) of
the project.
ii. Payback Analysis - Determines how long it takes an information system to pay for
itself through reduced costs and increased benefits.
iii. Net Present Value (NPV) (of a project) - The total value of the benefits minus the
total value of the costs, with both costs and benefits adjusted to reflect the point
in time at which they occur.
• These tools and many others can be used to determine TCO
Cost Benefit Analysis Checklist
The best way to monitor the application of the tools discussed. The checklist
follows the steps below:
• List each development strategy being considered.
• Identify all costs and benefits for each alternative. Be sure to indicate when costs will
be incurred and benefits realized.
• Consider future growth and the need for scalability.
• Include support costs for hardware and software.
• Analyze various software licensing options, including fixed fees and formulas based
on the number of users or transactions.
• Apply the financial analysis tools to each alternative.
• Study the results and prepare a report to management.
The Software Acquisition Process
A typical example of issues and tasks involved in software acquisition:
Step 1: Evaluate the Information System Requirements
i.
ii.
iii.
iv.
v.
vi.
Evaluate the IS requirements
Identify key features of the software
Consider network and web related issues
Estimate volume and growth
Specify hardware, software and /or personnel
Prepare a RFQ
Step 2: Identify Potential Vendors or Outsourcing Options
Step 3: Evaluate the Alternatives
i.
ii.
iii.
Contact existing users/ clients
Application testing
benchmarking
Step 4: Perform Cost-Benefit Analysis
Step 5: Prepare a Recommendation
Activity IV:
1. To complete the systems analysis phase, the analyst must:
a.
b.
c.
Finalize the system requirements document,
Present their findings to management and
Begin the transition to systems design.
Discuss what is involved in each of the phases listed.
2. Suppose you tried to explain the concept of “Weighted evaluation
models” to a manager and she responded by asking, “So, how do
you set the weight factors? Is it just a subjective guess?” How would
you reply?