Submission (ENG)

A product requirements document (PRD) is a document containing all the requirements for a certain product. It is written to allow people to understand what a product should do. A PRD should, however, generally avoid anticipating or defining how the product will do it in order to later allow interface designers and engineers to use their expertise to provide the optimal solution to the requirements.

It is in Markdown, because that is what developers are familiar with and also compatible with GitHub and many IDEs.

It is in A4 IEEE Conference Paper Format, because that is what technical whitepapers are usually formatted in for academic publications.

Anything you like! Can you screen capture or talking heads or both. Whatever tells the adjudicator about the essence of your project.

Other than adhering to the format of the chapter headings convention — e.g. 1. for section one, 1.1 for the first subsection of section one, and 1.1.1 for the first subsubsection of the first subsection of section one — you may use any formatting as you like, as well as any naming or organizational structure as you like. But the document must be in Markdown.

You will not be disqualified for using AI as long as it does not infringe copyright. Please properly attribute all sources to avoid issues with copyright.

Having real data would make life easier, but quality data sets are usually hard to access or unavailable. If you use simulated data set, make note of it in your submission material.

It should be able to demonstrate the use cases you envisioned.

It can be anything to demo the use case you envisioned.

No. It is optional, but it is useful as supporting material and something you can use in your future academic and/or professional career.

The page limit of the main whitepaper forces teams to be very clear and concise with their information transmission. However, there are no limits to the length of supplementary Annex(es).

The chapter headings may be anything! Below are the Level 1 Chapter Headings used by previous IDSOL Whitepapers. As you can see, they are similar, but they fit the project's nature (which is inherently different), telling the story they want to tell in the way they want it to be told.

3 Chapters

1. Background

2. Solution

3. Next Steps

4 Chapters

1. Introduction

2. Related Work

3. Proposed Solution

4. Conclusion

5 Chapters

1. Problem Space

2. States-of-the-Art

3. Solution Overview

4. Solution Design

5. Challenges

6 Chapters

1. Orientation

2. Situation

3. Mission

4. Execution

5. Administration

6. Coordination

7 Chapters

1. Problem Statement

2. Vision

3. Use Case and Existing Solutions

4. Risks and Challenges

5. Architecture and Infrastructure

6. Distribution and Continuation

8 Chapters

1. Introduction

2. Problem Statement

3. Competitive Overview

4. Solution Overview

5. Solution Design

6. Impact, Governance, Scalability

7. Challenges and Future Plans

8. Conclusions

9 Chapters

1. Introduction

2. Problem Statement

3. Solution Architecture

4. Operations

5. Value Proposition

6. Features, Benefits, Impact

7. Competitive Analysis

8. Success Factors and Mitigated Risks

9. Conclusion