Analysis Strategy

Functional Requirements

Rule: Keep it simple. Pre-populated AH concepts + max 8 additional (including validation).

Excessive requirements make tracking impossible and lose marks.

UML Use Case Diagrams

Use these early to identify end-user tasks. Every interaction in the UML should be an End-User Requirement in the spec.

Constraints

Accurately describe hardware/software limits and state your programming language clearly.

Design Evidence (Mandatory)

Software (Procedural)
  • Top-Level Design: Showing data flow between modules (Crucial - often missed).
  • Data Structure: Design of 2D arrays/records (types and dimensions).
Software (OOP)
  • UML Class Diagram: Must be from scratch (not auto-generated by a framework).
  • Include fields, methods, and search/sort logic.
Database/Web Integration
  • SQL Query Design: Logic for complex joins/aggregates.
  • Process Refinement: Show exactly where database connections and query executions occur.
  • Site Structure: Show all pages and redirects.

Validation design must be shown on wireframes or described in underlying processes.

Ongoing Testing Log

Do not just record errors. Record progress.

  • Checkpoints: Run code as concepts/integration are added. Note successful runs.
  • Issues: Note encountered problems, how you resolved them, and full references used.
  • Advanced Techniques: Screenshots of breakpoints or watchpoints are excellent evidence.

Mandatory Screenshots

Algorithms (Software)

1. Sorting:

MUST show Unsorted Data (Before) and Sorted Data (After).

2. Binary Search:

MUST show the full list of values being searched.

Database (SQL)

Initial State:

Evidence of tables before queries run (even if empty).

Query Outcomes:

  • INSERT: Show additional records.
  • UPDATE: Show records have changed.
  • DELETE: Show records removed.

Final Testing

Test Plan Detail

Don't group requirements into single tests. Provide discrete tests for data validation, database connection, and query success.

End-User persona

Adopt the persona of a specific user. Document the results of following the scenarios/user stories from the analysis.

Screenshots MUST be legible. Avoid dark mode themes in code screenshots.

Evaluation & Maintenance

Maintainability

Describe how your code supports:

  • Corrective: Fixing bugs (e.g. meaningful names).
  • Adaptive: Changing environment (e.g. modularity).
  • Perfective: Adding features (e.g. internal commentary).
Robustness

Be honest. If you have limited input validation, your solution is not robust. Discuss the validation you did implement.

Fitness for Purpose

Link directly back to EVERY functional requirement from the analysis stage. Track them through implementation and testing.