IS622 · Information Systems 622

2026 Study Guide Revision

Information Systems 622 Study Hub

A dark, readable one-page guide covering the major development, design, implementation, support, and security ideas from the Information Systems 622 study guide.

Start CA Revision Browse General Content

Core concepts Good practice Trade-offs Risks Structures

CA References

A focused open-book reference for Chapters 1-3. Use the diagnostic index to identify the problem, then open the relevant chapter for solutions, trade-offs and limitations.

Reference pattern: Symptom -> Diagnosis -> Suitable response -> Benefit -> Limitation/risk -> Control.

At-a-Glance Diagnostic Index

Visible symptom	Likely diagnosis	Primary reference	Typical response
Package does not fit; legacy integration is difficult; internal skills are limited.	Software acquisition/development-strategy problem.	Ch. 1.3-1.6	Compare in-house, package, customisation, outsourcing and SaaS using fit, TCO, control and risk.
Costs look low initially but support, training or upgrades are unclear.	Incomplete TCO and vendor evaluation.	Ch. 1.7	Include lifetime costs, benefits, vendor viability, service levels and exit risk.
Users make errors, abandon tasks or need excessive training.	HCI, usability or input-design weakness.	Ch. 2.4-2.5	Redesign workflow, layout, feedback, help, defaults and validation around real users.
Managers receive too much data or miss urgent exceptions.	Wrong report type or poor output design.	Ch. 2.6	Select detail, summary or exception output and apply headers, grouping and control breaks.
Names, addresses or prices conflict across files.	Redundancy and update anomalies.	Ch. 3.1-3.3	Move to related tables, define keys and normalize to 3NF.
One field contains many values or one table mixes several subjects.	Repeating groups, partial or transitive dependencies.	Ch. 3.6	Apply 1NF, 2NF and 3NF in sequence; preserve relationships with foreign keys.
Orphan records, unauthorised access or untraceable changes occur.	Referential-integrity and data-control failure.	Ch. 3.7-3.9	Add PK/FK constraints, subschemas, privileges, encryption, audit trails and recovery controls.

Chapter 1 CA Reference: Development Strategies

Central question: How should an organisation obtain software that fits its requirements, constraints, risk tolerance and long-term strategy?

Source map: Study Guide PDF pages 8-36. Open fuller Chapter 1 notes Open acquisition worked example

1.1 Traditional versus Web-Based Systems Development

View Traditional vs Web-Based Systems in General Module Content ↓

Criterion	Traditional environment	Web-based environment
Platform	Often tied to internal hardware, operating systems, LAN/WAN and legacy applications.	The web is the application platform; access is commonly browser or service based.
Reach and scaling	Usually centred on employees and controlled locations.	Supports broad access, diverse devices and rapid scaling, but depends on network availability.
Control	Greater direct control over infrastructure and internal integration.	May depend on cloud, hosting or service providers and their service levels.
Security	Strong perimeter and internal access controls remain important.	Internet exposure adds authentication, encryption, privacy and availability risks.

1.2 Evolving Trends

View Evolving Trends in General Module Content ↓

Trend	Meaning and benefit	Diagnosis / suitable use	Limitation	Example
Cloud computing	On-demand shared computing resources improve scalability and reduce local infrastructure work.	Demand varies or rapid capacity is needed.	Connectivity, privacy, provider control and recurring cost.	Add server capacity during seasonal online enrolment.
Mobile/web platforms	Provide broad access across devices and locations.	Users need remote or field access.	Device diversity, responsive design and greater internet exposure.	Sales staff update orders from phones.
SaaS	Delivers hosted software as a subscription service.	Standard functionality is needed quickly.	Lock-in, customisation, availability and data-portability risk.	Hosted customer relationship management.

1.3-1.6 Development Options, Outsourcing, Offshoring and SaaS

View Development Options View Make, Buy, Customise or Empower Users ↓

Option	Choose it when...	Main benefit	Main risk or cost
Develop in-house	Requirements are unique; existing systems or technology impose constraints; internal capability is strategic.	Close business fit, control and internal knowledge.	Longer delivery, scarce skills, development risk and continuing support cost.
Buy a package	The need is common and reputable horizontal or vertical packages exist.	Faster implementation, tested product and vendor upgrades.	Process change, integration, training, licensing and imperfect fit.
Customise a package	A package meets most requirements but needs limited changes.	Better fit without building everything.	Custom work may break upgrades or vendor support and increase TCO.
User application	A small group needs a controlled solution using productivity tools.	Fast and inexpensive response to a local need.	Weak governance can threaten security, integrity, documentation and support.
Outsource	External expertise, capacity or service reliability is stronger than internal provision.	Access to specialists and flexible capacity.	Less control, provider dependence, confidentiality, ownership and continuity risks.
Offshore	Suitable work can be moved internationally with adequate governance.	Potential labour savings and access to global skills.	Culture, language, time zone, quality, legal and data-security complications.
SaaS	A standard service can be accessed online and subscription economics are suitable.	Provider handles infrastructure, maintenance and upgrades.	Recurring fees, internet/provider dependence, data portability and customisation limits.

High-value distinctions: a horizontal application serves many industries; a vertical application serves one specialised industry; a VAR adapts a commercial product; an ASP supplies application access; BPO transfers a whole business process; IBS provides managed internet-based business services.

1.7 Selecting a Development Strategy

View the Full Acquisition Worked Example ↓

TCO: include acquisition, licences, hardware, conversion, integration, customisation, training, disruption, maintenance, upgrades, support, staffing and exit costs.
Payback period: how long benefits or savings take to recover the investment.
ROI: compares net benefits with investment cost; useful for relative return but dependent on forecast quality.
NPV: adjusts future costs and benefits to present value because timing affects value.
Vendor checks: financial stability, experience, references, product maturity, support, warranties, licensing, ownership, security, recovery plans and upgrade path.
Product checks: requirements fit, usability, compatibility, performance benchmarks, scalability, integration and test results.

1.8 Software Acquisition Process

View Software Acquisition Process in General Module Content ↓

Development strategy decision map from business diagnosis through option comparison, cost and risk evaluation, evidence gathering, recommendation and management approval. — Follow the decision from business need to management approval. The system requirements document carries the evidence, alternatives and recommendation into the decision.

Requirements -> Web/network constraints -> Build/buy/service options -> RFP or RFQ -> Vendor and product evaluation -> Cost-benefit/TCO -> Recommendation -> Management decision -> Systems design

Tool/document	When to use it	Essential content
RFP	The business describes a need and asks vendors to propose a solution.	Requirements, features, service levels, support, timetable, pricing and evaluation criteria.
RFQ	The product or service is already clearly specified and comparable prices are needed.	Precise specification, quantities, terms and quotation comparison.
System requirements document	Systems analysis is complete and management must decide what happens next.	Requirements, alternatives, costs, benefits and recommendations.

1.9 Completion of Systems Analysis Tasks

View Acquisition and Analysis Completion in General Module Content ↓

Output/stage	Purpose	Benefit	Limitation/risk	Example
System requirements document	Consolidates requirements, alternatives, costs, benefits and recommendation.	Creates a traceable basis for management decision.	Weak or outdated requirements can misdirect design.	Recommends SaaS subject to integration and SLA conditions.
Management presentation	Explains evidence, trade-offs and recommendation to decision-makers.	Allows questions, clarification and ownership.	Technical detail without business meaning can obscure risk.	Present TCO scenarios and vendor-risk controls.
Transition to systems design	Moves approved logical requirements into detailed design.	Maintains continuity and traceability.	Unresolved assumptions become expensive design changes.	Approved web access and security needs become UI, database and architecture specifications.

Chapter 1 Definitions, Benefits, Limits and Examples

Term	Plain-language definition	Diagnosis / when relevant	Benefit	Limitation or risk	Example
TCO Total Cost of Ownership	The full lifetime cost of acquiring, operating, supporting and eventually replacing a system.	The purchase price looks cheap, but training, conversion, support or upgrades are unclear.	Prevents decisions based only on initial price.	Depends on forecasts; hidden and future costs can be estimated incorrectly.	A R200 000 package may cost far more after licences, migration, training and five years of support.
ROI Return on Investment	A percentage comparing net benefits with the amount invested.	Management must compare the financial return of alternative projects.	Provides a simple relative measure of value.	Can ignore timing and relies on credible benefit estimates.	A system costing R500 000 that produces R650 000 net benefit has a positive return.
NPV Net Present Value	Future benefits and costs converted into today's value, then netted against one another.	Costs and benefits occur over several years.	Recognises that money received sooner is worth more than money received later.	The result changes with the discount rate and cash-flow assumptions.	Compare a large benefit in year five with implementation costs paid today.
Payback period	The time required for accumulated benefits or savings to recover the investment.	Liquidity and speed of cost recovery are important.	Easy to understand and useful for risk screening.	Ignores benefits after payback and may ignore the time value of money.	A R300 000 system saving R100 000 annually has a simple three-year payback.
RFP Request for Proposal	A document describing a business need and asking vendors to propose how they would solve it.	The organisation knows the outcome it needs but wants vendors to design competing solutions.	Allows comparison of approach, capability, service and price.	Vague requirements produce proposals that are difficult to compare.	A college asks vendors to propose an integrated registration platform.
RFQ Request for Quotation	A request for prices and commercial terms for a clearly specified product or service.	The required item is known and price comparison is the main need.	Produces relatively comparable bids.	Not suitable when the solution itself still needs to be designed.	Request prices for 200 named SaaS user licences with defined support.
VAR Value-Added Reseller	A firm that adds services or custom features to another vendor's commercial product.	A standard package is close to the requirement but needs industry-specific adaptation.	Combines an established product with specialised implementation knowledge.	Custom changes can complicate upgrades and create dependence on the reseller.	A VAR adapts an accounting package for medical-practice billing.
ASP Application Service Provider	A provider that hosts and supplies access to an application for a fee.	The company wants application use without operating the full platform itself.	Reduces internal installation and maintenance work.	Creates provider, connectivity, security and availability dependence.	A business rents access to hosted payroll software.
BPO Business Process Outsourcing	Transferring an entire business process, not merely its software, to an outside provider.	The organisation wants an external specialist to run a complete function.	Can provide expertise, scale and predictable service.	Reduces direct control and can expose sensitive processes and data.	A provider operates payroll calculation, payment and employee queries.
IBS Internet Business Services	Managed internet-based services for transactions and business operations.	Online processing, hosting or customer-facing functions require external operational support.	Provides managed infrastructure and broad internet access.	Service quality, integration and provider continuity must be governed.	A managed host operates online ordering, billing and customer relationship services.
SaaS Software as a Service	Software hosted by a provider and accessed online through subscription or usage-based fees.	The requirement is fairly standard and the organisation wants rapid access without local deployment.	Provider handles infrastructure, maintenance and upgrades.	Recurring cost, limited customisation, lock-in and data portability concerns.	Microsoft 365 delivers office applications through a subscription.
SLA Service-Level Agreement	A contract measure defining expected service quality, availability, response and remedies.	A critical service is provided by an outsourcer, ASP or SaaS vendor.	Makes performance expectations measurable and enforceable.	A weak SLA may exclude important failures or offer inadequate remedies.	99.9% uptime, four-hour critical-response time and service credits.
Horizontal application	Software that supports a common function across many industries.	The business need is standard rather than industry-specific.	Large customer base can reduce cost and improve product maturity.	May not reflect specialised workflows.	Payroll or general accounting software.
Vertical application	Software designed for the specialised needs of one industry.	Industry rules and workflows are central to the requirement.	Provides a closer functional fit and industry terminology.	Smaller vendor market, higher cost and possible vendor dependence.	A hospital patient-management or airline-reservation system.

Diagnosis -> solution -> limitation

Compare with all Chapter 1 General Module Content ↓

Diagnosis / evidence	Suitable solution	Why it helps	Limitation or control
No package satisfies unique requirements; legacy rules cannot change.	Develop in-house or build a controlled custom layer.	Maximises business fit and integration control.	Requires skills, time, testing, documentation and long-term ownership.
Requirements are standard and time-to-value is critical.	Buy a proven horizontal/vertical package.	Reuses tested software and vendor support.	Confirm process fit, integration, training, licensing and upgrade costs.
Internal capacity is weak or workload fluctuates.	Outsource to a capable service provider.	Provides specialist skills and flexible capacity.	Use SLAs, security clauses, ownership terms, recovery provisions and an exit plan.
Users need broad online access without local infrastructure.	SaaS or managed web service.	Provider manages hosting, maintenance and upgrades.	Assess recurring fees, availability, lock-in, privacy and data portability.
Quoted purchase price appears attractive.	Perform TCO, ROI, payback and NPV analysis.	Exposes lifetime cost and benefit timing.	Forecasts are uncertain; test assumptions with scenarios and sensitivity analysis.
Management lacks enough evidence to proceed.	Complete evaluation and issue a system requirements document.	Provides requirements, alternatives, costs, benefits and recommendation.	Management may approve, revise or stop; unresolved risk must remain visible.

Critical limitation: buying, outsourcing or moving to SaaS is not automatically cheaper. Suitability depends on requirements, control, integration, provider risk and total cost over the system's life.

Chapter 1 Worked Example: Acquiring a Clinic Booking System

Case: A growing clinic uses telephone bookings and spreadsheets. It needs online booking within four months, has one IT technician, handles confidential patient information and must connect to its existing billing system.

Case fact	Diagnosis	Applied response	Benefit	Limitation and control
Four-month deadline and limited internal skills	Full in-house development has high schedule and capability risk.	Shortlist a healthcare-focused vertical package or SaaS service rather than building from zero.	Faster deployment and access to tested specialist functions.	The package may not fit every process; use fit-gap analysis and configure before considering customisation.
Patient information is confidential	Hosting and vendor access create privacy, security and accountability risks.	Put access control, encryption, audit logs, breach duties, backup and data-location requirements in the RFP and SLA.	Makes protection measurable and gives the clinic contractual remedies.	Contracts cannot prevent every incident; conduct due diligence, monitor the SLA and test recovery.
The new service must exchange billing data	A stand-alone package would create duplicate entry and inconsistent records.	Require a documented interface, common identifiers, validation and reconciliation testing.	Reduces transcription work and preserves consistency between systems.	Integration adds cost and vendor dependency; prototype the interface and define ownership.
The monthly fee looks affordable	Purchase price alone hides migration, training, support, integration and exit costs.	Compare alternatives using total cost of ownership (TCO), return on investment (ROI), payback and net present value (NPV).	Compares lifetime cost and benefit timing, not only the first invoice.	Forecasts depend on assumptions; perform sensitivity analysis for user growth and fee increases.

Reasoned recommendation: select the best-fitting vertical SaaS product only if its security, billing integration, service availability and data-export requirements pass evaluation. Run an RFP, score vendors with weighted criteria, negotiate the SLA, pilot the workflow, train users and retain an exit plan. Compare with the General Module acquisition example ↓

Chapter 2 CA Reference: User Interface Design

Central question: How can an analyst make interaction accurate, efficient, learnable, accessible and secure for the people performing the business work?

Source map: Study Guide PDF pages 37-76. Open fuller Chapter 2 notes Open forms/reports worked example

2.1-2.3 User Interfaces, HCI and Design Habits

View UI and HCI View the Seven Design Habits ↓

HCI studies how people interact with computer systems. A strong design begins with users, tasks, business rules, work environment, devices, skill levels and accessibility needs—not colour and decoration.

Understand the business -> Understand users and tasks -> Model/prototype -> Observe and measure usability -> Gather feedback -> Refine -> Document

User interface flow showing task-focused input, validation and access controls, DBMS processing, purpose-fit output and a user feedback loop. — The quality chain links interface design to validation, database integrity and useful output. Weak input produces unreliable output even when the report looks professional.

Design goal	Practical application	Why it matters
Easy to learn and use	Consistent language, predictable navigation, recognition rather than recall.	Reduces training time and user errors.
Productivity	Logical tab order, defaults, shortcuts, lookups and minimal re-entry.	Reduces task time and operational cost.
Flexibility	Support novice and expert paths, multiple devices and suitable personalisation.	Accommodates different users without losing control.
Help and feedback	Clear status, confirmation, corrective error messages and accessible help.	Lets users recover and understand system state.
Readable layout	Grouping, alignment, whitespace, contrast and consistent visual hierarchy.	Improves scanning and reduces cognitive load.

2.4-2.5 Interface Guidelines, Input and Source Documents

View Validation Rules in General Module Content ↓

Validation/control	Question it asks	Example
Sequence check	Are records or numbers in the expected order?	Detect a missing invoice number.
Existence check	Was a mandatory field entered?	Patient ID cannot be blank.
Data-type check	Is the value the correct type?	Quantity must be numeric.
Range check	Is the value between fixed limits?	Assessment mark must be 0-100.
Reasonableness check	Is the value plausible in context?	An employee cannot work 200 hours in a week.
Validity check	Is the value in the permitted list or master data?	Doctor ID must exist.
Combination check	Are related values acceptable together?	A delivery date cannot precede the order date.
Batch control	Is a group complete and correctly totalled?	Record count and financial control total agree.

Source-document zones: heading, control, instructions, body, totals and authorisation. Good forms follow the business sequence, use clear captions and collect data once at its source.

2.6 Printed Output and Report Design

View Forms, Reports and Controls View the Worked Example ↓

Position	Typical content	Purpose
Report header	Report title, organisation and date range.	Identifies the whole report once.
Page header	Column headings, date and page identity.	Keeps each page understandable.
Detail area	Records or transactions.	Provides the required operational information.
Control break	Group subtotal when a sorted control field changes.	Summarises each group, such as a store or department.
Page footer	Page number or repeated report identity.	Supports sequence and document control.
Report footer	Grand totals and final notes.	Closes and summarises the complete report.

Report selection: use a detail report for every relevant record, a summary report for grouped totals, and an exception report for items requiring attention. Printed output must have a justified audience, purpose, frequency, delivery method and security classification.

2.7-2.9 Technology, Security, Responsive Design and Prototyping

View Prototyping and Trends View Technology, Controls and Emerging Trends ↓

Output channels: screens, printed documents, internet delivery, email, messaging, wireless devices, digital audio/images/video and specialised devices. Select according to user, timing, portability, confidentiality and accessibility.
Input choices: batch input suits accumulated work; online input suits immediate interaction. Automated capture improves speed but still requires validation and controls.
Output security: restrict recipients and viewing, protect storage and disposal, classify confidential reports and retain audit evidence.
Input security: authentication, authorisation, encryption, validation, audit trails and controlled source documents.
Responsive design: adapt layout and interaction to device size without hiding essential tasks or controls.
Prototype: test requirements and usability early; distinguish a throwaway learning model from production-quality software.

Chapter 2 Definitions, Benefits, Limits and Examples

Term	Plain-language definition	Diagnosis / when relevant	Benefit	Limitation or risk	Example
UI User Interface	The screens, controls, messages, forms and outputs through which a person uses a system.	Users struggle to navigate, enter data or understand results.	Connects business tasks and system functions in a usable form.	A polished UI cannot repair incorrect business rules or poor data design.	A clinic appointment screen with patient lookup, date selection and confirmation.
HCI Human-Computer Interaction	The study and design of how people interact with computer systems while performing tasks.	Errors, slow completion, frustration or accessibility barriers suggest a person-system mismatch.	Improves effectiveness, efficiency, learnability and satisfaction.	Needs representative user research; assumptions by designers can be misleading.	Observing receptionists use a prototype to identify confusing field order.
GUI Graphical User Interface	An interface using windows, icons, menus, buttons and other visual controls.	Users need direct visual interaction instead of typed commands.	Supports recognition, visual feedback and easier learning.	Can become cluttered, inconsistent or inaccessible.	A dashboard with labelled navigation, icons and interactive forms.
Usability	The degree to which specified users achieve goals effectively, efficiently and satisfactorily.	Tasks take too long, errors are frequent or users avoid the system.	Reduces training, mistakes and support demand.	Must be measured for particular users and tasks; it is not simply appearance.	Users complete a return transaction accurately in under two minutes.
GIGO Garbage In, Garbage Out	Poor, incomplete or invalid input produces unreliable output.	A professional-looking report contains incorrect totals or decisions.	Highlights why source quality and validation matter.	Validation cannot detect every believable but incorrect value.	An incorrect quantity entered on a return form creates a wrong stock report.
FDD Functional Decomposition Diagram	A hierarchy that breaks a business function into smaller functions and tasks.	The interface may omit tasks or mix unrelated functions.	Helps map navigation and screens to complete business functionality.	Shows functional hierarchy, not timing, data movement or detailed interaction.	Sales decomposes into capture order, verify credit, dispatch and invoice.
Prototype	An early model used to test requirements, interaction or layout before full construction.	Requirements are unclear or users disagree about how work should flow.	Reveals misunderstandings early and supports user feedback.	A throwaway prototype may lack security, scalability and production-quality code.	A clickable clinic booking mock-up tested by receptionists.
Responsive web design	A design approach that adapts layout and controls to different screen sizes and devices.	Mobile users must zoom, scroll sideways or cannot reach essential actions.	Improves access across phones, tablets and desktops.	Complex tables and workflows may still need device-specific simplification.	A report filter stacks vertically on a phone but displays in one row on desktop.
Source document	The original form that captures, authorises or records transaction data at its source.	Staff enter inconsistent data from informal notes or duplicate documents.	Standardises capture and creates an original transaction record.	Poorly designed forms reproduce errors and increase work.	A numbered goods-return form with heading, control, body, totals and authorisation zones.
Validation rule	A rule that checks whether entered data satisfies an expected condition.	Missing, mistyped, out-of-range or inconsistent values reach processing.	Detects many input errors close to their source.	A valid-looking value can still be factually wrong; overrides may be needed.	A validity check requires Doctor ID to exist in the doctor master table.
Detail report	A report showing one or more lines for every relevant record.	A user needs transaction-level evidence or audit detail.	Provides completeness and traceability.	Can overwhelm managers and hide exceptions.	Every sale, item, quantity and price for the day.
Summary report	A report grouping and totalling information for higher-level review.	Managers need trends or totals rather than every transaction.	Supports quick comparison and decision-making.	Aggregation can hide unusual individual records.	Total monthly sales by branch and product category.
Exception report	A report showing only records that meet an unusual or action-required condition.	Urgent cases are buried in a long detail report.	Focuses attention and reduces information overload.	Bad thresholds can miss important cases or generate too many alerts.	Accounts overdue by more than 60 days.
Control break	A point where a sorted control field changes and triggers a subtotal or group action.	A report needs subtotals for each branch, department or category.	Creates readable grouped summaries.	Records must be sorted by the control field first.	Print a store subtotal whenever StoreNumber changes.
Audit trail	A traceable record of who performed an action, what changed and when.	Errors or unauthorised changes cannot be attributed or reconstructed.	Supports accountability, investigation and control.	Logs require secure storage, monitoring and retention rules.	Record the user, timestamp, old value and new value for a price change.

Diagnosis -> solution -> limitation

Compare with all Chapter 2 General Module Content ↓

Diagnosis / evidence	Suitable solution	Why it helps	Limitation or control
Users need training for routine tasks or repeatedly get lost.	Simplify navigation, use familiar terms, consistent layouts and visible feedback.	Reduces memory load, task time and support demand.	Test with representative novice and experienced users; designer intuition is insufficient.
Incomplete, invalid or implausible data enters the system.	Use mandatory fields, type/range/reasonableness/validity/combination checks and controlled lookups.	Stops errors close to their source.	Over-validation can block legitimate exceptions; provide authorised override and audit trails.
Staff retype data and make transcription errors.	Defaults, codes, selection controls, automated capture and integrated source documents.	Reduces volume, duplication and entry time.	Automatic values can propagate bad source data; users must verify critical fields.
Managers cannot identify urgent problems in long reports.	Use exception reports, meaningful grouping, control breaks and clear totals.	Directs attention to actionable deviations.	Bad thresholds can hide important cases or create alert fatigue.
Confidential data appears on screens or printed output.	Apply authentication, role-based access, output classification, encryption and audit logging.	Limits viewing and creates accountability.	Printed copies and exports still require secure distribution, storage, retention and disposal.
Requirements are unclear or users disagree about layout.	Prototype, observe tasks, collect feedback and refine iteratively.	Makes assumptions visible before expensive construction.	A throwaway prototype is not secure, scalable or production-ready.

Critical limitation: visual attractiveness alone does not establish usability. A design is successful only when real users complete real tasks accurately, efficiently and securely.

Chapter 2 Worked Example: Redesigning Booking Input and Reports

Case: Receptionists enter appointments on a crowded screen. Dates are typed freely, doctor codes are memorised, errors appear only after submission, and managers receive a 60-page daily printout containing every appointment.

Observed symptom	Diagnosis	Design solution	Benefit	Limitation and control
Staff skip fields and enter impossible dates.	Poor grouping and weak validation allow garbage in, garbage out (GIGO).	Group patient, booking and payment fields; mark required items; use date controls plus range and reasonableness checks.	Prevents incomplete and implausible records at the source.	Rigid rules may reject genuine exceptions; allow authorised override with a reason and audit entry.
Receptionists memorise doctor codes.	The interface increases memory load and selection errors.	Use a searchable list displaying doctor name and specialty while storing the controlled DoctorID.	Improves learnability and selects a valid database value.	Outdated lists remain harmful; synchronise them with the master doctor table.
Errors appear only after submission.	Feedback is late and does not identify the exact correction.	Validate beside the field, preserve valid entries and state the error and remedy in plain language.	Shortens recovery time and prevents repeated submission.	Too many alerts interrupt work; prioritise critical errors and test messages with users.
Managers search a 60-page report for problems.	A detail report is being used for exception-based management.	Provide a summary dashboard and exception report for unpaid, cancelled or overbooked appointments; keep detail available on demand.	Directs attention to action while preserving supporting evidence.	Incorrect thresholds can hide cases; review rules and reconcile totals to source records.

Worked result: prototype the revised form, observe receptionists completing realistic tasks, measure completion time and error rate, refine the design, then apply role-based access and protect printed/exported reports. Compare with the General Module forms and reports example ↓

Chapter 3 CA Reference: Data Design

Central question: How should data be structured, related, stored and controlled so it remains accurate, non-redundant, accessible and secure?

Source map: Study Guide PDF pages 77-122. Open fuller Chapter 3 notes Open normalization worked example

3.1-3.3 Data Concepts, DBMS Components and Web-Based Design

View Data Structures and DBMS View the Mario and Danica Comparison ↓

Issue	File-oriented system	Relational database and DBMS
Organisation	Separate files owned by applications or departments.	Related tables form an integrated data structure.
Redundancy	The same facts may be stored in multiple files.	Normalised tables aim to store facts once and link them with keys.
Integrity	Updates can leave conflicting copies.	Constraints and referential integrity protect consistency.
Access	New information needs may require new programs.	Interfaces and DML provide flexible controlled access.

DBMS components: user interface, DBA interface, interfaces to related systems, data manipulation language, schema, subschemas and the physical data repository. The schema defines the overall database; a subschema exposes an authorised view for a user or application.

3.4-3.5 Data Terms, Integrity and Entity-Relationship Diagrams

View Data Terms and Integrity View Entity-Relationship Diagrams ↓

Crow's-foot ERD for Customer, Order, Order Line, Product and Supplier, including primary and foreign keys and a cardinality legend. — Read every relationship in both directions. The associative ORDER_LINE entity resolves the many-to-many relationship between ORDER and PRODUCT and stores relationship facts such as quantity and selling price.

Concept	Operational meaning
Entity	A person, place, thing, event or concept about which data is stored.
Attribute	A characteristic describing an entity; represented as a field/column.
Primary key	The minimal field or field combination that uniquely identifies each row.
Foreign key	A field that stores the primary-key value of a related table.
Referential integrity	A foreign-key value must match an existing primary key, unless a permitted null represents no relationship.
Cardinality	The number and optionality of instances participating in a relationship.

Relationship visual: CUSTOMER 1 ---- M ORDER 1 ---- M ORDER_LINE M ---- 1 PRODUCT. ORDER_LINE resolves the many-to-many relationship between ORDER and PRODUCT and can store relationship facts such as quantity and selling price.

ERD method: extract nouns as candidate entities, identify business events, assign keys, connect relationships, label cardinality/optionality, resolve every M:N relationship with an associative entity, then validate the model against realistic transactions and business rules.

3.6 Normalization Stages

View Normalization View the Full Worked Example ↓

Stage	Question to ask	Action
UNF to 1NF	Are there repeating groups or multi-valued fields?	Make values atomic and place repeating groups in rows or a related table.
1NF to 2NF	With a composite key, does a non-key field depend on only part of it?	Move partial dependencies to a table where that determinant is the key.
2NF to 3NF	Does a non-key field depend on another non-key field?	Move transitive dependencies to their own table and retain a foreign key.

Quick example: ORDER_LINE(OrderNo, ProductNo, OrderDate, ProductDescription, SupplierNo, SupplierName, Quantity). The composite key is OrderNo + ProductNo. Move OrderDate to ORDER; move product facts to PRODUCT; move SupplierName to SUPPLIER. Keep ORDER_LINE for facts depending on the complete order-product combination.

Why normalize: reduce redundancy and prevent insertion, update and deletion anomalies. Always state the problem removed at each step.

3.7-3.9 Codes, Storage, Access and Data Control

View Codes View the Expanded Codes Reference ↓ View Data Storage and Access View Data Control

Code type	Best use	Caution
Sequence	Unique items issued in order.	Carries no descriptive meaning.
Block sequence	Reserve number ranges for categories.	Blocks may run out or be poorly sized.
Alphabetic/category	Identify a class with letters.	Abbreviations can be ambiguous.
Mnemonic	Human-readable memory aid.	Similar names can create collisions.
Significant digit	Each position represents a fact.	Becomes rigid when classifications change.
Derivation	Generate a code from existing attributes.	Can expose personal facts and may not remain unique.
Action	Tell the system which operation to perform.	Must be simple, controlled and documented.

Data warehouse: integrated enterprise data from multiple sources for analysis and decisions.
Data mart: smaller, department-focused analytical collection.
Data mining: discovers useful patterns and relationships; clickstream and market-basket analysis also raise privacy concerns.
Logical storage: the user's structured view of fields and records. Physical storage: how binary data is placed on media and managed by hardware/operating systems.
Data coding: ASCII, EBCDIC, binary and Unicode represent data; Unicode supports large multilingual character sets.
Date storage: the study guide compares sortable ISO-style YYYYMMDD dates with absolute dates, which count days from a base date to support date calculations.
Controls: subschemas, passwords, privileges, encryption, audit trails, backup and recovery protect accuracy, completeness and security.

Chapter 3 Definitions, Benefits, Limits and Examples

Term	Plain-language definition	Diagnosis / when relevant	Benefit	Limitation or risk	Example
DBMS Database Management System	Software that creates, controls and provides access to a database.	Separate files duplicate data or require custom programs for every query.	Central integrity, security, shared access and flexible queries.	Cost, complexity and need for administration.	Users and applications access related customer and order tables through the DBMS.
DBA Database Administrator	The specialist responsible for database structure, access, performance, backup and recovery.	Ownership of database control and maintenance is unclear.	Central accountability and technical governance.	Creates dependence on scarce specialist skills.	The DBA grants roles and monitors slow queries.
DML Data Manipulation Language	Commands used to query, insert, update and delete data.	Users or applications need controlled interaction with stored data.	Provides consistent operations over database records.	Incorrect or unauthorised commands can damage or expose data.	SQL SELECT retrieves orders; UPDATE changes an approved status.
ERD Entity-Relationship Diagram	A visual model of entities, attributes and their relationships.	Business rules and data relationships are unclear.	Exposes missing entities, incorrect cardinality and M:N relationships.	A diagram can still be wrong if business rules were misunderstood.	CUSTOMER 1-to-many ORDER.
PK Primary Key	The minimal attribute or combination that uniquely identifies a row.	Records cannot be identified reliably or duplicates exist.	Supports uniqueness, relationships and accurate updates.	A poor natural key may change; composite keys can complicate joins.	OrderNo uniquely identifies ORDER.
FK Foreign Key	An attribute holding the primary-key value of a related table.	Tables need a controlled connection.	Implements relationships and supports referential integrity.	Invalid or unmanaged FKs create orphan records.	ORDER.CustomerNo references CUSTOMER.CustomerNo.
UNF Unnormalised Form	Data that still contains repeating groups, lists or mixed subjects.	Fields such as Item1, Item2, Item3 or comma-separated values appear.	Identifying UNF reveals where normalization must begin.	It is unsuitable as a final relational design.	One order row contains several product columns.
1NF First Normal Form	Every field contains one atomic value and repeating groups are removed.	One cell contains many values or columns repeat.	Creates consistent rows that can be searched and related.	Redundancy can remain through partial and transitive dependencies.	Move repeating products into ORDER_LINE rows.
2NF Second Normal Form	1NF plus every non-key attribute depends on the whole composite key.	A field depends on only OrderNo or only ProductNo within ORDER_LINE.	Removes partial-dependency duplication.	Mainly matters where composite keys exist; transitive dependencies may remain.	Move ProductDescription to PRODUCT.
3NF Third Normal Form	2NF plus no non-key attribute depends on another non-key attribute.	SupplierName depends on SupplierNo rather than the table's key.	Removes transitive dependencies and update anomalies.	More tables can make queries more complex.	Move SupplierName to SUPPLIER and retain SupplierNo as FK.
Cardinality	The number and optionality of entity instances allowed in a relationship.	The model does not show whether a relationship is one, many, mandatory or optional.	Turns business rules into precise database constraints.	Wrong assumptions produce an incorrect design.	One ORDER contains one or many ORDER_LINE records.
Associative entity	An entity that resolves an M:N relationship and stores facts about that relationship.	Each instance on both sides can relate to many on the other side.	Converts M:N into two manageable 1:M relationships.	Needs correct composite/unique keys and cardinality.	ORDER_LINE links ORDER and PRODUCT and stores Quantity.
ASCII	A character-coding standard historically used widely on personal computers.	Text must be stored or exchanged using an agreed character code.	Simple and broadly compatible for basic characters.	Limited character range compared with Unicode.	The letter A is represented by a numeric code.
EBCDIC	A character-coding scheme associated mainly with IBM mainframes.	Legacy or mainframe data must be interpreted or converted.	Supports established mainframe environments.	Less universal than ASCII/Unicode and may complicate integration.	Convert an EBCDIC mainframe export before loading it into a modern system.
Unicode	A character standard supporting a very large range of world scripts and symbols.	A system must store multilingual names and content consistently.	Enables global language support and reliable exchange.	Encoding must be handled consistently across systems.	Store English, isiZulu and Arabic customer names in one database.

Diagnosis -> solution -> limitation

Compare with all Chapter 3 General Module Content ↓

Diagnosis / evidence	Suitable solution	Why it helps	Limitation or control
The same customer, product or employee fact differs between rows/files.	Separate entities and normalise related tables.	Stores each fact once and removes update anomalies.	More tables require correct joins, keys and DBMS support.
A cell contains a list; columns repeat as Item1, Item2, Item3.	Apply 1NF and create a child/transaction-line table.	Makes each value atomic and supports unlimited occurrences.	The new relationship needs a foreign key and correct cardinality.
A composite-key table contains facts about only one part of the key.	Apply 2NF and move partial dependencies.	Prevents facts such as ProductDescription repeating per order.	2NF alone does not remove non-key-to-non-key dependencies.
A non-key field determines another non-key field.	Apply 3NF and create a table for the transitive dependency.	Prevents facts such as SupplierName repeating with SupplierNo.	Excessive decomposition can complicate reporting; preserve meaningful business entities.
A many-to-many relationship appears directly in the model.	Create an associative entity with the parent keys and relationship attributes.	Represents each transaction/event and converts M:N into two 1:M relationships.	Define uniqueness and optionality carefully to prevent duplicate relationships.
Managers need analysis across several operational databases.	Use an integrated data warehouse or a focused data mart.	Supports consolidated historical and multidimensional analysis.	Data quality, refresh delay, privacy, lineage and integration cost remain concerns.
Records are orphaned or changes cannot be traced.	Enforce referential integrity and add privileges, subschemas, audit trails and recovery.	Protects consistency, accountability and availability.	Controls require administration, monitoring, testing and periodic review.

Critical limitation: normalization improves integrity but does not replace validation, access control, backup, recovery or sound business rules.

Chapter 3 Worked Example: Converting a Booking Spreadsheet

Case: One spreadsheet stores AppointmentNo, Date, PatientNo, PatientName, PatientPhone, DoctorNo, DoctorName, Procedure1, Procedure2, AmountPaid. Patient details repeat, procedure columns are limited, and some doctor numbers do not exist.

Evidence	Diagnosis	Data-design response	Benefit	Limitation and control
Procedure1 and Procedure2 repeat the same kind of fact.	The spreadsheet is unnormalised and cannot support an unlimited number of procedures.	Create APPOINTMENT_PROCEDURE with AppointmentNo and ProcedureNo as keys plus Quantity/Price.	Achieves first normal form and resolves the appointment-procedure many-to-many relationship.	Prevent duplicate lines with a composite or surrogate key plus a uniqueness rule.
PatientName and PatientPhone repeat for every appointment.	Patient facts depend on PatientNo, causing update anomalies.	Create PATIENT(PatientNo PK, Name, Phone); retain PatientNo as an FK in APPOINTMENT.	Stores the patient's current details once.	History may be needed; deliberately store approved snapshot fields or use temporal history.
DoctorName repeats and invalid doctor numbers occur.	Redundancy and missing referential integrity allow inconsistent assignments.	Create DOCTOR(DoctorNo PK, Name) and enforce APPOINTMENT.DoctorNo as an FK.	Prevents appointments referring to nonexistent doctors.	Deletion rules must protect history; deactivate doctors rather than deleting referenced rows.
Blank AmountPaid is used to imply non-payment.	Null has ambiguous meaning and weak business rules.	Store charges/payments as related transaction records and calculate balance; validate amount and status.	Supports partial payments, an audit trail and reliable outstanding-balance reporting.	Calculated totals must reconcile to source transactions and be protected by permissions.

Resulting relationships: PATIENT 1—M APPOINTMENT M—1 DOCTOR and APPOINTMENT 1—M APPOINTMENT_PROCEDURE M—1 PROCEDURE. Each table has a primary key; foreign keys implement relationships; validation, privileges, audit trails and backups protect the normalised design.

Reasoned conclusion: the redesign reaches third normal form by separating patient, doctor and procedure facts according to their determinants. It removes repeating groups and update anomalies, but the DBMS still needs input validation, security, backup and recovery. Compare with the General Module ERD and normalization example ↓

Combined Chapters 1-3 Case Reference

Integrated Case Table

Use the case facts to connect acquisition strategy, user interaction and data design. A strong integrated discussion follows the whole system rather than treating the chapters as isolated topics.

Integrated flow:

Business need → acquisition strategy → interface and input controls → database structure and integrity → useful output → risk review

System Example Bank

System example	Purpose and typical users	Chapter 1 angle	Chapter 2 angle	Chapter 3 angle	Useful case scenario
CRM Customer Relationship Management	Sales, marketing and support staff manage customers, leads, interactions and service cases.	Compare a packaged cloud CRM with custom development; assess subscription TCO, integration and vendor lock-in.	Design quick contact capture, sales pipelines, reminders and exception views for overdue cases.	Relate CUSTOMER, CONTACT, SALES_OPPORTUNITY and INTERACTION while preventing duplicate customers.	A growing retailer cannot see a complete customer history because each branch keeps separate spreadsheets.
SMS Student Management System	Students, lecturers and administrators manage applications, registration, modules, marks and fees.	Evaluate a higher-education package or SaaS platform against institutional rules, scalability and legacy integration.	Provide role-specific portals, clear registration feedback, prerequisite validation and accessible mobile forms.	Relate STUDENT, MODULE, ENROLMENT, ASSESSMENT and PAYMENT; ENROLMENT resolves the Student–Module M:N relationship.	Students are registered twice, prerequisite failures are missed and marks differ between lecturer files.
ERP Enterprise Resource Planning	Integrates finance, purchasing, inventory, production and human resources across an organisation.	Package fit and business-process change are central; consider phased implementation, customisation and high TCO.	Use consistent navigation and role-based dashboards while avoiding screens overloaded by enterprise complexity.	A shared database links departments and master data, but requires strong ownership, codes and access privileges.	Finance and warehousing report different stock values because departments use disconnected systems.
POS and inventory system Point of Sale	Cashiers record sales while managers control products, stock, prices and replenishment.	Choose between a retail package, custom solution or hosted service based on store count, offline needs and integration.	Support rapid scanning, clear totals, payment validation, error recovery and low-stock exception reports.	Relate SALE, SALE_LINE, PRODUCT, STORE and STOCK; SALE_LINE resolves the Sale–Product M:N relationship.	A chain oversells products because online and store inventory are updated in separate files.
Clinic or patient management system	Receptionists, clinicians and billing staff manage patients, appointments, treatment and payments.	A vertical healthcare package may deliver faster fit, but privacy, billing integration, SLA and data portability are critical.	Use searchable patient selection, appointment conflict checks, confidential role-based views and unpaid-account exceptions.	Relate PATIENT, DOCTOR, APPOINTMENT, PROCEDURE and PAYMENT with referential integrity and audit history.	A clinic duplicates patient details and cannot reliably identify unpaid appointments or doctor availability.
HRIS Human Resources Information System	Human resources staff and managers administer employees, leave, recruitment, performance and payroll-related data.	Assess package functionality, payroll integration, legal compliance, vendor support and confidentiality.	Provide employee self-service, manager approvals, validation and tightly restricted salary or disciplinary views.	Relate EMPLOYEE, POSITION, DEPARTMENT, LEAVE_REQUEST and PERFORMANCE_REVIEW; preserve employment history.	Leave balances conflict across spreadsheets and unauthorised staff can view confidential employee details.
E-commerce system	Customers browse products, place orders and pay; staff manage fulfilment, stock and returns.	Compare a hosted commerce platform with custom development using scalability, transaction fees, integration and control.	Design responsive product search, a short checkout, immediate validation, progress feedback and safe error messages.	Relate CUSTOMER, ORDER, ORDER_LINE, PRODUCT and PAYMENT; protect transaction integrity and customer data.	Customers abandon mobile checkout and stock reports become inaccurate when orders fail midway.
Fleet or logistics management system	Dispatchers and drivers manage vehicles, routes, deliveries, maintenance and tracking.	Evaluate specialist software, mobile/GPS integration, service availability and the cost of operational downtime.	Give dispatchers exception dashboards and drivers simple mobile task screens with timely status feedback.	Relate VEHICLE, DRIVER, ROUTE, DELIVERY and MAINTENANCE_EVENT while retaining time-stamped history.	Late deliveries cannot be diagnosed because route, driver and vehicle data are stored separately.

Choosing an example: use the system that naturally matches the case facts. CRM suits fragmented customer contact; an SMS suits registration and marks; ERP suits cross-department integration; POS suits sales and stock; a clinic system suits appointments and privacy; HRIS suits employee records; e-commerce suits online transactions; logistics suits routes and deliveries.

Cross-Chapter Case Patterns

Case fact / diagnosis	Chapter 1: strategy	Chapter 2: interface	Chapter 3: data	Integrated benefit	Limitation / control
Rapid growth has made spreadsheets slow, duplicated and unreliable.	Compare a vertical package, custom system and SaaS using fit, time, TCO, ROI and integration.	Replace free-text capture with task-based forms, validation, feedback and exception reports.	Identify entities and keys, resolve M:N relationships and normalise to 3NF.	A scalable system captures accurate data once and turns it into timely management information.	Migration can carry old errors forward; profile, cleanse, reconcile and retain an auditable migration trail.
Customers and mobile staff need access from different devices.	Assess web/SaaS options, scalability, provider reliability, recurring cost and lock-in.	Use responsive design, accessible controls, clear navigation and secure sessions.	Use one controlled database with roles/subschemas and stable identifiers across channels.	Users share current information without separate device-specific records.	Connectivity, privacy and device loss remain risks; use offline rules, encryption, authentication and remote session control.
A vendor demo looks impressive, but requirements are uncertain.	Complete requirements, issue an RFP, use weighted evaluation, references, a pilot and contract/SLA review.	Prototype real workflows and usability-test them with representative users.	Inspect the vendor data model, import/export format, integrity controls and portability.	Selection evidence covers business fit, human use and long-term ownership of data.	A polished prototype may hide integration or performance problems; test realistic volumes and end-to-end scenarios.
Management cannot identify unpaid or exceptional transactions.	Require reporting, integration and measurable service outcomes in the chosen solution.	Provide summary and exception output with useful grouping, totals and drill-down detail.	Model charges and payments as related records; enforce keys and calculate balances from transactions.	Reliable stored facts produce actionable reports and stronger decisions.	Wrong rules produce misleading output; reconcile totals, review thresholds and maintain an audit trail.
Confidential records will be hosted by an external provider.	Perform due diligence and define security, availability, backup, incident, ownership and exit terms in the SLA.	Apply least-privilege screens, masked fields, safe errors and controlled printing/export.	Use roles, privileges, encryption, referential integrity, audit logs, backup and tested recovery.	Technical and contractual controls protect data across acquisition, use and storage.	No control removes all risk; monitor access and service levels, test recovery and maintain a portable exit copy.
Users resist the new system and continue creating private files.	Include user participation, training, support and change cost in the acquisition and implementation plan.	Observe work, reduce unnecessary entry, use familiar language and iteratively test prototypes.	Provide governed views and reports that meet legitimate needs without uncontrolled copies.	Adoption improves because the system fits work and supplies trusted information.	Convenience can conflict with control; monitor workarounds, address root causes and govern exports.

At-a-glance synthesis: Chapter 1 decides how the system is obtained; Chapter 2 decides how people enter, receive and act on information; Chapter 3 decides how that information is structured and protected. The best recommendation must make all three compatible.

Answer Guide Key

Label	What to include	Quick test
Definition	The precise meaning of the concept.	What is it?
Diagnosis	The underlying problem shown by the facts or symptoms.	What is going wrong, and what evidence proves it?
Solution	The method, design choice or control that addresses the diagnosis.	What should change?
Justification	The reason the solution fits this situation and the benefit it creates.	Why is this suitable here?
Limitation	A cost, risk, dependency, trade-off or condition under which the solution may fail.	What does the solution not solve?
Control	A measure that reduces the identified risk or protects quality, security and integrity.	How is the limitation managed?
Recommendation	The preferred option, stated with the conditions and assumptions that make it appropriate.	What should be chosen, under which conditions?

Compact content chain: Define -> Diagnose -> Select solution -> Justify benefit -> State limitation -> Add control -> Recommend.

Exam Focus Areas

Confirmed exam focus areas will be added here once the assessment coverage is available.

Coming soon

Exam focus areas are coming soon

The current exam-focus content has been cleared and will be updated when the confirmed focus areas are provided.

General Module Content

Chapters 1–6 follow the full study guide, from choosing a development strategy through interface and data design, architecture, implementation, support and security. Each chapter includes explanations, comparisons and a worked example. The module-wide reference brings its concepts, tools, methods and standards together.

Chapter 1: Development Strategies

Development strategy is about choosing the most suitable way to acquire or build software while balancing requirements, cost, risk, web integration, staffing, and long-term support.

Chapter 1

1.1 Traditional vs Web-Based Systems

1.1.1 Traditional development

Traditional systems are designed to function within specific hardware and software environments. They usually depend on company-controlled infrastructure, LAN/WAN resources and existing legacy systems. Internet resources may be used as enhancements, but the core system remains tied to a defined technical environment.

1.1.2 Web-based development

Web-based systems use the web as a central platform. They are generally more scalable, less dependent on specific hardware, easier to access across different devices and well suited to outsourced operation and support. Web 2.0 adds collaboration, information sharing and social-networking capabilities.

Traditional	Web-based
Legacy integration strongly affects design.	Internet framework is central to the application.
Often depends on company networks and desktop resources.	Can operate across varied devices and environments.
Security is often inside a private network.	Security must handle internet exposure and service access.

1.2 Evolving Trends

Web 2.0, cloud computing, mobile devices, SaaS, and web-hosted software expanded the acquisition choices available to organizations. The analyst must understand how each trend changes cost, control, scalability, and maintenance.

Web 2.0

Web 2.0 platforms emphasise collaboration, information sharing, user participation and social networking rather than one-way publishing.

Cloud computing

Cloud computing allows companies to access software and data over the internet through powerful shared infrastructure, reducing the need for in-house servers and resources.

SaaS: applications are provided as services, reducing installation and maintenance work for the customer.
Mobile and web platforms: increase access needs and raise compatibility, security, and interface concerns.

1.3 In-House Software Development Options

Section 1.3 is a decision set, not one single option. The study guide compares making software, buying a package, customizing it, and creating user applications.

1.3.1 Make-or-buy decision

Compare developing a custom system with purchasing a commercial package. Consider total cost of ownership, business fit, implementation time, available skills, integration and long-term support. A horizontal application serves many industries; a vertical application targets a specialised industry. A value-added reseller (VAR) customizes commercial software for a particular customer or market.

1.3.2 Developing software in-house

In-house development may be appropriate when a company wants to:

Satisfy unique business requirements that commercial software cannot meet.
Minimize changes to existing business procedures and policies.
Meet constraints imposed by existing systems and integration requirements.
Meet constraints imposed by existing hardware, software or legacy technology.
Develop internal IT resources and capabilities for long-term support.

1.3.3 Purchasing a software package

Buying a commercial package can provide the following benefits:

Lower initial development costs because the package is sold to multiple customers.
Less time to implement because the software has already been designed, programmed, tested and documented.
Proven reliability and performance benchmarks when the product has an established user base.
Less need for technical development staff.
Future upgrades and enhancements provided by the vendor.
Useful input from other companies that already use the package.

Balance these benefits against process disruption, retraining, integration and total-cost effects.

1.3.4 Customizing a software package

Purchase a basic package with vendor customization: select optional modules or add-ons that the vendor provides.
Negotiate directly with the vendor for enhancements: pay the vendor to change or extend the package.
Purchase the package and modify it internally: make permitted changes using internal analysts and programmers.

Additional considerations: vendor customization can increase cost and delivery time, while internal changes can make future upgrades and support more difficult.

1.3.5 Creating user applications

Users may create smaller solutions with productivity software such as spreadsheets or word processors. This can reduce the IT backlog and empower users, but it still requires training, support, security, data-integrity controls and clear limits on access to corporate data.

The systems analyst's role changes by option: deeper design and testing involvement for in-house work, more vendor evaluation and contract/support focus for packages and outsourcing.

Expanded comparison: 1.3.1-1.3.5

The guide treats software acquisition as a practical decision, not a slogan. A company can develop software in-house, purchase a package, customize a package, create user applications from tools such as Microsoft Office, outsource, offshore, use SaaS, or combine several of these. The analyst must explain what the organization gains and what it gives up.

Option	Best fit	Main caution
Develop in-house	Unique requirements, minimal change to business procedures, special legacy or technology constraints, or a desire to build internal IT capability.	Usually needs more analyst, programmer, testing, documentation, and long-term support effort.
Purchase a package	Common horizontal needs such as payroll, accounting, or inventory where vendors already provide tested software.	Lower purchase cost can be offset by retraining, process disruption, integration, and support costs.
Customize a package	The standard package is close, but not close enough for the business process.	Vendor upgrades may not support custom changes, and internal modifications can remove the time and cost advantages of buying.
Create user applications	Small user or departmental needs that can be solved with productivity software and careful controls.	Corporate data still needs security, integrity, training, and support.

Exam trap: horizontal application means a package can serve many industries; vertical application means it targets one industry with specialized requirements.

1.4 Outsourcing

1.4.1 The growth of outsourcing

Outsourcing transfers development, operation or maintenance to an external service provider for a fee. It can range from a small programming task to a complete IT function or business process. Organisations use it to control costs, obtain specialist skills and avoid directing internal IT effort toward routine maintenance.

Application Service Providers (ASPs): rent access to an operational software application, commonly through a subscription or usage fee.
Internet Business Services (IBS): provide hosted web-based support for transactions such as order processing, billing and customer relationship management.

1.4.2 Outsourcing fees

Fee model	Meaning
Fixed fee	A set fee for a defined service level.
Subscription	Cost varies with the number of users or workstations.
Usage or transaction	Cost rises with transaction or operation volume.

1.4.3 Outsourcing issues and concerns

Evaluate control, information ownership, confidentiality, licensing, liability, support quality, provider stability, disaster recovery and the long-term effect on internal capability. The quality of the result depends heavily on the provider's capability and financial stability.

1.5 Offshoring and 1.6 Software as a Service

Related 1.4 context: outsourcing transfers development, operation, or maintenance work to an external service provider for a fee. It can range from a small programming task to a full IT function, business process outsourcing, application service provider support, or managed hosting through internet business services.

1.5 Offshoring: global outsourcing moves IT development, support or operations to another country. Cost savings must be weighed against:

Project control across remote teams.
Security and differences in data-protection requirements.
Cultural and language differences.
Effective communication across distance and time zones.

1.6 Software as a Service (SaaS): hosted software is delivered over the internet through subscription or usage-based access. The provider handles much of the infrastructure, operation, maintenance and updating, while the customer evaluates service levels, security, vendor dependence and long-term cost.

Fee model	How it works	Revision clue
Fixed fee	One agreed fee for a defined service level.	Best when service needs are predictable.
Subscription	Cost varies by users or workstations.	Count users carefully before comparing options.
Usage or transaction	Cost rises with volume of transactions or operations.	Volume forecasts become part of the TCO calculation.

1.7 Selecting a Development Strategy

The systems analyst helps management compare outsourcing, in-house development, packaged software, user applications or a combination. In-house development requires deeper involvement in design, testing and implementation; outsourcing and commercial packages shift more of that work to the vendor. Include users and relevant IT staff in the evaluation team, compare total cost of ownership, and rule out alternatives that do not meet requirements.

1.7.1 The systems analyst's role

Analyse requirements, costs, benefits, risks and future needs, then present a recommendation that management can approve.

1.7.2 Cost-benefit analysis

TCO is the key selection factor because it includes initial development or purchase cost plus long-term maintenance, support, upgrades, training and operating costs. Use payback analysis, return on investment (ROI) and net present value (NPV) to compare alternatives.

1.7.3 Cost-benefit checklist

List alternatives, identify when costs and benefits occur, allow for growth, include support and licensing costs, apply the financial tools, and report the results.

1.8 The Software Acquisition Process

The five-step acquisition process turns requirements into a justified acquisition decision:

Evaluate requirements: identify features, network and web issues, future volume and hardware, software and personnel constraints; prepare an RFP or RFQ.
Identify vendors or outsourcing options: investigate vendors, consultants, industry sources, forums and current users.
Evaluate alternatives: compare proposals, demonstrations, tests, references, benchmarks and weighted evaluation models.
- Existing users: ask current customers about reliability, performance, support and implementation experience.
- Application testing: test important features and workflows against the organisation's requirements.
- Benchmarking: measure performance under realistic transaction volumes and workloads.
Perform cost-benefit analysis: include licensing, support, maintenance, training, staffing, customization, transaction fees and TCO.
Prepare a recommendation: present costs, benefits, risks, limitations and the best-fit option to management before implementation planning begins.

RFP versus RFQ: an RFP asks vendors how they will meet a business requirement; an RFQ is used when the product or service is known and comparable pricing is required.

1.9 Completion of Systems Analysis Tasks

1.9.1 System requirements document: the output of systems analysis, containing detailed specifications, requirements, alternatives, recommendations and cost and time estimates.
1.9.2 Presentation to management: communicates the findings, financial case, risks and recommended direction so management can decide whether to proceed, modify the current system, purchase or customize software, or stop the project.
1.9.3 Transition to systems design: hands the approved requirements and decisions to the design phase and provides the basis for implementation planning.

Worked Example: Choosing Software for an Order System (supports 1.7-1.9)

Scenario: a company wants a new order processing system. A website is expected to increase orders by almost 80%, but the company also has legacy accounting software and limited internal programmers.

Evaluate requirements: list required features, web access, network/intranet needs, data exchanged with customers or vendors, expected growth, and hardware/software/personnel constraints.
Prepare an RFP or RFQ: use an RFP if vendors must propose how they will satisfy the requirement; use an RFQ if the exact product/service is already known and pricing is needed.
Identify vendors or outsourcing options: use vendor sites, industry trade sources, consultants, forums, and references from existing users.
Evaluate alternatives: compare package features against the RFP, ask existing users, run application tests, and use benchmarks for volume-sensitive performance.
Perform cost-benefit analysis: include licenses, support, maintenance, training, volume-based fees, staffing, customization, and what-if scenarios.
Recommend: present costs, benefits, advantages, disadvantages, and the option that best fits strategy and risk.

Strong exam answer: mention the analyst's role, the selection team, user ownership, TCO, and management approval. That shows you understand the whole decision path.

Chapter 1 Key Points

Traditional versus web-based systems: traditional systems are tied more closely to defined hardware, software and legacy environments, while web-based systems are more scalable and suited to distributed or outsourced operation.
Cloud computing and SaaS: both provide internet-based access; cloud computing focuses on shared infrastructure, while SaaS provides hosted application functionality.
Development choices: in-house development offers business fit and control, while commercial packages can be cheaper, faster and supported by vendor upgrades.
Outsourcing and offshoring: these can reduce cost or provide expertise, but introduce control, security, communication, cultural and provider-dependence risks.
Systems analyst's role: involvement is deeper for in-house development and shifts toward evaluation, contracts and support when vendors provide the solution.
TCO and financial analysis: compare long-term costs, not only the initial price, using TCO, payback, ROI and NPV.
Acquisition process: evaluate requirements, identify vendors, evaluate alternatives, perform cost-benefit analysis and prepare a recommendation.
Requirements document: records the analysed requirements, alternatives, recommendations, costs and time estimates that support management approval and transition to design.

Chapter 1 Glossary: Development Strategy Terms

build or buy: The decision to develop software internally or acquire it from a vendor or service provider.
TCO: Total cost of ownership; includes purchase, maintenance, support, upgrades, retraining, disruption, staffing, and long-term operating costs.
horizontal application: Software usable across many industries, such as accounting or payroll.
vertical application: Software designed for one industry, such as banking, hospitals, airlines, or colleges.
VAR: Value-added reseller; a firm that enhances and customizes commercial software for a specific market.
outsourcing: Transferring development, operation, support, or maintenance work to an external provider.
ASP: Application service provider; rents access to an operational software application for a fee.
IBS: Internet business services; managed hosting and web-based support for transactions such as billing, CRM, and order processing.
BPO: Business process outsourcing; outsourcing an entire business process, not only a software task.
offshoring: Moving IT development, support, or operations to another country.
SaaS: Software as a Service; hosted software delivered over the internet through subscription or usage-based access.
RFP: Request for Proposal; describes business needs, required features, service levels, support expectations, and pricing terms.
RFQ: Request for Quotation; used when the product or service is known and comparable price quotations are required.
payback analysis: Financial tool that estimates how long a system takes to pay for itself through benefits or savings.
ROI: Return on investment; compares net benefits to total project costs as a percentage.
NPV: Net present value; benefits minus costs adjusted for when they occur.
system requirements document: The analysis-phase document that summarizes requirements, alternatives, and recommendations for management approval.

Back to General Module Content

Chapter 2: User Interface Design

UI design covers how users interact with systems through screens, menus, functions, outputs, forms, controls, feedback, and error prevention.

Chapter 2

2.1 User Interfaces and 2.2 Human-Computer Interaction

A user interface is the hardware, software, screens, menus, functions, outputs, and features that support communication between user and computer. HCI focuses on making that interaction productive, learnable, and user-friendly.

Modern UI design starts from user needs and business goals, not from printed outputs alone. The best interfaces often feel invisible because users can complete tasks naturally.

2.3 Guidelines for User Interface Design

The seven design habits in 2.3.1-2.3.7 are to:

Understand the business; maximize graphical effectiveness; think like a user; use models and prototypes; focus on usability; invite feedback; and document everything.

2.4 Detailed Guidelines for User Interface Design

Use the 2.4.1-2.4.10 checklist below to translate the broad habits into concrete interface decisions.

Expanded detail: 2.4.8 Use Validation Rules

Validation rules reduce incorrect or inconsistent data before it enters the system. The study guide highlights checks such as sequence, existence, range, reasonableness, and validity checks.

Check	Purpose
Sequence	Ensures values are entered in the required order.
Existence	Prevents mandatory fields from being left blank.
Range	Rejects values outside allowed limits.
Reasonableness	Flags values that are possible but suspicious.
Validity	Checks values against accepted codes or records.

2.5 Source Document and Form Design

Use six zones to make a source document clear and controllable: heading, control, instruction, body, totals and authorization.

2.6 Printed Output

2.6.1 Report design

Choose the report's purpose, audience, content, timing, distribution and control requirements before deciding its layout.

2.6.2 Report design principles

Use report headers and footers, page headers and footers, repeating fields where useful, and a consistent design.

2.6.3 Types of reports

Detail reports list transactions; exception reports show items needing attention; summary reports group or total information.

2.7 Technology Issues

2.7.1 Output technology

Output channels include internet-based delivery, email, blogs, instant messaging, wireless devices, digital audio/images/video, automated fax, podcasts, computer output to digital media (CODM), and specialised output forms.

2.7.2 Input technology

Compare batch input with online input. Online input is used in point-of-sale (POS) terminals, ATMs, factory workstations, hospitals, retail stores and libraries. Select between them based on timeliness, volume, error handling, cost and operational needs.

2.8 Security and Control Issues

2.8.1 Output security and control

Protect reports and other output through key control methods, secure distribution and storage, safe disposal, access restrictions and IT department oversight. Diskless workstations can reduce the risk of local data being retained on user devices.

2.8.2 Input security and control

Use audit trails, controlled handling of source documents, data security policies, audit-trail files and reports, protection from unauthorised access, and encryption of sensitive data.

2.9 Emerging Trends

2.9.1 Modular design

Modularity supports flexibility, team collaboration and easier maintenance.

2.9.2 Responsive web design

Responsive layouts combine CSS3, flexible images and fluid grids so content adapts to different screen sizes and devices.

2.9.3 Prototyping

Distinguish a system prototype, which explores system behavior, from a design prototype, which explores the interface. Weigh the value of early feedback against the risks of incomplete functionality, quality or maintainability.

Prototype risk: users may want to adopt a rough prototype too quickly, even when reliability, maintainability, and quality have not been fully tested.

Expanded notes: 2.3.1-2.3.7 Interface Design Habits

The guide's user interface chapter keeps returning to one idea: a good interface supports real work so smoothly that users can focus on the task instead of the system. That is why the analyst must understand business functions, user skill levels, user language, and feedback from actual use.

Habit	What it means in revision language	Example exam wording
Understand the business	Start from business functions and goals; an FDD can act as a checklist of tasks.	"Explain why the screen must reflect order tracking work."
Maximize graphical effectiveness	Use visual layout, windows, icons, and clear screen organization to help users learn quickly.	"Evaluate whether this screen supports visual learning."
Think like a user	Design for user experience, knowledge, terminology, errors, and real-world expectations.	"Why should novice and expert users both be considered?"
Use models and prototypes	Use storyboards, sketches, interviews, questionnaires, observation, and usability metrics.	"Explain how feedback reduces misunderstanding."
Focus on usability	Give users all required tasks and commands without overwhelming them with too many options.	"Identify why a menu with too many choices is weak."
Invite feedback	Monitor use after implementation because real operations reveal issues missed in prototype tests.	"Why should help screens be revised after rollout?"
Document everything	Save approved screens, storyboards, menu trees, and CASE/screen-generator designs for programmers.	"State why numbering screens matters."

Expanded notes: 2.4.1-2.4.10 Detailed UI Design Guidelines

The second guideline group is more operational: it turns the design habits into concrete checks for screens, menus, feedback, data entry, and volume reduction.

Guideline	Quick application
2.4.1 Easy to learn and use	Define system design objectives; make the interface understandable and memorable; keep commands and responses consistent; support error correction; label controls; use familiar images and clear instructions; show available commands and dim unavailable ones; make navigation easy.
2.4.2 Enhance productivity	Organize tasks and menus logically; provide expert shortcuts, default values, duplicate-value functions, fast-find tools and, where suitable, natural-language capabilities.
2.4.3 Provide flexibility	Support different user skills, preferences and work conditions with suitable alternative paths and interaction methods.
2.4.4 Help and feedback	Keep help available; offer user-selected and context-sensitive help; preserve return points; show contact details; confirm deletion; provide undo; highlight errors; use useful links and logical, persistent messages; alert users to delays and task outcomes; explain icons; write professional, specific messages.
2.4.5 Attractive layout and design	Use appropriate colors and restrained effects; group related information; manage screen density; keep displays, terminology and mouse actions consistent; make commands predictable; support clear data-entry flow, familiar color patterns, keyboard alternatives, familiar platform conventions and language without jargon.
2.4.6 Enhance the interface	Start with a clear opening screen; use command buttons, customization, shortcuts and dialog guidance; choose suitable toggles, list boxes, radio buttons, checkboxes and calendar controls.
2.4.7 Focus on data-entry screens	Use form filling, restrict access to appropriate fields, provide cancel and modification options, descriptive captions, flexible navigation, layouts matching source documents, sample formats and input masks; set appropriate field endings and numeric formats; use defaults, acceptable-value guidance, error messages and pre-submit confirmation; anticipate future needs.
2.4.8 Use validation rules	Apply sequence, existence, data-type, range, reasonableness, validity and combination checks, plus batch controls.
2.4.9 Manage data effectively	Help users retrieve and work with data efficiently while preserving accuracy, access control and integrity.
2.4.10 Reduce input volume	Enter only necessary data; avoid entering retrievable or calculable values; avoid repeating constant data; use codes where appropriate.

Exam trap: "attractive" does not mean decorative. In this chapter it means readable, consistent, predictable, and task-focused.

Worked Example: Redesigning a Sales Return Form and Report

Scenario: users complain that returned goods are recorded incorrectly and managers receive a confusing monthly report.

Design object	Apply the guide	Revision answer
Source document	Use zones: heading, control, instruction, body, totals, and authorization.	Add company logo/title, return number/date, short instructions, item rows, refund totals, and manager signature.
Input screen	Use validation and reduce volume.	Make return number required, use product lookups, range-check quantity, validate customer number, and provide default dates.
Output report	Ask why printed output is needed, who uses it, what it includes, when it updates, and whether it is confidential.	Create a summary report for managers and an exception report for unusually high return rates.
Control break report	Sort by the control field before producing subtotals.	Sort by store number, print each store subtotal, then print a grand total in the report footer.

Exam trap: GIGO links form design to output quality. Bad source documents and weak validation produce bad reports even if the report layout looks professional.

Expanded notes: 2.7-2.9 Technology, Security and Emerging Trends

Technology choices affect both input and output. Screen output, printed output, source documents, RFID, automated data capture, responsive layouts, and modular design must still be judged by user needs and control requirements. The guide also keeps security inside interface design: reports can expose confidential information, and input screens can let unauthorized or inaccurate data enter the system.

Control area	What to check
Output security	Who receives the report, whether it is confidential, where it is stored, whether it is printed, and whether access is logged.
Input security	Audit trails, encryption, passwords, access levels, validation, data security, and controlled source documents.
Responsive design	Whether the interface adapts to different devices without losing important tasks or clarity.
Prototyping	Whether the prototype is throwaway for learning or is being mistaken for a finished production system.

Chapter 2 Glossary: UI, Forms and Reports

UI: User interface; the screens, menus, functions, outputs, hardware, software, and features that support two-way user-system communication.
HCI: Human-computer interaction; the study and design of how people communicate with computers while performing tasks.
GUI: Graphical user interface; uses icons, graphical objects, windows, and pointing devices.
usability: How effectively and comfortably users can learn, use, and complete tasks with the system.
FDD: Functional decomposition diagram; breaks business functions into levels and can guide interface task coverage.
storyboard: A sketch or model showing screen layout before full development.
usability metrics: Measures gathered from user interaction, often through software tracking, to evaluate interface effectiveness.
GIGO: Garbage in, garbage out; output quality depends on input quality.
source document: A form that collects input data, authorizes or triggers action, and records the original transaction.
heading zone: Form area for company name/logo, form title, and form number.
control zone: Form area for codes, identification numbers, and dates used for tracking.
authorization zone: Form area for signatures or approvals.
detail report: A report listing detailed records or transactions.
summary report: A report that groups and totals information for review.
exception report: A report showing only items outside normal limits or requiring attention.
control break: A report point where a control field changes and subtotals or group actions are triggered.
responsive web design: Design approach where screens adapt to different device sizes and contexts.
prototype: A working model or mock-up used to test design ideas and gather feedback.

Back to General Module Content

Chapter 3: Data Design

Data design organizes data into structures that support storage, retrieval, integrity, security, and analysis.

Chapter 3

3.1 Data Design Concepts

3.1.1 Data Structures

A data structure organizes, stores, and manages data. File-oriented systems store separate files, which can create redundancy and inconsistency. A database uses connected tables as an overall data structure.

3.1.2 Mario and Danica: A Data Design Example

Use the auto-shop example to compare disconnected files, which duplicate mechanic data and can become inconsistent, with Danica's relational DBMS, where related tables share a common key.

3.1.3 Database Management Systems

A DBMS provides tools and interfaces for adding, updating, managing, accessing and analysing data. Its benefits include scalability, economies of scale, enterprise-wide applications, stronger standards, better security and data independence.

3.2 DBMS Components

DBMS components include interfaces for users, DBAs and related systems, a data manipulation language, schema and subschemas, and the physical data repository.

3.3 Web-Based Design

Internet or intranet access connects browsers and web servers to databases. Middleware translates web requests into database commands and translates results back into pages, across the database, web server and telecommunication links.

3.4 Data Design Terms and Referential Integrity

Term	Meaning
Entity	A person, place, thing or event about which data is stored.
Table or file	A collection of related records arranged in rows; columns represent fields.
Field	A single data item or attribute in a table column.
Record	A row containing the fields that describe one entity instance.
Primary key	A field or field combination that uniquely identifies a record.
Composite primary key	A primary key made from two or more fields.
Candidate key	A field or field combination that could uniquely identify a record and be chosen as the primary key.
Foreign key	A field that refers to a key in another table; used to link related records.
Secondary key	A non-unique field used to retrieve or group records.
Referential integrity	Prevents a foreign key value unless the matching primary key exists.

3.5 Entity-Relationship Diagrams

ERDs show entities, their attributes and relationships. Mark primary keys, foreign keys and secondary keys where applicable. When drawing, identify the entities first, add key attributes, connect related entities, choose the relationship type and show cardinality/participation at each end.

Relationship	Meaning	Design note
1:1	Each instance on either side relates to at most one instance on the other side.	Confirm whether the entities should be combined or kept separate for a reason.
1:M	One instance can relate to many on the other side; each of those relates back to one.	Place the foreign key on the many side.
M:N	Many instances on each side can relate to many on the other side.	Resolve through an associative entity, producing two 1:M relationships.

Ask “how many is many?” by stating minimum and maximum participation based on the business rules. Normalization helps resolve M:N relationships and refine the resulting tables.

3.6 Normalization Stages

3.6.1 Standard notation and unnormalized design

Use standard notation to show primary keys and attributes. Identify repeating groups and mark the original unnormalized table before decomposing it.

Normal form	Rule
1NF	No repeating groups.
2NF	In 1NF and every non-key field depends on the whole primary key.
3NF	In 2NF and no non-key field depends on another non-key field.

3.6.2 First Normal Form

Remove repeating groups and keep each field atomic.

3.6.3 Second Normal Form

Remove partial dependencies so every non-key attribute depends on the whole key. This addresses cumbersome updates, inconsistent data, difficulty adding a product and accidental loss of product information when deleting a record. Check whether other anomalies remain after conversion.

3.6.4 Third Normal Form

Remove transitive dependencies. This prevents repeated supplier details, inconsistent supplier data, difficulty adding a supplier and loss of supplier information when deleting a related product or order.

3.6.5 Two Real-World Examples

Crossroads College: begin with a STUDENT table containing a repeating group of courses, convert it to 1NF using Student Number + Course Number, split student/course/grade facts to reach 2NF, then move advisor name and office into ADVISOR to remove the transitive dependency and reach 3NF. GRADE becomes the associative entity between STUDENT and COURSE.

Magic Maintenance: use the service company's seven linked tables as a larger real-world illustration of normalized customer, technician and service-call data sharing common keys.

Normalization refines table design to reduce redundancy, update problems and data inconsistency.

3.7 Codes

Codes use letters or numbers to represent data. They can speed entry, reduce storage, cut transmission time, reveal information, or conceal information. The study guide groups them into sequence, block sequence, alphabetic, significant-digit, derivation, cipher and action codes.

3.8 Data Storage and Access

Storage and access design covers strategic tools for using organisational data, the distinction between users' logical view and its physical implementation, suitable data formats and the treatment of date fields.

3.8.1 Tools and Techniques

Data warehousing: integrates data from multiple organisational systems—such as orders, inventory and payroll—so it can be analysed together to support management decisions.
Data mart: a smaller, focused collection for a particular department. Its narrower scope can make access faster and more relevant to that department.
Data storage and access: storing large volumes requires planned architecture and structure, regardless of whether the organisation uses a warehouse or a mart.
Data mining: software searches data for meaningful patterns and relationships. The guide's examples include customer-purchase patterns and market-basket analysis; clickstream use also raises privacy and ethical concerns.
Logical vs. physical storage: logical storage is the user's view of fields and records; physical storage is how hardware and the operating system place and retrieve binary data on media. Allocate field sizes for anticipated values without waste.
Data coding: computers represent information with bits. The guide covers EBCDIC, ASCII, binary and Unicode: binary stores numeric values efficiently, while Unicode supports a broad range of multilingual characters.
Storing dates: a four-digit-year ISO format (YYYYMMDD) avoids the two-digit-year problem and sorts chronologically. For date arithmetic, an absolute date counts the days from a chosen base date; subtracting two such values gives the interval.

3.9 Data Control

File and database management must keep stored data accurate, complete and protected, including the physical security of the system and controls over input and output. A well-designed DBMS provides security and integrity features such as subschemas, passwords, encryption, audit-trail files, and backup and recovery procedures. The analyst ensures these controls are used correctly.

Expanded example: 3.1.2 Mario and Danica

The guide's auto shop example is a clean way to remember why relational databases matter. Mario stores mechanic and job data in two separate file-oriented systems. Because Mechanic No, Name, and Pay Rate are duplicated, one file can show Jim Jones at one rate and another file can show a different rate. The issue is not just storage waste; it is data quality and integrity.

Danica uses a DBMS with two related tables joined by a common field, Mechanic ID. The pay rate appears in only one place, while the common field connects the mechanic table to the job table. This is the basic idea of the relational model: tables are separate, but meaningful relationships allow them to work together.

Design	What happens	Main revision point
File-oriented system	Separate unlinked files store overlapping data.	Redundancy can create inconsistency.
Relational database	Tables are connected through common fields.	Data is stored once where possible and reused through relationships.
DBMS	Provides tools, interfaces, schemas, DML, and physical repositories.	Users get timely, flexible access while the DBA manages enterprise-wide structure.

Expanded notes: DBMS Components

A DBMS sits between the database and the users, DBAs, applications, and related systems that need access. The guide highlights user interfaces, DBA interfaces, related-system interfaces, a data manipulation language, a schema, subschemas, and a physical data repository.

3.2.1 Interfaces for Users, DBAs and Related Systems

Interface or component	Purpose
Users	Query, add, update and view data through business-oriented interfaces.
Database administrators (DBAs)	Define and administer the database, security, performance and structure.
Related information systems	Exchange data with applications and other systems.
Data manipulation language (DML)	Queries and changes stored data.
Schema and subschemas	Define the complete database structure and selected user/application views.
Physical data repository	Stores the actual data and associated definitions.

3.2.2 Schema

The schema defines the overall logical structure of the database. Subschemas present only the relevant view to a particular user or application.

3.2.3 Physical Data Repository

The repository is the physical storage location for database data and definitions managed by the DBMS.

Expanded notes: Web-Based Design

Internet

Internet-based databases can provide global access, ease of use across multiple platforms and cost effectiveness. They also require attention to security and adaptability.

Intranet

An intranet applies web technologies and browser-based database access within an organisation.

Middleware

Middleware connects the database and web-facing components. Consider the database itself, the web server and the telecommunication links between them and their users.

Worked Example: From Order Form to Normalized Tables (supports 3.1-3.6)

Unnormalized source: ORDER (ORDER_NO, DATE, CUSTOMER_NO, CUSTOMER_NAME, (PRODUCT_NO, DESCRIPTION, QTY_ORDERED, SUPPLIER_NO, SUPPLIER_NAME)). The repeating product group means one order record can contain many product lines.

1NF: remove repeating groups. Put each product line into its own row or separate child table so every field stores one value per record.
2NF: if a table has a combined key such as ORDER_NO + PRODUCT_NO, every non-key field must depend on the whole key. Product description depends only on product, not on the whole order line key, so it belongs in PRODUCT.
3NF: remove dependencies between non-key fields. If SUPPLIER_NAME depends on SUPPLIER_NO, store supplier details in SUPPLIER rather than repeating them in order lines.

Result table	Purpose	Key idea
`ORDER`	Order header: order number, date, customer number.	One row per order.
`ORDER_LINE`	Products listed on an order, including quantity.	Associative entity between order and product.
`PRODUCT`	Product description and supplier reference.	Product facts stored once.
`SUPPLIER`	Supplier name and details.	Supplier facts stored once.

Exam trap: do not jump straight to 3NF language. Say what problem is removed at each stage: repeating groups, partial dependencies, then transitive dependencies.

Expanded notes: 3.7 Codes

3.7.1 Overview of Codes

Codes represent data concisely and can support identification, classification, sorting, data entry, storage and processing. Good design avoids ambiguity and allows for future growth.

3.7.2 Types of Codes

Codes simplify input, output, and storage by representing data with letters or numbers. The guide identifies seven code types and sets out ten design criteria: keep codes concise; allow for expansion; keep them stable, unique and sortable; use a simple structure; avoid confusing characters; make codes meaningful; use each code for a single purpose; and keep coding consistent across systems.

Code type	Meaning	Example pattern from the guide
Sequence	Assigned in order and carries no extra meaning.	Employee numbers issued consecutively.
Block sequence	Blocks of numbers represent classes or categories.	100-level and 200-level course numbers.
Alphabetic category	Letters identify a category.	`GN` for gardening, `HW` for hardware.
Alphabetic abbreviation	Letters abbreviate a longer name or term.	Short letter groups used to represent a product or location.
Mnemonic	Letters chosen to be easy to remember.	`ATL` for Atlanta or `MIA` for Miami.
Significant digit	Digit groups each carry meaning.	Warehouse, floor, section, aisle, and bin in one location code.
Derivation	Built from attributes of the item/person.	Postal code, letters from surname, house number, and street name.
Cipher	Substitutes or transforms characters to conceal or encode information.	A code mapping transforms the original value.
Action	Indicates an operation the system should perform.	`D` display, `A` add, `X` exit.

3.7.3 Designing Codes

Apply all ten criteria when designing a code scheme; for example, avoid ambiguous characters such as O/0 and I/1, leave capacity for growth, and avoid combining unrelated attributes in one code.

Chapter 3 Glossary: Data Design Terms

data structure: A system for organizing, storing, and managing data in files or tables.
file-oriented system: A design where separate files are not linked, often causing redundancy and inconsistency.
relational database: A database model where tables are connected by common fields.
DBMS: Database management system; tools, features, and interfaces for adding, updating, managing, accessing, and analyzing data.
DBA: Database administrator; manages the database for enterprise-wide needs.
DML: Data manipulation language; supports querying, updating, deleting, and manipulating database data.
schema: The definition of the database structure.
subschema: A view of the database for a particular user, application, or need.
entity: A person, place, thing, or event about which data is stored.
attribute: A characteristic or field describing an entity.
record: A set of fields for one entity instance; also called a tuple in relational language.
primary key: A field or field combination that uniquely and minimally identifies a record.
foreign key: A field that matches a primary key in another table.
referential integrity: A rule requiring a foreign key value to match an existing primary key value.
ERD: Entity-relationship diagram; a model of logical relationships among system entities.
cardinality: The detailed number relationship between entity instances.
associative entity: A third entity used to implement an M:N relationship, such as registration between student and class.
1NF: First normal form; removes repeating groups.
2NF: Second normal form; every non-key field depends on the whole primary key.
3NF: Third normal form; removes dependencies between non-key fields.
audit log: A record of database activity used to trace changes and support control.

Back to General Module Content

Chapter 4: System Architecture

System architecture transforms logical design into the physical structure of hardware, software, networks, processing methods, data, procedures, people, and security.

Chapter 4

4.1 Architecture Checklist

Corporate organization and culture
ERP and SCM integration
Initial cost and total cost of ownership
Scalability and web integration
Legacy system interfaces
Processing options, security, and corporate portals

4.2 The Evolution of System Architecture · 4.3 Client/Server Architecture

Servers provide data and processing services to clients. In client/server architecture, processing is distributed between the client and a central server.

Design	Meaning
Fat client	Most application processing happens on the client.
Thin client	Most processing shifts to the server.
Two-tier	Client handles UI; server stores data and may share logic.
Three-tier	Adds an application server/middle layer between client and data server.

4.4 Impact of the Internet · 4.5 E-Commerce Architecture · 4.6 Processing Methods

The internet changed architecture through e-commerce, packaged web solutions, service providers, cloud computing, and Web 2.0 collaboration. Processing methods also shape design.

Method	Use
Online processing	Users interact with systems that process transactions in real time.
Batch processing	Transactions are collected and processed in scheduled groups.

4.7 Network Models · 4.8 Wireless Networks

Networks share hardware, software, and data. The OSI model has seven layers: physical, data link, network, transport, session, presentation, and application. Topologies include hierarchical, bus, ring, star, and mesh designs.

Wireless LANs based on IEEE 802.11 standards improve flexibility, but they introduce interference and security concerns.

4.9 Systems Design Completion

The system design specification documents the complete architecture and supports final presentations. After review, the project may move into development, require more design work, or be canceled.

Expanded notes: 4.1 Architecture Checklist

System architecture is the physical design of the information system. The guide's checklist asks whether the design fits corporate culture, enterprise systems, costs, growth, web integration, legacy systems, processing options, security, and portals.

Checklist item	Question to ask	Why it matters
Corporate organization and culture	Will the architecture match how the company actually works?	A technically strong system can fail if it conflicts with business structure.
ERP and SCM	Does the design need to integrate enterprise resource planning or supply chain management?	Enterprise integration changes data, process, and interface requirements.
Initial cost and `TCO`	Have assumptions changed since the build/buy decision?	Hard costs and soft costs continue across the system's life.
Scalability	Can the system expand, shrink, or change as business volumes change?	Architecture decisions are expensive to reverse later.
Web integration	Does the system use the internet, intranet, customer/vendor access, or web services?	Web access adds compatibility, availability, and security demands.
Legacy interfaces	What existing systems must still exchange data?	Old systems often constrain new architecture.
Security	What must be protected at the system, network, data, and user levels?	Security belongs in design, not only after installation.

Expanded notes: 4.2-4.3 Architecture Evolution and Client/Server Design

The guide traces architecture from centralized mainframes, through personal computers, toward networked and distributed systems. In client/server architecture, clients request services and servers provide data, logic, storage, or processing.

Architecture idea	Meaning	Exam clue
Mainframe	Central computer performs most processing for connected users.	Central control, but less distributed flexibility.
Personal computer impact	Processing power moves closer to the user.	Users gain local tools, but data sharing and support become harder.
Network evolution	Computers share hardware, software, data, and communication resources.	Architecture becomes a blend of local and central resources.
Fat client	Client handles much of the application processing.	Needs more capable client devices.
Thin client	Server handles most processing; client mainly presents the interface.	Useful when control, updates, and central management matter.
Two-tier	Client communicates directly with server/database layer.	Simpler, but can become harder to scale.
Three-tier	Client, application/middleware layer, and data layer are separated.	Improves flexibility and separates interface, logic, and data.

Exam trap: middleware is not the same as hardware. It is software that connects applications, manages communication, and supports data sharing between tiers or systems.

Worked Example: Architecture for a Retail Chain (supports 4.1-4.9)

Scenario: a retail chain has local stores, a head office, an online shop, and shared inventory data.

Need	Architecture decision	Reason
Sales must update inventory immediately.	Use `online processing` for store and website transactions.	Users need real-time interaction and current stock levels.
Monthly statements and large payroll runs.	Use `batch processing`.	Transactions can be collected and processed together on a schedule.
Website order, billing, and CRM support.	Compare in-house e-commerce, packaged solutions, and service providers.	Choice depends on control, cost, implementation speed, support, and TCO.
Store-to-head-office communication.	Use routers, gateways if different network environments must connect, and proxy servers for controlled internet access.	Network devices extend and protect communication paths.
Reliable store network layout.	Prefer star for manageability or mesh for high redundancy where justified.	Topology affects cost, performance, fault tolerance, and expandability.

Strong answer: connect architecture choices to business timing. Immediate stock lookup points to online processing; scheduled totals point to batch processing.

Expanded notes: 4.7-4.9 Networks, Wireless and Design Completion

The guide uses the OSI model to organize network communication into seven layers: physical, data link, network, transport, session, presentation, and application. It also compares topologies such as hierarchical, bus, ring, star, and mesh.

Topology	Strength	Weakness
Hierarchical	Clear levels of control and processing.	Upper-level failure can affect many lower-level nodes.
Bus	Lower cabling and flexible additions.	Central bus failure can stop the network; performance drops as devices grow.
Ring	Structured one-direction data flow.	One device failure can disrupt the ring unless bypass mechanisms exist.
Star	Easy to expand and manage through a central switch.	Switch failure can bring the network down.
Mesh	Redundant paths and strong reliability.	Expensive and complex because of many connections.

Wireless networks add flexibility through IEEE 802.11 standards such as 802.11b, 802.11g, 802.11n, and 802.11ac, but the guide warns about interference and security exposure.

At completion, the system design specification should include a management summary, system components, system environment, implementation requirements, time/cost estimates, and additional material from earlier phases. Presentations usually move from technical team, to users/managers, to final management approval.

Chapter 4 Glossary: Architecture and Network Terms

system architecture: The physical design covering hardware, software, networks, data, procedures, people, processing, and security.
hard costs: Tangible costs such as hardware, software, and equipment.
soft costs: Less visible costs such as training, downtime, support, and productivity disruption.
scalability: The ability of a system to expand, shrink, or change as business needs change.
ERP: Enterprise resource planning; integrated enterprise-wide system support for business functions.
SCM: Supply chain management; systems and processes for managing suppliers, materials, and product flow.
legacy system: An older system that remains important and may constrain new design choices.
client/server: Architecture where client devices request services and servers provide data or processing.
fat client: A client that performs much of the application processing locally.
thin client: A client that relies heavily on server-side processing.
middleware: Software connecting applications, tiers, or systems so they can communicate and share data.
online processing: Real-time transaction processing where users interact with the system immediately.
batch processing: Processing collected transactions together at scheduled times.
OSI model: Seven-layer network model: physical, data link, network, transport, session, presentation, application.
router: A network device that connects networks and forwards traffic.
gateway: A device or software component that connects different network environments or protocols.
proxy server: A server that provides controlled internet connectivity for internal users.
802.11: IEEE wireless LAN standards family.
MIMO: Multiple Input Multiple Output; wireless technique used in newer standards to increase throughput.
system design specification: The final design document used to communicate architecture and implementation requirements.

Back to General Module Content

Chapter 5: Managing Systems Implementation

Implementation turns design into a working system through development, testing, documentation, installation, training, and evaluation.

Chapter 5

5.1 Quality Assurance

QA aims to prevent defects or detect them early. Poor quality can come from unclear requirements, design flaws, coding mistakes, weak documentation, or ineffective testing.

Software engineering applies engineering principles to requirements, design, construction, testing, and maintenance. Systems engineering widens the view to hardware, networks, and interfaces.

5.2 Application Development · 5.3 Structured Development · 5.4 Object-Oriented Development · 5.5 Agile Development

Method	Tools and ideas
Structured	DFDs, structure charts, modules, data flows, control flows, loops, conditions.
Object-oriented	Use case diagrams, class diagrams, sequence diagrams, state transition diagrams.
Agile	User stories, priorities, iterations, releases, and customer testing.

Expanded detail: 5.3.2 Cohesion and Coupling

Cohesion measures how focused a module is. High cohesion is desirable because a module performs one specific function.

Coupling measures interdependence between modules. Loose coupling is desirable because modules can work with less reliance on each other.

5.7 Testing · 5.8 Documentation

Programmers use desk checking, code reviews, and unit testing. Analysts prepare test plans for integration testing and system testing. Documentation includes program, system, operations, user, and online documentation.

A strong answer separates unit testing, integration testing, and system testing instead of calling everything "testing".

5.9 Installation and Changeover

Method	Risk and cost profile
Direct cutover	Least expensive, but highest risk because the old system stops immediately.
Parallel operation	Safest, but most expensive because both systems run together.
Pilot operation	Tests the new system in one group before wider rollout.
Phased operation	Introduces the system one module or function at a time.

Installation also includes data conversion, user training, post-implementation evaluation, and a final report to management.

Expanded notes: 5.1 Quality Assurance, Software Engineering and ISO

The implementation phase includes application development, testing, documentation, training, and changeover, but quality assurance starts before code is written. The guide states that testing can find problems during implementation, but preventing or detecting mistakes earlier is cheaper and better.

Quality source	What can go wrong	How QA responds
Requirements	Users and developers misunderstand what the system must do.	Review requirements and design documents before building.
Design	Architecture, interface, database, or process models contain flaws.	Use structured reviews, diagrams, prototypes, and traceability.
Coding	Program logic is incorrect or inconsistent with design.	Use desk checking, code reviews, standards, and unit tests.
Documentation	Program, system, operations, or user information is incomplete.	Prepare documentation during development, not after users are already confused.
Testing	Tests are too narrow or unrealistic.	Plan unit, integration, system, and user-involved tests with real data patterns.

Software engineering applies engineering principles to requirements, design, construction, testing, and maintenance/evolution. Systems engineering widens the view to hardware, networks, people, procedures, and interfaces. The guide also names ISO as an international quality standards body; ISO-style work emphasizes documented testing, records, procedures, and quality evidence.

Expanded notes: 5.2-5.5 Development Methods

Implementation method affects how the design turns into working software. Traditional structured or object-oriented approaches usually begin after design is complete; agile approaches begin with prioritized user stories and iterative releases.

Approach	Guide details to remember	Exam contrast
Structured development	Uses DFDs, structure charts, modules, data couples, control couples, conditions, loops, and pseudocode.	Focuses on processes, modules, and flow from top-level logic to lower-level functions.
Object-oriented development	Uses use case diagrams, class diagrams, sequence diagrams, state transition diagrams, object interaction, cohesion, and coupling.	Focuses on objects/classes and their responsibilities/interactions.
Agile development	Uses customer-created user stories, priorities, iterations, releases, and careful customer testing.	Focuses on increments and user feedback rather than waiting for one final delivery.
Extreme programming	Emphasizes small releases, constant testing, user involvement, and adaptable design.	Often appears in questions about rapid change and close customer participation.

Exam trap: cohesion and coupling are not opposites. You want high cohesion inside a module and loose coupling between modules.

Expanded notes: 5.6-5.8 Coding, Testing and Documentation

After coding, testing proves whether programs and the whole system operate correctly. The guide separates programmer-level checks from analyst-planned integration and system testing.

Testing/documentation type	Purpose	Who needs it
Desk checking	Manually trace logic before running the program.	Programmers and reviewers.
Code review	Inspect code for logic, style, standards, and maintainability.	Development team.
Unit testing	Test one program or module by itself.	Programmers, then analysts reviewing results.
Integration testing	Test programs that interact with one another.	Analysts and developers.
System testing	Test the complete system, including user participation.	Users, analysts, IT team, management reviewers.
Program documentation	Explains program logic and internal details.	Programmers and maintainers.
System documentation	Explains system functions, data, design, and controls.	Analysts and maintenance teams.
Operations documentation	Explains how IT operations staff run, monitor, back up, and recover the system.	IT operations.
User documentation	Manuals, help screens, procedures, tutorials, and examples for daily use.	End users and managers.
Online documentation	Searchable, updateable help that can include hypertext, FAQs, webinars, and multimedia.	Users needing task-level assistance.

Worked Example: Planning a Payroll System Changeover (supports 5.6-5.9)

Scenario: a payroll replacement passed system testing. Management must decide how to install it, convert data, train staff, and evaluate success.

Separate environments: keep the operational environment for live data separate from the test environment used for testing and training practice.
Choose changeover: direct cutover is cheapest but riskiest; parallel operation is safest but expensive; pilot tests in one location/group; phased introduces one module or function at a time.
Convert data: move existing employee, payroll, tax, and benefits data into the new format, then validate accuracy before live use.
Train people: identify users, managers, and IT staff; choose vendor, outside, or in-house training; use group sessions, hands-on practice, manuals, tutorials, webinars, podcasts, and previous trainees.
Evaluate after implementation: review output accuracy, user satisfaction, reliability, maintainability, controls, security, platform performance, database implementation, IT team performance, documentation, training, cost-benefit estimates, and schedules.
Report to management: include final documentation, evaluation results, unresolved issues, planned maintenance, and recommendations.

Exam trap: training is not a one-line afterthought. The guide says the right people need the right training at the right time, and training plans should be considered early while documentation is created.

Chapter 5 Glossary: Implementation Terms

QA: Quality assurance; preventing defects or detecting them as early as possible.
software engineering: Engineering discipline for requirements, design, construction, testing, and maintenance/evolution of software.
systems engineering: Broader engineering view that includes hardware, software, networks, people, procedures, and interfaces.
ISO: International Organization for Standardization; creates international standards for quality products and services, including software.
structure chart: A structured development tool showing modules and the relationships between them.
module: A program component that performs a specific function.
data couple: Data passed between modules in a structure chart.
control couple: A message or flag passed between modules to control processing.
cohesion: How closely a module's internal tasks belong together; high cohesion is preferred.
coupling: How dependent modules are on each other; loose coupling is preferred.
user story: A customer-created agile statement of a needed feature and its priority.
iteration: A short agile development cycle that produces tested work.
release: A delivered version or increment of the system.
desk checking: Manual tracing of program logic to find errors before execution.
unit testing: Testing a single module or program independently.
integration testing: Testing interacting modules or programs together.
system testing: Testing the complete system, often with user participation.
direct cutover: Immediate switch from old system to new system; cheap but risky.
parallel operation: Old and new systems run together; safer but more expensive.
pilot operation: New system is tried in one location or group before wider rollout.
phased operation: New system is introduced module by module or function by function.
post-implementation evaluation: Review of the completed system's quality, performance, user satisfaction, controls, costs, and documentation.

Back to General Module Content

Chapter 6: Managing Systems Support and Security

Support and security cover the operational life of a system: helping users, maintaining the system, managing performance, protecting assets, backing up data, and planning retirement.

Chapter 6

6.1 User Support

Systems analysts often act as internal consultants. User support includes training, help desks, troubleshooting, technical guidance, knowledge bases, and support for new versions or changes.

A help desk is a centralized resource that helps users use system resources effectively, answers technical and operational questions, and improves productivity.

6.2 Maintenance Tasks

Type	Purpose
Corrective	Fix system errors.
Adaptive	Add capabilities or respond to new business/system requirements.
Perfective	Improve efficiency, performance, or maintainability.
Preventive	Reduce the likelihood of future failures.

6.3 Maintenance Management · 6.4 System Performance Management

Maintenance requests are evaluated, prioritized, scheduled, investigated, analyzed, designed, developed, tested, and implemented. Change management controls versions, documentation changes, and release timing.

Performance measures include response time, bandwidth, throughput, and turnaround time. Capacity management uses these measures to forecast future support needs.

6.5 System Security · 6.6 Security Levels

A security policy defines how assets are protected and how attacks are managed. Risk management identifies, analyzes, anticipates, and reduces risks to an acceptable level.

Level	Focus
Physical	Protect rooms, servers, desktops, and equipment.
Network	Protect communications, including wireless links.
Application	Use hardening, permissions, input validation, patches, and logs.
File	Control file permissions and encryption.
User	Manage identities, passwords, awareness, and social engineering risk.
Procedural	Use managerial controls and secure operating procedures.

6.7 Backup and Recovery · 6.8 System Retirement · 6.9 Future Challenges

Backup and recovery decisions include media, schedules, retention periods, RAID, cloud backup, and business continuity. Systems eventually reach the end of useful life when maintenance or operating costs rise, new technology becomes available, or the system cannot meet new requirements.

Future IT professionals need technical skill, critical thinking, credentials, and awareness of security, environmental, economic, political, and social pressures.

Expanded notes: 6.1 User Support and Help Desks

After implementation, a systems analyst often acts as an internal consultant. The guide notes that well-designed systems can require even more support because users discover features, ask for improvements, and need help applying the system to real work. Support can be in-house or outsourced, but quality must be actively monitored.

Help desk objective	Practical meaning
Show users how to use resources effectively.	Help with queries, reports, advanced features, intranet/internet access, and everyday operation.
Answer technical or operational questions.	Resolve network issues, passwords, licensing, upgrades, hardware costs, and software behavior.
Improve productivity.	Build a knowledge base, identify repeated problems, support training, and guide users toward better system use.

Exam trap: outsourced support still belongs to management. Saving money does not help if long waits, weak online tools, or poor staff performance reduce customer satisfaction.

Expanded notes: 6.2-6.3 Maintenance Types and Management

Maintenance is a mini-version of the SDLC. A maintenance request is submitted, evaluated, prioritized, scheduled, investigated, analyzed, designed, developed, tested, documented, and implemented. The maintenance team often includes analysts and programmers; in larger IT departments, maintenance and new development can be separate teams.

Maintenance term	Meaning	Example
Corrective	Fixes errors.	Correcting a payroll calculation bug.
Adaptive	Adds capabilities or responds to new requirements.	Adding a new tax field after legislation changes.
Perfective	Improves efficiency, performance, or maintainability.	Optimizing a slow report or simplifying support procedures.
Preventive	Reduces the chance of future problems.	Refactoring fragile code, archiving old data, or updating security controls before failure.

Management technique	Purpose
Maintenance requests	Capture the need, source, affected system, urgency, and expected benefit.
Priorities	Decide what gets handled first based on urgency, value, risk, and resources.
Configuration management	Controls maintenance requests, system versions, and documentation changes.
Maintenance releases	Group approved changes into planned releases.
Version control	Tracks system versions and changes so teams know what is current.
Baselines	Formal reference points used to measure and control system evolution.

Expanded notes: 6.4-6.6 Performance and Security

System performance management covers fault management, workload measurement, and capacity planning. The guide's performance terms are useful in short questions because they look similar but measure different things.

Measure	Meaning
Fault management	Detect, isolate, diagnose, and correct system problems.
Response time	How long the system takes to respond to a user request.
Bandwidth	Network capacity for transmitting data.
Throughput	Amount of work processed in a given time.
Turnaround time	Total time from submitting work to receiving the result.
Capacity planning	Forecasting future processing, storage, network, and support needs.

Security begins with policy and risk management. The guide frames risk management as identifying, analyzing, anticipating, and reducing risks to an acceptable level. Security should be evaluated across physical, network, application, file, user, and procedural levels.

Security level	Examples of controls
Physical	Locks, secure rooms, access cards, fire protection, climate control, and equipment protection.
Network	Firewalls, monitoring, wireless protection, secure protocols, and intrusion prevention.
Application	Input validation, patches, hardening, permissions, and logging.
File	Permissions, encryption, backup, and access logs.
User	Authentication, password discipline, awareness, and social engineering prevention.
Procedural	Management policies, operating procedures, audits, and separation of duties.

Worked Example: Recovering and Retiring an Ageing System (supports 6.4-6.8)

Scenario: an old inventory system has rising corrective maintenance, slow reports, repeated outages, and users asking for web access. A power failure damages a server during peak trading.

Business continuity: use the disaster recovery plan to identify roles, emergency actions, damaged equipment, recovery sequence, and communication responsibilities.
Backup and recovery: restore data from approved backups, follow retention rules, verify the latest clean copy, and test restored data before normal operations resume.
Performance review: measure response time, throughput, turnaround time, workload, and capacity to see whether the system can still support business needs.
Maintenance classification: fix the outage as corrective maintenance, improve slow reports as perfective maintenance, add web access as adaptive maintenance, and reduce future failure through preventive work.
Retirement decision: rising maintenance, expensive changes, user demands, new technology, poor support for new requirements, and declining value indicate that replacement planning should begin.

Strong exam answer: keep recovery and retirement separate. Recovery restores operations after disruption; retirement is the planned end of a system's useful life.

Expanded notes: 6.9 Future Challenges, IT Careers and Cyberethics

The closing section looks beyond day-to-day maintenance. IT professionals need technical knowledge, strategic planning ability, credentials or certifications where useful, and critical thinking. The guide also emphasizes cyberethics: security, privacy, fair use of systems, and responsible professional judgment become more important as systems connect more people, suppliers, and data.

Future-facing area	Revision meaning
Trends and predictions	IT work changes with security, operations, outsourcing, new technologies, and supplier expectations.
Strategic planning	IT professionals must connect technology decisions to business goals and long-term direction.
Credentials and certification	Certifications can demonstrate current technical knowledge in a changing field.
Critical thinking	Professionals must analyze problems, evidence, risks, alternatives, and consequences.
Cyberethics	Responsible behavior around access, privacy, security, information ownership, and professional conduct.

Chapter 6 Glossary: Support, Security and Maintenance

user support: Training, guidance, troubleshooting, and operational help provided after a system is implemented.
help desk: Central support point where users ask questions, report issues, request maintenance, and receive technical guidance.
knowledge base: Stored support information built from recurring problems, solutions, and user questions.
corrective maintenance: Maintenance that fixes errors.
adaptive maintenance: Maintenance that adds capability or responds to new requirements.
perfective maintenance: Maintenance that improves efficiency, performance, or maintainability.
preventive maintenance: Maintenance that reduces the likelihood of future failure.
configuration management: Control of maintenance requests, system versions, releases, and documentation changes.
version control: Tracking and managing different versions of software or system components.
baseline: A formal reference point for measuring and controlling system changes.
response time: Time between a user request and the system's response.
bandwidth: Data transmission capacity of a communication channel.
throughput: Amount of processing completed in a given time.
turnaround time: Total time from submitting a job/request to receiving the completed result.
capacity planning: Forecasting resources needed for future workload, storage, network, and support demands.
security policy: Management statement defining how information assets are protected.
risk management: Identifying, analyzing, anticipating, and reducing risks to acceptable levels.
authentication: Confirming a user's identity before allowing access.
authorization: Controlling what an authenticated user is allowed to access or do.
backup policy: Rules for what is backed up, how often, where it is stored, and how long it is retained.
retention period: The required length of time backup copies or records must be kept.
RAID: Redundant array of independent disks; combines disks for improved capacity, performance, or reliability.
disaster recovery plan: Plan for restoring operations after a disaster, including roles, actions, equipment, data recovery, and testing.
business continuity: Planning that keeps essential business functions operating during and after disruption.
system retirement: The planned removal or replacement of a system that no longer supports user or business needs effectively.
cyberethics: Responsible and ethical behavior in the use, protection, access, and management of information systems.

Back to General Module Content

Concepts, Tools, Methods & Standards

A full-module reference for Chapters 1–6. Use the quick index to search, browse by chapter or choose a term A–Z. Each entry gives an example and links to fuller notes. Examples illustrate the study-guide concepts.

Quick index search

Find a concept, tool, method or standard

Search all six chapters, or browse below.

Browse A–Z

Follow the system life cycle

Choose how to obtain a system → design its interface and data → select its architecture → build and install it → support, secure and eventually retire it. For a complete answer, explain the choice, apply it to a scenario and state the relevant control or trade-off.

Source: 2026 Information Systems 622 Study Guide. The chapter ranges below refer to PDF pages. Use the original PDF for formal citation.

Chapter 1 · Choose a development strategy

PDF pp. 8–36 · Chapter notes · Worked example

Concept, tool, method or standard	What it does / when to use it	Example	Fuller notes
Traditional vs web-based systems	Compare deployment and access needs before choosing a design.	A local payroll system serves one office; a web portal serves branches.	Open notes
In-house development	Build with internal staff when close control and specialist business knowledge matter.	A clinic team builds a booking workflow around its own approval rules.	Open notes
Build, buy or customise	Compare fit, speed, control, support and total ownership cost.	A package covers most bookings, but needs a custom referral field.	Open notes
Outsourcing and offshoring	Choose external delivery or work in another country with explicit oversight.	A vendor hosts booking software under a support agreement.	Open notes
SaaS and ASP	Access provider-run software as a service; check continuity and data control.	The clinic subscribes to a hosted appointment platform.	Open notes
Total cost of ownership	Compare acquisition with training, integration, maintenance and support costs.	A cheap licence needs expensive data conversion and annual support.	Open notes
RFP and vendor evaluation	State requirements and assess proposals against common criteria.	Score suppliers on security, workflow fit, cost and support.	Open notes
Systems analysis completion	Document the chosen option and obtain agreement before detailed design.	Present the recommendation, costs and unresolved risks to sponsors.	Open notes

Chapter 2 · Design input, interface and output

PDF pp. 37–76 · Chapter notes · Worked example

Concept, tool, method or standard	What it does / when to use it	Example	Fuller notes
HCI and usability	Design around users, their tasks and feedback.	Reception staff can complete a booking with clear labels and few steps.	Open notes
Seven interface design habits	Understand the business, use models, focus on usability and document feedback.	Observe the booking desk before drawing the screen.	Open notes
Ten interface guidelines	Apply learnability, productivity, flexibility, help, layout and data-entry guidance.	Use consistent navigation, defaults and useful error messages.	Open notes
Source document	Capture and authorise data at its origin using clear form zones.	A numbered booking form records patient, time and approval.	Open notes
Validation rules	Check required, range, reasonableness, validity and field combinations.	Reject an appointment date before today; check Doctor ID exists.	Open notes
Report types	Choose detail, summary or exception output for the decision.	Managers see overbooked sessions in an exception report.	Open notes
Input and output controls	Protect entry and reports with access, audit trails and secure handling.	Only authorised staff edit bookings; patient reports have restricted access.	Open notes
Responsive design and prototyping	Test layouts on devices and revise a model with user feedback.	Try a booking form on a phone before implementation.	Open notes

Chapter 3 · Model and control data

PDF pp. 77–122 · Chapter notes · Worked example

Concept, tool, method or standard	What it does / when to use it	Example	Fuller notes
DBMS and schema	Use a database system and schema to manage shared data consistently.	Patient and appointment tables use defined fields and relationships.	Open notes
Keys and referential integrity	Identify records and keep foreign-key links valid.	Every Appointment.PatientID must match an existing patient.	Open notes
ERD and cardinality	Draw entities and one-to-one, one-to-many or many-to-many relationships.	One patient can have many appointments.	Open notes
First normal form	Remove repeating groups and keep values atomic.	Move several service codes out of one booking cell into separate rows.	Open notes
Second normal form	Remove attributes dependent on only part of a composite key.	Move ProductName out of an OrderLine table keyed by OrderID and ProductID.	Open notes
Third normal form	Remove dependencies between non-key attributes.	Store DepartmentName in Department, not in every employee row.	Open notes
Codes and code design	Use meaningful, unique, maintainable identifiers where appropriate.	Assign a stable clinic code rather than using a changing name as a key.	Open notes
Storage, access and data control	Choose access methods and safeguard accuracy, permissions and recovery.	Index PatientID for lookup and restrict confidential records.	Open notes

Chapter 4 · Select an architecture and network

PDF pp. 123–157 · Chapter notes · Worked example

Concept, tool, method or standard	What it does / when to use it	Example	Fuller notes
Architecture checklist	Evaluate cost, scalability, legacy integration, processing and security.	Compare a local server with a hosted branch-wide system.	Open notes
Client/server tiers	Separate presentation, business logic and data responsibilities.	A browser calls an application tier that queries a database.	Open notes
Middleware	Connect applications or tiers and handle communication between them.	An integration service passes confirmed orders to inventory.	Open notes
E-commerce architecture	Choose in-house, packaged or provider-based delivery for online trade.	A retailer adopts a package and integrates stock data.	Open notes
Online vs batch processing	Use immediate processing for interactive work and scheduled batches for grouped jobs.	Confirm a booking now; produce end-of-day totals overnight.	Open notes
OSI model and network topology	Use the layered model to reason about communication and topology to map links.	Check whether a branch fault is in cabling, routing or the application.	Open notes
IEEE 802.11 wireless standards	Recognise WLAN standards as a factor in range, bandwidth and security choices.	Choose a suitable wireless network for mobile reception desks.	Open notes
System design specification	Record architecture and design decisions for review and implementation.	Document tiers, database, network, controls and interfaces.	Open notes

Chapter 5 · Build, test and install the system

PDF pp. 158–205 · Chapter notes · Worked example

Concept, tool, method or standard	What it does / when to use it	Example	Fuller notes
Quality assurance and ISO	Plan and document quality checks across development and maintenance.	Record review criteria and test evidence for a supplier build.	Open notes
Structure charts	Show modules and the calls or data passed between them.	Booking module calls CheckAvailability and SaveBooking.	Open notes
Cohesion and coupling	Keep each module focused and dependencies manageable.	Place price rules in one service, with a clear input/output contract.	Open notes
Object-oriented design	Model responsibilities in objects with attributes and behaviour.	Appointment stores its time and can change status.	Open notes
Agile, XP and user stories	Deliver short iterations around prioritised user needs.	“As a receptionist, I can reschedule a booking” guides a sprint.	Open notes
Unit, integration and system tests	Test a component, its interactions and the whole system in sequence.	Test a date rule, then booking-save flow, then full clinic workflow.	Open notes
Documentation and training	Prepare program, system, operations and user information for each audience.	Give support staff a recovery runbook and users a booking guide.	Open notes
Changeover and data conversion	Choose direct, parallel, pilot or phased rollout and migrate checked data.	Pilot one clinic, reconcile migrated appointments, then expand.	Open notes

Chapter 6 · Support, secure and retire the system

PDF pp. 206–247 · Chapter notes · Worked example

Concept, tool, method or standard	What it does / when to use it	Example	Fuller notes
Help desk and knowledge base	Resolve user issues, record answers and spot recurring faults.	Log repeated booking errors and publish a short help article.	Open notes
Four maintenance types	Classify corrective, adaptive, perfective and preventive changes.	Fix a bug, add a new rule, speed a report and replace fragile code.	Open notes
Configuration management	Control requests, versions, releases, documentation and baselines.	Tie a security fix to its approved request and release number.	Open notes
Performance measures	Compare response time, throughput, turnaround and bandwidth.	Measure how many booking requests finish per minute.	Open notes
Capacity planning	Forecast future load, storage and network demand.	Add capacity before a new branch doubles booking traffic.	Open notes
Security policy and risk management	Set protection rules and reduce identified risks to acceptable levels.	Require access review after a staff role changes.	Open notes
Security levels	Apply physical, network, application, file, user and procedural controls.	Lock server rooms, patch apps and limit patient-file access.	Open notes
Backup, recovery and continuity	Set backup and retention rules; rehearse restoration and essential operations.	Restore a clean appointment backup after a server failure.	Open notes
System retirement and cyberethics	Plan replacement when value falls; handle access and data responsibly.	Archive required records and remove old access before shutdown.	Open notes

Learning Lab

Use these interactive tools to practise Information Systems 622 concepts. Your quiz attempts are saved only in this browser.

Quiz Builder

Choose how many questions to draw from each topic, then answer and submit when ready.

Flashcards

Recall the definition before flipping the card.

Concept	Meaning	Simple example
Encapsulation	Keep data and the methods that manage it together, with controlled access to internal state.	An Account exposes deposit and withdraw operations.
Inheritance	A subclass reuses and extends attributes or methods from a superclass.	SavingsAccount inherits common features from Account.
Polymorphism	Related objects respond to the same operation in different ways.	CardPayment and EFTPayment each implement processPayment differently.
Object relationship	An association, aggregation or composition that connects collaborating objects.	Customer places Order; Order contains OrderLine items.

Assignment idea	What to show
E-commerce checkout	Customer submits an order; checkout validates it; inventory is checked; the payment gateway authorises payment; inventory is updated; confirmation or an error is returned.
BPM	Model the end-to-end business process with activities, events, decisions, roles, hand-offs and outcomes.
Object modelling	Model the classes or objects, their attributes, methods, messages and relationships that implement the process.