Capstone Project Specs and Work Management Documen
Capstone Project Specs and Work Management Documen
Document
(Initial Draft: December, 2009)
Section 1 Project Identification – Projects Name, Project Sponsor (if any), Project
Supervisor, Project's Business Function (e.g., Hotel Reservation Management), Starting Date,
Estimated End Date
Section 4 Project Scope – Describe in general what the project is supposed to do, and
what is not from business standpoint
2. Operating Environment (Describe the environment in which the software will operate, including the
hardware platform, operating system and versions, and any other software components or applications with which
it must peacefully coexist. )
3. Design and Implementation Constraints (Describe any items or issues that will limit the options
available to the developers. These might include: institutional regulatory policies; hardware limitations (timing
requirements, memory requirements); interfaces to other applications; specific technologies, tools, and databases
to be used; parallel operations; language requirements; communications protocols; security considerations; design
conventions or programming standards.)
4. Assumptions and Dependencies (List any assumed factors (as opposed to known facts) that could affect
the requirements stated in the document. These could include third-party or commercial components that you
plan to use, issues around the development or operating environment, or constraints. The project could be
affected if these assumptions are incorrect, are not shared, or change. Also identify any dependencies the project
has on external factors, such as software components that you intend to reuse from another project.)
System Feature 1 (Don’t really say “System Feature 1.” State the feature name in just a few words.)
Description and Priority (Provide a short description of the feature and indicate whether it is of High,
Medium, or Low priority. You could also include specific priority component ratings, such as benefit,
penalty, cost, and risk (each rated on a relative scale from a low of 1 to a high of 9. )
Stimulus/Response Sequences (List the sequences of user actions and system responses that
stimulate the behavior defined for this feature. These will correspond to the dialog elements associated
with use cases.)
Functional Requirements (Itemize the detailed functional requirements associated with this feature.
These are the software capabilities that must be present in order for the user to carry out the services
provided by the feature, or to execute the use case. Include how the product should respond to anticipated
error conditions or invalid inputs. Requirements should be concise, complete, unambiguous, verifiable, and
necessary. Use “TBD” as a placeholder to indicate when necessary information is not yet available .)
Note that each requirement should be uniquely identified with a sequence number or a
meaningful tag of some kind.
REQ-1:
REQ-2:
Safety Requirements (Specify those requirements that are concerned with possible loss, damage, or harm
that could result from the use of the product. Define any safeguards or actions that must be taken, as well as
actions that must be prevented. Refer to any external policies or regulations that state safety issues that affect the
product’s design or use. Define any safety certifications that must be satisfied. )
Security Requirements (Specify any requirements regarding security or privacy issues surrounding use of the
product or protection of the data used or created by the product. Define any user identity authentication
requirements. Refer to any external policies or regulations containing security issues that affect the product.
Define any security or privacy certifications that must be satisfied. )
Software Quality Attributes (Specify any additional quality characteristics for the product that will be
important to either the customers or the developers. Some to consider are: adaptability, availability, correctness,
flexibility, interoperability, maintainability, portability, reliability, reusability, robustness, testability, and usability.
Write these to be specific, quantitative, and verifiable when possible. At the least, clarify the relative preferences
for various attributes, such as ease of use over ease of learning .)
Other Requirements (Define any other requirements not covered above. This might include database
requirements, internationalization requirements, legal requirements, reuse objectives for the project, and so on.
Add any new sections that are pertinent to the project. )
Section 2 Control Plan (how change/modification of the requirements is controlled, and how schedule is
controlled in order to keep on track)
Section 3 Risk Management Plan (list the risks/issues that you have thought about, their impact and
ways of mitigation)
Section 4 Testing Plan (describe how you would do unit testing, regression testing, and integration test.
Any testing scenarios you can plan before any code is written )
Section 5 Project Organization/Decomposition (Describe how the project will be divided into
increments (or milestones) and the completion timeframes .)