Welcome to MRSI: The MILCON Requirements, Standardization, and Integration home page presents Military Construction policy, regulations, standards, and designs in order to provide the facility community with the tools they need to build and maintain the Army's vast facility infrastructure.
This site is part of research initiatives conducted at the Construction Engineering Research Laboratory (CERL), the Illinois site of the Engineer Research and Development Center. Partnering with federal and industry organizations, our mission is to enhance the proficiency and productivity of the Corps’ construction community for planning, design, and execution of the Corps’ facility acquisition process: we do this by providing tools and curated information for this community. This site and the tools provided herein are part of that research, as lessons learned from interacting with the community are incorporated into future tools and research programs.
Document Generation
Our current document generation tool is the modern, web-based MRSI Wizard, which is the third generation of our Wizard concept. We have created a unified wizard tool, based on a current web software development stack that can produce disparate document types with a WYSIWYG user interface, while maintaining the capability to support agency-specific requirements. Prior experience led us to conclude that most of the documents we were being asked to help produce had two common elements: a template that defined the format of the standard document and delineated what type of document would be produced (i.e., would it be the next great American novel or a fast food window receipt?) which was mostly boilerplate, but with sections of it being variable text dictated by the specifics of the project gathered as user input. The term varitext was coined to represent this second element and research commenced on how to use this insight to meet the goals for the new tool.The result of this research was varitext objects embedded within the templates that allow us to encapsulate everything about that portion of the document within them: the prompt the user is presented to request the needed input, how it is presented, what is done with the user’s response, and how the document is modified based on said input. By treating the non-boilerplate portions of the document as varitext, we can update our documents over time as requirements change without having to change source code. This makes not only updates in existing modules faster, less error-prone, and more secure but also means new modules/programs for additional document types can be deployed much faster than was previously possible.