TY - GEN
T1 - An architecture-centric approach for systems design
AU - Neill, Colin J.
AU - Sangwan, Raghvinder S.
AU - Paulish, Daniel J.
PY - 2009/1/1
Y1 - 2009/1/1
N2 - The most critical requirements for the lifetime value of a system are its nonfunctional requirements such as reliability, security, maintainability, changeability, etc. These are collectively known as the 'ilities' and are typically addressed in system design once the functional architecture has been developed. In this paper we propose the use of architecturecentric design that modifies this standard workflow so that those non-functional requirements, which actually reflect the true business needs, are addressed first. This ensures that the final system better reflects and embodies those architecturally-significant requirements rather than having them addressed secondarily. This is an important change since the 'ilities' are systemic properties (properties of the system as a whole) rather than systematic properties (properties of individual components or sub-systems) and are therefore difficult to address once the functional architecture has been determined and the separation of concerns is already somewhat completed. We provide an example of the approach based around a simplified case study of an online, on-board health monitoring system for shipboard gas turbine electricity generators that collects, filters, analyzes, transmits, and mines sensor data from the generators subsystems.
AB - The most critical requirements for the lifetime value of a system are its nonfunctional requirements such as reliability, security, maintainability, changeability, etc. These are collectively known as the 'ilities' and are typically addressed in system design once the functional architecture has been developed. In this paper we propose the use of architecturecentric design that modifies this standard workflow so that those non-functional requirements, which actually reflect the true business needs, are addressed first. This ensures that the final system better reflects and embodies those architecturally-significant requirements rather than having them addressed secondarily. This is an important change since the 'ilities' are systemic properties (properties of the system as a whole) rather than systematic properties (properties of individual components or sub-systems) and are therefore difficult to address once the functional architecture has been determined and the separation of concerns is already somewhat completed. We provide an example of the approach based around a simplified case study of an online, on-board health monitoring system for shipboard gas turbine electricity generators that collects, filters, analyzes, transmits, and mines sensor data from the generators subsystems.
UR - http://www.scopus.com/inward/record.url?scp=84878073353&partnerID=8YFLogxK
UR - http://www.scopus.com/inward/citedby.url?scp=84878073353&partnerID=8YFLogxK
M3 - Conference contribution
AN - SCOPUS:84878073353
SN - 9781615674398
T3 - 19th Annual International Symposium of the International Council on Systems Engineering, INCOSE 2009
SP - 299
EP - 310
BT - 19th Annual International Symposium of the International Council on Systems Engineering (INCOSE 2009) in conjunction with the 3rd Asia-Pacific Conference on Systems Engineering APCOSE 2009
PB - INCOSE-International Council on Systems Engineering
T2 - 19th Annual International Symposium of the International Council on Systems Engineering, INCOSE 2009
Y2 - 20 July 2009 through 23 July 2009
ER -