System Analysis and Design
Agents and large language models now produce the analyst's traditional deliverables - user stories, process and data models, prototypes - so professional value in systems analysis has shifted toward elicitation quality, verification of machine-drafted artifacts against real stakeholders, and specifying systems whose components behave probabilistically. The course therefore adds verification of agent-drafted requirements, acceptance criteria and monitoring for non-deterministic components, accountability and escalation as specified requirements, and evidence-based evaluation of vendor AI claims, without displacing the course's requirements, architecture, modeling, and project commitments.
Current description → proposed description
Systems Analysis and Design allows students to investigate the theory, practice, and application of systems analysis and design in the context of information technology. This course emphasizes the vital and various roles played by people during the analysis and design of problem-solving systems. Key topics include requirements, acquisition and sourcing, integration, management, quality assurance, organizational context, and architecture. The tools and techniques of systems analysis and design are covered along with the information technology problem-solving model and appropriate documentation. Prototyping, process and data modeling, feasibility and reliability issues, and user interaction are studied. Current state-of-the-art topics in IT are used as illustrative examples. A project relating to a large IT system allows students to implement analysis and design techniques in a realistic setting.
This course investigates the theory, practice, and application of systems analysis and design in the context of information technology, emphasizing the vital and various roles played by people throughout the analysis and design of problem-solving systems. Students work through requirements, acquisition and sourcing, integration, management, quality assurance, organizational context, and architecture, applying the information technology problem-solving model, prototyping, process and data modeling validated against sample extracts from the source systems, feasibility and reliability analysis, and the study of user interaction with appropriate documentation. Because AI coding agents and large language models now draft user stories, process and data models, and disposable prototypes directly from stakeholder input, the course centers on validating machine-drafted artifacts against the stakeholders and the organizational context that produced them, and on specifying systems that contain probabilistic components rather than deterministic ones alone. Students accordingly define acceptance criteria for behavior that is not simply pass or fail, treat cost, latency, transparency, and human escalation as first-class non-functional requirements, weigh vendor AI claims during feasibility and sourcing, and plan post-deployment monitoring for drift. Current state-of-the-art topics in IT are used as illustrative examples, and a project relating to a large IT system allows students to carry these techniques through a realistic setting.
What changes
- Verification of agent-drafted requirements, user stories, and process/data models against stakeholders
- Acceptance criteria, error-cost thresholds, and drift monitoring for probabilistic components
- Human-in-the-loop escalation, disclosure, and accountability records specified as requirements
- Evidence-based feasibility evaluation of vendor AI claims during acquisition and sourcing
- Graduate framing: defended design judgment under organizational constraint rather than technique practice
6 proposed outcomes, mapped to 6 program outcomes
Each outcome below is written to be observable and assessable, and each is mapped to the program learning outcomes for which it produces evidence.
Students will be able to analyze conflicting stakeholder needs across organizational roles, reconciling them into a validated requirements baseline and confirming each requirement drafted or summarized by an AI assistant with the originating stakeholders in their own non-technical terms, including what an AI-assisted component would and would not do for them.
The CLO's requirement that students confirm machine-drafted requirements with originating stakeholders in non-technical terms, specifically including what an AI-assisted component will and will not do, is the technical-to-non-technical communication of AI capability and limitation that PLO 5.1 names.
Students will be able to design the data and integration architecture for a multi-source information system, specifying conceptual and process models, source-system and API contracts, data quality and cleansing rules, and provenance and retention requirements, then validating those cleansing and quality rules by pulling and profiling a sample extract from at least two of the specified source systems and revising them from what the extracted records actually contain, so that the stored data can be reused dependably in reporting and in the evaluation of AI components.
PLO 2.1 asks students to conduct data acquisition from multiple sources, and this CLO has them conduct it on the system they specify: collecting a sample extract through the source-system APIs and databases they specified, profiling it, cleaning it against their own quality rules and revising those rules from what the records contain, and storing the result under stated provenance and retention requirements so it can support reporting and the evaluation of the system's AI components.
Students will be able to differentiate what a vendor's claimed AI capability technically does from how it is marketed during a feasibility and sourcing study, testing product documentation and demonstrated behavior on representative organizational data against the semantic, historical, and popular senses in which the term is used, and recommending build, buy, or defer on the stated evidence.
PLO 5.2 asks students to define and evaluate artificial intelligence while distinguishing semantic, historical, and popular definitions, and this CLO makes exactly that distinction operational by separating a vendor's demonstrated technical behavior from its marketing language in a sourcing decision.
Students will be able to justify where automated and probabilistic decision-making belongs in a proposed system, specifying the boundary between deterministic and model-driven behavior, human-in-the-loop escalation and override paths, the disclosure end users receive, the records that hold the organization accountable for an automated decision, and the privacy, consent, and access limits governing the data those components consume.
The specified disclosure to users, accountability records for automated decisions, escalation paths that keep a person answerable, and privacy and consent limits on the underlying data are the transparency, accountability, privacy, and potential-harm evidence for this outcome, which the workbook states twice in word-for-word identical language, once under Christian Faith as PLO 1.1 and again under Integrated Disciplinary Knowledge as PLO 3.2, so a CLO earning one necessarily earns the other.
Students will be able to evaluate a delivered system, including its AI-enabled components, against the acceptance criteria, error-cost thresholds, and cost and latency budgets set during analysis, verifying the deterministic behavior against the requirements baseline and testing the probabilistic behavior on a documented held-out set with metrics appropriate to non-deterministic output, and revising the requirements baseline and post-deployment monitoring plan from the resulting diagnostic evidence.
Measuring the system's AI-enabled components against error-cost thresholds and latency budgets on a documented held-out test set, with metrics suited to non-deterministic output, is the performance-and-limitations assessment PLO 6.2 requires, and the required revision of the baseline and monitoring plan is the analyst's form of the diagnostic-driven iterative refinement that outcome calls for.
Students will be able to construct the design documentation for a large IT system project at two registers, architecture, interface, and data specifications for the build team and a plain-language account of scope, residual risk, and the limits of the system's AI-assisted behavior for sponsors and end users, defending the underlying trade-offs in a formal design review.
Producing the same design at a technical and a plain-language register, including an explicit account of the limits of AI-assisted behavior, and defending it under questioning in a formal review is directly the clear and responsible communication to both technical and non-technical audiences that PLO 5.1 specifies.
Program outcomes this course reaches
Filled cells are program learning outcomes with at least one supporting course learning outcome in this course. Sparse coverage is expected — no single course carries all twelve.