### Functional and technological specification Put your specification in your *readme.md* in your gitlab.liu.se repo. Use [markdown](https://docs.gitlab.com/ee/user/markdown.html). **Submissions by email will not be considered.** Remember, the specification is not a contract - you can change any way you want after submission. After the deadline we will give you feedback. Comments will relate to scope and complexity, not so much functionality. Comments will be in the form of cautions and suggestions. Since you are free to make your own choice about technology, we do not and cannot know every detail **about** your tech, but we look for technical risks and realistic scope. Also, remember, our approval doesn't mean you have a contract to pass the course - examination is based on the end result. **Don't wait for our feedback, as a rule 99 out of 100 projects are acceptable. You should get started working right away.** #### Functional: Describe your project vision and core functions. Don't mention every little detail - this is for us to help you define a suitable scope. Compare to other projects on YouTube, search for TDDD27, to get inspiration. Make sure you match the **requirements** from the [**technical** and functional requirements](https://www.ida.liu.se/~TDDD27/project/index.en.shtml). #### Technological: Describe *client framework* and *server framework/backend setup*. *Making intelligent framework choices* is part of the course. Take some time to research your options. Also, frameworks have varying complexity. Angular is perhaps the most complicated and React the least out of the box (but with React you tend to end up adding parts). Choose something that fits your experience level, but also at a suitable level for the course. --- ### Project status seminar: Sign up will be announced on course web page news and using email. Students that have substantial progress now tend to finish and get good grades. You participate in a 2 hour workshop, the whole team present your project for about 10 minutes. **One person should book in webreg.** Live demonstration (or prerecorded screencast). Spend most of your time describing your current project so far and your experiences so far. Don't make long winded presentations about the project proposal when you have nothing to show. You should not go through every detail of the system. If your presentation is shorter than 10 minutes, no problem. **Seminars will run back-to-back so you must be prepared.** --- ### Individual oral code screen-cast: *Link **to** your screencasts in your readme-file on gitlab.liu.se in the main branch.* The screencasts should be published online somehow, on YouTube, OneDrive or Vimeo or some other place. The screencast should be visible for anyone with the link without password or specific access. This is so that we can also elicit others to help us in the review process. Every student will individually present the code and all system parts. You should show and speak in your own voice to explain. Add screencast picture-in-picture **recording**. **E-mails containing screencasts or links to screencasts **will NOT** be considered.** You can find a Wikipedia article on software for [screencasts here](http://en.wikipedia.org/wiki/List_of_screencasting_software) **For some students we may require a personal demonstration at IDA and we will in those cases email you on your student email. One reason may be that you have not presented anything substantial on the mid-course seminar. Also, we may not understand your project **completely**. Furthermore, there might be some uncertainty about your code/project.** --- ### Project Screencast: Link on your gitlab.liu.se repo. The screen cast should be published online somehow, on YouTube, OneDrive or Vimeo or some other place. *Put the link **to** your screencast in your readme-file on gitlab.liu.se.* The screen-cast should be visible for anyone with the link **without** password or specific access. This is so that we can also elicit others to help us in the review process. In your project screen cast you should present your web project. Use the keywords {TDDD27, LiU, projectname} in the title. Give a general overview *what you have done* but also present some technical challenges and *how you have solved them*. **E-mails containing screencasts or links to **screencasts** **will NOT** be considered.** You can find a Wikipedia article on software for [screen casts here](http://en.wikipedia.org/wiki/List_of_screencasting_software) --- ### Final source code hand-in: What's on gitlab.liu.se on the deadline is your hand-in. You don't have to do anything special. But remember we are coders that look **at** branches, commits, commit comments and so forth.