Click for next page ( 20


The National Academies | 500 Fifth St. N.W. | Washington, D.C. 20001
Copyright © National Academy of Sciences. All rights reserved.
Terms of Use and Privacy Statement



Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.

OCR for page 19
Assessing Your Requirements 19 Establishing Requirements You will want to enumerate the requirements for your system before you start the design. These requirements encompass how you want the system to operate, what you want to accomplish with the system, who will have access, and what functions are essential to performing your business. If you will be contracting the system development, it is important to include this information in your request for bids. Operational considerations include the following: Internet/intranet-based system or desktop client-server application Remote access and user management Public access Management of data input, use, and output Inclusion of business rules and decision support modules Geospatial tracking Geospatial decision support Document management Examples of what you might want to accomplish could include the following: Streamlining your business activities Managing staff and contractors Improving your ability to balance workloads Near real-time monitoring of the status of different aspects of the process Automatic reporting to upper management and FHWA Improving your response to owners and persons being relocated Improving your auditing structure Improving data quality and reducing redundancy Use Cases To be embraced, the system must serve users for the activities that those users need to accomplish. Each of these different interactions with the system is referred to as a use case. In addition to ensuring that the system provides the necessary functionality, use cases are important in developing the interface design, or GUI, especially procedures for navigating around the system. Use cases are also important for testing the software to ensure that it performs the way the user expects it to. Another purpose for use cases can be to set priorities for software development by focusing on use cases that would provide the greatest net value. Table 5 summarizes use cases that were identified as part of the 8-55A logical model. Business Processes Requirements for the functionality of the system are initially captured when defining the business processes that are necessary to do the business of the right-of-way office. These requirements are then used to build the computer-based UML structure, which is then used to actually write code. The business process diagrams for the 8-55A logical model were extracted from the Project Development Guide (FHWA 2009) and are included in Appendix B. Appendix B explains how to use these diagrams to customize the model to your needs. Table 6 summarizes the high-level business process functions used in the 8-55A logical model.