The proposal is your first major deliverable in the capstone project. It sets the stage for everything that follows, so it's essential to get it right.
The proposal is an output from performing the Needs Analysis life cycle phase (Kossiakoff SE P&P 3rd edition Chapter 5).
Below are guidelines and tips to help you succeed on the proposal.
Your need statement is the foundation of your project. You'll convert the capabilities identified in this section into top-level requirements and include them in your Requirements Analysis Report. Ensure your requirements form a hierarchy:
Need statement level requirements
Operational or capability requirements
Derived and decomposed requirements
Remember, you won't have many derived and decomposed requirements initially, as these require the development of the RAR, FAR, CDR and ultimately the A-Spec.
Use your context diagram as a foundation for your functional domain when constructing the Functional Analysis Report. Pay close attention to the inputs and outputs at the system level. This diagram serves as an excellent starting point for identifying functional inputs and outputs.
Your context diagram should have:
The System in the center.
Primary external elements that interact with the system surrounding the system.
Separate input and output arrows to/from each external to/from the system.
Functional interfaces transferred between the elements: Material, Energy, Data, Signal. Be semi-specific. e.g. the ATM provides "cash material" from the ATM to the user. The user provides "account credential data" to the ATM, etc.
The source for the externals and interactions should come from the CONOPs mission descriptions / scenarios. The more robust your CONOPs, the more robust your context diagram will be.
The conceptual block diagram primarily validates the need and assures stakeholders that the project is feasible and worth the investment. However, do not use this diagram as the basis for your physical domain in the Conceptual Design Report. Instead, rely on systems engineering activities to guide you toward an optimal physical configuration.
Only show the internal subsuystems. If subsystems are decomposed further, this implies the student went too far, too fast. Components are typically discovered during concept definition (Kossiakoff 3rd edition Chapter 7).
Risk Statements: Phrase your risk statements using the "If (root cause), then (consequence)" format. This approach highlights both the root cause and the potential consequence.
Mitigation Strategies: Clearly distinguish between likelihood and consequences. Specify which category is lowered by each mitigation step. Keep in mind that planning, designing, and analyzing are preliminary steps and do not themselves lower the risk. Actual implementation is necessary to reduce risk. For example, planning to include a spare tire in a car's design does not reduce the risk of being stranded with a flat tire. Only having the spare tire (and necessary tools) actually installed lowers that risk.
If you plan to complete the capstone project in a single semester, then your proposed schedule is likely aggressive and high-risk. Consider spreading your project across two semesters.
Time Commitment: Let's say you estimate that your capstone will take 252 hours. 252 hours over 110 days = 2.3 hours per day. If you start working on the capstone at 6 PM after settling in from work, you'd have to work non-stop until about 8:30 PM every night, with no days off, to meet this schedule.
Outbriefing Slots: Capstone presentation slots are in very high demand. It’s essential to plan for an earlier completion date, as the final days of the semester might not be available.
If you insist on attempting to complete the project in a single semester, make not finishing on time one of your project risks.
To plan your project timeline, here's one approach:
Review final reports from previous students to understand the actual hours they invested in similar projects.
Decompose each deliverable into tasks. For each task, estimate the hours required and sum these to determine the total project duration.
Determine the number of hours you can realistically dedicate to the project each day, considering other commitments.
Using your task estimates and daily availability, create your project schedule. Tools like Gantt charts can help visualize timelines and dependencies. Excel works fine if you don't have access to MS Project or similar.
Allocate additional time (buffer) to account for unforeseen challenges or delays, especially mentor review. Worst case for me is 5 days. Best case is 1 day. Most likely is 2 days.
If your resulting 'Oral Defense Presentation' milestone is on or before the semester end, then you're good to go. If it falls after, you may need to adjust your available hours.
Don't forget to use EVM to track your project's progress against the planned schedule and budget. I have a dedicated EVM page on this site.
As the project progresses, compare actual hours spent with your estimates and adjust the schedule as necessary to stay on track. TCPI is a good metric to use for this.
Before you can track earned value, you must define the project work. Your WBS should first include all the major project deliverables as Level 2 elements:
Proposal
Requirements Analysis Report (RAR)
Functional Analysis Report (FAR)
Conceptual Design Report (CDR)
Trade Study Report (TS)
A-Spec (System Specification)
Risk Report
Test Report
Final Report
Final Presentation
Each deliverable should then be broken down into manageable work packages down to a weekly level; such as research, drafting, modeling, analysis, or review tasks.
This structure ensures that your EVM baseline matches the real expectations of the course and allows you to track project progress against deliverable completion.
Check out the EVM page on this mentor site for more information about setting up and tracking your EVM.
One key point for EVM is to take samples weekly rather than applying 0/100 or 50/50.
The proposal is your opportunity to demonstrate that your project is well thought out and feasible. Make sure each section is thorough and clearly presented. Remember that this document will guide your work throughout the capstone process, so take the time to ensure it's comprehensive and accurate.
Follow the template in the Guidelines. Proposals that do not follow the template in the guidelines will be rejected.
When you update deliverables, please include a summary of changes, as I do not have the capacity to re-review your entire document to identify where improvements were made.
System Introduction (System introduction and student biography)
Need for the System (Define the problem; describe how your proposed concept meets the need, and include references)
System Architecture / Description of System (Start with a Context Diagram; then include…)
Stakeholders
Environment description
External organizations and systems
System Conceptual Block Diagram (preliminary system block diagram, identifying major subsystems and their connections to each other, and include external entities)
Project Background
List 2-4 stakeholders you plan on engaging to gather needs and information
Work Breakdown Structure (identify ≥20 tasks, expected completion dates, and expected number of hours of effort)
Milestones and Schedule
Earned Value Management (Consider schedule as dates and cost as hours applied to the project. Your baseline schedule should define your Budgeted Cost of Work Scheduled (BCWS) and Budget at Completion (BAC). Budgeted Cost of Work Performed (BCWP), Actual Cost of Work Performed (ACWP), Cost Performance Index (CPI), Schedule Performance Index (SPI), and Estimate at Completion (EAC) should be reported on a regular schedule—weekly is recommended. Here is a template for using EVM.
Risk Management / Initial Risk Assessment (identify 3-6 risks; for each you should provide a title, description, consequences if realized, and an initial assessment of likelihood and consequences on a 1-5 scale. May be programmatic, technical or operational).
Systems Engineering Justification
Why would systems engineering be required for the project? See good & bad project concept ideas on the home page.
Scenarios (list at least 3 scenarios that would adequately describe the intended system operation and interactions. Provide a 1-2 paragraph description of each.)
Measures of Effectiveness (MOEs) (list 5 MOEs that can measure your system’s overall performance)
Analytical tools and techniques (how will you estimate/assess whether your system concept will meet it requirements?)
Your level of work should fall somewhere between 200 and 350 hours of work. Most students finish the project in under 300 hours. No student (who passes) spends less than 200 hours.
Checklist Credit: Steve Biemer