|Problem Statement Creation and Use
, submitted by
View Revision History
|Students learn to create a general vehicle, the problem statement, which communicates the needs to all stakeholders, and is used to guide their expectations and their project work.
Lecture: 25 min
Lab: 25 min
Homework: 2 hours
|This module follows common industry practice for large projects and for new work, both of which are difficult to control and tend to drift away from critical targets.
Requirements specification & documentation
Project control (MGT.ctl)
1. Prior experience with real software projects (and so understanding how often stakeholder expectations are misaligned).
2. Basic grasp of process improvement and software menagement tools and appreciation of their value.
1. Assess the ability of a software project and its design to deliver value to its external stakeholders.
2. Use very general, non-technical goals as a starting point in creating an architecture.
3. Coordinate high-level needs statements with very detailed versions of software requirements.
1. Build problem statements interactively with project stakeholders.
2. Compare problem statements to other project artifacts, histories and outcomes.
Make architectural decisions based on high-level priorities expressed in a problem statement.
Problem statement introduction with example
No alternate modules.
Problem Seeking: An Architectural Programming Primer, Third Edition by William Pena. AIA Press, 1987, ISBN 0-913962-87-2.
Log in to
rate this module.
Discuss this module in the forums.