E. M. Gray and R. H. Thayer, "Requirements," in Aerospace Software Engineering, A Collection of Concepts. Ed. C. Anderson and M. Dorfman. Washington: AIAA, 1991, pp. 89--121.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....and the software inputs (e.g. monitor data) are also specified. Similarly, specifying the interfaces especially the timing and dependency relationships between the software outputs (e.g. star identification) and system outputs (e.g. closing the shutter on the star scanner) is necessary. [6, 11] System development issues such as timing (real time activities, interrupt handling, frequency of sensor data) hardware capabilities and limitations (storage capacity, power transients, noise characteristics) communication links (buffer and interface formats) and the expected operating ....

....parts of the system (maximum transfer rate, consequences of race conditions or cycle slippage) The capability to describe dynamic events, the timing of process interactions in distinct computers, decentralized supervisory functions, etc. should be 10 considered in chooosing a formal method [3, 5, 6, 15, 21, 24]. 4. Promote informal communication among teams. Many safety related software errors resulted from one individual or team misunderstanding a requirement or not knowing a fact about the system that member(s) of another development team knew. The goal is to be able to modularize responsibility in ....

E. M. Gray and R. H. Thayer, "Requirements," in Aerospace Software Engineering, A Collection of Concepts. Ed. C. Anderson and M. Dorfman. Washington: AIAA, 1991, pp. 89--121.

....and the software inputs (e.g. monitor data) are also specified. Similarly, specifying the interfaces especially the timing and dependency relationships between the software outputs (e.g. star identification) and system outputs (e.g. closing the shutter on the star scanner) is necessary. [5, 10] System development issues such as timing (realtime activities, interrupt handling, frequency of sensor data) hardware capabilities and limitations (storage capacity, power transients, noise characteristics) communication links (buffer and interface formats) and the expected operating ....

....other parts of the system (maximum transfer rate, consequences of race conditions or cycle slippage) The capability to describe dynamic events, the timing of process interactions in distinct computers, decentralized supervisory functions, etc. should be considered in chooosing a formal method [2, 4, 5, 15, 20, 23]. 4. Promote informal communication among teams. Many safety related software errors resulted from one individual or team misunderstanding a requirement or not knowing a fact about the system that member(s) of another development team knew. The goal is to be able to modularize responsibility in ....

E. M. Gray and R. H. Thayer, "Requirements," in Aerospace Software Engineering, A Collection of Concepts. Ed. C. Anderson and M. Dorfman. Washington: AIAA, 1991, pp. 89--121.

....(software system interfaces, failure modes, timing, boundary conditions and values) which in the past have caused errors that persisted until integration and system testing. The Safety Checklist has been developed as a tool to aid in this requirements analysis. II. Related Work Gray and Thayer [9] identify two key components of any software requirements methodology: 1) to aid in determining the software requirements and (2) to represent the software requirements specifications. The work described here is focused solely on the first of these two functions. The paper describes a checklist ....

E. M. Gray and R. H. Thayer, "Requirements," in Aerospace Software Engineering, A Collection of Concepts. Ed. C. Anderson and M. Dorfman. Washington: AIAA, 1991, pp. 89--121.

....(software system interfaces, failure modes, timing, boundary conditions and values) which in the past have caused errors that persisted until integration and system testing. The Safety Checklist has been developed as a tool to aid in this requirements analysis. II. Related Work Gray and Thayer [Gray 1991] identify two key components of any software requirements methodology: 1) to aid in determining the software requirements and (2) to represent the software requirements specifications. The work described here is focused solely on the first of these two functions. The paper describes a checklist ....

E. M. Gray and R. H. Thayer, "Requirements," in Aerospace Software Engineering, A Collection of Concepts. Ed. C. Anderson and M. Dorfman. Washington: AIAA, 1991, pp. 89--121.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC