In this article, we discuss traditional and modern system development tools used in systems analysis. These include modern and traditional data collection tools such as interviews, observations, JAD sessions, prototypes, systems documentation tools, financial analysis, optimizing and programming tools.
Data Collection tools used in systems analysis
These are also known as “requirements-gathering/determining techniques”. They gather information on what systems should do from many sources and include:
- Users
- Reports
- Forms
- Procedures
Characteristics for gathering requirements include:
- Impertinence: Question everything
- Impartiality: Find the best solution of the organisation
- Relaxation of constraints
- Attention to detail
- Re-framing: View the organisation in new ways
Types of deliverables are:
- Information collected from users
- Existing documents and files
- Computer-based information
- Understanding of organisational components
- Business objectives
- Information needs
- Rules of data processing
- Key events
System development tools are divided into two:
- – Traditional
- – Modern
Systems Analysis: Traditional system development tools
Interviewing and Listening
- Most commonly used methods
- Gather facts, opinions and speculations
- Observe body language and emotionsÂ
Basic steps:
- Selecting Interviewees
- Designing Interview Questions
- Preparing for the Interview
- Conducting the Interview
- Post-Interview Follow-up
Selecting Interviewees
- Based on information needs
- Best to get different perspectives
- Managers
- Users
- Ideally, all key stakeholders
- Keep organizational politics in mind
Designing interview questions
Unstructured interview useful in early information gathering – the goal is broad, roughly defined information. Structured interviews are useful later in process – the goal is very specific information.
Preparing for the interview
- Prepare general interview plan
- List of question
- Anticipated answers and follow-ups
- Confirm areas of knowledge
- Set priorities in case of time shortage
- Prepare the interviewee
- Schedule
- Inform of reason for interview
- Inform of areas of discussion
Conducting the interview
- Appear professional and unbiased
- Record all information
- Check on organizational policy regarding tape recording
- Be sure you understand all issues and terms
- Separate facts from opinions
- Give interviewee time to ask questions
- Be sure to thank the interviewee
- End on time
Post interview follow-ups
- Prepare interview notes within 48 hours
- Prepare interview report
- Have interviewee review and confirm interview report
- Look for gaps and new questions
Questionnaires
A set of written questions, often sent to a large number of people. May be paper-based or electronic. They are more cost-effective than interviews. Select participants using samples of the population (e.g. convenient, random, purposive, stratified). Design the questions for clarity and ease of analysis. Administer the questionnaire and take steps to get a good response rate and finally draft the questionnaire follow-up report.
Observation: Directly observing users
Watch processes being performed. Users/managers often don’t accurately recall everything they do and so observation checks validity of information gathered other ways. It also serves as a good method to supplement interviews. Be aware that behaviors change when people are watched, thus it is difficult to obtain unbiased data. Strive to be unobtrusive and identify peak and lull periods.
Systems Analysis: Document and Procedures analysis
Types of information to be discovered include:
- Problem with existing system
- Opportunity to meet new need
- Organisational direction
- Names of key individuals
- Values of organisation
- Special information processing circumstances
- Reasons for current system design
- Rules for data processing
Four types of useful documents
1. Written work procedures – Describes how a job is performed and includes data and information used and created in the process of performing the job or task.
2. Business forms – Explicitly indicate data flow in or out of a system.
3. Reports – Enable the analyst to work backwards from the reports to the data that generated them.
4. Description of current information system
Systems Analysis: Modern System Development Tools
Joint Application Development/Design (JAD)
JAD is a structured group process focused on determining requirements. It involves the project team, users, and management working together. The purpose is to collect systems requirements simultaneously from key people. It’s a very useful technique and often conducted off-site.
JAD Participants
1. Facilitator/Session leader – Trained in JAD techniques and sets agenda and guides group processes.
2. Scribe(s) – Record content of JAD sessions.
3. Users and managers from business area with broad and detailed knowledge.
4. Sponsor
5. System analyst
6. IS staff
Conducting JAD sessions
The formal agenda and ground rules are laid down. A top-down structure is most successful. Facilitator activities include:
- Keep session on track
- Help with technical terms and jargon
- Record group input
- Stay neutral, but help resolve issues
- Post-session follow-up report
Post JAD follow-up
The post-session report is prepared and circulated among session attendees. The report should be completed approximately a week to two after the JAD session
Prototype
The prototype is a repetitive process. A rudimentary version of the system is built and the prototype replaces or augments the Systems Development Life Cycle (SDLC). The goal is to develop concrete specifications for the ultimate system. A prototype quickly converts requirements to a working version of the system. Once the user sees requirements converted to a system, they will ask for modifications or will generate additional requests. It is most useful when:
- User requests are not clear
- Few users are involved in the system
- Designs are complex and require concrete form
- History of communication problems between analysts and users
- Tools are readily available to build prototype
Prototyping: Drawbacks
With prototypes, there is a tendency to avoid formal documentation. They are also more difficult to adapt to a more general user audience. Sharing data with other systems is often not considered and Systems Development Life Cycle (SDLC) checks are often bypassed.
Selecting the Appropriate Requirements-Gathering Techniques
- Type of information
- Depth of information
- Breadth of information
- Integration of information
- User involvement
- Cost
- Combining techniques
Comparison of Systems Analysis and System Development Tools
Financial Systems Analysis Tools
NPV = PV(future cash inflows) – PV(future cash outflows)
PV = Cash flow amount / (1 + interest rate)n ,  where:
interest rate = required return
n = number of years in future
If NPV >= 0, Project is OK
If NPV < 0, Project is unacceptable
Break Even Analysis
How long before the project’s returns match the amount invested. The longer it takes to break even, the higher the project’s risk.
Systems Analysis: Documentation Tools
Process modelling
Graphically represent the processes that capture, manipulate, store and distribute data between a system and its environment and among system components.
Process model (replica, copy)
A formal way of representing how a business system operates. Illustrates the activities that are performed and how data moves among them.
Data Flow Diagrams (DFDs)
Graphical representation of data as it passes from one step to another. DFDs are used to consider data without bothering about the equipment used to store it. DFDs are used as a first step in describing a system.
Elements of a DFD
1. Process – An activity or function performed for a specific business reason, e.g. calculation; can be manual or computerized.
2. Data flow – A single piece of data or a logical collection of data; always starts or ends at a process.
3. Data Store – A collection of data that is stored in some way. Data flowing out is retrieved from the data store. Data flowing in updates or is added to the data store.
4. External entity – A person, organization, or system that is external to the system but interacts with it. Can either be a source of data, such as an order form from a customer or part of the system which uses/consumes the data, called a sink.
Creating DFDs
DFDs start with the use cases and requirements definition. One use case is a set of activities required to give out a particular output. Generally, the DFDs integrate the use cases. Names of use cases become processes. Inputs and outputs become data flows. “Small” data inputs and outputs are combined into a single flow. One should create DFD fragments for each use case and organize them into a level 0 diagram.
Decompose level 0 processes into level 1 diagrams as needed; decompose level 1 processes into level 2 diagrams as needed; etc. The next step is to draw one process representing the entire system (process 0). Proceed to find all inputs and outputs listed at the top of the use cases that come from or go to external entities; draw them as data flows. Finally, draw in external entities as the source or destination of the data flows.
System Flowcharts
Flowcharts are probably the most common system development tools. A flowchart is diagram which gives an overall view of a system. It shows the path taken as data pass from one organisational unit or processing machine to another within a company. It also shows the tasks that are performed on the data e.g. sorting or updating. Additionally, it shows the type of storage media used to hold data e.g. magnetic disk, magnetic tape etc. Generally, the emphasis of flowcharts is on people, activities, documents and media.
Systems Analysis: Decision Making Tools
One of the major challenges for a Systems Analyst is to effectively communicate the system requirements to a diverse audience. This entails taking facts harvested from stakeholders and presenting them in a readable form, with enough detail to facilitate testing and other downstream activities. An Analyst can describe complicated business logic by way of other system development tools called decision tables and/or decision trees.
Decision Tables
A decision table is a table representing a complete set of conditional expressions where expressions are mutually exclusive in a predefined area. A decision table lists causes and effects in a matrix. Each column represents a unique combination. The purpose is to structure logic. Cause = condition; effect = action = expected results. Decision tables are system development tools applied in Business Analysis, Programming, Testing, Hardware Design, etc.
Steps to create a decision table
- List all causes in the decision table
- Calculate the number of possible combinations
- Fill columns with all possible combinations
- Reduce test combinations
- Check covered combinations
- Add effects to the table
Decision trees
These describe a decision’s rationale or process. Using a decision tree diagram makes it much easier for everyone—analyst, presenter and audience—to see how a decision was made or should be made.
Creating a decision tree
Start by structuring the problem—consider the alternatives and consider the outcomes for each alternative. Follow some rules: outcomes flow from left-to-right or from top-to-bottom. There are three types of nodes: leaf or terminal node, chance node and decision nodes. It helps to use different shapes for each type of node, but it is not required. Start with a box at the top or left of the diagram. Enter the trigger event or decision statement. Example: Let’s look at the product line decision
The text version: “Extend or Consolidate”
| Extend – traditional | Extend – rapid development |
| Cost is $150,000 | Cost $80,000 |
| Revenue $500,000 | Revenue $100,000 |
| Profit = $350,000 | Profit = $20,000 |
| Consolidate – make enhancements | Consolidate – maintain products |
| Cost $30,000 | Cost $0 |
| Revenue $60,000 | Revenue $10,000 |
| Profit = $30,000 | Profit = $10,000 |
Summary
Other decision making and system development tools used in systems analysis include the financial tools and optimizing tools. Optimizing Tools includes tools such as linear programming, simulation and queuing. Programming Tools includes the tools such as structured programming, pseudo codes, HIPO charts and flowcharts.