Sample body of Latex thesis

thesis-body.tex

\def\bibliocommand{\bibliography{IEEEabrv,../../bibtex/thesis-new}}
\def\bibliostyle{plainnat-nourl}
\def\mytitle{Software Evolution: a Requirements Engineering Approach}
\def\myauthor{Neil Alexander Ernst}
\input{ut-thesis-begin} % the preceding lines are directly converted from Scrivener Meta-Data.

\chapter{Introduction}
\label{introduction}

\section{Motivation}
\label{motivation}

Creating and maintaining software is a design activity ~\citep{Jarke2010}. The outcome of the design activity is a software program\footnote{As I use the term ``software'' in this thesis, it is aggregating many concepts: software ecosystems, service computing, Software As A Service, a Machine, cloud computing, etc. Regardless, the essential tripartite problem structure remains.} that ensures satisfaction of a set of requirements. The design activity can create a new piece of software, or more commonly, re-design existing software to adjust to changes. There are three elements to consider. The first is the properties that are assumed to hold in the domain and are exploited in designing the software---the \textbf{domain assumptions} under which the software will operate. Next, there is the desired set of new properties of that domain---the \textbf{requirements} the software must meet for its users to accept it. Finally, there is the detailed plan for creating the software---the \textbf{specification}. These three elements are related: if the software is developed according to the specification, taking into account the domain assumptions, it will satisfy the requirements. 

Challenges arise when these elements change. For example, the users of the software might decide they have a new requirement that is vital to their continued acceptance and use of the software. The specification might need revision to accommodate new understanding of implementation costs. Finally, the assumptions we made about the operating domain, such as the legal obligations the software bears for user privacy, might be invalidated by new legislation. It is important to note that the creators and maintainers of the software cannot always anticipate these changes. If they were anticipated, then the specification would have been designed to accommodate them. 


\begin{figure*}
   \centering
  \includegraphics[width=3in]{figures/re-triangle}
  \caption{The relationship between requirements, specification, and the domain}
   \label{fig:rekb-triangle}
\end{figure*}


REFSQ We intend to do further testing to explore how communities conceptualize these fairly abstract `-ilities'. We think `ground-truthing' our results with qualitative studies would be useful to make our results inform a theory about quality in software, such that techniques could be predictive as well as descriptive.

\input{ut-thesis-end}

\end{document}