There is an additional Technical section which I won't post because it goes into details of how things operate in the background. It describes the actual processing steps, db calls, validation, decisions, db table diagrams, etc that will occur behind the scenes as a user moves from page to page.
Structure Change Calculator
This document describes a functional specification - how a product will work entirely from the user's perspective. It talks about features. It specifies screens, menus, dialogs, and so on.
This document includes a section called Technical Notes, which contains additional details of a more technical nature (data structures, data models, choice of programming languages and tools, algorithms, etc.). A non-technical reader can safely skip the Technical Notes section.
The Structure Change Calculator (SCC) is an application that allows users to enter data about their farming operations to help them determine if they will be in a structure change position for the current processing year.
The SCC takes a “wizard” type approach in walking the user through the process of calculating their structure change position.
This spec is not complete or final. It is expected that this specification will grow and change with the nature of the application.
There are no non-goals to mention at this time
The interfaces of the SCC will be a series of wizard pages the user steps through to add financial information about their farming operations before seeing a final result page.
The following display interfaces have been identified:
The following input interfaces have been identified:
The SCC contains several interfaces as outlined above.
This is the starting point of the SCC. The user will see an introduction page here and links to wizpage1 and scchelp.
The user will see a form that allows them to choose a province from a drop down list box (DDLB). The user will also see a “next” button to proceed to the next page.
This page is displayed only if the province selected in wizpage1 contains municipalities. If the province selected does not have municipalities, the user proceeds directly to wizpage3. If it does have municipalities, the user is asked to select one from a DDLB. The user can navigate from here via “next” and “previous” buttons.
The user will be presented with several inputs on this page. The user must enter previous year margin history for between 3 and 5 years. They must also choose whether or not this is a non-calendar year-end operation. Finally they must also enter a percentage of ownership of this operation.
The rest of the page is optional to fill out depending on the user’s operations. The rest of this page deals with crop information. There are several rows of “static” crops that are so common they are already shown on the page, and there is a DDLB from which the user can select less common crops. The user can enter 5 years of data for each crop type.
The user can navigate from here via “next”, “previous”, and “add row” buttons. The “add row” button will add a new blank DDLB crop row for the user to add additional crops as long as there is no blank one that has not had data entered into it. The “previous” button is displayed only if the user has not entered more than one operation, otherwise the user can no longer modify the information relevant to the location of the operation.
Once the entry of a second operation (see wizpage4 for more details) has started, an additional DDLB menu appears at the top of the page to allow the user to navigate to any of the previously entered operations to modify their data. When the user jumps to another operation to modify the data, they are always taken to wizpage3 to start navigating from there.
The use can enter livestock data on this page. It is the same layout as wizpage3, but without the previous margin history, non-calendar selection, and percentage ownership (they are only needed once per operation).
There are several rows of “static” livestock that are so common they are always shown. There is also a DDLB where the use can select less common livestock. The user can enter up to 5 years of data for each livestock item.
The use can navigate via, “previous”, “add row”, “add operation”, and “calculate” buttons. The “add row” button will add a new, blank, DDLB livestock row for the user to add additional livestock types as long as there are currently no blank DDLB rows on the page. The “add operation” button will take the user back to wizpage3 so the user can add data for a second operation. The “calculate” button takes the user to the last page of the calculator to view the final results of the structure change calculation.
If the user is navigating back to this page after having entered more than one operation’s worth of data, an additional DDLB menu appears at the top of the page to allow the user to navigate to any of the previously entered operations to modify their data. When the user jumps to another operation to modify the data, they are always taken to wizpage3 to start navigating from there.
The wizpage5 interface is where the final results of all the calculations are displayed. All the data previously entered by the user is used to calculate the final results to be displayed here.
The user can navigate via “previous”, and “start over” buttons. The “start over” button will clear all results and take the user back to wizpage1 to enter all new data.
The help interface is accessed in one of two ways. If the user browses to the full help listing (scc.help) all the help topics are shown on one page. If the user clicks a help icon while using the calculator they are shown a pop-up window that contains help information relevant to the topic the icon was next to.
The back-end flow of the SCC differs lightly from what it appears to be in the interface descriptions above.
Between each page change (i.e. from wizpage1 to wizpage2) the processing is actually routed through a validate fuse that does data validation every time the user clicks a navigation button that is not labeled as “previous” (no need to validate going backwards…only moving forward). The validate fuse controls all the flow by running validation checks, and then setting which page to redirect to based on the outcome of user selections, and data input.
Each of the interfaces listed above will be covered in detail here, and additionally a section for the validate fuse will be included.
Because the framework used for this application is Fusebox, there are certain processes that will take place on every page load, and do not need to be explained in each interface description. These include establishing a database connection, starting the session, setting the language variable for correct display of information, setting up the main template for the site, and basic Fusebox initialization.
From a programmatic standpoint, there is not much happening on this page of a dynamic nature (beyond language file includes). When the main interface is invoked several actions occur at the server:
1) A function called is made to display a demonstration help icon.
2) A module call is made to the help fuseaction to get some help content that needs to be displayed on the main page
The content is rendered for display.