ADDIS ABABA UNIVERSITY

College of Business and Economics

Department of Management

System Analysis and Design Individual Assignment

Title: Comprehensive Exercises

Submitted by: Muslim Yasin

User Name: UGR/0229/13

Section: 3

Submitted to: Mesfin Fikre (PhD)

Submission Date: June, 2023

1|Page
Table of Contents
CHAPTER ONE (1).....................................................................................................................................6
System Development Environment............................................................................................................6
1. Sub systems

2. Systems thinking...................................................................................................................................6
6. Waterfall model....................................................................................................................................8
10. Interrelated system components.......................................................................................................9
11. Joint application design (JAD).........................................................................................................9
13. Prototyping Model...........................................................................................................................10
14. Rapid application development (RAD)..........................................................................................10
15. Repository.........................................................................................................................................10
17. Systems analysis...............................................................................................................................11
18. Systems analyst................................................................................................................................11
19. Systems design..................................................................................................................................11
20. Systems development life cycle (SDLC).........................................................................................11
21. Systems development methodologies.............................................................................................12
Part II..........................................................................................................................................................12
Sources of SW.............................................................................................................................................12
CHAPTER TWO (2)..............................................................................................................................13
Managing the IS Project........................................................................................................................13
1. Critical path........................................................................................................................................13
11. Network diagram.............................................................................................................................15
14. IS Project management body of knowledge..................................................................................15
18. IS Project initiation..........................................................................................................................16
19. IS Project management...................................................................................................................16
25. IS project cost estimation................................................................................................................17
28. IS project success factors.................................................................................................................17
29. IS project success criteria................................................................................................................18
CHAPTER THREE (3).............................................................................................................................18
System Planning and selection..................................................................................................................18
2. System analyst technical skills..........................................................................................................18
3. System analysis as a profession.........................................................................................................18
4. IS problems and their manifestations..............................................................................................19
6. Break-even analysis...........................................................................................................................19
8. Intangible benefit:..............................................................................................................................20
11. Present value.....................................................................................................................................20

2|Page
 14. Tangible benefit................................................................................................................................20
15. Tangible cost.....................................................................................................................................21
CHAPTER 4...............................................................................................................................................21
Determining system requirements............................................................................................................21
4. IS requirements tractability matrix.................................................................................................22
6. IS requirement gathering techniques...............................................................................................22
7. Business process reengineering (BPR).............................................................................................23
9. Major IS requirement types..............................................................................................................25
10. Closed-ended questions...................................................................................................................25
13. Informal system.................................................................................................................................25
16. Open-ended questions......................................................................................................................26
CHAPTER 5...............................................................................................................................................26
Structuring System requirements: PM....................................................................................................26
1. Process Modeling:..............................................................................................................................26
2. Data Flow Diagram(DFD).................................................................................................................26
3. Context DFD.......................................................................................................................................27
4. Data flow.............................................................................................................................................27
5. Data Store...........................................................................................................................................27
6. IS Process............................................................................................................................................27
7. Data Sources/Sink/.............................................................................................................................27
8. DFD Completeness.............................................................................................................................28
9. DFD Balancing...................................................................................................................................28
10. DFD Consistency..............................................................................................................................28
11. Gap Analysis......................................................................................................................................28
12. Level-0 diagram...............................................................................................................................29
13. 1-level DFD:......................................................................................................................................29
14. 2-level DFD:......................................................................................................................................29
15. Level-n DFD.....................................................................................................................................30
16. DFD Drawing Rules.........................................................................................................................30
CHAPTER SIX (6).....................................................................................................................................31
DATA MODELING...................................................................................................................................31
1.Attribute...............................................................................................................................................31
2. Entity...................................................................................................................................................31
3. Entity Class.........................................................................................................................................32
4. Binary relationship............................................................................................................................32
5. Candidate key.....................................................................................................................................32

3|Page
 6. Cardinality..........................................................................................................................................32
7. Conceptual data model (ERD)..........................................................................................................32
8. Entity instance (instance)..................................................................................................................32
9. Entity Identifier..................................................................................................................................32
10. Relationship......................................................................................................................................33
11. Ternary relationship........................................................................................................................33
12. Unary (recursive) relationship........................................................................................................33
CHAPTER SEVEN (7)..............................................................................................................................34
Logic Modeling PART I............................................................................................................................34
1. Logic Modeling...................................................................................................................................34
PART II.......................................................................................................................................................37
Designing Databases..................................................................................................................................37
CHAPTER EIGHT (8)..............................................................................................................................38
2. Installation..........................................................................................................................................39
3. Acceptance testing -...........................................................................................................................39
4. Adaptive maintenance.......................................................................................................................39
5. Alpha testing -....................................................................................................................................39
6. Beta testing -.......................................................................................................................................40
7. Corrective maintenance.....................................................................................................................40
8. Direct installation...............................................................................................................................40
9. System documentation.......................................................................................................................40
10. User documentation.........................................................................................................................40
12. Integration testing -..........................................................................................................................41
13. Internal documentation -.................................................................................................................41
14. Issue tracking system -....................................................................................................................41
15. Maintenance.....................................................................................................................................41
16. Parallel installation..........................................................................................................................41
17. Perfective maintenance....................................................................................................................41
18. Phased installation...........................................................................................................................41
19. Preventive maintenance -................................................................................................................41
20. Single-location installation..............................................................................................................41
21. Support..............................................................................................................................................41
22. System testing...................................................................................................................................41
23. Stress testing.....................................................................................................................................41
24. Unit testing........................................................................................................................................42

4|Page
5|Page
CHAPTER ONE (1)
Part I

System Development Environment

1. Sub systems

A subsystem is a single, predefined operating environment through which the system coordinates
the work flow and resource use. The system can contain several subsystems, all operating
independently of each other. Subsystems manage resources.

2. Systems thinking
Systems thinking is an approach to integration that is based on the belief that the component
parts of a system will act differently when isolated from the system’s environment or other parts
of the system.

3. Software Agile Methodologies

6|Page
It is a type of software development methodology that anticipates the need for flexibility and
applies a level of pragmatism to the delivery of the finished product.
4. Application software

application software, also called application program, software designed to handle specific tasks
for users. Such software directs the computer to execute commands given by the user and may be
said to include any program that processes data for a user.
5. System Components

Information systems are defined by the components that make up the system, and the role those
components play in an organization. Information systems can be viewed as having three core
components: technology, people, and process that take the data and transform it into information.

Information Systems Components

6. Waterfall model
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.

7|Page
7. Spiral model

Spiral Model is a risk-driven software development process model. It is a combination of

waterfall model and iterative model. Spiral Model helps to adopt software development elements
of multiple process models for the software project based on unique risk patterns ensuring
efficient development process.

8|Page
8. Computer-aided software engineering (CASE)

Computer-aided software engineering (CASE) is the application of computer-assisted tools and

methods in software development to ensure a high-quality and defect-free software.
9. Information systems analysis and design

Amethod used by companies to create and maintain systems that perform basic business
functions Main goals to improve employee efficiency by applying software solutions to key
business tasks.

10. Interrelated system components.

Computer systems consist of three components as shown in below image: Central Processing
Unit, Input devices and Output devices. Input devices provide data input to processor, which
processes data and generates useful information that's displayed to the user through output
devices. This is stored in computer's memory.

11. Joint application design (JAD)

JAD is defined as a structured workshop where people come together to plan projects, design
systems, or make business decisions (whether IT related or not).
12. Participatory design (PD)

Is an approach to designing technological systems that seeks to improve them by including future
users in the design process.

9|Page
13. Prototyping Model
The prototyping model is a systems development method in which a prototype is built, tested and
then reworked as necessary until an acceptable outcome is achieved from which the complete
system or product can be developed.

14. Rapid application development (RAD)

Rapid application development (RAD) is a development approach focusing on designing and
prototyping stage for the purpose of getting instant user feedback.

15. Repository
A repository, or repo, is computer storage for maintaining data or software packages. This
location contains files, databases, or information organized for quick access over a network or
directly. A repo allows consolidating data with a version control system to store metadata for
every file and log changes.
16. System

A system is an interrelated set of business procedures used within one business unit working
together for a common purpose or goal.

17. Systems analysis

Systems Analysis is a proven method to help business utilize information to its fullest capacity

10 | P a g e
18. Systems analyst
It is the person who responsible for the development of an information system. Systems analysts
design and modify systems by turning user requirements into a set of functional specifications,
which are the blueprint of the system.

19. Systems design

System design is the phase that bridges the gap between problem domain and the existing system
in a manageable way. This phase focuses on the solution domain, i.e. “how to implement?”

20. Systems development life cycle (SDLC)

The systems or software development life cycle is the process of creating, releasing, and
maintaining an information system, which may comprise hardware, software, or both. The
typical SDLC has six sequential phases: planning, analysis, design, implementation, testing, and
maintenance.

11 | P a g e
21. Systems development methodologies

22. System development team members

A development team is responsible for determining the specific objectives of the system and is
also ultimately responsible for delivering a system that meets these objectives. A development
team typically includes users, managers, system analysts, programmers, technical specialists and
other stakeholders.
23. Systems implementation and operation

Systems implementation reflects a set of procedures performed to complete the design contained
in the approved systems design document and to test, install, and begin to use the new or revised
information system.

System Operations means the Provider’s operation, maintenance and repair of the
System performed in accordance the requirements herein.

Part II
Sources of SW
1. Cloud computing

12 | P a g e
Cloud computing is the delivery of different services through the Internet. These resources
include tools and applications like data storage, servers, databases, networking, and software.
2. Enterprise resource planning (ERP) system

Enterprise resource planning (ERP) is a type of software system that helps organizations
automate and manage core business processes for optimal performance
3. Software Development Outsourcing

Outsourcing involves commissioning an individual or a group outside your company to handle

some or all of the workload.
4. Request for proposal (RFP)

A request for proposal (RFP) is a business document that announces a project, describes it, and
solicits bids from qualified contractors to complete it.

CHAPTER TWO (2)

Managing the IS Project
1. Critical path
The critical path refers to the longest stretch of the activities, and a measure of them from start to
finish.
2. Critical path scheduling

Critical path scheduling can provide businesses with significant financial savings as well as
eliminate wasted time -- if implemented correctly. Software programs have made it easier to
employ critical path scheduling as part of company operations.
3. IS Deliverable(s)

A Deliverable Information System (DIS) is a project management tool that helps teams track and
manage project deliverables, which are the tangible products or services that result from a
project.
4. IS Feasibility study

13 | P a g e
A feasibility study, also known as feasibility analysis, is an analysis of the viability of an idea. It
describes a preliminary study undertaken to determine and document a project’s viability.
5. Economic F/S

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.
6. Operational F/S

Assessing operational feasibility is to gain an understanding of whether the proposed system will
likely to solve the business problems, or take advantage of the opportunities or not. It is
important to understand how the new systems will fit into the current day-to-day operations of
the organization.
7. Legal F/S

Legal feasibility determines whether the proposed system conflicts with the legal requirement or
not. A project may face legal issues after completion if this factor is not considered at the first
stage.
8. Political F/S

Assessing political feasibility is to gain an understanding of how key stakeholders within the
organization view the proposed system
9. Technical F/S

Assessing technical feasibility is to evaluate whether the new system will perform adequately
and whether an organization has ability to construct a proposed system or not.
10. IS Gantt chart

A Gantt chart is a type of bar chart that is commonly used in project management to visualize the
schedule of tasks and their dependencies over time.

14 | P a g e
11. Network diagram
Network diagrams give IT professionals a bird’s eye view of an organization’s technology
infrastructure, its entire network.
12. PERT (program evaluation review technique)

The program evaluation and review technique (PERT) is a statistical tool used in project
management, which was designed to analyze and represent the tasks involved in completing a
given project.
13. Information System Project

A specific kind of project in which an Information System is planned, developed and

implemented in an organization.

14. IS Project management body of knowledge

The Project Management Body of Knowledge (PMBOK) is a document containing standard
terminology, best practices and process guidelines around project management.
15. IS Project charter

A project charter is a document that defines the objectives, scope, and stakeholders of a project,
providing a roadmap for the team to follow.
16. IS Project closedown

15 | P a g e
Project closure is the critical last phase in the project management lifecycle. During project
closure, the team reviews the deliverables, then compares and tests its quality to the intended
project outcome.
17. IS Project execution

Project execution is the stage of the project where everything your team has planned is put into
action. Your team does everything it can to get projects off on the right foot.

18. IS Project initiation

Project initiation ensures that you lay a strong foundation for a new project. It’s the first of five
project management phases, when you outline why you’re doing the project and what business
value it will deliver.

19. IS Project management

A project management information system gathers, organizes, and uses project data via one or
more software applications.
20. IS Project manager

A project manager is a professional who organizes, plans, and executes projects while working
within restraints like budgets and schedules. Project managers lead entire teams, define project
goals, communicate with stakeholders, and see a project through to its closure.
21. IS Project planning

Project planning involves defining clear, discrete activities and the work needed to complete
each activity within a single project. It often requires you to make numerous assumptions about
the availability of resources such as hardware, software, and personnel.
22. IS Project workbook

This book presents a series of practices, processes and techniques that could aid project
managers and project teams to manage projects’ information in a systematic way in order to
achieve better project outcomes
23. IS Project Slack time

16 | P a g e
It's defined as the amount of time that activities related to a project can be delayed without
having a negative impact on the project's overall completion.
24. IS Work Breakdown Structure

is a method for completing a complex, multi-step project. It's a way to divide and conquer large
projects to get things done faster and more efficiently.

25. IS project cost estimation

An IS project cost estimation helps forecast the cost of a project. The project team uses this
forecast to decide if a project makes sense to execute.
26. IS project risks

Technology risk means your projects may have to be altered or amended due to problems or
changes in the hardware and software you use.
27. IS project risk identification

Identifying risks is the process of understanding what potential events might hurt or enhance a
particular project. It is important to identify potential risks early, but you must also continue to
identify risks based on the changing project environment.

28. IS project success factors

The most important information Systems Success factors based are the following ones:

 Accuracy of output
 Reliability of output,

17 | P a g e
  Timeliness of output
 Realization of user requirements, and
 User's confidence in the systems.

29. IS project success criteria

The most commonly known information systems success criteria are scope of the project, the
time it takes to completed, and the cost that expensed on the project until completed.

CHAPTER THREE (3)

System Planning and selection
1. System analyst as problem solver

A Systems Analyst is basically a problem solver. It is a must that he study the problem in depth
and suggest alternate solutions to management. Problem solving approach usually incorporates
the following general steps:

 Identify the problem

 Analyze and understand the problem
 Identify alternative solutions and select the best solution

2. System analyst technical skills

Technical skills focus on procedures and techniques for operation analysis, systems analysis
and computer science
System analyst business skills

Discover business systems analyst jobs, including responsibilities, skills, and qualifications.
Uncover what it takes to become a business analyst and the earning potential.

System analyst interpersonal skills

Interpersonal skills deal with relationships and the interface of the analyst with people in
business. They are useful in establishing trust, resolving conflict, and communicating
information.

18 | P a g e
3. System analysis as a profession
As a professional working in IT, a systems analyst needs to have strong technical skills, such as
the ability to interpret software code and design databases. A successful analyst also has proven
competency in the following areas: Investigation and analysis: A business gathers data from a
variety of source.

4. IS problems and their manifestations

Information system problems are issues that arise when an information system is not
functioning as intended. These problems can manifest in many ways, including data loss, system
crashes, slow performance, security breaches, and more.

-Some of the common manifestations of information system problems include:

System crashes or freezes

Slow performance

Data loss or corruption

Security breaches

Inability to access data or applications

Compatibility issues with other systems

Poor user experience

5. Baseline project plan (BPP)

The Baseline Project Plan (BPP) contains all information collected and analyzed during project
initiation and planning. The plan reflects the best estimate of the project’s scope, benefits, costs,
risks, and resource requirements given the current understanding of the project. The BPP
specifies detailed project activities for the next life cycle phase, analysis, and less detail for
subsequent project phases (these depend on the results of the analysis phase).The content and
format of a BPP depends on the size, complexity, and standards of an organization.

19 | P a g e
6. Break-even analysis
Break-even analysis is a financial tool that is widely used by businesses as well as stock and
option traders. It is used to determine the minimum sales volume of a product or service at which
a business can recoup the cost of offering that product or service. In other words, it helps
businesses determine the point at which they will break even and begin to make a profit.
7. Business case: A business case is a project management document that explains how the
benefits of a project overweigh its costs and why it should be executed.

8. Intangible benefit: Intangible benefits cannot be quantified directly in economic terms, but
still have a very significant business impact. Intangible benefits can increase or decrease over
time.
9. Intangible cost: Costs that are known to exist but whose financial value cannot be
accurately
measured are referred to as intangible costs. For example, employee morale problems
caused by a new system or lowered company image is an intangible cost
10. One-time cost: A one-time cost refers to a cost associated with project initiation and
development and the start-up of the system.

11. Present value

Present value (PV) is the current value of a future sum of money or stream of cash flows given a
specified rate of return. Future cash flows are discounted at the discount rate, and the higher the
discount rate, the lower the present value of the future cash flows. Present value takes the future
value and applies a discount rate or the interest rate that could be earned if invested. It is a way
of representing the current value of future cash flows, based on the principle that money in the
present is worth more than money in the future.
12. Project scope statement: A project scope statement is a short document prepared
primarily for the customer to clearly describe what the project will deliver and outline generally
at a high level all the work required for completing the project. It is therefore a useful
communication tool.
13. Recurring cost

Recurring cost is a regularly occurring cost or estimated cost which is documented with one
record—a Recurring Cost record—that describes the income or expense and its pattern (how
20 | P a g e
often it occurs, the rate at which it increases or decreases, the time period during which the cost
applies, and so forth.

14. Tangible benefit

The intangible benefits, sometimes also called “soft benefits”, are the profits ascribable to the
improvement project that cannot be reported for formal accounting purposes.These benefits are
not included in financial calculations because they are not monetary or are difficult to quantify
and calculate.

15. Tangible cost

An outlay of cash for a specific item or activity is referred to as a tangible cost. They are
usually shown as disbursements on the books. The purchase of hardware or software,
personnel training and employee salaries are examples of tangible costs. They are readily
identified and measured.

CHAPTER 4
Determining system requirements
1. IS requirements

Information system requirements are a set of rules and guidelines that define what an information
system must accomplish and how it must be designed to meet those objectives.These
requirements are critical to the success of your projects because they help you develop processes
to quickly deliver consistent products.
2. IS requirement validations

Requirements validation is the process of checking that requirements defined for development,
define the system that the customer really wants. To check issues related to requirements, we
perform requirements validation.
3. IS requirement validation techniques

There are various techniques that can be used to validate the requirements. Theyinclude:

21 | P a g e
Checks – While checking the requirements, we proofread the requirements documents to ensure
that no elicitation notes are missed out. During these checks, we also check the traceability level
between all the requirements. For this, the creation of a traceability matrix is required.

Prototyping – This is a way of building a model or simulation of the system that is to be built by
the developers. This is a very popular technique for requirements validation among stakeholders
and users as it helps them to easily identify the problems, detect missing requirements and
understand how technology can help them. We can just reach out to the users and stakeholders
and get their feedback.

Test Design – During test designing, we follow a small procedure where the testing team build a
few testing scenarios. Tests have to be derived from the requirements specification The aim of
this process is to figure out the errors in the specification or the details that are missed out
leading to difficulties in the definition of the test scenarios.

Requirements Review – During requirement review, a group of knowledgeable people analyze

the requirements in a structured and detailed manner and identify potential problems. After that,
they gather up to discuss the issues and figure out a way to address the issues. A checklist is
prepared that the reviewers fill up to provide a formal output of the review. After that, a final
approval sign-off is done

4. IS requirements tractability matrix

This matrix ensures that all the requirements are being properly considered and everything that is
specified is justified. We also check the format of requirements during these checks. We see if
the requirements are clear and well-written or not.
5. IS requirement gathering.

Requirements gathering is an exploratory process that involves researching and documenting a

project’s requirements from start to finish.

6. IS requirement gathering techniques

Gathering requirements can be overwhelming, but it doesn’t need to be overly complicated —
particularly if you break it down into four steps.

Step 1. Preliminary analysis

22 | P a g e
Working with the key stakeholders, formulate responses to the following questions:

What is your vision or goal for the project?

What do you want from the system that hasn’t been possible previously?

Why do you/we need this new system? What is your/our current state?

What are your/our areas of improvements?

Step 2. Identify the techniques to capture requirements

Capturing requirements is not as straightforward as just asking stakeholders what they think the
system should do. In many cases, they won’t be aware of a system’s potential and may be limited
by their immersion in the current state.

Step 3. Document the requirements

There are many ways to document the requirements you’re gathering, from a simple Word
document, spreadsheet or presentation to sophisticated modelling diagrams.

Step 4. Validate the requirements

Once your requirements are documented, don’t assume that everybody is now on the same page.
Distribute and confirm final requirements with all stakeholders. If additions are made, this needs
to be confirmed by the project sponsor and the project team to reduce scope creep or increasing
costs. If anything was overlooked or misunderstood, it’s better to know now.

7. Business process reengineering (BPR)

Business process reengineering is the act of recreating a core business process with the goal of
improving product output, quality, or reducing costs.

23 | P a g e
 BPR by figure
8. IS requirement stakeholders

Users of the System:

They are the ones who will be most affected by the system and who will have the most to gain or
lose from its success or failure.

System Developers:

System developers also have a stake in the system. They have designed and built the system, and
they want it to be successful. If the system fails, they may lose their jobs or be held liable for
damages.

System maintainers:

are responsible for keeping the system running. They may be employees of the organization that
developed the system or they may be contracted to provide support services.

System administrators : Are responsible for ensuring that the system is used in accordance with
the organization’s policies. They may be employees of the organization or they may be
contracted to provide support services. If the system is used improperly, they may be held liable
for damages.

24 | P a g e
9. Major IS requirement types
In software engineering, requirements fall into three categories: business, user and software.
Solution requirements are further grouped into functional and non-functional requirements.
Functional requirements describe the behaviors of the product while non-functional requirements
describe the environmental conditions or qualities required for the product to be effective.
Specific, measurable, achievable, relevant, and time-bound requirements are needed (SMART).

10. Closed-ended questions

It consists of questions that are used when the systems analyst effectively lists all possible
responses, which are mutually exclusive.
11. Disruptive technologies

Disruptive technologies are innovations that significantly alter the way that consumers,
industries, or businesses operate. They sweep away the systems or habits they replace and create
new ones in their place. These technologies can drastically change market behavior, operations,
and social or economic norms.
12. Formal system

Formal system is the official way a system works as described in organization's documentation.It
is a Procedure documents which describe formal system.

13. Informal system

Informal system is the way a system actually works in practice .We use Interviews and
observation to reveal informal system.
14. JAD session leader

The JAD leader organizes and runs the JAD. This person has been trained in group management
and facilitation as well as in systems analysis. The JAD leader sets the agenda and sees that it is
met. He or she remains neutral on issues and does not contribute ideas or opinions, but rather
concentrates on keeping the group on the agenda, resolving conflicts and disagreements, and
soliciting all ideas.
15. Key business processes

25 | P a g e
Key business processes are operational processes that fall within the following buckets:
Developing vision and strategy, developing and managing products and services, marketing and
selling products and services, delivering services, managing customer service.

16. Open-ended questions

It consists of questions that can be easily and correctly interpreted. They can explore a problem
and lead to a specific direction of answer.

CHAPTER 5
Structuring System requirements: PM

1. Process Modeling:

Process modeling involves graphically representing the processes, or actions, that capture,
manipulate, store, and distribute data between a system and its environment and among
components within a system.

2. Data Flow Diagram(DFD)

A data flow diagram is a common form of a process modeling. It is a graphic representation that
illustrates the movement of data between external entities and the processes and data stores
within a system. It is used to increase software development productivity.

26 | P a g e
3. Context DFD
First, a context data-flow diagram shows the scope of the system, indicating which elements are
inside and outside the system. Second, data-flow diagrams of the current system specify which
people and technologies are used in which processes to move and transform data, accepting
inputs and producing outputs. The detail of these diagrams allows analysts to understand the
current system and eventually to determine how to convert the current system into its
replacement.

Third, technology-independent, or logical, data-flow diagrams show the dataflow, structure, and
functional requirements of the new system. Finally, entries for all of the objects in all diagrams
are included in the project dictionary or CASE repository.

4. Data flow
A data flow is data that are in motion and moving as a unit from one place in a system to another.
A data flow could represent data on a customer order form or a payroll check. It could also
represent the results of a query to a database, the contents of a printed report, or data on a data-
entry computer display form. A data flow can be composed of many individual pieces of data
that are generated at the same time and that flow together to common destinations.

5. Data Store
A data store is data at rest. A data store may represent one of many different physical locations
for data, including a file folder, one or more computer-based file(s), or a notebook.To understand
data movement and handling in a system, the physical configuration is not really important. A
data store might contain data about customers, students, customer orders, or supplier invoices.

6. IS Process
A process is the work or actions performed on data so that they are transformed, stored, or
distributed. When modeling the data processing of a system, it doesn‘t matter whether a process
is performed manually or by a computer.

7. Data Sources/Sink/
Finally, a source/sink is the origin and/or destination of the data. Source/sinks are sometimes
referred to as external entities because they are outside the system. Once processed, data or
information leave the system and go to some other place.

27 | P a g e
8. DFD Completeness
DFDs offer a way to check the completeness of your process model, particularly as regards your
understanding of the data that would be required by an information system (e.g., is all the data
that would be needed for input actually available? Does each processing step produce data that
could be used by subsequent steps? Is all data generated usable by an information system where
necessary?). DFDs can provide a fast way to generate further questions that need to be asked
about the process.

9. DFD Balancing
The concept of balancing states that all the incoming flows to a process and all the outgoing
flows from a process in the parent diagram should be preserved at the next level of
decomposition.

10. DFD Consistency

DFD must be consistent with other models of the system – entity relationship diagram, state-
transition diagram, data dictionary, and process specification models. Each process must have its
name, inputs and outputs. Each flow should have its name. Each Data store must have input and
output flow. Input and output flows do not have to be displayed in one DFD – but they must exist
in another DFD describing the same system.

28 | P a g e
11. Gap Analysis
The process of discovering discrepancies between two or more sets of data flow diagrams or
discrepancies within a single DFD

12. Level-0 diagram

DFD Level 0 is also called a Context Diagram. It's a basic overview of the whole system or
process being analyzed or modeled. It's designed to be an at-a-glance view, showing the system
as a single high-level process, with its relationship to external entities.

13. 1-level DFD:

In 1-level DFD, the context diagram is decomposed into multiple bubbles/processes. In this
level, we highlight the main functions of the system and breakdown the high-level process of 0-
level DFD into subprocesses.

29 | P a g e
14. 2-level DFD:
2-level DFD goes one step deeper into parts of 1-level DFD. It can be used to plan or record the
specific/necessary detail about the system’s functioning.

15. Level-n DFD

Level-n DFD shows the sub-processes of one of the processes in the Level n-1 DFD

Primitive Data Flow Diagram

The lowest level of DFDs is called a primitive DFD. It is a context diagram which shows how
the system operates. This would then get into more detail and start from level zero
Then, each process evolves into Level 1 DFD depending and after that inside each the Level 1
DFDs some of the processes may be decayed into Level 2 DFDs, and then to Level 3, it will
depend on how complex the system is.

16. DFD Drawing Rules

Following are the rules which are needed to keep in mind while drawing a DFD (Data Flow
Diagram).

Data cannot flow between two entities.

Data cannot flow between two data

30 | P a g e
Data cannot flow directly from an entity to data store

A process must have at least one input data flow and one output data flow

A data store must have atleast one input data flow and one output data flow

Two data flows can not cross each other.

All the process in the system must be linked to minimum one data store or any other process.

CHAPTER SIX (6)

DATA MODELING
What is data modeling?

Data modeling is the process of creating a visual representation of either a whole information
system or parts of it to communicate connections between data points and structures.

1.Attribute
That said, defining every detail of a problem as an entity is not a good practice. This is why we
define an additional set of details that are specific to each entity and are inherited by each
individual of the same entity type. These additional details are called attributes. They define the
real entity or concept much better

31 | P a g e
2. Entity
An entity is a representation of either a physical object from the real world or a singular concept
that is generally very well defined and delimited.

3. Entity Class
An entity class is essentially an object wrapper for a database table. The attributes of an entity
are transformed to columns on the database table.

4. Binary relationship
A Binary Relationship is the relationship between two different Entities i.e. it is a relationship of
role group of one entity with the role group of another entity.

5. Candidate key
The minimal set of attributes that can uniquely identify a tuple is known as a candidate key. For
Example, STUD_NO in STUDENT relation.

It is a minimal super key.It is a super key with no repeated data is called a candidate key.The
minimal set of attributes that can uniquely identify a record.

6. Cardinality
Relationship Cardinality refers to the number of entity instances involved in the relationship. For
example:

One CUSTOMER may be placing one or more ORDERS

many STUDENTS may be signing up for one or more CLASSES

7. Conceptual data model (ERD)

The highest-level view containing the least detail. Its value is showing overall scope of the model
and portraying the system architecture.

8. Entity instance (instance)

Whereas an entity type represents an abstract category, an entity instance is a manifestation of an
entity within that category. For example, Cell could be the entity type, but Cell_1 , Cell_2 , and
Cell_3 would represent the actual items within the network. Parent topic: Glossary.

32 | P a g e
9. Entity Identifier
A special attribute used to identify a specific instance of an entity.Typically we look
for unique identifiers:Social Security Number uniquely identifies an EMPLOYEE, CustomerID
uniquely identifies a CUSTOMER.

10. Relationship
An association between two (or more) entities. Relationships are typically given names. A
relationship can include one or more entities.

11. Ternary relationship

A ternary relationship is an association among three entities. This type of relationship is required
when binary relationships are not sufficient to accurately describe the semantics of the
association. The ternary relationship construct is a single diamond connected to three entities

12. Unary (recursive) relationship

A relationship between two entities of similar entity type is called a recursive relationship. When
there is a relationship between two entities of the same type, it is known as a recursive
relationship. This means that the relationship is between different instances of the same entity
type.

33 | P a g e
 CHAPTER SEVEN (7)

Logic Modeling
PART I
1. Logic Modeling
Logic modeling involves representing the internal structure and functionality of the processes
represented on data-flow diagrams. These processes appear on DFDs as little more than black
boxes, in that we cannot tell from only their names precisely what they do and how they do it.
Yet, the structure and functionality of a system‘s processes are a key element of any information
system. Processes must be clearly described before they can be translated into a programming
language.
2. Structured English

Structured English is a modified form of English used to specy the logic of information
processes

Uses a subset of English vocabulary to express process procedures example:

34 | P a g e
- Action verbs - read, write, print, move, merge, add, sort

- Noun phrases-name, address

- No adjectives or adverbs

-No specific standards - each analyst will have his own way

• File and variable names are CAPITALIZED Logical comparisons are spelled out and not used
symbols

Structured English is used to represent processes in a shorthand manner that is relatively easy for
users and programmers to read and understand.
3. Decision Tree: A decision tree is a graphical representation of a decision situation

• Decision situation points (nodes) are connected together by arcs and terminate in ovalsMain
components

- Decision points represented by nodes - Actions represented by ovals

- Particular choices from a decision point represented by arcs

• To read a decision tree - begin at root node on far left

• Each node is numbered and each number corresponds to a choice Choices are spelled out in a
legend

• From each node there are at least two paths leading to next step - another decision point or an
action

• All possible actions are listed on the far right in leaf nodes Each rule is represented by tracing a
series of paths

35 | P a g e
Figure: Decision tree representation for salary

4. Decision Table

A decision table is a diagram of process logic where the logic is reasonably complicated. All of
the possible choices and the conditions the choices depend on are represented in tabular form, as
illustrated in the decision table in the following figure.

36 | P a g e
PART II
Designing Databases
1. Data bases

A database is a systematic collection of data. They support electronic storage and manipulation
of data. Databases make data management easy

Database A collection of related information stored on a computer and organized in a manner

that allows access, retrieval, and use of that data..
2. Database Fields

In databases, fields are used to maintain relationships between tables. This is done by creating
matching fields in two or more tables.

37 | P a g e
3. Input forms: Is an efficient way to enter data into a table. Input forms are especially useful
when the person entering the data is not familiar with the inner workings of Microsoft Access
and needs to have a guide in order to input data accurately into the appropriate fields.
4. Output reports: A database report is the formatted result of database queries and contains
useful data for decision-making and analysis.

CHAPTER EIGHT (8)

System Implementation and operation
1. Coding -is the process through which the physical design specifications created by the design team
are turned into working computer code by the programming team.

38 | P a g e
2. Installation -is the process during which the current system is replaced by the new system. It
includes conversion of existing data, software, documentation, and work procedures to those
consistent with the new system.

3. Acceptance testing -Once the system tests have been satisfactorily completed, the system is
ready for acceptance testing, which is testing the system in the environment where it will
eventually be used. Acceptance refers to the fact that users typically sign off on the system and
―accept it once they are satisfied with it.

4. Adaptive maintenance - The process of modifying the system to meet changing user needs
or to adapt to changes in the environment.

5. Alpha testing - The first phase of testing a software product before it is released to the
public, usually conducted by the developers.

39 | P a g e
6. Beta testing - The second phase of testing a software product before it is released to the
public, usually conducted by a group of users who are not part of the development team.

7. Corrective maintenance - The process of fixing errors or defects in the system after it has
been deployed.

8. Direct installation - The process of installing software directly onto a computer or system
without using an intermediary such as a CD or USB drive.

9. System documentation - Documentation that describes the technical aspects of the system,
including its architecture, design, and functionality.

10. User documentation - Documentation that provides instructions on how to use the system,
including user manuals, help files, and tutorials.

40 | P a g e
12. Integration testing - The process of testing how different components of a system work
together to ensure that they function correctly as a whole.

13. Internal documentation - Documentation that is used by developers and other technical
staff to understand the system's design, code, and functionality.

14. Issue tracking system - A tool used to track and manage reported issues or bugs in a
software system.

15. Maintenance - The ongoing process of keeping a system running smoothly, including
correcting errors, updating software, and making modifications to meet changing needs.

16. Parallel installation - The process of installing and running a new system alongside the
existing system to ensure that it works correctly before fully replacing the old system.

17. Perfective maintenance - The process of making improvements to a system to enhance its
performance or functionality.

18. Phased installation - The process of installing a new system in stages or phases rather than
all at once.

19. Preventive maintenance - The process of proactively maintaining a system to prevent

problems from occurring in the future.

20. Single-location installation - The process of installing a system on a single computer or

location rather than across multiple locations.

21. Support - Assistance provided to users to help them use and troubleshoot issues with the
system.

22. System testing - The process of testing the entire system to ensure that it meets all
requirements and functions correctly.

23. Stress testing - The process of testing the system under extreme conditions to evaluate its
performance and stability under high loads or stress.

41 | P a g e
24. Unit testing -sometimes called module or functional testing. In unit testing, each module
(roughly a section of code that performs a single function) is tested alone in an attempt to
discover any errors that may exist in the module‘s code.

42 | P a g e