A first Capella project often puts the system under design into Operational Analysis: a box named after the product, sitting among the actors, already performing the work. The model then fights itself. Screens appear before anyone has written who does the work today. Components show up in the same sitting as missions. A scenario cannot be walked because it does not trace to a named capability, or to the entities that actually perform the activities. A reviewer asks a fair question — “which part of this is the operational story?” — and the diagram has no clean answer.
Operational Analysis, in the Arcadia method, is the stakeholder story: the organization, the people, the missions, the activities they already need to carry out, before you specify what the system must do. Official Arcadia reference material describes it as the place to understand real customer need, expected missions and activities, “far beyond (and often before) customer requirements, and before specifying expectations on the system and its boundaries.” If you start with system functions, user-interface layout, or components, you have skipped the layer you are nominally working on.
The Operational Analysis Day-1 Project (for Eclipse Capella) is a Day-1 OA increment you can finish and review: scope, actors and entities, capabilities, activities and interactions, one first scenario, and a naming sheet. Then you build that same increment in Eclipse Capella 7.1. The kit ships the method and the worksheets. It does not include a .capella project file. You create and save the project in Capella 7.1 so the .capella file and its companions are produced by the tool you will keep using. That is deliberate, and it is worth saying plainly up front.
What goes wrong when the operational story is never written first?
Six problems show up so often in a first project that they are worth treating as the actual brief for Day 1.
The first is an OA model that starts with system functions, screens, or components because the operational story was never written down. The product is already on the diagram, doing the work that, in OA, belongs to a ferry master, a dock crew, or harbor control — or to whatever the real operation is in your domain.
The second is a first Capella project that mixes Operational Analysis with later-layer content in the same sitting. Logical components, physical nodes, and vendor names leak in because the tool will let you place them, and because there is no agreed increment to stop at.
The third is inconsistent naming. Actors, capabilities, and activities are named slightly differently on different diagrams, so a first review cannot tell whether two elements are the same thing.
The fourth is a scenario that does not trace to a named capability, or to the entities that actually perform the work. A scenario that cannot be walked on a single sheet is not yet a scenario. It is a sketch of a later model.
The fifth is the system-under-design leaking into OA before the operational need is stable. Naming the system on a Scope sheet is useful. Putting it on the Actors & Entities sheet, and giving it activities, is how OA stops being OA.
The sixth is a blank Capella project with no agreed increment: no stop line, and a temptation to run OA-to-SA transition commands on day one. This kit has a stop line. Day 1 ends at a complete, reviewable OA increment. The OA-to-SA transition is a later kit in the same pipeline. Do not run those commands as part of Day 1.
Why write the story before you draw the system?
Three older practices make the same demand, in different vocabularies, and they are all worth borrowing.
A playwright does not start by building the set. The script and the blocking come first: who is on stage, what they must be able to do, and what has to happen in order. The scenery is in service of that story. If you start with a staircase because the workshop already has one, you will spend the rehearsal explaining why the scene now includes a staircase.
Military operations orders have, for generations, put situation and mission before equipment. The five-paragraph order is a particular form of that habit: you say what the operation must accomplish, and who is involved, before you enumerate the tools. The tools are not the mission. They are how a later layer supports it.
Architects learned a related discipline under the name of the program. Before the floor plan, you write what the building must make possible — the rooms, the adjacencies, the work that will happen there. Vitruvius already insisted that a work has to answer more than one question, and that commodity, the usefulness of the place, is not the same question as the construction of the walls. Operational Analysis is the program. System Analysis and the architecture layers are the plan and the construction. Mixing them in one sitting is how a review becomes an argument about which drawing you are looking at.
A Capella model is in the same position. Write the operational story, then transcribe it. The model should be a record of decisions you can already defend, not a place you discover the story by clicking until a diagram looks busy.
What is a complete Day-1 increment?
A first increment is thin and complete. Day 1 in this kit has a stop point: a short operational story, the actors and entities in this increment, three to six capabilities, a compact activity and interaction set, and one readable scenario. Park the rest.
The vocabulary is the method’s, restated so you can put it on a worksheet. An operational entity is a real-world stakeholder or organization involved in the mission. An actor is a usually human operational entity you do not decompose further. A mission is a major goal to which the future system is expected to contribute; the mission belongs to the operational world. An operational capability is the ability to provide a service that supports a mission — an outcome the organization must be able to carry out, not a product feature. An operational activity is an action fulfilled by an operational entity, contributing to a mission. An operational process is a logical organization of activities and interactions that fulfils a capability. An operational scenario is a time-ordered set of interactions between activities, performed by entities, for a given situation.
The system under design is named on the Scope sheet, then left off the Actors & Entities sheet. It will appear in System Analysis, when you decide what the system must do. In OA, the activities are performed by the people and organizations in the story, not by “the app.”
What, exactly, is in the kit?
The zip is a 7-page guide, an Excel workbook with eight sheets, and a README. The guide covers OA vocabulary, the Day-1 increment, the stop line, and how to enter the same content in Capella 7.1 after the worksheets are decided. The workbook, OA-Day-1-Worksheets.xlsx, has eight sheets: Start Here, Scope, Actors & Entities, Capabilities, Activities & Interactions, First Scenario, Naming, and Example — Ferry Dock, which is fictional. The workbook opens in Excel, Google Sheets on import, or LibreOffice. There is no .capella file, and there is no official sample model. A Capella project is a set of XML/XMI resources — a .capella file plus companion files such as representations and metadata — that should be created and saved by Capella itself. This kit does not ship an unverified model. You create the project in Capella 7.1 and enter the elements you have already decided on the worksheets. That is the reliable path.
The ferry-dock example is a fictional worked example, Northshore Ferry Dock, labeled as such. It is a small coastal slip and a vehicle ferry that do not exist. No real operator, no real timetable, no performance claims. The example exists so you can see a complete Day-1 OA on one path: berth, board, depart, and a weather hold. The system-under-design is named only on the Scope sheet, as a dock-operations support system, and is kept out of OA. It is not an OA actor and it does not own activities.
In the fictional example, the actors and entities are a ferry master, a dock crew, a passenger, harbor control, and a weather service. The capabilities are operational outcomes: berth and secure the ferry, board passengers and vehicles, depart on a safe window, and hold or divert in weather. Activities stay with the people and organizations who perform them. What moves between them is an operational item: an approach clearance, a count, a hold decision, a condition report. The first scenario is a Saturday arrival in rising wind. The ferry nears the slip; the ferry master requests approach clearance; harbor control issues it; the dock crew secures lines and begins boarding; an updated condition report arrives mid-board; the ferry master decides a hold; the dock crew announces the hold. Departure is not requested. The story stops there. That is enough for Day 1: the hold capability is exercised, and a review can walk the sequence without a second diagram. Notice what is absent: no notification service, no hold-light controller, no software actor. Those questions belong later, when System Analysis asks what the system must do so this operational story can still be carried out.
How do you use it on day one?
Read the guide, especially the OA vocabulary and the Day-1 stop line. Open the workbook, start on Start Here, and fill Scope, Actors & Entities, Capabilities, Activities & Interactions, First Scenario, and Naming — in that order. On Scope, write the operational paragraph, name the system under design, and write the stop point for this increment. On Actors & Entities, if you are about to add a row with the product’s name on it, stop; that row belongs on Scope as the system under design, not here. Fill capabilities as outcomes, then activities and interactions in operational language: “announce a weather hold,” not “the module posts an event.” Write one first scenario. If a review cannot follow it on a single sheet, shorten it. Apply the Naming sheet so the strings you type into Capella are the strings on the workbook. Study the fictional ferry-dock example if you want to see a completed increment before you write your own. Do not copy it into a real project as if it were a site survey.
Then, in Capella 7.1, create a new project with Capella’s own new-project wizard and, in Operational Analysis, enter the elements you already decided: entities and actors, capabilities and involvements, activities, interactions, and one scenario. Use Capella’s own commands and palettes. If a diagram introduces an element that is not on the workbook, update the workbook first or leave that element out of this increment. Do not run OA-to-SA transition commands as part of Day 1.
How is this different from the Arcadia Layer Pocket Guide?
The pocket guide answers “which Arcadia layer is this element on?” This kit is the Day-1 OA increment itself: scope it, write it, and build it in Capella. They pair well. They are not the same product.
Written for Eclipse Capella 7.1.0 and the Arcadia Operational Analysis layer as Capella implements it. Capella is a trademark of Eclipse Foundation AISBL. Arcadia is the method Capella supports. This is an independent tool for people who use Eclipse Capella. It is not an official Eclipse or Capella product, and it does not include the Capella application or any official sample model.
A stop line is a feature
You get a defined increment, a workbook that forces the decisions in the right order, a naming sheet that keeps the first review coherent, and a stop line so Day 1 ends at complete OA instead of a half-built later layer. The kit is honest about what it is: worksheets and method, not a pre-built .capella file. The project you will keep using should be created in the tool you will keep using, from decisions you have already written down.
Start with the guide and the worksheets, in order, then create the project in Capella 7.1 from those decisions. Get the Operational Analysis Day-1 Project (for Eclipse Capella) and write the operational story before you draw the system.
The Operational Analysis Day-1 Project is listed on our Tools for Eclipse Capella page, alongside the rest of the tools in that line. You can browse every Organa Obscura tool on the Products page.
Leave a Reply