> For the complete documentation index, see [llms.txt](https://x.ancorasir.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://x.ancorasir.com/me303-311/2020-autumn/project-work/design-need-report.md).

# Design Need Report

### Overview <a href="#overview" id="overview"></a>

The Design Need Report is a standalone, formal documentation of the machine design project that summarizes the background information of the design translates the client’s need into engineering specifications that the machine needs to satisfy an alpha prototype, paving ways towards a final product of engineering.

* A template is provided here, which should cover the sections explained the [guidelines](https://x.ancorasir.com/me303-311/2020-autumn/project-work/design-need-report#guidelines).
  * Refer to your Feishu shared folder to edit the password-protected version, accessible only by all members of your team.
* The link to submission is here.
  * The deadline for submission is on [Saturday noon on Week 07](https://maindl.ancorasir.com/?page_id=929).
  * The review will be released [the week after](https://x.ancorasir.com/me303-311/2020-autumn/weekly-teaching/syllabus#week-08-design-need-review).

The Design Engineer is mainly in charge of the submission of the [Design Need Report](https://x.ancorasir.com/me303-311/2020-autumn/project-work/design-need-report) on behalf of the task force, but all members of the task force shall be involved or consulted while preparing the report, and it is the Design Engineer’s job to properly allocate any necessary sub-tasks to the rest of the task force towards a working report submission.

It should be noted that it is rarely the case that the first design will work perfectly towards the alpha prototype. Therefore, it is critical for the design engineer to keep refining the engineering design during the process by listening to the feedback from the task force and the team, making informed decisions on the necessary changes to the engineering design, and making sure that the design needs are still being met throughout the process.

### Guidelines <a href="#guidelines" id="guidelines"></a>

A template is provided in your task force’s shared Feishu folder as a Feishu Doc, which can be simultaneously edited by all members on the browser as a collaborative effort. Don’t worry about making changes to the document, as you can access historical versions of the final while preparing it.

* General:
  * Report Name: Design Need Report by \[Red/Green/Blue/Yellow] \[Apple/Banana/Cherry] on \[Machine Type]
  * Task Force Members: @ all members of the task force
  * Submitted by: @ Design Engineer
  * Reviewed by: @ Feasibility Engineer @ Test Engineer
  * Date & Version: YY-MM-DD-V1.0
  * \[Proper use of document style is highly recommended to stay the file organized.]
  * \[Use the build-in Print function of Feishu Doc to save it as PDFs before making the submission.]
* Report Overview
  * Briefly explain how this task is originated \[who proposed the design need in what scenario?]
  * Briefly explain how you understand the design need \[what is your task force’s opinion on this design need?]
  * Briefly summarize the key outcomes of this report \[what you have achieved in this report?]
* From Need to Specifications
  * Briefly summarize the engineering need for this design task \[what does the client want with the design?]
  * Explain in detail your translated machine specifications of the design \[all key metrics that define the engineering need?]
  * It is highly recommended to prepare key results of this section in tables, numbers, units, or any specifications necessary.
* Design Proposals
  * Summarize the challenges of the design and your team’s design strategy \[how your task force understand the task towards a solution]
  * Design proposal 1 \[required, through kinematic diagrams, estimated calculations, analyze how this design may solve the challenge]
  * Design proposal 2 \[required, through kinematic diagrams, estimated calculations, analyze how this design may solve the challenge]
  * Design proposal 3 \[add if necessary]
* Engineering Drawings
  * Provide screenshots of the CAD drawings of the machine design that may be realized \[materialize your design concept into feasible understanding]
  * Proper notations shall be added with matching terminologies and dimensions in the design proposal \[help feasibility engineer and others to understand]
  * Your task force should already have a conceptual design in CAD that MAY satisfies the engineering specifications \[totally ok if you are not fully sure yet]
  * The drawings should correspond to Design Proposal 1 directly, and if necessary, you can add drawings for Design Proposal 2 as backup designs.
  * Indicate the Feishu folder where the CAD files are stored, and add all notes necessary when using these files.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://x.ancorasir.com/me303-311/2020-autumn/project-work/design-need-report.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.