Design Document
As with the requirements documents, some settings may require a very formal design document. The goal of our document is to encourage planning and to share some aspects of your design with your advisor. Your document should include:
- A list of technical design issues your team is experiencing, if any. The goal is to inform your "boss" (advisor) of any issues so there are no surprises. In the requirements document you identified potential risks. The issues you would report here are items that have actually become a problem. For example, one field session team struggled for 2 weeks to get an Nginx web server running (and finally had to switch to Apache). Another team tried to use Kivy and then Xamarin to do cross platform development. Neither were successful, and they finally ended up just creating an Android app. In a homework assignment the instructor typically ensures the approach is feasible (at least for most undergrad courses). This may not be the case with real projects... so it's important to keep your advisor informed and be prepared to take a different approach if needed.
- One or two images that represent the design of your system. See examples below. NOTE: create more images if appropriate. You'll need at least two for your final report.
Depending on your project, your design might consist of an architecture diagram, UML diagrams, database schema, flowcharts, finite state automata, wireframes (screen layouts) or other relevant figures:
- Architecture diagram, mobile app + website
- Architecture diagram, networking system
- Architecture diagram, database + reporting system
- Architecture diagram, sensor networks
- WSN architecture
- Data flow, database + reporting system
- Process flow, sensor networks
- Finite State Automata
- Data packet design
- Database design
- UML diagram
- Application workflow
- Game storyboard
- Mobile app wireframes
- Math equations
Even more: https://herbertograca.com/2019/08/12/documenting-software-architecture/
