CSC 321: SYSTEM ANALYSIS
& DESIGN
SYSTEM
The term “system” originates from the Greek term systēma, which means to “place together”.
System An integrated set of interoperable elements, each with explicitly specified and bounded
capabilities, working synergistically to perform value-added processing to enable a User to
satisfy mission oriented operational needs in a prescribed operating environment with a
specified outcome and probability of success.
Systems are created to solve problems. One can think of the system Systems are created to
solve problems. One can think of the systems approach as an organized way of dealing with a
problem. In this dynamic world, the subject System Analysis and Design (SAD), mainly deals
with the software development activities.
Basically there are three major components in every system: input, processing and output.
In a system the different components are connected with each other and they are interdepen
dent.
Figure1: System components
In a system the different components are connected with each other and they are
interdependent. For example, the human body represents a complete natural system. We are
also bound by many national systems such as political system, economic system educational
system etc.
The objective of the system demands that some output is produced as a result of processing
the suitable inputs.
1
SYSTEM ANALYSIS AND SYSTEM DESIGN
System Analysis is the study of a business problem domain to recommend improvements and
specify the business requirements for the solution.
System Design is the specification or construction of a technical, computer-based solution fo
r the business requirements identified in a system analysis.
STAKEHOLDERS IN SYSTEM DEVELOPMENT
System Owners: are the information system's sponsors and chief advocates. They are usually
responsible for funding the project to develop, operate, and maintain the information system.
System Users: are the people who use or are affected by the information system on a regular
basis capturing, validating, entering, responding to, storing, and exchanging data and
information. A common synonym is client.
System Designers: translate system users' business requirements and constraints into a
technical solutions. They design the computer files, databases, inputs, outputs, screens, net
works and programs that will meet the system users' requirements.
System Builders: construct the information system components based on the design specific
ations from the system designer. In many cases, the system designer and builder for a
component are one and the same.
Systems Analyst: facilitates the development of information systems and computer
applications.
A systems analyst studies the problems and needs of an organization to determine how
people, data, processes, communications, and information technology can best accomplish
improvements for the business.
2
SYSTEMS ANALYST
The system analyst is a person who is thoroughly aware of the system and guides the system
development project by giving proper directions. He is an expert having technical and
interpersonal skills to carry out development tasks required at each phase. He pursues to match
the objectives of information system with the organization goal.
REQUIRED SKILLS OF THE SYSTEMS ANALYST
Systems analysts need a great variety of special skills, like technical knowledge and skills,
business knowledge and skills, people knowledge and skills, integrity skills and ethics etc.
1.
Technical Knowledge and Skills
A systems analyst should understand the fundamentals about:
● Computers and how they work.
●Devices that interact with computers, including input devices, storage devices and output
devices.
●Communications networks that connect computers.
● Databases and database management systems.
● Programming languages.
● Operating systems and utilities.
A systems analyst also need to know a lot about tools and techniques for developing systems
like:
●Software packages such as Microsoft Access and LibreOffice Base that can be used to
develop systems.
●Integrated development environments (IDEs) for specific programming languages, such as
Netbeans, Eclipse and MS Visual Studio .NET.
3
 Computer-aided system engineering (CASE) tools that store information about system
specifications created by analysts and sometimes generate program code, such as GNU
Ferret.
●Program code generators, testing tools, configuration management tools, software library
management tools, documentation support tools, project management tools and so on.
2.
Business Knowledge and Skills
 What business functions do organizations perform?
 How are organizations structured?
 How are organizations managed?
 What type of work goes on in organizations for example, finance, manufacturing,.marketing,
customer service and so on?
3.
People Knowledge and Skills
Because analysts usually work on development teams with other employees, systems analysts
need
to
understand
a
lot
about
people
skills.
It is critical that the analyst understand how people:
● Think.
● Learn.
● React to change.
● Communicate.
● Work (in a variety of jobs and levels).
4.
Integrity Skills and Ethics
A systems analyst is asked to look into problems that involve information in many different
parts of organization.
 The analyst must have the integrity to keep private information, such as health, salary
and job performance.
 They are expected to uphold the highest ethical standards when it comes to private
proprietary information they might encounter on the job.
4
INFORMATION SYSTEMS DEVELOPMENT (ISD)
Information systems development is the process (activity) whereby a work activity or a larger
organizational setting is facilitated by introducing a new socio-technical information system
or modifying or expanding an existing one. ISD includes sub-activities of analysis,
design, development, implementation, and evaluation. Depending on the viewpoint, it can be
seen as a software engineering process of a software producer, an application acquisition
process of a software user, or a works development process. Information systems development
is seen as first a social process, though it will contain technical aspects.
Early computer applications were implemented without an explicit information systems
development methodology. The emphasis of computer applications development was on
programming, with systems developers technically trained hut rarely good communicators nor
were they systems analysts. The needs of the users were rarely well established with the
consequence that the design was frequently inappropriate to the application. The dominant
'methodology' was rule-of-thumb and experience. This led to poor control and management of
the project. Most emphasis was placed on maintaining present systems to get them right rather
than developing new ones. Management were not getting value for money, and there was a
growing appreciation of the potential role of the systems analyst and the need for a
methodology to develop information systems. Below is a review of different methodologies
for software development.
System Development Lifecycle (SDLC)
A System development life cycle (SDLC) is a process by which systems analysts, software
engineers, programmers, and end users build information systems and computer applications.
SDLC methodology was first developed in the 1960s to manage the large software projects
associated with corporate systems running on mainframes. It is a very structured and riskaverse methodology designed to manage large projects that included multiple programmers
and systems that would have a large impact on the organization.
5
Systems-development life cycle (SDLC)/ waterfall model
Various definitions of the SDLC methodology exist, but most contain the following
phases.
1. Preliminary Analysis.
In this phase, a review is done of the request. Is creating a solution possible? What alternatives
exist? What is currently being done about it? Is this project a good/ fit for our organization? A
key part of this step is a feasibility analysis, which includes an analysis of the technical
feasibility (is it possible to create this?), the economic feasibility (can we afford to do this?),
and the legal feasibility (are we allowed to do this?). This step is important in determining if
the project should even get started.
2. System Analysis.
In this phase, one or more system analysts work with different stakeholder groups to determine
the specific requirements for the new system. No programming is done in this step. Instead,
procedures are documented, key players are interviewed, and data requirements are developed
in order to get an overall picture of exactly what the system is supposed to do. The result of
this phase is a system-requirements document.
3. System Design.
In this phase, a designer takes the system-requirements document created in the previous phase
and develops the specific technical details required for the system. It is in this phase that the
6
business requirements are translated into specific technical requirements. The design for the
user interface, database, data inputs and outputs, and reporting are developed here. The result
of this phase is a system-design document. This document will have everything a programmer
will need to actually create the system.
4. Programming.
The code finally gets written in the programming phase. Using the system-design document as
a guide, a programmer (or team of programmers) develop the program. The result of this phase
is an initial working program that meets the requirements laid out in the system-analysis phase
and the design developed in the system-design phase.
5. Testing.
In the testing phase, the software program developed in the previous phase is put through a
series of structured tests. The first is a unit test, which tests individual parts of the code for
errors or bugs. Next is a system test, where the different components of the system are tested
to ensure that they work together properly. Finally, the user-acceptance test allows those that
will be using the software to test the system to ensure that it meets their standards. Any bugs,
errors, or problems found during testing are addressed and then tested again.
6. Implementation.
Once the new system is developed and tested, it has to be implemented in the organization.
This phase includes training the users, providing documentation, and conversion from any
previous system to the new system. Implementation can take many forms, depending on the
type of system, the number and type of users, and how urgent it is that the system become
operational. These different forms of implementation are covered later in the chapter.
7. Maintenance.
This final phase takes place once the implementation phase is complete. In this phase, the
system has a structured support process in place: reported bugs are fixed and requests for new
features are evaluated and implemented; system updates and backups are performed on a
regular basis.
The SDLC methodology is sometimes referred to as the waterfall methodology to represent
how each step is a separate part of the process; only when one step is completed can another
7
step begin. After each step, an organization must decide whether to move to the next step or
not. This methodology has been criticized for being quite rigid. For example, changes to the
requirements are not allowed once the process has begun. No software is available until after
the programming phase.
SDLC was developed for large, structured projects. Projects using SDLC can sometimes take
months or years to complete. Because of its inflexibility and the availability of new
programming techniques and tools, many other software-development methodologies have
been developed. Many of these retain some of the underlying concepts of SDLC but are not as
rigid.
Rapid Application Development
Rapid application development (RAD) is a software-development (or systems-development)
methodology that focuses on quickly building a working model of the software, getting
feedback from users, and then using that feedback to update the working model. After several
iterations of development, a final version is developed and implemented.
The RAD methodology consists of four phases:
1.
Requirements Planning.
This phase is similar to the preliminary-analysis, system-analysis, and design phases of the
SDLC. In this phase, the overall requirements for the system are defined, a team is identified,
and feasibility is determined.
8
2.
User Design.
In this phase, representatives of the users work with the system analysts, designers, and
programmers to interactively create the design of the system. One technique for working with
all of these various stakeholders is the so-called JAD session. JAD is an acronym for joint
application development. A JAD session gets all of the stakeholders together to have a
structured discussion about the design of the system. Application developers also sit in on this
meeting and observe, trying to understand the essence of the requirements.
3.
Construction.
In the construction phase, the application developers, working with the users, build the next
version of the system.This is an interactive process, and changes can be made as developers
are working on the program. This step is executed in parallel with the User Design step in an
iterative fashion, until an acceptable version of the product is developed.
4.
Cutover.
In this step, which is similar to the implementation step of the SDLC, the system goes live. All
steps required to move from the previous state to the use of the new system are completed here.
The RAD methodology is much more compressed than SDLC. Many of the SDLC steps are
combined and the focus is on user participation and iteration. This methodology is much better
suited for smaller projects than SDLC and has the added advantage of giving users the ability
to provide feedback throughout the process. SDLC requires more documentation and attention
to detail and is well suited to large, resource-intensive projects. RAD is more appropriate for
smaller projects that are less resource-intensive and need to be developed quickly.
Agile Methodologies
Agile methodologies are a group of methodologies that utilize incremental changes with a
focus on quality and attention to detail. Each increment is released in a specified period of
time (called a time box), creating a regular release schedule with very specific objectives.
While considered a separate methodology from RAD, they share some of the same
principles: iterative development, user interaction, ability to change. The agile methodologies
are based on the Agile Manifesto,” first released in 2001.
9
The characteristics of agile methods include:

small cross-functional teams that include development-team members and users;

daily status meetings to discuss the current state of the project;

short time-frame increments (from days to one or two weeks) for each change to be
completed; and

at the end of each iteration, a working project is completed to demonstrate to the
stakeholders.
The goal of the agile methodologies is to provide the flexibility of an iterative approach while
ensuring a quality product.
Lean Methodology
The Lean methodology
In the Lean methodology, the focus is on taking an initial idea and developing a minimum
viable product (MVP). The MVP is a working software application with just enough
functionality to demonstrate the idea behind the project. Once the MVP is developed, it is
given to potential users for review. Feedback on the MVP is generated in two forms:
10
(1) Direct observation and discussion with the users.
(2) Usage statistics gathered from the software itself.
Using these two forms of feedback, the team determines whether they should continue in the
same direction or rethink the core idea behind the project, change the functions, and create a
new MVP. This change in strategy is called a pivot. Several iterations of the MVP are
developed, with new functions added each time based on the feedback, until a final product is
completed.
The biggest difference between the lean methodology and the other methodologies is that the
full set of requirements for the system are not known when the project is launched. As each
iteration of the project is released, the statistics and feedback gathered are used to determine
the requirements. The lean methodology works best in an entrepreneurial environment where
a company is interested in determining if their idea for a software application is worth
developing.
PROJECT SELECTION AND MANAGEMENT
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, it is best if a
brief description of each project is written 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".
11
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.
Project selection becomes necessary when an organization has a number of suggested
projects but not enough resources, money or time to undertake all of the projects. The
ideas for such projects may have come from many sources including: the community,
funders, local and national governments and Non-Governmental Organizations (NGOs).
You will therefore need a way of deciding on a priority order and choosing a project.
Project Management
Software project management refers to the branch of project management dedicated to the
planning, scheduling, resource allocation, execution, tracking and delivery of software and
web projects.
Project management in software engineering is distinct from traditional project management
in that software projects have a unique lifecycle process that requires multiple rounds of
testing, updating, and customer feedback.
In the 1970s and 1980s, the software industry grew very quickly, as computer companies
quickly recognized the relatively low cost of software production compared to hardware
production and circuitry. To manage new development efforts, companies applied the
established project management methods, but project schedules slipped during test runs,
especially when confusion occurred in the gray zone between the user specifications and the
delivered software. There were a lot of crisis part because the greater power available in
computers meant that larger software projects were tackled with techniques developed on
much smaller projects. This give rise for the need of techniques for software project
management. Good project management cannot guarantee success, but poor management on
significant projects always leads to failure.
12
Software projects have several properties that make them very different from other kinds of
engineering projects;

Software products are intangible. For instance, it’s hard to claim a bridge is 90%
complete if there is not 90% of the bridge there however, it is easy to claim that a software
project is 90% complete, even if there are no visible outcomes.

Most large software systems are one-off, with experience gained in one project being of
little help in another.

The technology changes very quickly. Most large software projects employ new
technology.
Activities in software project management usually include:
– project planning; – project scheduling; – risk management; – managing people.
Project Planning
The biggest single problem that afflicts software developing is that of underestimating
resources required for a project. Developing a realistic project plan is essential to gain an
understanding of the resources required, and how these should be applied. •
Types of plan are:
– 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.
Project Scheduling
Project scheduling is a mechanism to communicate what tasks need to get done and which
organizational resources will be allocated to complete those tasks in what timeframe.
A project is made up of many tasks, and each task is given a start and end (or due date), so it
13
can be completed on time. The project schedule should reflect all of the work associated with
delivering the project on time. Without a full and complete schedule, the project manager will
be unable to communicate the complete effort, in terms of cost and resources, necessary to
deliver the project.
Risk Management
Risk management is concerned with identifying risks and drawing up plans to minimize their
effect on a project. A risk is a probability that some adverse circumstance will occur. When
planning a project, it is critically important to know what the key risks are, and if possible plan
for them. Risk management covers staff turnover, management change, hardware
unavailability, requirements change, specification delays, size underestimate, technology
change, product competition etc.
Managing People
People are the organization's most important asset. In most organizations that develop
software, programmers, analysts, and other professionals work together in a team. An adequate
team structure depends on many factors, such as the number of people involved, their
experience and involvement in the project, the kind of project, and individual differences and
style. Project managers have to choose people for their team and establish ways of working
that leads to effective team performance.
People management factors include:

Consistency: team members should all be treated in a comparable way without favorites or
discrimination.

Respect: different team members have different skills and these differences should be
respected.

Inclusion: involve all team members and make sure that people's views are considered.

Honesty: you should always be honest about what is going well and what is going badly in
a project.
14
USE CASE ANALYSIS
Use case analysis describes scenarios of input that a software or system receives and the
corresponding expected output. The use case analysis attempts to convey system requirements
and usage, the role of the user, the system actions in response to the user, and what the user
will receive from the system.
Use case analysis is a technique used to identify the requirements of a system and the
information used to both define processes used and classes which will be used both in the use
case diagram and the overall use case in the development or redesign of a software system or
program.
Use cases are used to explain and document the interaction that is required between the user
and the system to accomplish the user's task. Use cases are created to help the development
team understand more fully the steps that are involved in accomplishing the user's goals. Once
created, use cases often can be used to derive more detailed functional requirements for the
new system.
A software development lifecycle goes through several stages: design, analysis,
implementation, and close out. Use case analysis can happen at any stage. A use case analysis
is used to design a system from the viewpoint of the end user, the person actually using the
site or software. It is used to determine and convey system behavior information. The use case
analysis attempts to convey information on the system requirements and usage, the role of the
user, the system actions in response to the user, and what the user will receive from the system.
Without proper analysis, a design is likely to be wrong which can be devastating if not timely
detected. Common analysis activity will generally produce a number of use case scenarios.
The Purpose of a use case is to define a piece of behavior of a system [or subsystem or class]
without revealing the internal structure of the system.
The concept of the use case has evolved as an important component of determining
requirements for the new system. Use cases originated as a part of the object-oriented
development world but have been accepted as a useful tool regardless of the development
methodology in use. This is not surprising since in any development approach (waterfall, RAD,
15
or agile) we need to hear and understand what the user needs to accomplish with the system.
Use cases are especially valuable for business system applications and Web sites. Both of these
types of systems commonly involve extensive user interactions
A use case should describe what the system shall do for the user (or actor in UML terminolo
gy) to achieve a particular goal at an appropriate level or detail without any implementation s
pecifics.
The Unified Modeling Language is a general-purpose, developmental, modeling language in
the field of software engineering that is intended to provide a standard way to visualize the
design of a system. UML, short for Unified Modeling Language, is a standardized modeling
language consisting of an integrated set of diagrams, developed to help system and software
developers for specifying, visualizing, constructing, and documenting the artifacts of software
systems, as well as for business modeling and other non-software systems. The UML
represents a collection of best engineering practices that have proven successful in the
modeling of large and complex systems. The UML is a very important part of developing
object oriented software and the software development process. The UML uses mostly
graphical notations to express the design of software projects. Using the UML helps project
teams communicate, explore potential designs, and validate the architectural design of the
software.
Key Components of Use-Case Analysis
Actors: Entities that use or are used by the system; typically people, but could also be other
systems or devices as long as they are outside the system being specified. Actors are
characterized not by the identity of the user, but rather by the role played by the actor. One
person can be several different actors in different roles. One actor can be played (at
different times) by several different persons. An entire committee could be one actor. An
actor need not be a living thing; it could be another subsystem.
Connections from Actors to Use-Cases
Relationships between Actors or between Use-Cases
16
Trigger for the use case: the event that causes the use case to begin. A trigger can be an external
trigger, such as a customer placing an order, the fire alarm ringing, or an internal trigger, like
the La attendant requesting chemical for a lab test.
Common Components of a Use Case





Name
Symbolic label
List of actors
Initiator
Verbal description
Brief Use-Case Description (Example 1)
Use Case ID - UC.1
Use case name: Order from catalog
Actors: customer, sales rep., shipping dept.
Initiator: customer
Description: Customer calls to order items from the catalog. The sales rep. identifies the item
numbers, verifies that the items are in stock, and confirms the order with the customer, giving
him the order number. The sales rep. then forwards the order to the Shipping dept.
Flow of Events:
1 Customer calls to order from catalog.
2 Sales representative identifies item numbers.
3 Sales representative verifies stock.
4 Sales representative confirms order.
5 Sales representative gives order number to Customer.
6 Sales representative passes order to Shipping.
The Use Case Diagram
Use case diagrams are used for visualization of use case interactions; diagrams are not the use
cases themselves.
17
Use Case Icons
Descriptions
Actor
Use Case
System boundary
Connection
Use case diagram for Example 1 above
Steps in Use-Case Analysis
 Identify system boundaries
18
 Identify actors: (Recall: an actor is an entity playing a particular role with respect to the
system).
 Identify use cases themselves.
o Every use case has at least one actor.
o A specific actor initiates the use case.
o The same actor may participate in multiple use cases, as initiator in some and
not in others.
 Create the description including flow of events.
 Identify clarifying scenarios where helpful.
A Use Case Scenario
A scenario is a single path through the event flow. For example, if there is a conditional part,
only one branch is taken in the scenario. Obviously, all scenarios cannot be enumerated; there
might be an infinite set of them. If the use case involves iteration, only a finite number of
iterations are used in the scenario.
Use-Case 2 (Example 2)
Use Case ID - UC.2
Use case name: Money Transfer
Actor: customer, login agent
Description: Allows the actor transfer money between accounts
Flow of events
1. Actor logs into the system
2. Actor selects from account, enters to account and a sum
a. If the sum is ≥ N10,000, a fee of 2% the sum is added
b. If the sum is < N10,000, no fee is added
3. The updated balance is displayed
19
20
PROCESS MODELING
A process model describes business processes the activities that people do. Process models are
developed for the as-is system and/or the to-be system. A process model is a graphical way of
representing how a business system should operate. It illustrates the processes or activities that
are performed and how data move among them. A process model can be used to document the
current system (i.e., as-is system) or the new system being developed (i.e., to-be system),
whether computerized or not. Graphically depicting the system that will be developed in a set
of well-organized diagrams is a very useful approach which employ an array of tools and
techniques that will help stakeholders understand and clarify what the new system must do
before the new system is actually constructed. There are many different process modeling
techniques in use today, the most commonly used technique is:
Data Flow Diagram (DFD) & Decomposition Diagram
Data Flow Diagram (DFD) shows how data flows around an information system.
They are a simple and powerful graphic technique which is both easily updated and easily
understood by users. This is basically one of the main diagrammatic techniques of Structured
System Analysis and Design Methodology.
n
PN
Process: Shows a transformation of data and is also referred to as a function.
n
is the number of the process, this number also indicates the level of the process.
PN
is the process name.
A data flow diagram can be defined as a hierarchical set of diagrams which is used to define:
- the boundary of the system to be developed
21
- the information flow to and from the system
- data flows within the system
- the functions used by the system.
(used to define the project scope and to provide measures of performance - for use in estimating
and planning).
How is it developed?
1. Identify inputs & outputs.
2. Label all data flows.
3. Label all processes.
4. Identify data stores.
5. Label all External Entities.
6. Start again.
Data Flows between
 External entity and Process
 Data Store and Process,
 Process and Process
Note: Information (Data) held for any amount of time between processes is called a Data Store.
Decomposition Diagram
This is a tool used to depict the breaking of a system into subcomponents.
22
Decomposition diagram for Bus repair process.
Elements of Data Flow Diagrams
The language of DFDs includes a set of symbols, naming conventions, and syntax rules. There
are four symbols in the DFD language (processes, data flows, data stores, and external entities),
each of which is represented by a different graphic symbol.
Process
A process is an activity or a function that is performed for some specific business reason.
Processes are discrete actions that transform input data to output data.
Processes can be manual or computerized. Every process should be named starting with a verb
and ending with a noun (e.g., “Determine request quantity, Create Student Record, Calculate
Purchase Cost, Register Client” etc). Names should be short, yet contain enough information
23
so that the reader can easily understand exactly what they do. In general, each process performs
only one activity, so most system analysts avoid using the word “and” in process names
because it suggests that the process performs several activities. In addition, every process must
have at least one input data flow and at least one output data flow.
Data Flow
A data flow is a single piece of data (e.g., quantity available) (sometimes called a data element),
or a logical collection of several pieces of information (e.g., new chemical request). Every data
flow should be named with a noun. The description of a data flow lists exactly what data
elements the flow contains.
Data flows are the glue that holds the processes together. One end of every data flow will
always come from or go to a process, with the arrow showing the direction into or out of the
process. Data flows show what inputs go into each process and what outputs each process
produces. Every process must create at least one output data flow, because if there is no output,
the process does not do anything. Likewise, each process has at least one input data flow,
because it is difficult, if not impossible, to produce an output with no input.
Data Store
A data store is a collection of data that is stored in some way (which is determined later when
creating the physical model). Data stores are temporary or permanent repositories of
information that are inputs to or outputs of processes. E.g. Student Master, Client List etc.
24
Every data store is named with a noun and is assigned an identification number and a
description. Data stores form the starting point for the data model and are the principal link
between the process model and the data model.
D
3
Student
Master
External Entity
An external entity is a person, organization, organization unit, or system that is external to the
system, but interacts with it. The external entity typically corresponds to the primary actor
identified in the use case. External entities provide data to the system or receive data from the
system, and serve to establish the system boundaries. Every external entity has a name and a
description. The key point to remember about an external entity is that it is external to the
system, but may or may not be part of the organization. People who use the information
from the system to perform other processes or who decide what information goes
into the system are documented as external entities (e.g., student, customer, client,
managers, and staff etc.). In other words’ external entities represent persons, processes or
machines which produce data to be used by the system or receive data that is output by the
system.
Student
System
A system is the collection of all business processes which perform tasks or produce outputs
we are interested in. The system is a single process, connected to external entities which is
usually represented in a “Context Diagram”
Subsystems
25
A subsystem gives a more detailed view of individual processes contained in the context
diagram. It Includes data stores, more elementary processes etc.
An example of a DFD case study: Bus Garage Repairs
Buses come to a garage for repairs.
A mechanic and helper perform the repair, record the reason for the repair and record the total
cost of all parts used on a Shop Repair Order.
Information on labor, spare parts and repair outcome is used for billing by the Accounting
Department, parts monitoring by the inventory management computer system and a
performance review by the supervisor.
1. Key process (“the system”): performing repairs and storing information related to
repairs.
2. External Entities:






Bus
Mechanic
Helper
Supervisor
Inventory Management System
Accounting Department, etc.
3. Processes:






Record Bus ID
Record reason for repair
Determine parts needed
Perform repair
Calculate cost of parts used and total cost
Record labor hours, cost of labor.
4. Data stores:




Personnel file
Repairs file
Bus master list
Parts list
5. Data flows:
 Repair order
 Bus record
26
 Parts record
 Employee timecard
 Invoices
Bus Garage Context Diagram
DATA MODELING
A data model gives a detailed description of a conceptual representation of the data structures
that are required by a database. The data structures include the data objects, the associations
between data objects, and the rules which govern operations on the objects. As the name
implies, the data model focuses on what data is required and how it should be organized rather
than what operations will be performed on the data. To use a common analogy, the data model
is equivalent to an architect's building plans.
A data model is independent of hardware or software constraints. Rather than try to represent
the data as a database would see it, the data model focuses on representing the data as the user
27
sees it in the "real world". It serves as a bridge between the concepts that make up real-world
events and processes and the physical representation of those concepts in a database
Data Modelling in the Context of Database Design
Database design is defined as: "design the logical and physical structure of one or more
databases to accommodate the information needs of the users in an organization for a defined
set of applications". The design process roughly follows five steps:
1. planning and analysis
2. conceptual design
3. logical design
4. physical design
5. implementation
The data model is one part of the conceptual design process. The other, typically is the
functional model. The data model focuses on what data should be stored in the database while
the functional model deals with how the data is processed. To put this in the context of the
relational database, the data model is used to design the relational tables. The functional model
is used to design the queries which will access and perform operations on those tables.
Components of a Data Model
The data model gets its inputs from the planning and analysis stage. Here the modeller, along
with analysts, collects information about the requirements of the database by reviewing
existing documentation and interviewing end-users.
The data model has two outputs. The first is an entity-relationship diagram which represents
the data structures in a pictorial form. Because the diagram is easily learned, it is valuable tool
to communicate the model to the end-user. The second component is a data document. This
a document that describes in detail the data objects, relationships, and rules required by the
database. The dictionary provides the detail required by the database developer to construct
the physical database.
28
SYSTEM ACQUISITION STRATEGIES
SOFTWARE REQUIREMENT
Software Requirements Process
Software requirements process is the process of establishing the services that the customer
requires from a system and the constraints under which it operates and is developed. The
requirements themselves are the descriptions of the system services and constraints that are
generated during the requirements engineering process.
Requirements may range from a high-level abstract statement of a service or of a system
constraint to a detailed mathematical functional specification.
Types of Requirements
User requirements: are statements given in natural language plus diagrams of the services
the system provides and its operational constraints. They are usually written for customers.
System requirements: are structured document setting out detailed descriptions of the
system’s functions, services and operational constraints.
It defines what should be
implemented e.g. it may be part of a contract between client and contractor etc.
Functional and Non-Functional Requirements
Functional requirements: are statements of services the system should provide, how the
system should react to particular inputs and how the system should behave in particular
situations. It describes functionality or system services and it also depends on the type of
software, expected users and the type of system where the software is used.
29
Functional user requirements may be high-level statements of what the system should do but
functional system requirements should describe the system services in detail.
Non-functional requirements; are constraints on the services or functions offered by the
system such as timing constraints, constraints on the development process, standards, etc.
Domain requirements: are requirements that come from the application domain of the system
and that reflect characteristics of that domain.
*A case study for functional and non-functional requirements of a system.
The LIBSYS system
A library system that provides a single interface to a number of databases of articles in different
libraries. Users can search for, download and print these articles for personal study.
Examples of functional requirements for this case study are:
 The user shall be able to search either all of the initial set of databases or select a subset
from it.
 The system shall provide appropriate viewers for the user to read documents in the
document store.
 Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able
to copy to the account’s permanent storage area.
Examples of non-functional requirements for this case study is:
 The project should be completed within three (3) months.
30
System Analysis and Design, Fifth Edition by Roberta M. Roth, Barbara Haley Wixom, Alan
Dennis 2019 Edition: Information Systems for Business and Beyond.
The 2019 edition of the textbook by Dr. David Bourgeois. This edition has been updated
with new content.
31