Module Check
This lesson reviews the full arc of Module 2. You have moved from a fuzzy idea through requirements, scope, components, data modeling, pre-prompt planning, task decomposition, tool selection, and a complete build spec. These are not independent skills — they form a single, integrated discipline. A weakness at any stage propagates forward: vague requirements produce unmeasurable success criteria; unscoped projects balloon; poorly designed components create integration problems; unordered tasks produce broken builds; unconstrained AI prompts produce incoherent code. The questions and activities below test both recall and reasoning. If you find a concept that is unclear, return to the corresponding lesson before attempting the capstone activity.
Flashcards — click each card to reveal the answer
A requirement reads: 'The system shall allow users to log in.' What is missing that makes this requirement inadequate?
A team's MoSCoW analysis lists real-time collaborative editing as a Must Have for their note-taking app. The feature requires WebSocket expertise none of the team members have. What should they do?
Component A directly reads from Component B's database table instead of calling Component B's interface. What design problem does this create?
A front-end component fetches data from the server, stores it in a local variable, and uses that variable to render the UI. The server data is updated by another user. The front end does not refresh. What state management problem is this?
A build spec task reads: 'Implement user authentication.' A student gives this task description directly to an AI and receives code for a login form with no password hashing, no session management, and no error handling. What was the root cause of the poor output?
Which sequence correctly represents the recommended order for starting an AI-assisted software project?
Every skill in this module serves one goal: reducing the distance between your intent and what gets built. Requirements make intent explicit. Scope makes it achievable. Components make it modular. Data modeling makes it persistent and correct. Planning makes AI prompts precise. Decomposition makes progress visible. Tool decisions reduce surprises. A build spec puts everything in one place. Miss any step and the gap between intent and reality widens.
Capstone: Architect a Project End to End
- Choose a project you genuinely want to build — it can be anything within your skills: a study tool, a local business website, a simple game, a personal finance tracker, a community resource board.
- Produce a complete build spec with all six sections:
- 1. Project Overview (2-4 sentences, specific and concrete).
- 2. Requirements List (at least 8 functional and 3 non-functional requirements, each with an acceptance criterion and at least one failure-case requirement per feature).
- 3. Scope (in-scope feature list, explicit out-of-scope list, MoSCoW priority tier for each in-scope feature).
- 4. Architecture (component list with one-sentence responsibilities and interface descriptions; data model with entities, attributes, relationships, and access rules; component dependency diagram or list).
- 5. Task List (at least 10 tasks, each with title, output description, dependency list, and time estimate; verify the order is valid).
- 6. Constraints (at least 5 explicit rules; at least 3 Architecture Decision Records covering language, database/storage, and one key library).
- Then write 3 AI prompts derived from 3 different tasks in your task list, each following the format: architecture context header, task description with inputs/outputs/failure cases, and closing constraints.
- Review your spec against the five review questions from lesson 9 (completeness, consistency, feasibility, security, testability). Document what you found and any revisions made.
- This artifact is your entry point for actually building the project. The work is already done — the building is what comes next.