Methodology for the Specification of Software Requirements for an integrated Logistic Platform Lucio Tirone, Gaetano D’Altrui Aster S.p.A. via Tiburtina 1166, 00156 Rome (Italy) lucio.tirone@aster-te.it gaetano.daltrui@aster-te.it Copyright © held by the authors. Abstract — This article describes a methodology for the national and institutional levels. The LIMS platform will specification of the software requirements of an Open Logistic represent a web application offering to Port Community users Services Platform. A business processes analysis, through BPMN the following key services: models of information exchange between private and institutional actors linked to different logistic cycles, has allowed to identify • Logistic Data Validation Service: Ship Cycle Services and analyze Use Cases and to build, in SysML language, the managed by the Port Informer; definition of a Sequence Diagrams that describe the interactions between users. harmonized model for the management of the operative Through MBSE approach, functional requirements able to stages of ships in port, from the ship announcement to ensure the processes proper implementation have been derived. the arrival in port, maneuvers needed for commercial Through the UML language, the software architectural design operations, and departure of the ship. has been provided and, by defining components and artifacts, the software requirements of each module composing the Platform • Import Goods Management Service: Management of software have been specified. Customs clearance at sea, sharing of goods customs status as declared by competent authorities. Freight Keywords — logistic platform, business process, software Services: dedicated to the management of logistics component, BPMN, SysML, UML. operations that relate to the transport services scheduling and delivery of goods. I. INTRODUCTION: THE LIMS PROJECT • Export Goods Management Service: Business The present article shows the application of the Systems Services: dedicated to the management of processes Engineering approach to the specification of the software related to the booking of goods transport across the ship requirements of an integrated logistic platform for the and its payments; Customer/Hauler Order management; exchange of business information between the users inside the Freight tracking through all transit logistic nodes; port community, designed and developed within the LIMS Notification of arrival export cargo. (Logistic Information Management Service) project, funded by the Italian Ministry of Research and University. The main The development of the platform into its Hardware / objective of the LIMS project is the development and Software components relies on the generation of a harmonized demonstration of a regional-scale Open Services Platform, model that allows the study of solutions related to all aspects of which allows, on the basis of a unified model of the logistic information and documents exchange (information flows) processes, the harmonized management, and efficient use of between the multitude of actors involved in the logistic process commercial digitized information from the relevant authorities which may be different for the various Italian Port and and the public and private users operating in the integrated port Interport systems. In both cases, the platform is the only and interport logistics. In particular, the LIMS platform has interface with which users can turn to for accessing to data been developed considering the B2B (Business to Business) associated to their own shipment. In the specific case of the component that defines the commercial transactions between Campania Region (in the southern part of Italy), the logistics non-institutional users. To this aim, the information flows supply chain primary centers are configured as intermodal requested by the various actors involved and the most suitable road-sea (port of Naples and Salerno) and road-rail (interport of interfaces to accomplish the exchange of information have Nola and Marcianise). This model is able to represent the been both defined. The project fits into the broader picture of different cycles of logistics processes, depending on the the digitization process of the Public Administration and the exchange of messages among actors in the port / interport rationalization and standardization of transport management at community and based on the info-telematic systems they use. national level, in order to experience, at pilot level in the Once completed, it provides all the elements to identify, define Campania Region, the B2B service component of the future and develop the B2B (Business to Business) Services offered National Single Window for maritime transport to be to the actors involved in the logistics chain. implemented in the European Directive 2010/65 by 2015 at the Throughout the LIMS project, the Consortium, through the problems, and conceives reusable, combinable and lead of ASTER, has followed the Systems Engineering available services in a standardized manner. methodologies. Systems Engineering fosters the definition of common terms, interfaces management and control of those independent elements/systems, while providing controls to ensure that the overall product satisfies the stakeholder needs. It is often not straightforward to understand when a complex system crosses the boundary to become a system of systems, however it is often the case that the development of such an entity is a collaborative challenge in which the several involved teams are charged to develop elements that cooperate across many iterative stages to provide the required capabilities. II. OVERALL METHODOLOGY The proposed approach, reported in Fig. 1, is a top-down iterative process that follows the entire typical flow-down of requirements, starting from the acquisition of the user/stakeholder needs, which are elaborated for the definition of the stakeholder requirements, then modeling the processes in a standard format, and proceeding with the definition of the system requirements. The interaction between layers is based on a “customer-supplier” paradigm, according to which each layer interacts with the next layers ‘providing’ a specification Fig. 1. LIMS Overall Approach of the requested behavior, in the same way as the final user provides its needs to the system developer. The process will The first step in the realization of the platform model is the end when the set of requirements is well-suited to be developed analysis of the Business Model, in order to define the by a single team. The final output of LIMS Project is a web- information flows and the exchange of data and documents based platform, an info-telematics system for logistic between the various actors involved in the logistic cycles information exchange used by different actors, interfaced with related to ships and goods management. The definition of the external institutional systems. Hence, it is useful to model the Business Model requires a focus on the system context (its platform as a system, i.e. an artifact consisting of blocks that, boundaries, external actors, external interfaces). The system together, pursue a goal [3]. A block can be generally software, context diagram shows the system’s environment and thus the hardware, an individual, or any other unit. But the LIMS system boundary. It is not a predefined diagram of SysML or platform, in its final realization, is a software with a front-end, UML, but a variant of block diagram. In the center of the for user access, and a back-end for the management and diagram is the system under development. It is a block with the implementation of logistic processes, data storage and stereotype system. This clearly distinguishes this block from notification transmission among the involved operators. So, a other system blocks yet to be identified. All currently known system model is useful to derive the system requirements, interaction partners are denoted all around the system and whereas a model of the software, through UML concepts, is associations are used to connect them needed to represent the different software blocks, their interactions and the requirements allocation. In order to meet The context of the LIMS platform is represented in Fig. 2. the operational requirements described above, the platform The upper part of the figure indicates the Actors that interact must be designed in such a way as to implement efficiently the with the system, while the right section illustrates external logistic cycles according to the typical business models of the systems exchanging information with the LIMS Platform. An port and inter-port context. To this aim, the physical and actor is not a concrete system or a concrete individual, but a functional architecture, and the provided services of the role. The system Actors, within LIMS project, are listed below: Platform, have been defined using a Service-Oriented • Port Informer; Architecture (SOA) approach, which can support the use of web services to ensure interoperability between different • Shipping Line (or the Ship Agents, which is the systems. The definition of a system using a SOA approach is Shipping Line representative); composed of the following phases: • Freight Forwarder; • Implementation of a system Model on the basis of the Model Based System Engineering (MBSE) • Terminal Operator; methodology, which allows to define the • Road Hauler; functionalities and physical composition of a system. • Consignee; • Services Definition with a Service-Oriented methodology, that suggests to divide and classify a • Shipper; complex problem into smaller and non-merged • Port Authority. realities are related. A very important feature of the BPMN standard is that it often allows tight integration with software development systems. In fact, applications that allow the BPMN designer to represent the process details using BPMN and then to translate that model into software programs for the process management, are now available. Through dedicated technical meetings with the different operators, the processes that the platform has to implement to guarantee each of the key services defined above, have been defined and validated. These processes have been modeled through the BPMN language, by means of Choreography and Orchestration diagrams. A Choreography diagram, representing the macro-activities of the process represented in a chronological sequence, has been realized for each key service. Each macro-activity is represented by a block showing, in the upper part, the initiating partner, and the secondary actors in the lower part. A dedicated Orchestration diagram has been provided to represent the detailed information exchange between the actors of each block. A section of the BPMN choreography diagram related to the Export Goods Management Services (in particular, the Fig. 2. LIMS Platform Context Booking Request task) is reported in Fig. 3 (it represents just one choreography task to which the Orchestration Diagram The list of External Systems, exchanging information with corresponds). LIMS Platform, is reported below: The orchestration diagram, showing the information flows • Port Management Information System (PMIS): it is a between the freight forwarder and the hauler for an optimized system managed by the Italian General Command of and digitized (through the platform) management of transport Harbour Masters. Informations exchange is related to order, is depicted in Fig. 4. The BPMN diagrams show clearly the Mooring Plan of the Ships; the user tasks, which require the interaction of the user with the • TC Platform: it represents the information exchange platform for the submission of data or the visualization of platform between a terminal operator and the Customs forms and summary tables, and the send/receive tasks, which info-telematic system (AIDA-CARGO). LIMS indicate the functionality of data structures transmitting to the platform requests to TC the Import/Export Goods actors who need the information, adding more data, if needed, Manifest, the goods items reference numbers (A3), and to complete the task, for planning purposes and hence speeding the customs status of the goods to be unloaded in a up the whole process. terminal. These information can be accessed with the same temporal rate with which a terminal itself receives them; • Port Informer Sensors: sensors managed by the Port Informer (AIS portal, meteo-stations, cameras, tide gauges and other sensors network) for the validation of logistic data provided by the Ship Master by means of the radio communications with the Port Informer itself. Fig. 3. Choreography Diagram: Export Goods Management Service The language we choose to formally describe the business process is the BPMN (Business Process Model and Notation), a standard internationally defined by the OMG (Object Management Group). It is able to provide a graphical representation to specify individual processes through a Business Process Diagram (BPD), with a standard, effective and intuitive notation for all the stakeholders involved in the processes. The BPMN diagrams are able to provide a common “framework” upon which it is possible to describe interactions among different operators working in a port or in an interport [1]. The adoption of the BPMN language allows to offer a clear vision of the processes among actors which have heterogeneous characteristics and different responsibilities, also contributing to the modeling of the interactions that take place within the Port Regionalization, where the port cluster is seen as a changing environment to which different logistic Fig. 4. Orchestration Diagram: Transport Order Management III. DERIVATION OF PLATFORM REQUIREMENTS in order to produce the requested output, without any concern The following step is the identification of the system Use on how the system elements interact with each other in the Cases, representing the goals of a system from the perspective process. of the users, from the analysis of the business processes. Using Fig. 6 shows one sequence diagram developed for the case the SysML language, formal Use Case diagrams are drawn, to under study, and the requirements derived from it. The first one show the complete list of actors (primary and secondary), as is related to the request of a form for the declaration of goods well as a full text description for each of them to illustrate the data associated to a transport order, while the other two are goal of the primary actor and the role of the secondary actors. associated to the request to the platform of saving and So, the Diagram provides an high-level view of a system submission of the data structure originated from the user form. functionality, depending on how the actors use the system itself. A typical use case description may include the Preconditions, i.e. the conditions that must hold for the use case to begin, Postconditions, the conditions that must hold once the use case has completed, and the Trigger, which identifies the event that causes the activation of the use case. Fig. 5 shows one example of Use Case Diagram of the case under study, representing the functionality of transport order elaboration related to the process analyzed in Fig. 4. At this point, the analysis of the platform behavior, within each Use Case, can be performed thorough dedicated sequence diagrams, used to describe the main interactions between the system and its environment. The approach for the derivation of the requirements is based on the detailed analysis of the sequence diagrams, as Fig. 6. Sequence Diagram related to Transport Order Management follows: • Looking at the Use Case description, draw messages It may be the case that functional System Requirements between actors and system. These messages represent written in this way are too complex to be efficiently managed, an exchange of information rather than data, because for example for testability reasons. If this happens, the the focus is on the functional behavior, independently requirement can be decomposed in smaller and more from the actual physical realization (i.e. different manageable units, but still maintaining the unity of the main message standards could be used, but the information system level requirement. content of the message is what we are concerned about in this phase). IV. DEFINITION OF SOFTWARE ARCHITECURE • Draw a “message to self” before each output message The goal of the last phase is to decompose the system into a on the system lifeline. These messages correspond to set of system elements, describe their interactions, and derive “operations” allocated to the system. from the system level functional Requirements an associated list of requirements to be associated to each system element. The phase is divided in two steps, the first with a purely functional white-box analysis, and the second with the physical analysis, based on the real components chosen as system elements. The approach is recursive, in that each level of system decomposition is requested to perform the same chain of activities, until the lowest significant level for the requirements is reached. Thus, for example, the developer of a system element will receive the Requirements allocated to it, and perform the entire analysis already developed, as if the system level were its customer. As, for the case under study, the platform is itself a software system, it has been defined through the UML approach [4], [5], [6], [7], [8]. The UML is able to represent the static structure and the dynamic behavior of a software system [2]. A software system is modeled as a collection of discrete objects interacting to Fig. 5. Use Case Description: Transport Order Confirmation Request perform functionalities that are ultimately exploited by an external user. The UML also contains constructs for organizing Each operation derived in this way is a very reasonable models in Packages that enable software teams to divide the candidate for a functional requirement, because it has to software system into smaller parts, identifying dependencies describe what the system has to do with the input information, between Packages, and to manage in this way the installation of these software parts on complex execution environments. Visual Paradigm is the software tool used to describe the LIMS Platform UML model. The main UML modeling element is the Component. A component describes a modular piece of a logical or physical system whose externally visible behavior can be described much more concisely than its implementation. It is an abstract element of design that hides its implementation behind a set of interfaces. The Component interfaces describe the functionalities that the component supports. Interfaces may be provided or required. A provided interface describes the operations that a Component guarantees to make available to other components. The component may supply additional operations, but it must at least supply all the operations in a provided interface. A required interface describes the functionality that it needs from other components. The component may not always use all of the listed operations, but it is guaranteed to work if the components that it uses at least supply all the listed operations. Any component that satisfies the set of interfaces can be substituted in a slot. A component is realized by Classes, collected in an “Artifact”, which means a file or a set of files, i.e. a physical unit of the construction of a system. Fig. 7. Software Modules of LIMS Platform A Subsystem is used to model a wide part of a software system, so Components on large-scale, and it is seen as a For each Module, a dedicated Component Diagram, <> of a component. A subsystem is therefore a showing the UML components defined for it with the related coherent part of the design. It’s possible to introduce the interfaces, has been realized. Fig. 8 shows the Component concept of module, which is a storage and manipulation Diagram for one of the Logistic Modules of the Platform. software unit. Modules can be associated with a source code, with a binary code and with executables. A stereotype “module” referring to a Subsystem may be defined in Visual Paradigm tool. The Platform, in general, can be defined as the stereotype "Platform" applied to a Package, which is a part of the Model: this, in fact, is a set of Packages which provides a complete view of the system. The Platform is a set of all modules. A “Suite” is a collection of modules and represents the Product as sold to a specific Customer. LIMS Platform Modules are shown in Fig. 7. The Modules are classified according to the color codes defined in TABLE I. TABLE I. SOFTWARE MODULE CLASSIFCATION Table Column Head Module Color Description Type Code Modules devoted to the implementation of Logistic logistic Processes defined in the Business Modules Model Modules responsible for the monitoring of Application the process status and dataflow Modules management SW Core Modules related to the service software Modules infrastructure GIS Module related to the cartographic Module services Fig. 8. Component Diagram of a Module Then, different Suites have been defined as originating from CONCLUSION LIMS platform, with the set of modules imported. For each This paper described a model based approach for the Suite, it has been realized, from one side, a Component derivation of the functional specification and software Diagram (see for example the diagram in Fig. 9) showing the requirements of an integrated logistic platform which allows an modules included and the functional relationships between efficient information flows exchange within a port community. them and, from the other side, a Deployment Diagram (see for example the diagram in Fig. 10) where it is possible to see the REFERENCES physical nodes where the components may be deployed. [1] S. A. White, and D. Miers, “BPMN Modeling and Reference Guide”, 2008. After the software architecture modeling, and hence its [2] J. Rumbaugh, I. Jacobson, and G. Booch, “The Unified Modeling decomposition in components and related interfaces, the Language Reference Manual”, second edition, 2005. platform software requirements have been derived. A particular [3] Technical Board International Council on Systems Engineering attention has been given to the non-functional requirements, (INCOSE). Sustems Engineering Handbook, Vrsion 2a, June 2004. which specify requirements under which the system is required [4] UML for Systems Engineering: Request for Information. http://www.omg.org/cgi-bin/doc?ad/02-01-17, 2002. to operate or exist or system properties. Quality requirements [5] UML for Systems Engineering: Request for Proposal. and human factors are examples of this type. Speaking of http://www.omg.org/cgi-bin/doc?ad/03-03-41, 2003. product requirements, a focus has been made on reliability [6] UML 2.1.1 Superstructure Specification. http://www.omg.org/cgi- requirements, as the LIMS platform has to work in a safe and bin/doc?formal/07-02-03, 2007. reliable way. So, the actions of preventive and corrective [7] UML 2.0 Diagram Interchange. http://www.omg.org/cgi- maintenance, fault types and associated timelines, and methods bin/doc?ptc/2003-09-01, 2003. for instant troubleshooting have been defined. At the same [8] UML 2.0 Infrastructure Specification. http://www.omg.org/cgi- bin/doc?ptc/2003-09-15, 2003. time, the application servers configuration and redundant power supply have been considered. As for privacy requirements, which are of big importance in a platform for the exchange of commercial information, the following requirements related to software security have been defined: • Confidentiality; • Integrity; • Availability; • Authentication; • Authorization; • Logging; • Platform Session Management; • Management of errors and exceptions; • Software configuration parameters Management. The identification of the platform Modules has been made with this rationale: an ESB (Enterprise Service Bus) is a software architecture with which each application communicates, guarantying the manipulation of the messages and their routing to the final destination. The Application Logic is responsible for the monitoring of the processes status (executed by the Logistic Modules), the presentation of the correct GUI (Graphical User Interface) to the User on the basis of the current status, the management of the data flow in input (from GUI to the DB) and output (from DB or process to the GUI), and the management of the user interactions with the Browser Module. This approach facilitates the requirements allocation and traceability, as the logics of the application is separated from the user interface, and at the same time all the logistic processes, which have to be correctly implemented, are somehow defined with separated software modules. Fig. 9. Component Diagram of a Suite Fig. 10. Deployment Diagram of a Suite