Systems Analysis and Design: SDLC, Requirements and Models
Systems Analysis and Design
The exam tests the system development life cycle, requirements elicitation, process and data modelling, feasibility, and the choice between methodologies. Items typically ask you to identify a diagram, classify a requirement, or place an activity in the correct phase.
Core concepts
- SDLC phases. Planning, analysis, design, implementation, maintenance. Analysis asks what the system must do; design asks how it will do it.
- Methodologies. Waterfall is sequential with heavy documentation and late feedback; iterative/agile delivers increments and absorbs changing requirements; prototyping clarifies fuzzy requirements; RAD compresses the cycle through heavy user involvement.
- Requirements. Functional requirements state behaviour (the system shall compute sales tax); non-functional requirements state quality constraints (response under two seconds, 99.9% uptime, audit logging). Elicitation techniques include interviews, questionnaires, observation, document review and JAD sessions.
- Process models. A context diagram (DFD level 0) shows exactly one process and external entities only - no data stores, no internal flows. Level 1 decomposes that process; a data dictionary defines every flow and store.
- Data models. ERDs show entities, attributes, relationships and cardinality. Logical models are technology-independent; physical models name tables, columns and indexes.
- Feasibility. Technical, economic (cost-benefit, NPV, payback), operational (will users adopt it?), schedule and legal.
Worked example
A student drafts a context diagram for a library loan system containing two processes, Check Out Book and Return Book, external entities Member and Librarian, and a data store, Loans. What is wrong?
Two errors. First, a context diagram must contain exactly one process - the whole system as process 0 - so the two named processes belong on the level-1 decomposition. Second, data stores are never shown on a context diagram: Loans is internal to the system and appears only after decomposition. The external entities are correct because Member and Librarian sit outside the system boundary and exchange net data flows with it.
Traps
- Placing data stores on a context diagram.
- Labelling a performance target as a functional requirement.
- Confusing logical design (what data and processes are required) with physical design (how they are implemented).
- Assuming more documentation means better analysis; waterfall's real cost is discovering requirement errors late.