There's also nothing wrong with libraries still using physical 3x5 cards listing book information. It's just that there might be a much more efficient way.
Model-based systems engineering is a real buzz in the systems engineering community. A lot of us are talking about the promise of all the rich engineering capabilities model-based systems engineering will bring to our development environments.
Model instead of document
The approach allows systems engineers to model instead of documenting their solutions. A modelling environment with a central design repository and a common language creates a space for engineers to work together on solving some of the most challenging problems. These engineers work with staggering amounts of different information for example requirements and functions, elements and components in a system hierarchy, interfaces, a system’s behaviour, verification and validation, source documents, risks and much much more.
Just think about all the cross-reference tables and spreadsheets you need to manage for all these different information bits. This requirement traces from that source document and these functions are allocated to those components. This interface joins a component over here with another component over there. We verify this performance parameter with that demonstration and these constraints with those inspections etc. etc.
Interconnected information bits
Imagine you could create all these references as part of developing your system solution and not separate to it. Imagine all these information bits being interconnected in a system model as the primary engineering effort, not just an afterthought. Imagine your system model representing the state of your solution at any point during development. Think about how easy it will be to identify problems, find alternatives or even answer stakeholder questions when all imaginable cross-reference information is available at your fingertips. That is the promise and the power of model-based systems engineering.
Query a real-time system model
Think about the following example. Somewhere during development your customer asks you to use a specific component in your system design. It’s one from his downtown supplier. How will you find out what the effect of changing this component will be on your design? Working through stacks of documents with a hope that cross-references are up to date is just error prone drudgery. With a document-centric approach like this you’re never quite sure about the status of design information. How valuable will it be to query a real-time system model in a central design repository? You could ask about the impact of a design change on system functions and interfaces as well as the effects on requirements and other related information throughout the design. A model gives you the ability to ask these questions across the different aspects of your design at the touch of a button.
I think that’s a pretty neat and powerful ability. Your system’s definition is like a spiderweb of 3×5 cards clearly connected and easily interpreted. Defining these cards and their connections are the development and not a separate task to keep book of your information. The model-based systems engineering approach helps you to find answers to your tough development questions.