1. Systems Analysis I Introduction and Fundamentals
ISYS 200
Glenn Booker
ISYS 200
Week #1

2. Systems Analysis I
This course is an introduction to the process used to create an information system
Much of it also applies to creating any other kind of software
We’ll focus on the relational model for designing the data structure of a system
In contrast, ISYS 355 uses object-oriented methods
Both are useful approaches
ISYS 200
Week #1

3. Systems Analysis I
This course provides an overview of many topics which are examined in more detail in subsequent courses
Relational modeling is covered in ISYS 210
Interface design is covered in ISYS 110 and 310
Project management is covered in ISYS 420
Systems analysis starts with the concept for a system, and produces the blueprints to be able to implement it
ISYS 200
Week #1

4. The Life Cycle
We use one or more life cycle models to help structure the tasks needed to create a system
Key activities we’ll examine include
Determine if system is feasible
Gather information to determine requirements
Model processes with a Data Flow Diagram; and model data with an Entity Relationship Diagram
Design outputs, inputs, and the user interface
Implement the system
ISYS 200
Week #1

5. Syllabus
Note the office hours; other than that, is the best way to contact me
Participation isn’t graded per se, but you are responsible for the contents of the lectures, and they will help clarify the assignments
ISYS 200
Week #1

6. About the Text
We’re skipping five chapters of the text, since 700 pages in ten weeks is a bit much
There’s still a lot of reading, but most of it goes pretty quickly
Be sure to read the text and review the lecture notes before class
You’re responsible for printing the lecture notes after this set 
ISYS 200
Week #1

7. My Background
Come from 18 years of system analysis, design and maintenance for various government agencies (mostly FAA & DOD)
Teaching for Drexel since 1998
Predominantly graduate students for the first six years
Have been known to use acronyms, so be sure to stop me if I forget to define one
ISYS 200
Week #1

8. Industry Focus
Keep in mind that information systems are used to support nearly every industry
Banking, real estate, manufacturing, pharmaceuticals, logistics, retail sales, service fields (auto repair, restaurant, dry cleaner’s, etc.), legal offices, transportation, etc.
Are there any you’re particularly interested in?
ISYS 200
Week #1

9. Why Bother? Why do we need information systems?
There’s too much data to reliably track and manage manually
Why bother with analysis and design?
To prevent joining the third of major software projects that fail
By doing analysis and design properly, we will be much more likely to create a system which
Meets user’s and the organization’s needs, and
Is developed on time and within budget
ISYS 200
Week #1

10. A Bit of Review
The first chapter should be a review of what you covered in ISYS 102 – the types of information systems
From a systems analyst perspective, we might be involved in the development, maintenance, or reengineering of any of these kinds of systems
ISYS 200
Week #1

11. Types of Systems
From most basic to most complex, we have many types of info systems
Transaction processing systems (TPS) process data for routine business functions – sales, payroll, inventory, etc.
Office automation systems (OAS) manage or organize information
Includes MS Office applications, desktop publishing, scheduling, voice or , video conferencing
ISYS 200
Week #1

12. Types of Systems
Knowledge work systems (KWS) are used by various professionals to help them create new knowledge and share it with their organization or profession
Management information systems (MIS) take input from TPS and helps analyze that data to make better decisions
Typically uses models of business processes or rules
Decision support systems (DSS) are more customized systems to help make good decisions
ISYS 200
Week #1

13. Types of Systems
Artificial intelligence (AI) refers to a set of techniques for creating complex systems, whether they perform mundane tasks or expert tasks
AI also includes natural language processing (NLP), neural networks, and other approaches
Knowledge-based systems (KBS) are AI systems that represent knowledge explicitly
Expert systems are the first KBS methodology; they go beyond DSS to create new rules or select from existing rules to make their own decisions
KBS may use statistical approaches to deal with uncertainty, or apply fuzzy set theory
ISYS 200
Week #1

14. Types of Systems
Computer-supported collaborative work (CSCW) is a relatively new field to help groups of people work together on a project, whether in the same room or on different continents
Group decision support systems (GDSS) is a subset of CSCW used to focus on group decision-making
Executive support systems (ESS) help top management levels evaluate the overall status of an organization, often drawing from many TPS or MIS
ISYS 200
Week #1

15. Technologies
All of these types of systems can be supported by various kinds of technology
E-commerce has had a profound influence on the way businesses reach clients
Nothing else has had global impact on marketing at such small cost
Web-based systems are becoming universal
From four computers in 1969, the Internet protocols have provided a common language for almost every computer, and many devices
ISYS 200
Week #1

16. Technologies
Enterprise resource planning (ERP) systems are designed to integrate what were separate systems (manufacturing, payroll, logistics, etc.)
SAP is a big local player
Oracle just bought PeopleSoft
JD Edwards is also in the field
Wireless networks are common now
Wireless LANs (WLANs), Bluetooth, or generic Wi-Fi (802.11g)
ISYS 200
Week #1

17. Technologies Handheld devices (PDAs) are increasingly common too
Blackberry, Palm, etc.
Open source software has emerged in the last decade from a geek oddity to a significant force in the market
GNU and Linux are big players
ISYS 200
Week #1

18. The Systems Analyst
The role of the systems analyst is part detective, part translator
Detective to seek out the requirements from the various stakeholders and reconcile them
What’s a stakeholder? Why might you need to reconcile requirements?
Translator to translate those requirements into a design which will fulfill them, and be intelligible to the people who implement the system (programmers, etc.)
ISYS 200
Week #1

19. The Systems Analyst
An analyst might be called on for an objective opinion on a system elsewhere in the organization
Hence keeping current with HW and SW trends and technologies is critical
Implementing or modifying information systems also changes an organization, so the analyst must also plan and support those changes
ISYS 200
Week #1

20. The SDLC
A Software Development Life Cycle (SDLC) is used to systematically get from a need to an implemented system
How do you solve a big problem? Break it into little problems and solve them
That’s what the SDLC does, by breaking development into life cycle phases
There are many types of life cycles; we’re focusing on a basic ‘waterfall’ model
ISYS 200
Week #1

21. Typical SDLC Phases
Creating any kind of software system typically involves these phases
Identify problems and opportunities
Determine information requirements
Analyze system needs
Design the system
Develop the system
Test the system
Implement the system
ISYS 200
Week #1

22. Identify problems and opportunities
Creating an information system is expensive
Therefore, we must prove that doing so is worth our while (and money)
Start by identifying
What problems are there with the current system (whether manual or automated)? Is it slow, expensive, error-prone, …what?
What new features or capabilities could we put in the new system?
ISYS 200
Week #1

23. Identify problems and opportunities
Based on the problems and opportunities, define objectives for the new system
Estimate the percent improvement in processing speed, market share, data accuracy, etc.
Put the description of problems, opportunities and objectives into a feasibility study
Then some higher manager decides if the project is worth pursuing
ISYS 200
Week #1

24. Determine information requirements
Then determine the existing information requirements, by studying the users of the existing system, and the system itself
Interviews, data sampling, questionnaires, observation, and prototyping are methods typically used for gathering requirements
People, data, and procedures
Look for ways to improve existing procedures and data
ISYS 200
Week #1

25. Analyze system needs
Based on the information needs, determine the requirements for your system
Often this phase is combined with the previous
We’ll use a Data Flow Diagram (DFD) to capture the data needs for a system
A data flow diagram shows the types of users of the system, the processes which can be performed, and the types of data needed for each process
ISYS 200
Week #1

26. Design the system
Then the system is designed to accomplish the processes described in the DFD
This includes
Design of data structure using an entity-relationship diagram (ERD)
Design of the user interface
Design of data entry procedures (won’t cover in class)
ISYS 200
Week #1

27. Develop the system
Then the analyst supports the programmers and database analysts who develop the system itself
Includes documentation of the code, which is increasingly done automatically by the development environment
Requirements and design may be refined during development
ISYS 200
Week #1

28. Test the system The system is tested before being put into production
Unit level testing is done by the programmers
Integration and system testing are often done by a separate testing organization
Independent testers or customers may also perform testing
Maintenance of the system begins here
ISYS 200
Week #1

29. Implement the system
Implementation is when the system is put into routine use (also called ‘deployed into a production environment’)
Planning for implementation includes choosing a deployment strategy, data conversion and loading (DC&L), and training users and support staff
Now determine if system met its objectives
ISYS 200
Week #1

30. Maintenance
After the development life cycle, maintenance of the system begins
Maintenance can cost 50% to 200% of the cost of developing a system
Tasks are
Fix bugs in the existing system
Make minor improvements
Update commercial components (OS patches, apply service packs, product upgrades, etc.)
ISYS 200
Week #1

31. CASE Tools
Computer-Aided Software Engineering (CASE) tools are big, fancy software applications designed to help create other software applications
First used in the mid-80’s, CASE tools help manage the complexity in large scale software development
ISYS 200
Week #1

32. CASE Tools Used properly, they can help:
Increase productivity, by automating boring and error-prone tasks (generating diagrams, documenting code)
Improve communication with users, by speeding updates to diagrams, models, and prototypes
Integrate life cycle activities, by providing a common platform for exchanging work products
Help assess maintenance changes, by identifying the impact of changes across the system
ISYS 200
Week #1

33. CASE Tools There are upper and lower CASE tools
Upper CASE tools focus on the start of the life cycle – requirements and design of the system
Some help do prototyping too
Lower CASE tools, therefore, focus on the end of the life cycle – coding and testing
Automatic generation of code, and automated testing are key features here
ISYS 200
Week #1

34. CASE Tools
Some CASE tools can reverse engineer or help reengineer code
Reverse engineering code is to input the source code, and generate the design drawings from it
Is code generation run backwards
Reverse compilation is also possible
Reengineering code often refers to rethinking how business processes work, and restruc-turing how the applications support them
ISYS 200
Week #1

35. Extreme Programming (XP)
Extreme programming, agile programming, scrum, DSDM, and other variations are used to speed traditional development methods, but keep enough structure to maintain control
XP, for example, features
Short release schedules
A 40-hour work week
Having the customer onsite
Programming by pairs of people
ISYS 200
Week #1

36. The Systems View
There are two major aspects to what we’re calling ‘the systems view’
In dealing with the information system, we need to recognize that it consists of much more than just software or a database
It will include
Hardware (the servers and networking equipment it runs on)
Training materials (for users, support staff, etc.)
ISYS 200
Week #1

37. The Systems View Documentation, such as
User manual
Installation manual
Work products from development
Feasibility study
Requirements document
Design documents
Implementation plan
Processes used by the development team
Commercial components (e.g. the operating system, database system, … )
ISYS 200
Week #1

38. The Systems View
When we create an information system, we create all these things, not just some software
The second perspective is to realize that the organization’s top management doesn’t care about any of the previous components of our system – they think of it in terms of how it helps perform business functions
ISYS 200
Week #1

39. Organizations as Systems
Organizations typically have three levels of management focus
Strategic – what lines of business are we in?
Middle management – what projects within our line of business do we pursue?
Operations – how can I manage this project well?
Hopefully, all of them are working to achieve common goals or objectives
Usually, the goal is ‘make money’
ISYS 200
Week #1

40. Organizations as Systems
The levels of management tend to need different time scales of data from information systems
Strategic – long term trends and competitive information, lots of predictions
Middle management – short and medium term performance information, some historical data
Operations – repetitive, low level data on their project; current and past performance
ISYS 200
Week #1

41. Organizations as Systems
Each organization is broken into parts (e.g. divisions or departments) to help achieve different functions to meet that goal
Each part, or functional area, might be
Purchasing
Finance
Production
Marketing
Distribution
ISYS 200
Week #1

42. Organizations as Systems
Information systems typically serve more than one functional area of an organization
Hence to determine the information needs of your system, you first need to identify what areas are affected by it
Who will generate input for your system?
Who will use outputs from your system?
ISYS 200
Week #1

43. Organizations as Systems
Identify how those areas affect each other
Does output from one area become an input for another area?
Marketing results in production and then distribution
Purchasing provides materials for production
Finance pays for purchasing and marketing
ISYS 200
Week #1

44. Organizations as Systems
Look for feedback mechanisms to help improve your system
Any process exists to take some input(s) and create some output(s)
What kind of outputs from other systems could influence your system, either as a direct input, or change the rules your system uses?
ISYS 200
Week #1

45. Organizations as Systems
Look for outside influences on your organization and system
Export laws and tariffs may affect distribution
Production may be limited by labor laws
Finance should comply with accounting practices and tax laws
Marketing might be limited by truth-in-advertising laws, intellectual property rights, and competition
ISYS 200
Week #1

46. Organizations as Systems
Look for how open your system’s organization is
Is information encouraged to flow freely?
Are there a lot of approvals and checks & balances?
Who is allowed to communicate with whom?
Trouble is, everyone tends to think their organization is the most important one
ISYS 200
Week #1

47. Virtual Organizations
Organizations don’t have to be physically located together
If not, they are a virtual organization
Could save money on facilities or travel
Social aspects are unclear
Harder to form identity with a virtual team
ISYS 200
Week #1

48. Context Diagram
The context diagram (called in the text a ‘context-level data flow diagram’) is the highest level view of the data needs for a system
At its center is a rounded box which represents your entire system
Around that box are square boxes representing
1) The types of users of your system, and
2) External systems with which your system interacts
ISYS 200
Week #1

49. Context Diagram Show only users who interact directly with your system
Lines between your system and the other boxes are labeled to identify the types of data which flow between them
If data flow goes both directions, use separate lines for each direction to distinguish inputs from outputs
Example on page 33, figure 2.5
ISYS 200
Week #1

50. Context Diagram
The context diagram is also handy for defining system requirements
Consider each type of user or external system separately, and ask:
What kind of inputs and outputs would they want from this system?
What kind of processes would they expect to be able to perform?
ISYS 200
Week #1

51. Entity-Relationship Model
The Entity-Relationship Model will be refined later to show the data structure for our system
For now, we can use the same notation to indicate early results of system analysis
Each entity represents some key concept related to your system – a user, event, thing, etc. that you want to keep information about
Transient or temporary data aren’t kept in entities
ISYS 200
Week #1

52. Entity-Relationship Model
A line between entities is labeled with verb phrases to identify what kind of relationship exists between those entities
Employee ‘is assigned to’ Office
Passenger ‘is flying to’ Destination
The ends of the line are marked to show the “cardinality” – how many of one thing could be associated with the other?
ISYS 200
Week #1

53. Cardinality and Relationships
To determine the cardinality shown, ask “for one example of entity A, how many possible entries could exist in entity B?”
Consider extreme cases; a Customer may have zero Orders briefly, before their first order is completed A B
ISYS 200
Week #1

54. Cardinality and Relationships
Relationships are described by how many records of each entity may be related: 0 (shown by a ‘0’), 1 (shown with a single or double line), or many (shown by a trident)
Here we are using the Martin notation; many others exist
Cardinality of zero implies the relationship is optional in that direction
One-to-one is a unique relationship
ISYS 200
Week #1

55. Cardinality and Relationships
Cardinality conveys the minimum and maximum number of relationships, and must be defined in both directions for all relationships:
Only one
Zero or one
One or many (more)
Zero, (one), or many
Many (only >1)
ISYS 200
Week #1

56. Associative Entity
In discussion, cardinality is often abbreviated to “one to one”, “one to many”, or “many to many”
“Many to many” relationships are bad; break them up with an associative entity
An associative entity is an entity that shares traits from two other entities, because it is associated with both of them
ISYS 200
Week #1

57. Associative Entity The example in the text (p. 37) is breaking up
Patron – Concert
With the associative entity Reservation, to become
Patron – Reservation – Concert
Another example is
Employee – Employer
Becomes Employee – Contract – Employer
ISYS 200
Week #1

58. Associative Entity
An associative entity must also have some characteristics which are unique to it (e.g. data)
The symbol for an associative entity has a diamond in it
ISYS 200
Week #1