Systems Analysis & Design — Answer Key
Chapters 1–3 • Concise, numbered answers aligned to the Study Guide questions
Chapter 1 — Answer Key
1. Analysis = what the system must do; Design = how it will do it.
2. To provide a structured, repeatable process for building and maintaining systems.
3. Identify problem; Plan & monitor; Discover requirements; Design; Build/test/integrate; Deploy/support.
4. Core Process #4: Design system components.
5. Agile (iterative development).
6. Benefit: flexibility and early value; Drawback: changing scope/estimates.
7. It articulates the problem, capabilities, scope, and business benefits for approval.
8. Core Process #1: Identify the problem and obtain approval.
9. Work Breakdown Structure (WBS).
10. False—analysis focuses on what, not how.
11. All six SDLC steps are repeated each iteration to deliver a working increment.
12. System = whole solution; Subsystem = component within the system (e.g., UI subsystem).
13. A prescribed approach to development (e.g., Scrum).
14. Ensures user needs drive decisions and reduces rework.
15. They describe user-facing functions the system must support.
16. Architectural/Subsystem diagram (high-level design).
17. They verify quality and deploy value after design outputs are implemented.
18. Delivering in small increments that build toward the full system.
19. System Vision Document, WBS, schedule/iteration plan.
20. It marries technical execution with business value through staged processes.
Chapter 2 — Answer Key
1. Core Process #3: Discover and understand the details.
2. Gather info; Define requirements; Prioritize; Develop UI dialogs; Evaluate with users.
3. A business function the system must perform (e.g., process a payment).
4. A quality constraint (e.g., response < 2s; 99.9% uptime; role-based security).
5. FURPS (Functionality, Usability, Reliability, Performance, Security).
6. Functionals describe the actions; nonfunctionals set acceptable quality levels.
7. People or groups affected by the system; internal are inside the org, external are outside.
8. Operational use daily; Executive consume information and make decisions.
9. Interviews (depth), questionnaires (breadth), doc review (baseline), observation (reality), vendor
research (options), user feedback (validation).
10. It corroborates what users say with what they actually do.
11. False—useful throughout for options and best practices.
12. It shows steps, decisions, and responsibilities for a single end-to-end workflow.
13. A role/actor or organizational unit responsible for activities.
14. Shared visual language and standard semantics across teams.
15. Text: prose lists; Graphical: diagrams; Math: formulas/algorithms.
16. Scope of real-world concepts the system must remember and support.
17. To align scope, resources, and schedule with value.
18. Prototypes, reviews, walk-throughs, and feedback sessions.
19. Questionnaires/surveys.
20. Missing voices → missing/contradictory requirements and rework.
21. Open-ended for exploration; closed-ended for specifics/validation.
22. It reflects tacit knowledge that becomes explicit via prototypes or examples.
23. False—functional requirements are about business functions.
24. Visual flow clarifies sequence, ownership, and exceptions.
25. Iteration allows continuous refinement based on feedback.
Chapter 3 — Answer Key
1. A use case specifies system behavior that fulfills a user goal.
2. As a student, I want to upload an assignment so that my instructor can grade it.
3. Stories are brief stakeholder narratives; use cases provide detailed flows and conditions.
4. An external user/system that interacts with the application; identified by roles and interactions.
5. “What tasks do you need the system to help you accomplish?”
6. External, temporal, state.
7. External: place order; Temporal: end-of-month billing; State: inventory falls below threshold.
8. Ignore technology failures initially to focus on business requirements.
9. A single, complete unit of work that yields value; keeps use cases at the right granularity.
10. False—those are system controls, not user functions.
11. By enumerating all events that require a system response and mapping each to a use case.
12. A stick-figure icon.
13. The boundary separating user actions from automated system responsibilities.
14. «includes» is reuse of a shared sub-flow; inheritance relates classes, not use cases.
15. To tailor views for different stakeholders (e.g., actor-based vs. subsystem-based).
16. The flow of activities (normal/alternate).
17. They’re technical concerns added later to avoid biasing requirements.
18. Walk-throughs, reviews, and feedback cycles with users.
19. Actor-based centers on roles; subsystem-based groups functions by module.
20. Identify users → classify actors → elicit goals → consolidate → validate.
21. Both refer to a single execution path of a use case.
22. They are quick to create and easy to validate.
23. Core Process #3: Discover and understand the details.
24. They provide a shared reference for expected behavior.
25. True.