Abstract
The use of ilities for systems engineering of subsystems and components is investigated. Prior work on ilities has emphasized or restricted their application to system level, non-functional properties. The premise of this work is that ilities can be applied with benefit, and in some cases out of necessity, to lower levels of systems as well. The veracity of this premise is established by providing examples that demonstrate how some ilities are passed and used as a non-functional property of electrical and structural subsystems in aircraft. It is further demonstrated that flowing ilities down to the subsystem level is not only a useful practice for systems engineers, it can also be an essential step to ensure that customer needs are actually met by the system under design or service. Systems engineers often lack the detailed knowledge of the subsystems or components required to translate ilities into functional requirements. Thus, the system ilities are passed down and translated from non-functional to functional requirements by subject matter experts. We first discuss the definition, characteristics and scope of ilities. Then, we formulate the application of ilities at a subsystem level. Next, we show aircraft engineering examples for ilities applications. The application process is formalized with diagrams, and ilities’ relation to system architecture engineering is discussed. The work concludes with a summary and suggestions for future work.
Highlights
Ilities are a way for systems engineers to capture customer needs early in the system lifecycle, prior to the development of functional requirements
The definition and role of ilities at the system level are well known, but we propose its subsystems
The definition and role of ilities at the system level are well known, but we propose its use use can be extended to subsystems and components
Summary
Ilities are a way for systems engineers to capture customer needs early in the system lifecycle, prior to the development of functional requirements. A more restrictive definition of ilities limits them to only system level non-functional requirements They have been defined as “desired properties of systems, such as flexibility or maintainability, that often manifest themselves after a system has been put to its initial use. This same approach of limiting ilities to system level analysis exists in software development This approach is taken in [4], which uses non-functional requirements for software architecting. On their approach, each ility is listed in a table that can be used to assess the ability of the architecture to achieve desired system aspects for space mission flight software.
Sign-in/Register to view highlights & summary Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a callDisclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.
