Writing Project Specifications

Important Note – All Project Specs should be made from a copy of the template file found at the bottom of this page.

What is a Project Specification?

A project specification (shortened as “the spec”) is a tool / document used to communicate what the intended outcomes of a project are. The spec is methodical in it’s construction in that it carefully presents what each feature of a design will be how it will be quantified, and how many points execution of that feature will earn the engineer / maker. Project specifications are a tool created for the sake of systematically assessing broad open ended projects.

Why Write Project Specifications?

This scheme was originally created for the Open Source Hardware Enterprise – but I have since realized that with the advent of generative AI, projects should be the primary assessment tool in all classes. The spec allows students to formalize what they are doing for a project and communicate to a broad audience. This audience includes advisors, sponsors, and other students. Depending on the magnitude of the project, the spec may go through review from experienced students / advisors to best hone in the scope of the project.

Once a spec has been agreed upon, it exists as a sort-of contract between students and advisor, for which a significant portion of the project grade will be decided upon.

How to Write a Project Specification

The creation of a project spec should be carefully considered; reaching for the moon might leave you disappointed in the end, where not reaching far enough might invoke sharp criticism from your peers. The below sub-sections are intended to help create an ironclad spec that is sure to be successful, regardless of your skills as an engineer or maker.

Abstract

The abstract is a short paragraph that describes what the project is and what is unique about it. This paragraph should not exceed 250 words. It should also avoid acting as a redundancy to other information presented in the spec. This part of the spec communicates broadly the “spirit” of what you are setting out to do. It may be wise to also touch on the justification for your project. Uniqueness does not always need to be communicated and it depends on the open-endedness of the project. This will typically be communicated to you on a scale of Low to High

Open-Endedness Level	Description
Low	No uniqueness needs to be justified.
Medium	1-2 small elements or combinations of elements should be called out.
High	This project should have one substantial previously-unexplored approach specified.

Report on Current State

The Report on Current State is mainly intended for continuations of projects (perhaps multi-semester projects). This should be a concise description of what has been completed / achieved on the project thus far. It should not exceed 250 words. The point of this section is to inform reviewers of the foundation from which you are building. Obviously items listed in this section should not be listed amongst your specifications. This section is not always required.

Current State Required?	Description
No	Enter in “Not-Applicable”.
Yes	Review existing reports to derive and enter a concise synthesis of progress.

References

References are articles, books, or web pages that will provide substantial guidance in the implementation of this project. They may be existing implementations of a solution that are you drawing inspiration from, technical references, or how-to manuals that are providing key insights.

Selecting Specifications

The specifications are the real meat of this document. I recommend using various brainstorming methods to generate a list of features your project will require. Some of those won’t be features in a marketing sense or uniqueness sense, but rather important aspects that take effort to implement (IE Clean professional wiring).

Some brainstorming methods to consider are:

• Affinity Diagrams: Structured system for grouping specs or ideas based on their relationships
• Nominal Group Techniques: This structure for idea generation can help prevent some opinions from overshadowing other group members thoughts.
• The W6H Pattern: A method for formulating comprehensive questions to elicit detailed requirements.

For complex / group projects, I recommend setting up sub-systems (IE Mechanical, Electrical, Software, etc) and deriving all of the essential components for them.

The general rule – is the more complex the project, the more objectives should be selected. I will describe them using 3 terms.

Complexity Level	Description
Basic	Should have around 5 requirements
Intermediate	Should have around 10 requirements
Advanced	Should have more than 15 requirements

Writing Objectives

The first rule of writing objectives is to be precise in what you are doing – but do not prescribe how you will do it. If you list out specific methods, tools, or components that will be used, you are expected to use them. The only exclusion to this rule is if an objective of your project relies on a unique constraint that should be explicitly listed.

You also want to be sure that you aren’t selecting to large of objectives. If they are deemed too large – you should split them up into smaller objectives. The one caveat to this rule is if you are continuing a project from a previous semester that has several prerequisite objectives met.

Another key item to consider is the risk of the objective; is there a chance that you will not be able to achieve this goal by the due date? As you look at your goals consider which ones have the highest risk of failure, and consider how that goal can be pieced into smaller goals of which most are achievable, so the risky objective is left with a smaller portion of points.

In some cases, project objectives will be given to you in a project description. It is acceptable to extract them and include them in this specification.

Objectives should be 1 sentence each.

Here are some examples of bad objectives:

• The device will employ a NEMA 14 Stepper motor to move the cutting tool.
  • (This objective cites a specific form factor of motor, and if it’s moving a cutting tool it should prescribe some key traits like the max distance it should move, and mention the speed if relevant)
• The system will have safety protections.
  • (This is very non-specific. The protections that are desired should be listed out)
• The device will be able to detect and track 50 hostiles, plan a path to intersect each of them, and then carry out the required movements.
  • (This specification is too lofty in its promise. If one of these items aren’t achievable, then the entire objective is unmet. It should be split up into many smaller objectives)
• The system will be printed in red PLA.
  • (This specific objective is not a design challenge as printing with red PLA is pretty achievable with no effort)

Here are some examples of good objectives:

• The device will be capable of moving a cutting tool a distance of at least 10 cm.
• The system will detect if a user has opened the enclosure during operation, or if a user has disconnected a key sensor.
• The device will be able to identify a being as hostile reliably (80% accuracy or more).
• (There is no replacement for the red PLA objective above. However if you had to print with a complicated material like Ultem for strength reasons, that would be acceptable)

Writing Quantifications

A quantification should be attached to each objective. The quantification should call out an experiment or measurement that will be taken to demonstrate that the objective has been successfully met. If an objective is binary (IE detecting if a button is pressed) then its reliability should be the quantified aspect.

When writing quanitifications, ensure that you have the means to carry out the experiment. If not, then scale or adjust accordingly. Only as a last resort can visual observations be used for the sake of quantification.

It is possible that some requirements just aren’t quantifiable such as aesthetic attention. If those desired objectives, then this is a case where the text of the objective should be prescriptive in how the design will be made aesthetically pleasing, so then the grading can at least be performed against a set of requirements.

Quantification statements should be 1-2 sentences.

Here are some examples of good quantifications based off of the previous objectives listed:

• The cutting tools center point is capable of moving 10cm along a line.
• The system is able to detect all 50 enclosure openings or sensor disconnections in one test sequence.
• 100 hostile images will be shown that were not part of the training data, and at least 80 must be detected.

An example of a quanitification that is not exactly measurable might be:

• A user guide document will be created that indicates and demonstrates how the HMI works. All elements will be clearly explained and an example operation sequence will be given.
• The design will be free of sharp edges, printable without supports, have enterprise branding on it and will employ a cubism aesthetic.

Determining Ownership

For team projects, it is necessary to allocate out the tasks equitably. Consider each teammate’s current skill levels, interest, and time availability. If sub-systems have been defined, it is likely best to create corresponding sub-teams. All names should still be listed. The order of names implies the level of contribution expected.

*Note on Enterprise Capstone Students*

Specifically for enterprise projects, each objective should have a senior student as the most responsible member.

Assigning Points Values

The points value for each objective determines how much the completion will effect your grade. More complex objectives should be worth more points.

Though you can specify points via any system, I highly recommend using the calculator provided below that takes into account time estimates and complexity. For estimating time, reflect on previous projects you have done and consider the time that went into them, and set up as many comparisons as possible.

Here’s how the tool works:

1. Click “Add Objective” to create a new row.
2. For each objective:
   • Enter a brief description.
   • Estimate the time (in hours) it will take.
   • Choose a complexity rating from 1 (easy) to 5 (very difficult).
3. When you’re done, click “Calculate Points”. The tool will:
   • Calculate a raw weight using the formula: Time × Complexity
   • Normalize these weights so all your objectives add up to 100 points. Points are also rounded to the nearest integer by the “Largest Remainder Method”
4. You can also:
   • Import a CSV file with objectives (Description, Time, Complexity)
   • Export your completed objectives as a CSV for record-keeping

Make sure the point distribution reflects the effort and challenge of each part of your project.

Idle Goals

You can append objectives onto the specification that are referred to as "Idle Goals" These goals are not worth points but consider to be value added to the project. These goals should not be required for the project to work and should be able to be worked on at almost any point in the project. The idea behind these goals are to make sure there is always something to do, even if team members are waiting for another part of the project to be completed. Indicate their value as "Idle Goal" in the specification document.

Giving, Taking, and Applying Feedback

In some cases your project specification may be submitted for feedback, and a second revision will be expected. You may also be required to provide feedback on others specifications.

Giving Feedback

At the end of the project spec is an area to give feedback. Do not manually edit another teams spec. Consider each objective and ask the following questions of yourself.

• Is this objective meeting the spirit of the project as specified in their abstract?
• Is this objective required for this project to be functional?
• Has this objective already been completed in the Report on Current State?
• Is the objective too specific or broad?
• Is the quantification something that is measurable and achievable?
• Is the points value commensurate with your expectations?

List feedback for each objective in it's appropriate section. Make a new line for each comment. You do not need to comment on each objective.

Then, look at all of the specifications holistically and ask "Is there something missing?" If so, list that under general feedback.

Be sure to be professional and cordial when listing any feedback.

Taking & Applying Feedback

Quoting what needs to be done for a project, how complex it is, and how long it will take can be difficult - so the more eyes on an estimate, the better. With each piece of feedback ask yourself if it is valid or if the reviewer misunderstood something. I personally recommend erring on the side of the reviewer and applying their change or at least compromise.

I also implore criticism to not be taken personally, these are just students (or in some cases advisors) who are trying to make sure you are on a path for success.

How are Projects Graded That Come Out of This System?

It's pretty simple really. For each objective that you are able to demonstrate the quantification of, you will be awarded those points. Failure to do so will result in no points for that objective.

Typically the final product will be shown in some sort of physical presentation, video, or as a last resort, a report. In some cases (Tests that take a lot of time), the results summary can be shown.

For some assignments, additional time can be given after the primary assessment, but at a reduced point multiplier (IE 1 week after the assignment was due, you can only receive 75% of the max points for that objective). This "grace period" policy will be listed specifically for each assignment.

Files

• Project Spec Template (You may need to go to File > Make a Copy)
• Example Specification #1 (The project uniqueness level is Low, a Report on Current State is Not Required, and the Complexity Level is Basic.)
• Example Specification #2 (The project uniqueness level is High, a Report on Current State is Required, and the Complexity Level is High.)