The Community for Technology Leaders
RSS Icon
Issue No.02 - March-April (2013 vol.30)
pp: 54-60
Michael W. Whalen , University of Minnesota
Andrew Gacek , Rockwell Collins
Darren Cofer , Rockwell Collins
Anitha Murugesan , University of Minnesota
Mats P.E. Heimdahl , University of Minnesota
Sanjai Rayadurgam , University of Minnesota
Systems are naturally constructed in hierarchies, in which design choices made at higher levels of abstraction levy requirements on system components at the lower levels. Thus, whether an aspect of a system is a design choice or a requirement largely depends on your vantage point within the system components' hierarchy. Systems are also often constructed from the middle-out rather than top-down; compatibility with existing systems and architectures and availability of specific components influence high-level requirements. Requirements and architectural design should be more closely aligned: requirements models must account for hierarchical system construction and architectural design notations must better support requirements specification for system components.
Computer architecture, Contracts, Software, Analytical models, Cognition, Aerospace electronics, architecture, formal methods, requirements, refinement, model checking
Michael W. Whalen, Andrew Gacek, Darren Cofer, Anitha Murugesan, Mats P.E. Heimdahl, Sanjai Rayadurgam, "Your "What" Is My "How": Iteration and Hierarchy in System Design", IEEE Software, vol.30, no. 2, pp. 54-60, March-April 2013, doi:10.1109/MS.2012.173
1. R. Charette, “This Car Runs on Code,” IEEE Spectrum, Feb. 2009; this-car-runs-on-code.
2. A. van Lamsweerde, “Engineering Requirements for System Reliability and Security,” Software System Reliability and Security, M. Broy, J. Grunbauer, and C.A.R. Hoare eds., vol. 9, IOS Press, 2007, pp. 196-238.
3. E. Yu et al., Social Modeling for Requirements Engineering, MIT Press, 2011.
4. S.P. Miller et al., “Proving the Shalls: Early Validation of Requirements through Formal Methods,” Int'l J. Software. Tools for Technology Transfer, vol. 8, no. 4, 2006, pp. 303-319.
5. R. Lutz, “Analyzing Software Requirements Errors in Safety-Critical, Embedded Systems,” Proc. IEEE Int'l Symp. Requirements Engineering, IEEE, 1993, pp. 126-133.
6. B. Nuseibeh, “, Weaving Together Requirements and Architectures,” Computer, vol. 34, no. 3, 2001, pp. 115-117.
7. B. Boehm, “Requirements that Handle IKIWISI, COTS, and Rapid Change,” Computer, vol. 33, no. 7, 2000, pp. 99-102.
8. S. Friedenthal, A. Moore, and R. Steiner, A Practical Guide to SysML: Systems Modeling Language, Morgan Kaufmann, 2008.
9. Std. SAE-AS5506, Architecture Analysis and Design Language, SAE Int'l, Nov. 2004.
10. J. Rushby, “New Challenges in Certification for Aircraft Software,” Proc. 9th ACM Int'l Conf. Embedded Software, ACM, 2011, pp. 211-218.
11. S.P. Miller, M.W. Whalen, and D.D. Cofer, “Software Model Checking Takes Off,” Comm. ACM, vol. 53, no. 2, 2010, pp. 58-64.
12. J. Hammond, R. Rawlings, and A. Hall, “Will It Work?,” Proc. 5th IEEE Int'l Symp. Requirements Eng., IEEE, 2001, pp. 102-109.
13. K.L. McMillan,“Circular Compositional Reasoning about Liveness,” tech. report 1999-02, Cadence Berkeley Labs, 1999.
14. D.D. Cofer et al., “Compositional Verification of Architectural Models,” Proc. 4th NASA Formal Methods Symp. (NFM 12), A.E. Goodloe, and S. Person eds., vol. 7226. Springer, 2012, pp. 126-140.
15 ms
(Ver 2.0)

Marketing Automation Platform Marketing Automation Tool