Our team chose a feasibility report as a genre to study, model, and produce for writing project 2. Our initial access to a sample was through our group member Seth who had written a feasibility report for a previous class. After reading and analyzing his report, we looked for other example reports on the internet. We found about five other examples of feasibility reports produced by various universities and companies that appeared to be fitting examples off of which to base our studies. Documents published by a university or reputable company will generally be credible and of good value. Some of these sources gave guidelines and templates for writing feasibility reports. These aided our understanding of the actual samples we found.
In order to study the situation that a feasibility report addresses, we mostly referred to Seth, who had created a report before, along with the previously collected samples. Through studying samples, we found that feasibility reports are generally published or produced by a company or university attempting to validate or invalidate the need for the proposed product or action. These documents can be produced and read internally within an organization to decide whether a project is feasible, or they can be read by an outside party who will decide for themselves whether or not the idea or product will work. It was possible for us to access the scene of actually writing one of these reports by interviewing our group member Seth. We also were able to contact one of Seth’s professors about his experience reading these reports. In this way, we came to understand how different viewpoints interact with the same genre.
From our studies, we were able to identify the structural, rhetorical, and lexical features of a feasibility report. Structurally, most reports were written in a similar format. They contained an overall abstract or summary of what topic the paper was examining. The paper then moved into the requirements of the paper’s topic followed by the actual examination of the feasibility of different areas of the topic. Some of these areas included economic, environmental, and technical feasibility. These feasibility sections were then followed by a conclusion which provided the author’s opinion on whether or not the project would be viable given the examined factors. Rhetorically, the reports strongly appealed to logos as well as a more mild appeal to ethos. The reports contained many facts, data, and charts which provided logical arguments to the reader as to why the project may or may not be feasible. The appeal to ethos was provided by the company or university’s reputation. A highly regarded university producing a paper allows the reader to believe that the information is credible. The lexical features of the reports generally contained a lot of discipline specific language with declarative sentences that provided the facts found through the research done for the report.
We found that feasibility reports reveal quite a bit about the rhetorical situation that they address. The reports are always logic based. They do not deal with emotional responses to a situation, but rather provide factual information by which a logical decision can be made. It shows that in general, most decisions being made in engineering fields are made because of factual evidence pointing to the correct solution. Engineer’s emotions or personal preferences will usually not overpower facts laid out showing a better path to the solution.
The elements and attributes that we generated were all produced directly from the analysis that we did. The overall structure of the report provided a large number of elements for us. For example, each major section of the report was designated as its own element, such as the table of contents, executive summary, and feasibility sections. There were also attributes that we added based on topics discussed in each section. In the feasibility elements, there were attributes available to accurately describe the topic of feasibility such as technical, economic, and environmental feasibility. Some of the decisions that we had to make regarding our analysis were whether certain elements or attributes could be optional or required. Overall we included the same elements that were in our samples. However, we omitted a detailed project schedule since our time is limited.
Our group noticed that there was a larger variance in included sections. We believed that this is dictated by many factors, including the sources of funding, the actual medium of the project (physical or digital), and the potential impacts. We designed our genre model to allow for a flexibility with what to include and what to leave out, enabling our genre model to cover studies about building a dam, and building a web app equally well. For the sake of our projects and condensing the format slightly, we included less in depth versions of timelines and financial reports.
Update: After the first draft of P2, our group came to a few realizations. Firstly, while our schema allowed for carefully outlined and segmented ideas, we were missing the ability to create titles in certain places. This occurred primarily under success criteria and the preliminary requirements analysis. We also felt constrained without having the ability to include multiple requirements sections under the success criteria page. These two changes will allow us to better express our different ideas and bolden the section headings, increasing the readability of our document. We had to create an image account for our group to upload design images. This way we could refrain from cluttering the class repository with the documentation images. Lastly we added a global <ref> element that can be included on any page. This element allows us to include outside sources and cite them. This is not something we brainstormed during the development phase, but it proved necessary once we started our personal projects.
