Systems Engineering Capstone Project

Ronald Giachetti, PhD

Department of Systems Engineering
Naval Postgraduate School

September 16, 2016

The systems engineering programs at the Naval Postgraduate School (NPS) include a team-based cap-
stone project. The capstone project is a culminating engineering design project intended to demonstrate
the student’s mastery of the knowledge gained in the program. The students apply all the systems engi-
neering knowledge, methods, and tools they learned during their coursework to solve a sponsor’s problem.
The purpose of this document is to describe the nature of the capstone project experience at NPS and to
describe the characteristics of a successful capstone project.

1 Capstone Project Components

This section describes the major components of a capstone project including the problem statement,
milestones, team structure, work plan and schedule.

1.1 Problem Statement

The problem statement for NPS capstones usually comes from the sponsors. The reason for this is the
students at NPS are sponsored financially by their home commands, and it is to these sponsors that NPS
turns to for problem statements. The problem can come directly from a sponsor or indirectly through a
sponsored research project being conducted by faculty in the department. Either way, NPS capstones are
highly relevant and important issues for the Navy or other Department of Defense command. Because
the problems are defense related, many include information falling under one of the classifications. While
NPS is capable of properly handling classified information, it is preferable to keep the capstone report at
the lowest level security classification consistent with addressing the problem.

1.2 Milestones and Deliverables

The capstone project passes through three major milestones: the project proposal, the interim project
review, and the final project review. The primary and often the sole tangible deliverable of a capstone
project is a project report. The systems engineering department has a template all capstone project
reports must adhere to. The project report is expected to meet the high academic standards for engi-
neering analysis, critical thinking, and technical writing. Other guides available from NPS describe both
the elements of critical thinking and the mechanics of writing good technical reports.

1.3 Team Structure

A team of students, usually between five and eight, work together on a capstone project. The students
are often all from the same command and/or location but this is not always the case. Regardless of
whether the team is co-located or not, the main tools for supporting the team are the same ones used
throughout the program, which are Collaborate and the Sakai website. The project team is assigned one

1
to two advisors from the NPS faculty. The students and the advisors should meet at least once a week.
More frequent meetings and the duration of the meetings depends on the student team and the advisors.

1.4 Work Plan

The work plan describes the systems engineering process and how the team tailored it to their particular
problem, the system engineering activities, the tools and/or methods, and the deliverables. The system
engineering activities to include in the work plan are elaborated on more fully in Section 2.

1.5 Schedule
The project team has three quarters (approximately 36 weeks) from start to finish for the capstone
project. It is important for project teams to make good use of the time by quickly agreeing upon the team
organization such that each student has assigned roles, responsibilities, and agreed upon deliverables. A
project schedule should be developed with sufficient detail to track each student’s progress against tasks.
Importantly, the team should use the schedule during execution of the project and not treat it as an
academic requirement that is written and then ignored.

2 Content of Capstone Project

A capstone project will span some portion of the system engineering development process and/or the sys-
tem life-cycle. The system engineering development process includes the following engineering activities:

• Stakeholder Analysis - identify stakeholders, determine their needs and priorities, analyze their
power and influence with respect to the project.

• Problem Analysis - identify the problems, opportunities, and issues; determine casual relationships.

• Operational Architecture - design the operational architecture including CONOPS, scenarios, and
organizational structure.

• Needs Analysis - determine and analyze the capability needs of the system and the capability gaps.

• Requirements Analysis - define and analyze the system requirements; allocate to functions as ap-
propriate.

• Value System Design - determine the measures of effectiveness and measures of performance.

• Analysis of Alternatives - generate different alternatives, develop a comparison method, and conduct
analysis.

• Functional Architecture - design the functional architecture and perform functional allocation.

• Physical Architecture - design the system’s physical architecture.

• System Design - design the system, subsystems, and/or components.

• Verification and Validation - verify the project design and system design; validate the requirements,
analysis, and designs.

• Test and Evaluation - develop a test plan, conduct system test, and evaluate data.

• Integration - develop an integration plan, integrate the system.

2
 The project team has to tailor the systems engineering process to their project needs. Tailoring means
the team will: modify the sequence of activities; select and perform only those activities relevant to the
project; and change the content, level of effort, and/or approach to each activity. The process tailoring
depends on the project objective, what work has previously been done, what information is available,
stakeholder needs, and what type of deliverables are required among other possible reasons.
Not every systems engineering activity will be, or should be, done to the same level of detail. Likewise,
teams should avoid force fitting course work into the project if it is not appropriate. Student teams
including activities or products in the report for the sake of trying to show all the coursework exhibit a
lack of critical thinking on the student’s part.
In addition to the system engineering activities the SE curriculum covers the following topics, which
should be part of many capstone projects.
• Probability and Statistics - A capstone project will involve the collection and analysis of data.
Simulation or other modeling may be used to analyze the performance of the proposed system design.
In all cases, the students should use appropriate data analysis techniques and their probability and
statistical knowledge to aid in the analysis and presentation of the data.
• Cost estimation - A capstone project may need to estimate cost to support trade-off analysis, analysis
of alternatives, or support recommendations.
• Risk management - A capstone project may need to identify risk, analyze the risk, and determine risk
handling strategies to support the project execution and deliverables. While it may not formally
be done, all project teams should spend some time to identify the risks associated with project
completion and ability to make all the deadlines.
• Modeling - All capstone projects will likely model one or more aspects of the problem, system,
or process. The teams should use good modeling practice as taught in the curriculum. When
appropriate the team should make sure their models conform with DoDAF and other modeling
conventions.
• Simulation - Simulation is computational modeling but warrants its own discussion. Simulation
is a powerful tool to generate data to support tradeoff and other decisions. Project teams should
use good practice in terms of defining simulation assumptions, model limitations, and use relevant
experimental and statistical techniques for the input and output data.

3 Roles
The Student Team is responsible for the project plan, project schedule, execution of project activities,
deliverables, report recommendations, and final report content and format. The student team listens to,
considers, and synthesizes advice from advisors and other subject matter experts.
The Advisors are responsible for identifying the project objective with the student team, helping the
student team with all aspects of conducting the project, and reviewing and providing feedback on the
IPDs and final report. The advisors approve via their signature the project proposal and the project final
report and are responsible for ensuring both meet SE department standards.
The advisors provide advice to the student team, they do not lead the project, nor do they tell the
students how to do each activity in the project. The ultimate decisions are up to the students and they
should be ready to support their decisions with evidence, logic, and reasoning demonstrative of critical
thinking. To say, “the advisor told us we needed a stakeholder analysis” may be true, but this is not a
sound rationale for doing it. Two appropriate responses are: “the advisor suggested we do a stakeholder
analysis and we concur so that we could understand the needs of the stakeholders, guide tradeoff decisions,
and to document requirements;” or, “the advisor suggested we do a stakeholder analysis, but we decided
not to because one has already been done by the sponsor and it was sufficient to satisfy the project needs.”

3
 The project team should seek out Subject Matter Experts (SMEs) among the faculty who have relevant
expertise on a topic and can provide additional guidance to the students. The advisors can provide
suggestions on suitable SMEs since they know the NPS faculty better than the students. SMEs at NPS
are probably not stakeholders in most projects because they do not have a vested interest in the problem,
project, or the solution developed. Consequently, the students should not identify SMEs as stakeholders
in the capstone project.

4 Department Standards
The capstone project should demonstrate your mastery of systems engineering. Consequently, you should
be using the knowledge, methods, and tools you learned in the program. This includes having your models
adhere to DoDAF, using probability and statistics to analyze the inputs and outputs of simulation models,
or including maintenance and logistics issues in your life-cycle analysis. In all cases, the use of systems
engineering knowledge should be relevant and appropriate for the project.
The project report is the main deliverable of all capstone projects. The project report is formatted
in accordance with a template available from NPS. The project report is simultaneously both a technical
document and an academic product. It must adhere to the standards for technical writing, and it must
properly paraphrase and/or cite references from the technical literature. The SE Department and the
Graduate Writing Center has other references that discuss these issues including the important goal of
exposing your critical thinking in your writing.
A good technical report is one which completely and thoroughly describes the problem statement,
background information, team organization, process used, data collection, analyses conducted, data anal-
ysis, and designs. As you write the report, you need to balance the standards for completeness and
thoroughness with the goal of brevity. Technical reports tend to be long documents, and writing as suc-
cinctly as possible is a virtue your readers will appreciate. An aid in brevity is remembering who your
audience is, technical professionals, and not going into details or repeating information your audience will
already know.

5 Critical Success Factors

This section describes critical success factors for teams to complete a capstone project. Many of the critical
success factors are team and project management skills because the success of a capstone oftentimes relies
to a great extent on the team’s ability to plan and execute a project.
1. Translating primitive needs into effective needs. The capstone project starts with a sponsor’s de-
scription of a problem, opportunity, or need. The description is often ambiguous, incomplete, or
insufficient to build a project upon. It is the student’s responsbility to analyze the primitive need
as stated by the sponsor and develop an effective need to guide the project. Too many capstone
projects fumble around wasting time trying to define the effective need and project deliverables.
2. A detailed proposal. The capstone proposal describes the problem, its significance, the project
objectives, work plan, schedule, team structure, and expected deliverables. A good plan in the
proposal aligns all team members because it articulates expectations for the work and schedule. The
other benefit of a proposal is to achieve buy-in from the advisors because they must approve the
proposal. The capstone proposal is an agreement between the student team and the SE department
that if the plan is executed and the deliverables meet department standards, then the students are
done.
3. Multiple iterations. Engineering design and writing are iterative processes. Student teams who
expect a single iteration risk missing the schedule when it goes through multiple iterations. Your
first draft of the report will not be the same as the last draft.

4
 4. Division of work. The student team needs to clearly define the work content of the project and assign
the work to students. The schedule should show the tasks at the student level. Individual team
members need to be responsibile for specific tasks and deliverables. Only in this way can a person be
held accountable for a work item. There are cases where a couple of students should be assigned to
a task because of its complexity and effort required, and the task cannot be decomposed rationally
into smaller subtasks. Common issues are incomplete understanding of the work, describing the
work at too high a level, or assigning work to several students.

5. Clear definition of project objective and deliverables. All the team members, the advisor, and the
sponsor should agree upon the project objective and deliverables. This is documented in the project
proposal. The definition of the objective should be specific and as precise as possible. Whenever
the project objective is not clear or the understanding of the objective differs between the team and
the advisor, then there is a lack of alignment between all the participants, which leads to problems.

6. Demonstrating mastery of systems engineering. The capstone project’s primary purpose is an

academic one – the demonstration of the student’s mastery of systems engineering. While a team
should not do an activity solely for the sake of including it in their project, when they do include
an activity, it should be done according SE Department standards of performance for content and
quality.

7. Brevity in technical writing is a virtue. The SE Department provides via the webpage a guide on
technical writing and making critical thinking visible. Review the guide.

8. Make recommendations. A capstone project usually addresses a problem or designs a system to

solve a problem. The capstone project should be making clear recommendations supported by the
analysis done in the project. Make it clear what the recommendations are and why.

6 Summary
This document described the content of the capstone project and provided guidance on factors to make it
a successful learning experience for the students. The capstone project in the SE Department is a major
portion of the curriculum spanning three quarters in the program. It is a team-based project to emulate
how engineer work in industry and government. Moreover, it is usually sponsored by someone in the Navy
or DoD who has an interest in the results and let’s the student team experience interacting with project
sponsors and stakeholders.
The capstone project report is archived in the library and DTIC, which means that soon after publica-
tion the major search engines find and index the reports for worldwide consumption. Your capstone work
becomes part of NPS’s large contribution to systems engineering knowledge and application in military
systems. Make it a good one.