Laserfiche WebLink
<br />'. ,'~ <br /> <br />Functional Specification for the Planning Model <br /> <br />factors, The qualification upon this objective is necessary since the capability is not essential <br />to successful use of the model and since the feasibility of this feature will depend upon <br />implementation decisions. Therefore, this functionality is recognized as an objective which can <br />be considered during the programming design phase, subject to feasibility and budget <br />considerations and subject to guidance from the steering committee on relative priorities. <br /> <br />Sopport for Defining and Documenting Scenarios <br /> <br />The collection of capabilities and features which support a user's activities up to the <br />point of running a new scenario are informally referred to as the model's "front end," The <br />process of specifying new conditions or modifying assumptions for a scenario is complex and <br />error-prone, At the same time, these activities are an essential part of doing any useful work <br />with the model. Consequently, the usability of the model will dep~nd first and foremost upon <br />the: confidence and ease with which users are able to perform the tasks associated with defining <br />a scenario, The user interface features which support this activity are, therefore, of the highest <br />priority in the design of the user interface,. . <br /> <br />These activities fall into three or, possibly, Jour categories, First, there are some <br />planning options which will not be included in the Baseline conditions, but which, because of <br />their importance and complexity, will be pre-defined components of the model. Examples of <br />such options would be the alternative methods of exercising the Gunnison Tunnel's irrigation <br />decree and the addition of a minimum instream flow right for the Black Canyon. The user <br />activity corresponding to these options will consist of selecting the set of pre-defined options <br />anej components to be included in a given scenario, <br /> <br />Second, there are modifications to the Baseline which can be made by changing <br />parameter values of defined components. Users will be able to specify such modifications <br />either by direct, interactive data entry using on.screen dialog boxes with a combination of <br />standard mouse and keyboard techniques or by naming a data file. An example of such <br />parameter modification would be varying the target amounts for the instream flows below. the <br />Re4lands head gate, It is important to recognize that the great majority of the planning studies <br />for! which the model is intended to be used can be accomplished using only these first two <br />types of activity in specifying a new scenario. <br /> <br />The third category of user activity for specifying a new scenario is the most error-prone <br />and the most difficult to support. This category consists of making modifications to the <br />Baseline conditions which require the user to define new components, such as reservoirs and <br />diversions, within the network. The most likely examples of scenarios requiring such activity <br />would include the addition of a hypothetical demand, the addition of a hypothetical reservoir, <br />and the spatial disaggregation of a stream reach involving the splittiqg of existing demands <br />anej/or inflows and the insertion of additional stream reach segments. <br /> <br />. The possible fourth category of modifications to Baseline assuJllptions involves changing <br />the order in which different steps are executed when the model computes the allocation of <br />water at each time step. The incorporation of this feamre into the model is subject to <br />determination of feasibility and desirability during the programming specification phase of the <br />project (it is not clear at this time whether it is necessary to modify the order of solution <br />steps), From the user's perspective, this activity would probably appear identical to the first <br />category, where the user is able to select pre-defined options to be included within a scenario. <br /> <br />Overall Interface Layout and Style of Interaction <br /> <br />During the Needs Analysis, it was decided to. follow Common User Access (CUA) <br />guidelines in designing the layout of the graphical user interface for the Planning Model. This <br />is a sound policy which seeks to leverage the familiarity which many users will have with <br /> <br />18 <br /> <br />e <br /> <br />. <br /> <br />e <br />