Chapter 1

1. An information system  is an arrangement of people, data, process, information presentation, 
and information technology that interact to support and improve the operations in a business and 
to support the problem­solving and decision­making needs of management and users.
2. Information technology is a contemporary term that describes the combination of computer 
technology   (hardware   and   software)   with   telecommunications   technology   (data,   image,   and 
voice networks).
3. Information workers are the stakeholders in information systems. Information workers include 
those people whose jobs involve the creation, collection, processing, distribution, and use of 
information. They include:
a. System owners the sponsors and chief advocates of information system.
b. System users the people who use or are affected by the information system on a 
regular basis. Geographically, system users may be internal, mobile, remote, or external.
c. System designers technology   specialists   who   translate   system   users'   business 
requirements and constraints into technical solutions.
d. System builders technology   specialists   who   construct   the   information   system 
components based on the design specifications.
e. Systems analysts the people who facilitate the development of information systems 
and computer applications. They coordinate the efforts of the owners, users, designers, and 
builders. Frequently, they may play one of those roles as well. Systems analysts perform 
system analysis and design.
i)   Systems   analysis  is   the   study   of   a   business   problem   domain   to   recommend 
improvements and specify the business requirements for the solution.
ii) Systems design  is the specification or construction of a technical, computer­based 
solution for the business requirements identified in a systems analysis.
      f. Information technology vendors and consultants the   people   who   bring   external 
expertise,        experience, and human resource capacity to many projects.
4. The  systems   analyst facilitates  most of  the  activities   to develop or  acquire an  information 
system. A systems analyst studies the problems and needs of an organization to determine how 
people,   data,   process,   communication,   and   information   technology   can   best   accomplish 
improvements for the business.
5. A   business   analyst  is   a   systems   analyst   that   specializes   in   business   problem   analysis   and 
technology­independent requirements analysis.
6. Most systems  analysts  work for the systems  development group in the information  services 
group or department of a business. Alternatively systems analysts (under different titles) work 
for IT consulting firms, outsources, and application software vendors.
7. Players  in   the   information   systems   game   are   being   affected   by   a   number   of   business   and 
technology trends including:
a.   Total   quality   management,  a   comprehensive   approach   to   facilitating   quality 
improvements and management within a business.
b. Business process redesign, the study, analysis, and redesign of fundamental business 
processes to reduce costs and/or improve value added to the business.
c. Continuous process improvement, the continuous monitoring of business processes to 
effect small but measurable improvements to cost reduction and value added.
 d. The year 2000 compatibility problem and the Euro currency conversion directive.
e. Enterprise resources planning, the selection and implementation of a single vendor's 
fully integrated information system that spans most basic business functions required by a 
major corporation.
f.   Electronic   commerce,  a   new   way   of   doing   business   that   involves   conducting   both 
internal and external business over the Internet, intranets, and extranets.
8. The system analyst is a principal player in the information systems game. To prepare for a career 
as a systems analyst you will need to gain:
a. A current working knowledge of information technology, which you must keep current.
b. Some computer programming experience and expertise.
c. General business knowledge and, if possible, business experience.
d. Better than average problem­solving skills.
e. Better than average interpersonal communication skills.
f. Strong interpersonal relations and teamwork skills.
g. Flexibility and adaptability to change as the problem and politics of business change.
h. Good character and strong ethics, necessary because analysts gain access to sensitive and 
confidential data, facts, and opinions.
i. Systems analysis and design skills­the subject of this book!
9. Prospects for a career as a systems analyst look bright through 2006 and beyond. A shortage of 
analysts will fuel the prospects for those experienced analysts who have remained current with 
the fast­changing world of information technology.
Chapter 2

1. Data are raw facts about a business and its business transactions. Information is data that has 
been refined and organized by processing and purposeful intelligence.
2. An   information   system   (IS)  is   an   arrangement   of   people,   data,   processes,   interfaces,   and 
communications that interact to support and improve day­to­day operations in a business as well 
as support the problem­solving and decision­making needs of management and users.
a. Information systems are enabled by information technology, a contemporary­term that 
describes   the   combination   of   computer   technology   (hardware   and   software)   with 
telecommunications technology (data, image, and voice networks).
b. Front­office information systems support business functions that reach out to customers 
(or constituents).
c. Back­office information systems support internal business operations as well as interact 
with suppliers (of materials, equipment, supplies and services).
3. Information systems fulfill one or more of the following basic purposes:
a.   Transaction   processing   systems  capture   and   process   data   about   (or   of)   business 
transactions.
b. Management information systems  provide essential management reports required to 
plan, monitor, and control business operations.
c.   Decision  support systems  provide users, especially managers, with  decision­oriented 
information in response to various unstructured decision and problem­solving opportunities.
(1)   Decision   support   systems   are   built   around   data   warehouses   –   read­only, 
informational databases that are populated with detailed, summary, and exception data 
and information that can be accessed by end­users and managers with DSS tools that 
generate a virtually limitless variety of information in support of unstructured decisions.
d.   Expert  systems   capture   and  simulate  the  knowledge  and  expertise   of  subject   matter 
experts so non­experts may apply it.
e. Office automation (OA) systems support the wide range of business office activities that 
provide   for   improved   work   flow   and   communications   between   workers,   regardless   of 
whether or nor those workers are located in the same office.
(1) Personal information systems are those designed to meet the needs of a single user. 
They are designed to boost an individual's productivity.
(2) Work group information systems are those designed to meet the needs of a work 
group. They are designed to boost the  group's productivity.
4. Information systems architecture provides a unifying framework into which various people with 
different perspectives can organize and view the fundamental building blocks of information 
systems. The framework used throughout this book is based on, and adapted from, the Zachman 
“Framework for Information Systems Architecture.”
a.   The   information   system   framework  is   visually   presented   as   a   matrix.   The   rows 
correspond   to   the   perspectives   of   different   stakeholders   in   the   information   system 
development   process.   The   columns   correspond   to   a   specific   focus   or   dimension   of   the 
information system that must be analyzed, designed, and implemented. Each cell represents 
one perspective and one focus.
b. Although the cells can be studied and developed in isolation, they must be synchronized 
with   the   other   cells   (both   across   rows   and   down   columns)   to   develop   a   successful 
information system.
5. The six perspectives are provided by:
a. System owners, who pay for the system to be built and maintained. They own the system,  
set priorities for the system, and determine policies for its use.
b.   System   users,   who   actually   use   the   system   to   perform   or   support   the   work   to   be 
completed. System users define the business requirements and performance expectations for  
the system to be built.
c.   System   designers,   the   technical   specialists   who   design   the   system   to   meet   the   user's 
requirements. In many cases, system designers may also be system builders.
d. System builders, the technical specialists who construct, test, and deliver the system into 
operation.
e. Systems analysts, who facilitate the development of information systems and computer 
applications by bridging the communications gap that exists between nontechnical system 
owners and users technical system designers and builders.
f. IT vendors and consultants, who sell hardware, software and services to businesses for 
incorporation into their information systems.
6. The three focuses represented in the model are:
a. DATA the raw material used to create useful information.
b. PROCESSES the activities (including management) that carry out the mission of 
the business.
c. INTERFACES how   the   system   interfaces   with   its   users   and   other   information 
systems.
7. A fourth focus, COMMUNICATIONS, Was identified in the original Zachman framework but 
is omitted from our framework because computer networks are not typically built in conjunction 
with any single information system development project. Instead, computer networks are built in 
separate projects to support the communication requirements for many information systems. 
Regardless, the Communications focus can be viewed from the same perspective as the other 
framework focuses.
Chapter 3

1. A system development process is a set of activities, methods, best practices, deliverables, and 
automated   tools   that   stakeholders   use   to   develop   and   maintain   information   systems   and 
software.
2. The Capability Maturity Model (CMM)  is a framework to assess the maturity level of an 
organization's   information   system   development   and   management   processes   and   products.   It 
consists of five levels of measured by a set of guidelines called the key process areas.
a. Level 1 – Initial: This is sometimes called anarchy or chaos.
b. Level 2 – Repeatable:Project   management   processes   and   practices   are   established   to 
track project costs, schedules, and functionality.
c. Level 3 – Defined: A   standard   systems   development   process   (sometimes   called   a 
methodology)   is   purchased   or   developed   and   integrated   throughout   the   information 
systems/services unit of the organization.
d. Level 4 – Managed: Measurable goals for quality and productivity are established.
e. Level 5 – Optimizing: The   standardized   systems   development   process   is   continuously 
monitored and improved based on measures and data analysis established in level 4.
3. A   system   life   cycle   divides   the   life   of   an   information   system   into   two   stages,  systems  
development and systems operation and support – first you build it; then you use it.
A systems development methodology is a very formal and precise system development process 
that defines a set of activities, methods, vest practices, deliverables, and automated tools that 
system developers and project managers use to develop and maintain information systems and 
softwares.
4. The following principles should underlie all systems development methodologies:
a. Get the owners and users involved. f.   Don't   be   afraid   to   cancel   or   revise 
b. Use a problem­solving approach. scope.
c. Establish phases and activities. g. Divide and conquer.
d. Establish standards. h.   Design   systems   for   growth   and 
e. Justify systems as capital investments. change
.
5. System development projects are triggered by problems, opportunities, and directives.
a. A problem is an undesirable situation that prevents the organization from fully achieving 
its purpose, goals, and/or objectives.
b. An opportunity is a chance to improve the organization even in the absence of specific 
problems.
c. A directive is a new requirement that's imposed by management, government, or some 
external influence.
6. Wetherbe's   PIECES   framework   is   useful   for   categorizing   problems,   opportunities,   and 
directives.   The   letters   of   the   PIECES   acronym   correspond   to  Performance,   Information,  
Economics, Control, Efficiency, and Service.

7. Traditional, basic systems development phases include:
 a. Preliminary investigation. e. Design.
b. Problem analysis. f. Construction.
c. Requirements Analysis. g. Implementation.
d. Decision analysis.
8. Cross life cycle activities are activities that overlap many or all phases of the methodology. They 
may include:
a. Fact­finding
The formal process of using research, interviews, meetings, questionnaires, sampling, 
and other techniques to collect information about systems, requirements, and preferences.
b. Documentation
The  activity  of recording  facts  and  specification for a system  for current and   future 
reference.   Documentation   is   frequently   stored   in   a   repository,   a   database   where   system 
developers store all documentation, knowledge, and products for one or more information 
systems or projects.
c. Presentation
The   activity   of   communicating   findings,   recommendations,   and   documentation   for 
review by interested users and managers. Presentations may be either written or verbal.
d. Feasibility analysis
The activity by which feasibility, a measure of how beneficial the development of an 
information system would be to an organization, is measured and assessed.
e. Process management
The ongoing activity that documents, manages the use of, and improves an organization's 
chosen methodology (the “process”) for systems development.
f. Project management
The activity of defining, planning, directing, monitoring, and controlling a project to 
develop an acceptable system within the allotted time and budget.

9. There are different routes through the basic systems development phases. An appropriate route 
is selected during the preliminary investigation phase. Typical routes include:
a. Model­driven development  techniques emphasize the drawing of models to help visualize 
and   analyze   problems,   define   business   requirements,   and   design   information   systems.   Alternative 
model­driven strategies include:
(1) Structured analysis and design.
(2) Information engineering.
(3) Object­oriented analysis and design.
b. Rapid application development (RAD) techniques emphasize extensive user involvement in 
the rapid and evolutionary construction of working prototypes of a system to accelerate the system 
development process.
c. Commercial off­the­shelf (COTS)  techniques focus on the purchase and integration of a 
software   package   or   solution   to   support   one   or   more   business   functions   and   information 
systems.
d. The maintenance and re­engineering route is intended to guide projects through the 
operation and support stage of the life cycle.

10.  Automated tools support all systems development phases.
 a. Computer­aided systems engineering (CASE)  tools are software programs that automate 
or support the drawing and analysis of system models and provide for the translation of 
system models into application programs.
(1) A CASE repository is a system developer's database. It is a place where developers 
can store system models, detailed description and specifications, and other products of 
system development.
(2) Forward engineering requires the system analyst to draw system models, either from 
scratch   or   from   templates.   The   resulting   models   are   subsequently   transformed   into 
program code.
(3)   Reverse   engineering   allows   a   CASE   tool   to   read   existing   program   code   and 
transform that code into a representative system model that can be edited and refined by 
the systems analyst.
b. Application development environments (ADE's) are integrated software development tools 
that provide all the facilities necessary to develop new application software with maximum speed and 
quality.
c. Process management tools  to help us document and manage a methodology and routes,  its 
deliverables, and quality management standards.
d. Project   management tools help us plan system development activities (preferably using the 
approved methodology), estimate and assign resources (including people and costs), schedule 
activities and resources, monitoring progress against schedule and budget, control and modify 
schedule and resources, and report project progress.

 
Chapter 4

1. A project is a (temporary) sequence of unique, complex, and connected activities having one 
goal or purpose and that must be completed by a specific time, within budget, and according to 
specification.
2. Project management is the process of scoping, planning, staffing, organizing, directing, and 
controlling the development of an acceptable system at a minimum cost within a specified time 
frame.
3. Process management is an ongoing activity that documents, manages the use of, and improves 
an   organization's   chosen   methodology   (the   “process”)   for   systems   development.   Process 
management is concerned  with the activities, deliverables, and quality standards to be applied 
to all projects.
4. From   a   project   management   perspective,   a   project   is   considered   a   success   if   the   resulting 
information   system   is   acceptable   to   the   customer,   the   system   was   delivered   “on   time”   and 
“within   budget,”   and   the   system   development   process   had   a   minimal   impact   on   ongoing 
business operations.
5. The Project Management Institute has created the “Project Management Body of Knowledge” 
(PMBOK) for the education and certification of professional project managers. It addresses:
a. Project manager competencies.
b. Project management functions, which include:
i) Scoping v) Organizing
ii) Planning vi) Directing
iii) Estimating vii) Controlling
iv) Scheduling viii) Closing
c. Tools and techniques such as:
i)   PERT   charts,  graphical   network   models   that   depict   a   project's   tasks   and   the 
relationships between those tasks.
ii) Gantt charts, simple horizontal bar charts that depict project tasks against a calendar.
d. Project management software.
6. Project   management  is   a   cross   life   cycle   activity;   that   is,   project   management   tasks   that 
overlap   all   the   system   development   phases.   A   project   management   process   is   essential   to 
achieving CMM Level 2 maturity.
7. Joint project planning (JPP) is a strategy wherein all stakeholders in a project participate in a 
one­to­three­day project management workshop, the result of which is consensus agreement on 
project scope, schedule, resources, and budget.
8. The tasks of project management include:
a.   Negotiate   scope.  Scope   defines   the   boundaries   of   a   project   and   is   included   in     the 
statement of work, a narrative description of the work to be performed as part of a project.
b. Identify tasks. A work breakdown structure (Wbs) is a hierarchical decomposition of the 
project into its tasks and subtasks. Some tasks represent the completion of milestone or the 
completion of major deliverables during a project.
c.   Estimate   task   durations.  There   are   many   techniques   and   tools   for   estimating   task 
durations.
d. Specify intertask dependencies. The start or completion of individual tasks may be 
dependent   on     the   start   or   completion   of   other   tasks.   These   dependencies   impact   the 
completion of any project.
 i) Forward and reverse scheduling  are two strategies for generating the preliminary 
schedule. The former works forward from a project start date, while the latter works 
backward from a project deadline.
e.   Assign   resources.   The   following   resources   may   impact   a   project   schedule:   People, 
services, facilities and equipment, supplies and materials, and money.
i) Such resources must be assigned to tasks to develop a schedule.
ii) Resource leveling is  a strategy used to correct resource over­allocations  by  some 
combination of delaying or splitting tasks. Resource leveling requires knowledge of:
(1) The critical path – that sequence of dependent tasks that have the largest sum of 
most likely durations. The critical path determines the earliest possible completion 
date of the project.
(2) Slack time – the amount of delay that can be tolerated between the starting time 
and completion time of a task without causing a delay in the completion date of the 
entire project.
f. Direct the team effort. One of the most important dimensions of directing the team effort 
is the supervision of people.
g. Monitoring and control progress. During the project, the project manager must monitor 
project   progress   against   the  scope,   schedule,   and   budget,  and   when   necessary,   make 
adjustments scope, schedule, and resources.
i) Progress reporting is an essential control process that uses communication to keep a 
project within scope, on time, and within budget.
ii)  A complete project plan provides mechanisms and a process to manage requests for 
changes to scope. This is called change management.
iii)   Change   management  frequently   requires   a   project   manager   to   manage   the 
expectations of user management and users themselves. An expectations management 
matrix   is   a   rule­driven   tool   for   helping   management   understand   the   dynamics   and 
impact of changing project parameters such as cost, schedule, scope, and quality.
iv) Schedule adjustments  are required when a project's scope changes, or when other 
factors drive schedule or budget out of the projected range.
h. Assess project results and experiences. This final activity involves soliciting feedback 
from project team members (including customers) concerning their project experiences and 
suggestions aimed at improving the project and process management of the organization.
Chapter 5

1. Formally,   systems   analysis   is   the   dissection   of   a   system   into   its   component   pieces.   As   a 
problem­solving   phase,   it   precedes   systems   design.   With   respect   to   information   systems 
development, systems analysis is the preliminary investigation of a proposed project, the study 
and problem analysis of the existing systems, the requirements analysis of business requirements 
for the new system, and the decision analysis for alternative solutions to fulfill the requirements.
2. The results of systems analysis are stored in a repository for use in later phases and projects.
3. There are several popular or emerging strategies for systems analysis. These techniques can be 
used in combination with one another.
a. Model­driven analysis techniques  emphasize the drawing of pictorial system models 
that represent either a current reality or a target vision of the system.
1) Structured analysis is a technique that focuses on modeling processes.
2) Information engineering is a technique that focuses on modeling data.
3)   Object­oriented   analysis  is   a   technique   that   focuses   on   modeling   objects   that 
encapsulate the concerns of data and processes that act on that data.
b. Accelerated analysis  approaches emphasize the construction of working models of a 
system in an effort to accelerate systems analysis.
1) Discovery prototyping is a technique that focuses on building small­scale, functional 
subsystems to discover requirements.
2) Rapid architecture analysis  attempts to automatically generate system models from 
either   prototypes   or   existing   systems.   The   automatic   generation   of   models   requires 
reverse engineering technology.
c.   Both   model­driven   and   accelerated   system   analysis  approaches   are   dependent   on 
requirements discovery techniques to identify or extract problems and requirements from 
system owners and users.
1)   Fact­finding  is   the   formal   process   of   using   research,   interviews,   questionnaires, 
sampling, and other techniques to collect information.
2)   Joint   requirements   planning   (JRP)  techniques   use   facilitated   workshops   to   bring 
together all interested parties and accelerate fact­finding.
d.   Business   process   redesign   focuses  on   simplifying   and   streamlining   fundamental 
business processes before applying information technology to those processes.
4. Each   phase   of   system   analysis   (preliminary   investigation,   problem   analysis,   requirements 
analysis, and decision analysis) can be understood in the context of the information system 
building blocks: DATA, PROCESS, and INTERFACES.
5. The preliminary phase determines the worthiness of the project and creates a plan to complete 
those projects deemed worthy of a detailed study and analysis. To accomplish the preliminary 
investigation phase, the systems analyst will work with the systems owners and users to:
(a)   list   problems,   opportunities,   and  (d) plan the project, and 
directives;  (e)   present   the   project   to   the   business 
(b) negotiate preliminary scope;  community. 
(c) assess project worth; 
The deliverable for the preliminary investigation phase is a project charter that must be approved 
by   system   owners   and/or   a   decision­making   body,   commonly   referred   to   as   the   steering 
committee.
6. The purpose of the problem analysis phase is to answer the questions: Are the problems really 
 worth solving? And Is a new system really worth building? To answer these questions, the 
problem   analysis   phase   thoroughly   analyzes   the   alleged   problems   and   opportunities   first 
identified in the preliminary investigation phase. To complete the problem analysis phase, the 
analyst will continue to work with the system owner, system users, and other IS management 
and staff. The systems analyst and appropriate participants will: 
(a) study the problem domain;  and constraints; 
(b)   thoroughly   analyze   problems   and  (e) update the project plan; and 
opportunities,  (f)   present   the   findings   and 
(c) optionally, analyze business processes;  recommendations. 
(d) establish system improvement objectives 
The deliverables for the problem analysis phase are the system improvement objectives.
7. The   requirements   analysis   phase   identifies   what   the   new   system   is   to   do   without   the 
consideration of technology; in other words, define the business requirements for a new system. 
As in the preliminary investigation and problem analysis phases, the analyst actively works wih 
system   users   and   owners   as   well   as   other   IS   professionals.   To   complete   the   requirements 
analysis phase, the analyst and appropriate participants will: 
(a) define requirements;  (c) trace and complete the requirements 
(b) analyze functional requirements using  statements; 
system   modeling   and/or   discovery  (d) prioritize the requirements; and 
prototyping;  (e) update the project and scope. 
The   deliverable   of   the   requirements   analysis   phase   is   the   business   requirements   statement. 
Because   requirements   are   a   moving   target   with   no   finalization,   requirements   analysis   also 
includes an ongoing task to manage changes to the requirements.
8. The purpose of the decision analysis phase is to transition the project from business concerns to 
technical solutions by identifying, analyzing, and recommending a technical system solution. To 
complete the decision analysis phase, the analyst and appropriate participants will: 
(a) define candidate solutions; 
(b) analyze candidate solutions for feasibility (technical, operational, economic, and schedule 
feasibility); 
(c) compare feasible candidate solutions to select one or more recommended solutions; 
(d) update the project plan based on the recommended solution; and 
(e) present and defend the target solution. 
The deliverable of the decision analysis phase is the system proposal.
Chapter 6 

1. System  requirements  define   the   services  the  system   the  system   is   to  provide   and  prescribe 
constraints for its operation. In documenting the system requirements for a new information 
system,   an   analyst   will   likely   identify   dozens   of   unique   requirements.   To   simplify   the 
presentation   of   the   requirements   and   to   make   them   more   readable,   understandable   and 
traceable, requirements are often categorized as functional versus nonfunctional.
2. For systems analysts to be successful, they must be skilled in problem analysis. This is the 
ability to identify problems, understand the problems (including the causes and effects), and 
understand any constraints that limit the solution. A popular tool used by development teams to 
identify, analyze and solve problems is an Ishikawa diagram.
3. Effective fact finding techniques are crucial to the applications of systems analysis and design 
methods during systems projects. Fact finding is performed during all phases of the systems 
development life cycle. To support development activities, the analyst must collect facts about 
end – users, the business, data and information resources, and information systems components.
4. Conducting business in an ethical manner is a required practice, and analysts need to be more 
aware of the implications of not being ethical.
5. Fact  – finding activities usually produce requirements that conflict with each other. This is 
because requirements are solicited from many different sources and each person has his own 
opinions and the desire to the functionality and features of the new system. Systems analysts 
perform requirements analysis to discover and resolve the problems with the requirements and 
reach agreement on any modifications to satisfy the stakeholders.
6. System requirements are usually documented in a formal way to communicate the requirements 
to the key stakeholders of the system. This document usually serves as the contract between the 
system owners and the development team on what is going to be provided in terms of a new 
system.
7. Over the lifetime of the project it is very common for new requirements to emerge and existing 
requirements   to   change   once   a   requirements   definition   document   has   been   approved. 
Requirements  management encompasses  the policies, procedures, and processes that  govern 
how a change is handled.
8. There are seven fact – finding technique.
a. The sampling of existing documents and files can provide many facts and details with little 
or no direct personal communication being necessary. The analyst should collect historical 
documents, business operations manuals and forms, and information systems documents.
b. Research is an often – overlooked technique based on the study of other similar applications. 
It now has become more convenient with the Internet and World Wide Web. Site visits are a 
special form of research. 
c. Observation is a fact – finding technique in which the analyst studies people doing their 
jobs.
d. Questionnaires are used to collect similar facts from a larger number of individuals.
e. Interviews are the most popular but the most time consuming fact – finding technique. 
When interviewing, the analyst meets individually with people to gather information.
1) When most people talk about communication skills they think of speaking and writing, 
but the skills of listening may be the most important, especially during the interviewing 
process.
2) Research   has   determined   that   of   a   person’s   total   feelings,   only   7   percent   are 
 communicated verbally (in words), 38 percent are communicated by the tone of voice 
used, and 55 percent are communicated by facial and body expressions. If you only 
listen to someone’s words, you are missing most of what they have to say! Experienced 
systems analysts pay close attention to body language and proxemics.
f. Discovery   prototyping   is   frequently   applied   to   systems   development   projects,   especially 
when   the   development   team   is   having   problems   defining   system   requirements.   The 
philosophy   is   that   the   users   will   recognize   the   requirements   when   they   see   them.   It   is 
important that the prototype be developed quickly so it can be used during the development 
process.
g. Many analysts find flaws with interviewing – separate interviews often lead to conflicting 
facts, opinions and priorities. The end result is numerous follow – up interviews and / or 
group meetings. For this reason, many organizations used the group work session known as 
a joint requirements planning as a substitute for interviews.
1) Joint requirements planning sessions include a variety of participants and roles. Each 
participant is expected to attend and actively participate for the entire duration of the 
JRP session.
2) An   effective   JRP   session   involves   extensive   planning.   Planning   for   a   JRP   session 
involves three steps: selecting a location, selecting JRP participants and preparing an 
agenda.
9. Because “time is money,” it is wise and practical for the system analyst to use a fact finding 
strategy to maximize the value of time spent with the end – users.
10. Systems   analysts   should   assemble   or   document   the   information   they   have   gathered   in   an 
understandable and meaningful way. Good systems analysts used techniques and tools that allow 
them to clearly specify the system requirements.
a. Use cases describe the system functions from the perspective of external users and in a 
manner and terminology they understand.
b. Many organizations  have complex policies  and  decision – making rules  that  drive  their 
business processes. Decision tables are a popular tool in expressing and analyzing these 
requirements.
c. Many   organizations   document   their   requirements   in   tabular   form   called   a   requirements 
table.
Chapter 7

1. A model  is a representation of reality. Models can be built for existing systems as a way to 
better   understand   those   systems   or   for   proposed   systems   as   a   way   to   document   business 
requirements or technical designs.
a. Logical models document the business requirements to show what a system is or does. They 
are implementation independent; that is, they depict the system independent of any technical 
implementation. As such, logical models illustrate the essence of the system.
b. Physical   models  show   not   only  what  a   system   is   or   does,   but   also  how  the   system   is 
physically and technically implemented. They are implementation dependent because they 
reflect technology choices and the limitations of those technology choices.
2. Data   modeling  is   a   technique   for   organizing   and   documenting   a   system’s   DATA.   Data 
modeling is sometimes called database modeling because a data model is usually implemented 
as a database.
3. There are several notations for data modeling. The actual model is frequently called an entity 
relationship diagram (ERD) because it depicts data in terms of the entities and relationships 
described by the data.
4. An entity is something about which the business needs to store data. Classes of entities include: 
persons, places, objects, events or concepts.
5. An entity instance is a single occurrence of an entity class.
6. Pieces of data we want to store about each instance of a given entity are called an attribute. An 
attribute is a descriptive property or characteristic of the entity. Some attributes can be logically 
grouped into super attributes called compound attributes.
7. When analyzing a system, we should define those values for an attribute that are legitimate or 
that make business sense. The values for each attribute are defined in terms of three properties: 
data type, domain and default.
a. The data type defines what class of data can be stored in that attribute.
b. The domain of an attribute defines what values an attribute can legitimately take on.
c. The default value for an attribute is the value that will be recorded if not specified by the 
user.
8. Every entity must have an identifier or key. A key is an attribute, or a group of attributes, that 
assumes a unique value for each entity instance.
a.  Group of attributes that uniquely identifies an instance of an entity is called a concatenated 
key.
b. A candidate key is a “candidate to become the primary identifier” of instances of an entity.
c. A primary key is the candidate key that will most commonly be used to uniquely identify a 
single entity instance.
d. Any candidate key that is not selected to become the primary key is called an alternate key.
e. Sometimes, it is also necessary to identify a subset of entity instances as opposed to a single 
instance. A sub – setting criteria is an attribute (or concatenated attribute) whose finite 
values divide all entity instances into useful subsets.
9. A relationship  is natural business association that exists between one or more entities. The 
relationship may represent an event that links the entities or merely a logical affinity that exist 
between   the   entities.   All   relationships   are   implicitly   bidirectional,   meaning   they   can   be 
interpreted in both directions.
10. Cardinality  defines the minimum and maximum number of occurrences of one entity for a 
 single occurrence of the related entity. Because all relationships are bidirectional, cardinality 
must be defined in both directions for every relationship.
11. The degree of a relationship is the number of entity classes that participate in the relationship. 
Not all relationships are binary. Some relationships may be recursive relationships wherein the 
relationship   exists   between   different   instances   of   the   same   entity.   Relationships   also   exist 
between more than two different entities, as in the case of a 3 – ary or ternary relationship.
12. An associative entity is an entity that inherits its primary key from more than one other entity 
(parents). Each part of that concatenated key points to one and only one instance of each of the 
connecting entities.
13.  Foreign key is a primary key of one entity that is contributed to (duplicated in) another entity 
to identify instances of a relationship. A foreign key (always in a child entity) always matches 
the primary key (in a parent entity)
14. Non ­ identifying relationships are those in which each of the participating entities has its own 
independent primary key, of which none of the primary key attributes is shared.  The entities in 
a non – identifying relationship are referred to as strong or independent entities because neither 
depends on any other entity for its identification. Identifying relationships are those in which the 
parent entity contributes its primary key to become part of the primary key of the child entity. 
The  child entity of any identifying relationship is  referred to as    a  weak  entity because  its 
identification is dependent on the existence of the parent entity’s existence.
15. A nonspecific relationship (or many to many relationship) is one in which many instances of 
one entity are associated with many instances of another entity. Such relationships are suitable 
only for preliminary data models and should be resolved as quickly as possible. 
16. Generalization  is an approach that seeks to discover and exploit the commonalities between 
entities. It is a technique wherein the attributes are grouped to form entity super types and 
subtypes.
17. A logical data model is developed in the following stages:
a. Entities are discovered and defined.
b. A context data model is built. A context data model contains only business entities and 
relationships identifies by the system owners and users.
c. A   key   –   based   data   model   is   built.   The   key   –   based   model   eliminates   nonspecific 
relationships and adds associative entities. All entities in the model are given keys.
d. A fully attributed model is built. This model shows all the attributes to be stored in the 
system.
e. A fully described model is built. Each attribute is defined in the dictionary and described in 
terms of properties such as domain and security.
f. The completed data model is then analyzed for adapt – ability and flexibility through a 
process called normalization. The final analyzed model is referred to as third normal form 
data model.
18. A logical data model does not communicate data requirements on a business operating location 
basis. Systems analysts have found it useful to define these requirements in the form of a data – 
to – location – CRUD matrix.