0% found this document useful (0 votes)
957 views3 pages

Capstone Project Specs and Work Management Documen

This document outlines the requirements for a capstone project, including general information about the project, requirements, management plans, and appendices. The project requirements section describes key features, operating environment, constraints, assumptions, and detailed functional and non-functional requirements. The management plans section covers work plans, change control, risk management, testing, and project organization.

Uploaded by

Syam Sundar
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
957 views3 pages

Capstone Project Specs and Work Management Documen

This document outlines the requirements for a capstone project, including general information about the project, requirements, management plans, and appendices. The project requirements section describes key features, operating environment, constraints, assumptions, and detailed functional and non-functional requirements. The management plans section covers work plans, change control, risk management, testing, and project organization.

Uploaded by

Syam Sundar
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

Capstone Project Requirement Specification & Management

Document
(Initial Draft: December, 2009)

Chapter 1. General Information about the Project

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 2 Business Problem Description

Section 3 Project Purpose

Section 4 Project Scope – Describe in general what the project is supposed to do, and
what is not from business standpoint

Chapter 2. Project Requirements

Section 1 Overall Description


1. Product Features (Summarize the major features the product contains or the significant functions that it
performs or lets the user perform. Details will be provided in Section 2, so only a high level summary is needed
here. Organize the functions to make them understandable to any reader of the SRS. A picture of the major groups
of related requirements and how they relate, such as a top level data flow diagram or a class diagram, is often
effective.)

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.)

Section 2 System Features


This section illustrates organization of the functional requirements for the product by system
features, the major services provided by the product. You may prefer to organize this section by
use case, or UML software analysis diagrams, data flow diagrams, story boards, or combinations
of these, whatever makes the most logical sense in your view.

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:

System Feature 2 (and list as many feature as there are)


Section 3 Nonfunctional Requirements
Performance Requirements (If there are performance requirements for the product under various
circumstances, state them here and explain their rationale, to help the developers understand the intent and make
suitable design choices. Specify the timing relationships for real time systems. Make such requirements as specific
as possible. You may need to state performance requirements for individual functional requirements or features. )

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. )

Chapter 3. Management Plans


Section 1 Work Plan (descriptions about work activities and schedule allocation)

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 .)

Appendix Glossary and References


List all project related words that need particular definitions or clarifications (if any), and
references you will use for the projects (URLs of the websites, books, and articles)

You might also like