Right off the bat I have to vehemently state that the UML fails us practicing systems engineers and I do not advocate its use nor the use of any of the UML based tools: ROSE, Tau, Rhapsody, etc.
What I have been involved with over the last several years is the development and proselytizing of a methodology and technique for systematically exploring the system behavior problem space. I first got started this effort when I was with Scitor working a Ford Aerospace project. (yes, several years ago)
This was prior to the coming together of the “three amigos” and the development of the UML. At that time we were using every conceivable diagram to try to facilitate requirement and system design derivation and capture. I have pursued this passion through several different assignments with Lockheed, Boeing, a commercial medical hardware startup and various sub assignments with LM and Boeing. All of these were “cloistered” environments so sharing artifacts unique to the project and company are of course impossible.
At almost every assignment, and some I took specifically for this reason, the teams were trying to facilitate Systems Engineering through the use of UML tools. At Boeing we were using ROSE and I had access to an internal “tool smith” to tweak ROSE. We had support from Rationale (at the time), later on that assignment and also with a couple of Lockheed assignments we tried using the Telelogic products; Tau, Rhapsody. Basically what we, Systems Engineers, need is not supported by the UML. In conversations with Telelogic discussing what we now call Scenario Sequence Diagrams their chief architect acknowledged the utility but stated they would adhere to the UML standard as their business model. Around that time I wrote a paper for INCOSE in which we identify the failure of the UML in this regard.
SysML became the next best hope, and we were following the OMG discussion boards up until the SysML camps fractured and died of their own weight. Everyone’s pet diagram was included. Including mine as the “Activity Diagram with Swim Lanes”.
Our analysis methodology is rooted in solid requirements based Systems Engineering and over the years when we have presented this approach to experienced Systems Engineers they immediately appreciate its utility. My favorite anecdote is the elderly Boeing engineer I ran into when asked to present this approach to a contentious siste group “across town”. I thought he was going to upbraid me for suggesting yet another flash in the pan technique, but instead said, “I haven’t seen such a robust technique since the Apollo program.” Made my day.
The approach supports the generation, and enhances the utility of, the standard engineering artifacts; specifications, IDD/ICDs and Conops documents. Various terms have been used for the technique; Scenario analysis, Threads, Sequences, Use Cases, Use Case analysis. A few years ago we pretty much settled on Use Case elaboration through the use of Scenario Sequence Diagrams. We use the term Scenario Sequence Diagrams (SSDs) to differentiate from the UML sequence diagram.
The methodology and the tool integrate Architecture, Behavior and Functions in one construct. We have used a variety of drawing packages and commercial tools (ROSE and Telelogic discussion above) over the years before (out of frustration) creating a home grown Visio based tool to facilitate the methodology. It ain’t perfect but its way ahead of anything else.
The methodology starts with the identification of the Systems Use Cases; Install, Initialize, Operate, FD/FI/FR, and Disposal (I am now also advocating adding a development Use Case to cover unique build and test situations). Each Use Case is elaborated as a Scenario Sequence Diagram, first at the system level (system as actor) then decomposed at specific levels.
The basics of the diagram;
· Actors are listed across the top
· “lifelines” extend down from each actor
· Processes are shown as “bubbles” on the lifeline
· Messages between actors are shown as arrows
· Time flows down the page
The elements of the diagram capture: Source and derived (and allocated) requirements, architecture (as architectural components and interfaces between components) and behavior both over all conops of the Use Case being elaborated and as required derived behavior to be implemented by the next level of system decomposition.
For the most part I have implemented this approach on assignments as a compendium of analysis packages with individual scenarios assigned to engineers to develop. On my last assignment with Lockheed at Kirtland AFB we used a tailored LM IS&GS Architecture Based Design ABD approach which integrated with this methodology quite successfully. The approach, as with systems engineering in general, is reliant on understanding the interrelatedness of Requirements, Architecture and Behavior and also the appreciation of the roles of the specification, IDD/ICD and Conops documents in capturing and communicating the system design.
I recommend capturing the scenarios in section 8 of an Operations Concept Document (OCD) following the IEEE/AIAA standard. Ideally each requirement is linked to the scenario that elaborates it and the parent scenario that allocated it, which can be done in DOORS. The Visio tool has a robust database which we use in the capture of information embedded in the “smart shapes” but we haven’t yet integrated the database between diagrams nor with a product like DOORS. Maybe someday?
