Maintaining consistency between requirements and the design developed to satisfy them is both important and difficult. Maintaining consistency is important to satisfying stakeholders' desires, which the requirements express. Much of the difficulty of maintaining consistency stems from having redundant descriptions of requirements decisions-one in the requirements document and a second in the design document-typically recorded in widely divergent languages. To ameliorate this problem, we write requirements and design in such a way that requirements decisions and their expression in the requirements document are incorporated directly into the design document, which organizes the decisions and includes additionaldesign-decisions.

Standard Form 298 (Rev. 8-98)Prescribed by ANSI Std. Z39.18Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing this collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden to Department of Defense, Washington Headquarters Services, Directorate for Information Operations and Reports (0704-0188), 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to any penalty for failing to comply with a collection of information if it does not display a currently valid OMB control number. PLEASE DO NOT RETURN YOUR FORM TO THE ABOVE ADDRESS. 5a. CONTRACT NUMBER 5b. GRANT NUMBER 5c. PROGRAM ELEMENT NUMBER 5d. PROJECT NUMBER 5e. TASK NUMBER 5f. WORK UNIT NUMBER Approved for public release; distribution is unlimited. REPORT TYPE 1. REPORT DATE (DD-MM-YYYY) TITLE AND SUBTITLE AUTHOR(S) PERFORMING ORGANIZATION REPORT NUMBER PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) SPONSOR / MONITOR'S ACRONYM(S) 9. SPONSORING / MONITORING AGENCY NAME(S) AND ADDRESS(ES) SPONSOR / MONITOR'S REPORT NUMBER(S)12Unclassified Unclassified Unclassified UL James Kirby, Jr.(202) 767-3107 Software behavior Requirements documentationIt would be useful to write one description of software behavior to serve both requirements and design. Having one description could reduce effort by eliminating the work of developing two descriptions and of keeping them consistent throughout development and maintenance. It would also eliminate the inconsistency inherent in having two descriptions, a fertile source of error. A question paramount to software engineers is Could one description of behavior for a real system serve both requirements and design? The purpose of the present document is to answer that question by producing one such description of the software behavior of a real system. The specification presented here is based upon behavioral specifications extracted from function and abstract interface specifications developed by Paul Clements, Alan Parker, Kathryn Heninger Britton, David Parnas, John Shore, Stuart Faulk, Bruce Labaw, and David Weiss. 10-12-2007Memorandum Report 171 Dec. 2002 -Oct. 2007 Design documentation Behavioral specification 8089iii A previous paper [10] argued that it would be useful to write one description of required software behavior to serve both requirements and design. Having one description could reduce effort by eliminating the work of developing two descriptions and of keeping them consistent throughout development and maintenance. It could also eliminate the inconsistency inherent in having the two descriptions, a fertile source of error.In reference [10], software behavior is the changes over time...