University of Minnesota
Software Engineering Center
/

You are here

Anitha Murugesan

Anitha Murugesan
Student/Research Assistant
Office Location: 
6-248 Keller Hall
Education: 
Phd - Computer Science (Expected 2015) University of Minnesota

Master of Technology - Computer Science (2004) Vellore Institute of Technology, India

Bachelors of Engineering - Electrical and Electronics, University of Madras, India
Biography: 
Anitha Murugesan received B.E Degree in Electrical and Electronics Engineering from Madras University, India (2002) and M.Tech Degree in Computer Science and Engineering from Vellore Institute of Technology, India (2004). She has worked as a Software Engineer with Honeywell Technology Solutions, India (2004-2010). She is currently pursuing Ph.D in the area of Software Engineering at University of Minnesota. Her research interests are Requirements Engineering and Modeling for cyber physical systems.
Research: 
Critical Systems Requirements and Modeling
Interests: 
Software Engineering; Requirements; Model based development

Recent Publications

Your "What" is My "How": Iteration and Hierarchy in System Design

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.

Your what is my how: Why requirements and architectural design should be iterative

Systems are naturally constructed in hierarchies in which design choices made at higher levels of abstraction levy requirements on system components at lower levels of abstraction. Thus, whether an aspect of the system is a design choice or a requirement depends largely on one's location within the hierarchy of system components. In addition, it is often the case that systems are not constructed top-down, but rather middle-out; compatibility with existing systems and architectures, or availability of specific physical components may influence high-level requirements.

Pages