%% bare_jrnl.tex
%% V1.4
%% 2012/12/27
%% by <NAME>
%% see http://www.michaelshell.org/
%% for current contact information.
%%
%% updated by <NAME>
%% trevortomesh.github.io
%% 2019/01/16
%% <EMAIL>


\documentclass[journal]{IEEEtran}


% *** GRAPHICS RELATED PACKAGES ***
%
\ifCLASSINFOpdf
  % \usepackage[pdftex]{graphicx}
  % declare the path(s) where your graphic files are
  % \graphicspath{{../pdf/}{../jpeg/}}
  % and their extensions so you won't have to specify these with
  % every instance of \includegraphics
  % \DeclareGraphicsExtensions{.pdf,.jpeg,.png}
\else
  % or other class option (dvipsone, dvipdf, if not using dvips). graphicx
  % will default to the driver specified in the system graphics.cfg if no
  % driver is specified.
  % \usepackage[dvips]{graphicx}
  % declare the path(s) where your graphic files are
  % \graphicspath{{../eps/}}
  % and their extensions so you won't have to specify these with
  % every instance of \includegraphics
  % \DeclareGraphicsExtensions{.eps}
\fi



% *** Do not adjust lengths that control margins, column widths, etc. ***
% *** Do not use packages that alter fonts (such as pslatex).         ***
% There should be no need to do such things with IEEEtran.cls V1.6 and later.
% (Unless specifically asked to do so by the journal or conference you plan
% to submit to, of course. )


% correct bad hyphenation here
\hyphenation{op-tical net-works semi-conduc-tor}


\begin{document}

% paper title
% can use linebreaks \\ within to get better formatting as desired
% Do not put math or special symbols in the title.

\title{Writing a Design Report for Interactive Hardware and Embedded Computing}


\author{Trevor~Tomesh,~\IEEEmembership{Sessional Lecturer,~University~of~Regina}
        %other authors go below
        %Bob~Builder,~\IEEEmembership{Student,~University~of~Regina,}
        %and~Noob~McScrubb,~\IEEEmembership{Student,~University~of~Regina}
        }


% The paper headers
% This should either be the name of the journal or the 
% first four(ish) words of the paper
\markboth{Writing a Design Report, Feb~1st~2019}%
{Shell \MakeLowercase{\textit{et al.}}: Design, Template, Computer Science }
% The only time the second header will appear is for the odd numbered pages
% after the title page when using the twoside option.


% make the title area
\maketitle

% As a general rule, do not put math, special symbols or citations
% in the abstract or keywords.
\begin{abstract}
  A design report is an essential artefact that serves as comprehensive 
  documentation of a project / design. It is important to document a design
  thoroughly, especially if you have been commissioned to do a project. The 
  abstract is a quick description of what the design problem is and how the 
  proposed solution solves the design problem. It should be brief and easy 
  to read with very little jargon or presupposition of prior knowledge of the
  design problem. 

\end{abstract}

% Note that keywords are not normally used for peerreview papers.
\begin{IEEEkeywords}
design, report, computer science, CS 807
\end{IEEEkeywords}



% For peer review papers, you can put extra information on the cover
% page as needed:
% \ifCLASSOPTIONpeerreview
% \begin{center} \bfseries EDICS Category: 3-BBND \end{center}
% \fi
%
% For peerreview papers, this IEEEtran command inserts a page break and
% creates the second title. It will be ignored for other modes.
\IEEEpeerreviewmaketitle



\section{Introduction}

% Some journals put the first two words in caps:
% \IEEEPARstart{T}{his demo} file is ....
% 
% Here we have the typical use of a "T" for an initial drop letter
% and "HIS" in caps to complete the first word.
\IEEEPARstart{T}{he} introduction provides any background to the design problem that may be necessary for 
a reader to understand the design problem in the first place. It may not be required if the design problem
can be explained easily without any background information -- but this is unlikely. Again, avoid using 
jargon and acronyms without defining them (this would actually be the optimal time to do so if 
absolutely necessary). 
% You must have at least 2 lines in the paragraph with the drop letter
% (should never be an issue)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Problem Definition}
The problem definition is your understanding of the problem. This is sometimes given to you by the person
who commissioned you. Often, a client will not know what they want / may give you conflicting or confusing 
goals. It is up to you to articulate clearly and concisely what the problem is \textit{as you understand it}.
Simply copying and pasting something that was given to you by the client is not enough. The worst case 
scenario is that you will misunderstand the problem and thus provide an inadequate design. Generally, 
the client will clarify for you the problem before this happens. 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Design Description}

\subsection{Overview}
Once you've come up with your design solution, this is where you will describe it in brief. Give a 
summary of the design and how it works, but do not go into too much detail. A surface-level description
is all that is required in the overview. Include a drawing (or CAD mock-up) of your solution that shows 
all the essential components, but no pictures; a picture gives too much detail and you are only trying 
to convey the most important design decisions at this point. 

\subsection{Detailed Description}
This section is where you will discuss your design in high resolution detail. Give block diagrams, sketches, 
CAD and schematics here as well as a detailed description of how the device fits together and how it solves
the problem. 

\subsection{Use}
This section is a user-manual of sorts. Describe how a user might work with your solution to achieve the goal
outlined in the design problem. This section does not need to be particularly long, but it should be very 
specific in the intended utilization of the design solution.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Evaluation}

\subsection{Overview}
The evaluation section is where you detail the evidence for your design solution. The overview summarizes the 
approach that you took in your evaluation. The overview should discuss, in brief, what sort of methods were
used to test the solution. Did you make a number of prototypes and choose the best one? Did you do a 
series of prototypes that built on the failures of the previous designs? Did you run some sort of a simulation?
Did you have a focus group? These details should go here. 

\subsection{Prototype}
This is an overview of the prototype in the form that it was tested. Here you should highlight the features of
the prototype and discuss parts that may differ from a final solution. You may feature a picture here, but reserve
the detailed pictures (different angles, etc.) for the appendix. 

\subsection{Testing and Results}
Detail how you tested the device against the requirements outlined in the problem definition. You do not 
need to state how the solution stood up to these tests -- this is merely a discussion of the tests themselves 
and a justification for the design of said tests. 

\subsection{Assessment}
Once the tests have been performed, give an honest assessment of how your solution held up in the face of 
those tests. Did it break? Was it completely functional? What were the strengths and weaknesses? Perhaps 
the design is a good solution for a different use-case than what you've envisioned?

\subsection{Next Steps}
Now that you have a design that has been described in detail and evaluated, what are the next steps to move
the project forward? Perhaps this is the end product. Perhaps there are some improvements that can be done
and a new prototype can be built. It is very likely that you won't actually revisit this design in the future
so it is very important that you give a detailed description of what needs to be done next so that someone
who picks up your project down the line might be able to have an idea of where to start. 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Conclusion}
Here's where you sum-up what you designed, why you designed it, how it was tested and whether it worked. Keep
it brief. This is a reminder to the reader of what the original goal was and it serves to bring the whole 
project into focus. 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\appendices
\section{Diagrams and Pictures}
Any extra diagrams and pictures go here.
% you can choose not to have a title for an appendix
% if you want by leaving the argument blank
\section{Source Code}
The source code that YOU WROTE goes here. If you didn't use your own code, you need to reference that fact 
in the design description. 


% Can use something like this to put references on a page
% by themselves when using endfloat and the captionsoff option.
\ifCLASSOPTIONcaptionsoff
  \newpage
\fi

% references section

% can use a bibliography generated by BibTeX as a .bbl file
% BibTeX documentation can be easily obtained at:
% http://www.ctan.org/tex-archive/biblio/bibtex/contrib/doc/
% The IEEEtran BibTeX style support page is at:
% http://www.michaelshell.org/tex/ieeetran/bibtex/
%\bibliographystyle{IEEEtran}
% argument is your BibTeX string definitions and bibliography database(s)
%\bibliography{IEEEabrv,../bib/paper}
%
% <OR> manually copy in the resultant .bbl file
% set second argument of \begin to the number of references
% (used to reserve space for the reference number labels box)
\begin{thebibliography}{1}

\bibitem{IEEEhowto:kopka}
H.~Kopka and <NAME>, \emph{A Guide to \LaTeX}, 3rd~ed.\hskip 1em plus
  0.5em minus 0.4em\relax Harlow, England: Addison-Wesley, 1999.

\end{thebibliography}


% that's all folks
\end{document}


