Running head MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION 1.docx

Running head: MODEL-BASED SYSTEMS ENGINEERING
IMPLEMENTATION 1
Research Project: Model-Based Systems Engineering
Implementation
(Name and date withheld)
MODEL-BASED SYSTEMS ENGINEERING
IMPLEMENTATION 2
Model-Based Systems Engineering (MBSE) Implementation
Section 1: Requirements Analysis
Section 1 tasks for the MBSE project will identify issues and
requirements for
implementing an MBSE system for our Engineering and
Systems Integration work.
Problem Definition
Our Engineering department focuses on a niche market of
systems engineering, design,

integration, and ongoing maintenance and support of emergency
communication and power
systems, predominantly housed in High-Altitude
Electromagnetic Pulse (HEMP) protected
mobile environments. The complexity of the integrated voice,
data, network, and audio/video
systems we work with, the specialized nature of the work, and
the demanding project timelines
have put a strain on our resources and existing processes. We
need to leverage common
requirements and design elements across projects and customers
while remaining adaptive to
unique and changing customer needs. With people spread
across multiple projects, it is harder to
capture changes on one system that should be implemented on
others – especially since
requirements and design files are all in separate Word, Excel,
Visio and other documents. We
would also like to expand our business to new customers with
complex Systems-of-Systems
(SoS) environments that may require protections from HEMP
events. To do that, we need to
streamline our processes and reduce redundant work to allow
people to reasonably take on

additional projects and make new hires productive on project
work more quickly – while
maintaining critical quality factors.
Issues requiring solution. The following list describes the
primary issues requiring the
development of an MBSE system for Engineering.
1. Business growth is placing a strain on senior employees with
specialized skills
and knowledge.
IMPLEMENTATION 3
2. System information is contained in a large, diverse set of
files (Excel files, Word
documents, Visio diagrams, and CAD files) with no easy way to
share technical information.
3. We can’t easily reuse or modify applicable requirements and
design elements
between projects. This increases cost and effort of new work.
4. It 's hard to perform change management and assess impacts
on a short timeline
across the systems’ lifecycle, again increasing workloads and

quality risks.
5. We’re not able to quickly evaluate new customer
requirements and designs against
existing systems efficiently, increasing the effort and response
time on customer proposals.
6. There is an increasing demand from customers to see
architectural views and
interconnecting systems that help them understand the proposed
designs.
7. Consistently high workloads cause bottlenecks that slow
communications with the
other functional areas who are dependent on information from
the engineering group.
High level project and system objectives.
1. Develop a full-lifecycle MBSE proof-of-concept.
2. Create a central repository that links system information on
across the lifecycle–
research, concept, requirements, design, integration, test,
support and maintenance, and disposal.
3. Focus on a Commercial-off-the-Shelf (COTS) solution that
provides ongoing
product support and maintenance while reducing development
and implementation time.

Requirements for the MBSE implementation. Requirements
may be prioritized and
implemented in phases, but the fully developed MBSE system
shall:
1. Support ‘modules’ of reusable requirements and design
components.
2. Capture configuration management and analyze impacts of
systems changes.
3. Incorporate a bill of materials for reusable design
components.
IMPLEMENTATION 4
4. Enable creation of relationships and functional and physical
visualization model
5. Allow import from Word and Excel-compatible formats.
6. Enable capture of system-related information, including
materials.
7. Include a straightforward user interface with online help and
training aids.
8. Support systems engineering across the system and product
lifecycle.
9. Improve collaboration and information-sharing between
functional groups.

10. Enable architecture views and data exchange standards
required by DoDAF.
11. Map to standard modeling languages, including Lifecycle
Modeling Language (LML)
and Systems Engineering Modeling Language (SysML).
Constraints on the system. The two constraints on development
of the MBSE system
are : (1) the system must be installed in virtualized network,
and (2) system must support
existing business security guidelines and user access based on
Active Directory schemes.
Description of Proposed System
The MBSE System will be designed and implemented using a
web-based interface in a
virtual network environment. The MBSE Implementation
project would develop a process
approach and install the necessary software on the network; we
have selected LML and Innoslate
software as the primary tools for this effort. LML is an open-
standard modeling language that
supports systems engineering across the full life cycle of system
development and acquisition
stages. Innoslate is COTS software that fully supports the LML

standard and can map that
standard construct to other common modeling languages and
architecture frameworks.
System Context Diagram
The context diagram for the MBSE system can be seen on
Figure 1. This diagram shows
a generalized view of the MBSE system using LML and
Innoslate software. The MBSE system
receives input from the Engineering, Project Management, and
Verification/Validation System
IMPLEMENTATION 5
entities. Also, it sends information to the Engineering, Project
Management (PM),
Verification/Validation (V/V) testing, Information Assurance
(IA), and Customer entities.
Figure 1. MBSE Context Diagram
Engineering enters requirements, materials lists, and other
artifacts related to a project.
After processing the information, the MBSE system generates
architecture models, reports, and

specifications based on the needs of different functional
entities. Engineers receive as output a
graphical models generated from the system, the specifications
necessary to define the
manufacture and implementation of the project, and specialized
reports as required.
The Customer can view the specifications, reports, and model
views to understand and
clarify whether the proposed system will meet the requirements
of their project. PM receives
Engineering
Customers
Project
Management
MBSE
System
Requirements/
Artifacts
Model Views
Reports
Model Views

Information
Assurance
Verification/
Validation
Specifications and
Reports
Material
Tracking
Material/Components
Test Documents
Model
Views
Model
Views
Specifications and
Reports
Specifications and
Reports

IMPLEMENTATION 6
material lists related to a project and can update with material
purchased. PM can also view
status reports on project activities. V/V receives input on the
system functionality to allow them
to develop test documents; V/V can then attach test plans,
procedures, and reports as artifacts to
the project. IA receives model views, specifications, and
reports designed to assist them in
developing appropriate accreditation documentation and
determine necessary security testing.
Logical Model Data Flow Diagram
The logical data flow diagram for the MBSE System (Figure 2)
shows the five major
processes and a concept for the major system inputs and
outputs. The processes interact with
four data stores, all of which are internal to the Innoslate
program.
Description of processes. The processes shown in the logical
model are described below.
1.0 Import/Enter Requirements: An engineer logs in to
Innoslate to establish a

project and enter requirements using the Project entry screen
and Requirements entities.
Requirements either be imported from a Word or Excel file or
entered directly into the software.
2.0 Input/Update Materials List: Many of the same systems are
integrated into
different customer projects. Using the Resource entity, this
allows a centralized materials list to
be built, maintained, and reused across multiple projects and
systems.
3.0 Build/Update Database: This process is the heart of
defining the entities,
attributes, and relationships that LML and Innoslate use to
create the architectural views and
centralized management of engineering data we need. Future
phases will decompose this into
more detailed processes necessary to produce the required
architectural views and other artifacts.
4.0 Select Model Views: This process will uses the Diagram
view within Innoslate to
produce the architectural, functional, or traceability diagrams
inherent in the product.

IMPLEMENTATION 7
Figure 2. Logical Data Flow Diagram
Engineering
Customers
Project
Management
Establish Project
Model
Views
Model Views
Information
Assurance
Verification/
Validation
Material
Tracking
Material/
Components
Model

Views
Specifications
and
Reports
1.0
Import/Enter
Requirements
2.0
Input/Update
Materials List
3.0
Build/Update
Database
4.0
Select Model
Views
5.0
Create Reports
and
Specifications
D4

System
Descriptions
D3
Material
Components
D1
Customer /
Project
Information
D2
Requirements
System Requirements
Requirements
Statements
Customer/
Project Information
System
Descriptions
Project
BOM

Customer/Project
Equipment List
Equipment Requirements
Material by System
Systems and Relationships
Information Sets
Systems Information for
Testing
Specifications and
Reports
Requirements/Artifacts
IMPLEMENTATION 8
5.0 Create Reports and Specifications: In addition to graphical
views, Innoslate
enables creation of several standard and custom report formats.
Data Dictionary. The Data Dictionary defines the five data
stores internal to the
Innoslate software, and the fields found in them. Every entity

in Innoslate is comprised of a
name, number, and description fields; individual entities have
additional standard attributes and
relationships. Attributes names are unique for each entity, but
may be used in other entities.
The data dictionary for Data stores 1, 2 and 3 of the MBSE
project describes the fields on
the main input page for that function. Data store 4 can be
associated with any one or more of the
20 entities that LML and Innoslate allow. Screenshots of
primary input and output screens and
artifacts will found in the User Interface section in Section 2 of
the paper will describe the data
fields anticipated used for the MBSE project.
D1: Customer/Project Information. An engineer goes to the
Innoslate login page to
establish a new project, which will include customer
information.
Name: Project Name - obtained from project work statement or
statement of
work for external customers. A work order number, innovation
project number, or other
descriptive text for internal customers.

Description: Customer name, point or contact and contract
number for external
customers. The functional group and POC for internal projects.
Brief descriptive text can be of
the project goal can be included.
D2: Requirements. An engineer enters project requirements
which may either be
imported into the system using the Import Analyzer or entered
directly into the system using the
Requirements View. Whether imported or direct-entry, the
Requirements data store includes the
following fields
IMPLEMENTATION 9
Name: Brief text for requirement objective.
Number: A unique number that notes the requirements place in
the project
hierarchy; can be any alpha-numeric numbering scheme.
Description: The text needed to describe the requirement.
Rationale: Text capturing the reason behind the requirement.
Quality Score: Optional, generated by the system based on the

selections
assessing various quality attributes shown.
Clear: Yes/No, is the requirement clear and unambiguous
Complete: Yes/No, is the requirement in conflict with other
requirements
Correct: Yes/No, does the requirement describe the users true
intent
Design: Yes/No, does the requirement impose a specific
solution
Feasible: Yes/No, can the requirement be implemented using
existing technology
and within cost and schedule
Modular: Yes/No; can the requirement be changed without
excessive impact on
other requirements
Traceable: Yes/No, is the requirement uniquely identified and
able to be tracked
to predecessor and successor lifecycle items
Verifiable: Yes/No, is the requirement provable
D3: Material Components. Engineers enter the project bill of
materials into the system
as a Resource or by importing an existing list in .CSV format

Name: Name of resource.
Number: A unique alpha-numeric number designating the
specific resource.
Description: The text needed to describe the resource.
Minimum Amount: Minimum quantity of the resource
required.
Maximum Amount: Maximum quantity of the resource
required.
Units: Text that defines the measure values, such as 'each' or
'hours'.
IMPLEMENTATION 10
D4: System Descriptions. This data store captures information
and connections made
within Innoslate for any of the 20 Innoslate parent and child
entities called out by the LML
Specification.
Descriptions of inputs/outputs. The basic inputs and outputs of
the MBSE system are
shown in the logical data flow diagram and summarized in
Table 1.

Table 1. MBSE Process Inputs and Outputs
Process Inputs Outputs
1.0 Import/Enter Requirements Requirements/Artifacts
Requirement/Statements
Project Set Up
Equipment Requirements
2.0 Input/Update Materials List Equipment Requirements
Material Components
Material Changes
Materials by System
Project Bill of Material
Project Bill of Materials with
Costs
Material Tracking
Materials by System
3.0 Build/Update Database Material by System
Equipment List
System Requirements
System Descriptions

Material by System
System Descriptions
Systems and Relationships
4.0 Select Model Views System and Relationships Project
Information Sets
Systems Information for Testing
Model Views
5.0 Create Reports and
Specifications
Project Information Sets
Customer/Project data
Specifications and Reports
Summary of Cost/Benefit Analysis
The implementation of MBSE would provide both tangible and
intangible benefits. The
specific initial tangible benefits are reflected in the anticipated
reduction in labor hours for
requirements and design support of projects. We anticipate an
average cost reduction of 15% in

labor hours. Over the past two years, we have spent more than
8300 hours on requirements and
design activities. A reduction of 15% would realize
approximately 1250 hours saved over two
years. At an average rate of $91.00 per hour, the savings per
year would be almost $57,000.
Total Return on Investment would take approximately 2.7 years.
This does not account for
IMPLEMENTATION 11
potential savings realized by a reduction in rework and
improved change management, or by
improved collaboration and process improvement for other
groups.
Intangible benefits include reduced stress on senior staff,
increased customer satisfaction,
and improved support for marketing to new customers.
Section 2: System and Database Design
Entity-Relationship diagram (ERD).
The ERD (Figure 3) shows how the different major MBSE
entities are related. A

Customer can have one or more active Projects. On the other
hand, a Project can belong to only
one Customer. A Project will have many Requirements.
Requirements can describe many
Systems, and some individual Requirements may relate to
several Systems. Each System has
many specific Requirements. A system-requirement
relationship table joins those two entities.
Finally, a System will contain many types of Material, and any
piece of Material may be
part of several different Systems. A material-system
relationship table joins the System and
Requirements entities. The two relationship tables will serve to
reduce the many-to-many
relationship and provide individual linkages as necessary.
Figure 3. MBSE Entity-Relationship Diagram
CUSTOMER PROJECT
MATERIAL
A customer has 1toM
projects
generates lists

SYSTEM
REQUIREMENTS
SYSTEM-
REQUIREMENT
MATERIAL-
SYSTEM
generated
by
describe
Identifies
Has
Has Define
Built from
Builds
Belongs to
Has
A project has many
requirements
Requirements describe

many systems
Systems have many
parts/material
Material can be part
of many systems
Systems have many
requirements
IMPLEMENTATION 12
Database design. The LML specification calls out 20 parent and
child entities,
descriptions, and examples of their usage (LML Spec, 2015). .
The Innoslate software used to
implement the MBSE system provides full support to the LML
specification. The System entity
shown in the MBSE is comprised of these individually defined
entities and relationships.
Database file storage and access. In Innoslate, information is
stored within projects
using a Relational Database structure. Each project has its
individual database with physical

separation from other projects. A project can contain any
number of requirements documents,
system models, simulation results, reports, etc. Innoslate
projects are made up of entities,
attributes, and relationships. Each entity in Innoslate has a
name, number and description
attribute no matter which entity class.
Innoslate relationships are bi-directional, where the relation and
inverse relation comprise
one relationship. The Innoslate schema for Innoslate includes a
"verified by" relationship
between the Requirement and any other type of entity. The base
schema also has the "satisfied
by" relationship to track who or what fulfills the requirement.
The schema requires bi-
directionality and automatically generates an inverse
relationship (Innoslate, 2015). Innoslate
provides labels to support classification/ categorization of
requirements at any time.
Users will have sign-in access to Innoslate based on Active
Directory permissions.
Innoslate also provides three project-level permissions (Table 2)
for user-access controls on a

specific project (Innoslate, 2015).
Table 2. Innoslate Project-Level Permission Levels (Innoslate,
2015)
Project-Level Permissions Description
Read Only View project contents only, add and remove your
own
comments, unable to share project.
Read/Write View, modify, and delete project contents, add and
remove
comments, unable to share project.
Owner View, modify, and delete project contents, add and
remove
comments, share a project with other users.
IMPLEMENTATION 13
System Architecture
The Innoslate software will be installed on a separate partition
in our virtualized network
environment using VMware and vSphere, as depicted in Figure
4.

Figure 4. Virtual Network Architecture (VMWare, 2006)
Technical requirements for software installation include (these
can all be supported by
our network infrastructure) include: 1) SQL Database, 2) 1GB
available disk space, 3) 4GB
RAM, 4) Modern browser (Chrome, Safari, Edge, Firefox), and
5) Internet connection to server.
User Interface
Since our MBSE solution will make use of the LML and
Innoslate, this section will
provide a selection of Innoslate screenshots most commonly
used for MBSE efforts. The menu
and top navigation bar at the top of every Innoslate screen gives
users consistent access to links
IMPLEMENTATION 14
necessary to navigate around Innoslate (Figure 5). Also, all
entity ‘view' screens have a common
layout this is described further in the Input Screen section of
the document.
Figure 5. Innoslate Menu and Navigation Bar

Project Set-up and Dashboard. After logging in to Innoslate, a
user can establish a new
project. Figure 6 shows the screen for setting up a new project.
This is the entity that captures the
Project and Customer reference for Data store 1. When several
projects reside in Innoslate,
Dashboard screen appears (Figure 7) after login. To create a
new project from the dashboard,
select the drop down on the project name (red arrow) in the
menu bar and select Manage Projects.
Figure 6. New Project Screen
Figure 7. Innoslate Project Dashboard
IMPLEMENTATION 15
Importing and entering requirements. Requirements for a project
can be imported from
various formats, or entered individually into the system. Figure
8 shows the Import Analyzer
screen. As shown in the figure, requirements can be imported
from Word, Excel or DOORS (CSV
format), PDF files, or plain text. Innoslate can also export data

into an XML format.
Figure 8. Import Analyzer Screen Used to Import Artifacts.
Input screen: Requirement entity. All entity screens in
Innoslate share a common layout.
As shown in Figure 9 for the Requirement entity, the entity type
is shown in a black box on the
upper left part of the screen. A list of labels is underneath the
box; labels are used to categorize
further the instance of each entity. Attributes are displayed in
the center of the screen. The
‘name, number, and description' fields common to every
Innoslate entity are listed first.
Additional attributes follow the three mandatory fields. Unique
to the Requirement
entity, Rationale is an additional attribute. Some yes/no type
fields follow the Rationale field to
enable a self-assessment as to the quality of the specific
requirement. The last area common to
all entities is the Relationships section. Selections made here
are one method used to build the
architectural models based on and traced to individual
requirements.

IMPLEMENTATION 16
Figure 9. Innoslate Requirement Entity Screen
Input screen: Action entity. The layout of the Action entity is
consistent with the
Requirement entity screens; however, the standard labels,
attributes, and relationship choices
change. The Action entity attributes now include Duration,
Start Date and Time, Percent
Complete, and Comment Fields (Figure 10). The Action entity
is required for building a
functional or behavioral diagram for a system.
IMPLEMENTATION 17
Figure 10. Innoslate Action Entity Screen.
Input screen: Asset (Parent) and Resource (child) entities. The
Asset and Resource
entities are used to define specific physical components of a
system. The Resource entity is used
to capture consumable or producible assets of the system; this

can be used to define a bill or
materials that will be used on a project. Additional attributes
for the Resource entity include the
Initial, Minimum and Maximum Amount fields, and the unit
types for the resource (Figure 11).
Examples could include ‘each' to for a quantity of servers, or
‘feet' to define a cable length.
Figure 11. Innoslate Resource Entity Screen.
IMPLEMENTATION 18
Input screen: Building the model. Users can also access a drag
and drop interface from
the Diagrams drop down menu shown at the top of each entity
screen (red arrow). Figure 12
shows the drop-down list from the Asset entity screen. Figure
13 shows an example for building
an Action diagram. Once the basic Action entity is on the
screen, actions can be dragged from
the left-hand panel to develop the full sequence. This layout is
common throughout Innoslate.
Figure 12. Creating a Diagram from an Entity Screen.

Figure 13. Innoslate Drag-and-Drop Interface Screen Example
(Innoslate, 2015).
Outputs from the MBSE System
An essential output from the MBSE system is the graphical
model. Selecting the Diagrams
from the top navigation bar will present the user with all the
diagrams that have been created for a
project (Figure 14).
IMPLEMENTATION 19
Figure 14 Innoslate Diagram View Screen (Innoslate, 2015).
There are three mandatory ‘visualizations’, or graphical models
associated with LML:
Requirements traceability related to the requirements database,
Physical models associated with
Asset entities, and Functional or Action diagrams related to the
Action entity. Diagrams can also
be created by clicking the New Diagram button on the Diagrams
screen shown in Figure 14, or
from within any entity (Figure 12).

Output: Action Diagram. Figure 15 shows a completed action
diagram example.
Figure 15. Action Diagram Example (Innoslate, 2015)
IMPLEMENTATION 20
Output: Spider Diagram. A Spider diagram can display up to
nine (9) levels of
decomposition of entities used to visualize requirements
traceability. The Spider Diagram is
generated based on the current project's requirements database.
The entities display as rounded
blocks showing number and name of the entity; relationships
create the structure displayed as
arrow lines. Figure 16 shows an example of requirements
decomposition of LML entities using
the decomposed by relationship (LML Relationship Spec, 2015).
Figure 16. Spider Diagram Showing LML Traceability between
Entities (LML Spec, 2015).
Output type: Documents. As shown in the logical model
(Figure 2) for the MBSE

system, a variety of reports need to be created. The Menu
button on the navigation screen will
IMPLEMENTATION 21
display a selection of report types built into to Innoslate (Figure
17). Figure 18 shows an
example Concept of Operations (CONOPS) document generated
by the system.
Figure 17. Standard Innoslate Document Formats.
Figure 18. Sample CONOPS Document Format (Innoslate,
2015).
Section 3: Project Plan
The plan for the MBSE project will fall under follow a Process-
based Data Architecture
(Crain, 2015) framework to determine what information is
needed to effectively execute our
business processes and map our MBSE information environment
related (Figure 19).
Figure 19. Ten-step MBSE System Development Process
(Crain, 2014)

IMPLEMENTATION 22
Task List
A list of tasks, durations, and personnel resources needed are
related to the overarching
PDA process methodology for implementing the proposed
MBSE are captured in the MS Project
file for the MBSE Implementation Project. Figure 20 capture
the Task Sheet from the project file.
Figure 20. MBSE Project Tasks, Duration, and Resources
Task descriptions and process map. The following sections
describe how the specific
tasks map to our Process-based Data Architecture approach for
developing the MBSE system.
Innoslate installation and set up and Innoslate on-site vendor
training. Use of the COTS
software and LML specification provide the Application
Architecture Selection, Application
Schema Development, and Application Methodology Definition
solutions. Installation of the
software onto our virtual network and training on the software
and systems engineering approach

are the foundation of the Shared Integration Service segment of
the process.
IMPLEMENTATION 23
Planning. The Planning tasks, lines 4-11, support the Data
Object Application
Assignment and Disparate Data Object Identification functions.
During Planning, data inputs,
and their authoritative repositories will be identified, as well as
necessary system outputs.
Individual systems of our SoS will be prioritized for
development. The Implementation Plan
will determine what and how information needs to be captured
and entered into the system, and
the Test Plan will describe how to verify the required
capabilities of the MBSE system.
Input data/build prioritized database, Build required models,
and Create and
download/export reports. These project tasks (lines 12-20) will
Define the System of Interest
Architecture necessary to the last step of the PDA process,
System Definition. These tasks

encompass all the inputs and outputs necessary to realize the
MBSE project objectives.
Testing, training, demonstration, and ongoing maintenance and
support. The next
project tasks (lines 21 through 28) will wrap up the project,
providing the testing, training, and
management reviews necessary to fully launch the MBSE
project into the mainstream business
activities of the organization and manage ongoing licensing
agreements.
Additional iterative development. Once the initial MBSE
development has been successfully
completed, there will begin an ongoing cycle of system
definition based on the prioritized list of
systems; subsequent phases will focus on expanding the
database, models, and reports (Lines 12-20).
These activities will be fall under ongoing project support for
customers. Lessons learned will be
reviewed and become part of a project backlog for the ongoing
development.
Cost Estimates
Table 4 shows the costs for labor resources according to the
time allocated in the project
task table (Figure 20) and material needed to complete the

MBSE project. The initial MBSE
IMPLEMENTATION 24
phase will capture the Non-Recurring costs; additional work
related to system definitions and
model building will transition into normal support activities on
new and existing projects.
Table 4. Resource Allocation and Costs
Resource Name Cost
System Architect (SA) $9,047.00
Systems Engineer 1 (SE1) $19,804.74
Systems Engineer 2 (SE2) $27,260.10
Systems Engineer (SE) $1,216.00
Network Engineer 1 (NE1) $18,717.48
Project Manager $647.29
Communication Systems Engineer $15,735.60
Audio/Visual Engineer (A/V) $13,258.74
Mechanical Engineer 2 (ME2) $4,391.00
Electrical Engineer 2 (EE2) $6,359.64

Engineering Manager $3,467.10
Systems Engineering Lead $3,189.76
Information Assurance Analyst (IA) $175.84
Test $523.04
Labor Costs $123,793.33
Innoslate software 4 seats, 2 floating/2
fixed-1 year license $9,799.00
Innoslate 5-day onsite training, includes
instructor travel $19,500.00
Network Servers and Storage Upgrades $1,000.00
Material Costs $30,299.00
Projected Cost Phase 1 $ 154,092.33
Project Summary
The MBSE Project Gantt chart (Figure 21) shows the proposed
timeline and assigned
resources for the project. The project has an estimated duration
of 21 weeks at a labor and

material cost of $154,092. This cost includes all non-recurring
activities and definition of the
system prioritized first during the planning stage. Subsequent
iterations will complete the full
SoS definition under standard project support costs.
IMPLEMENTATION 25
Figure 21. MBSE Implementation Project Phase 1 Schedule.
IMPLEMENTATION 26
References
Crain, R. (2014.). MBSE without a process-based data
architecture is just a random set of
characters. Aerospace Conference, IEEE. Pages 1-10. doi:
10.1109/AERO.2014.6836221
Innoslate v3.4 [Computer software]. (2015). User's Guide.

Retrieved from
https://docs.innoslate.com/latest/users-guide/
Lifecycle Modeling Language (LML) Specifications. (2015).
Retrieved from
http://www.lifecyclemodeling.org/specification/ and
http://www.lifecyclemodeling.org/spec/LML_Relationships_Spe
cification_1_1.pdf
VMWare, Inc. (2006). VMWare Infrastructure Architecture
Overview White Paper. Retrieved
from https://www.vmware.com/pdf/vi_architecture_wp.pdf
https://docs.innoslate.com/latest/users-guide/
http://www.lifecyclemodeling.org/specification/
http://www.lifecyclemodeling.org/spec/LML_Relationships_Spe
cification_1_1.pdf
https://www.vmware.com/pdf/vi_architecture_wp.pdf
Warehouse management system project
Project Deliverables
The project requires students to perform three phases: (a)
requirements analysis, (b) system and database design, and (c) a
project plan. Note that in the phase 3, students are required to
use the MS Project software for their project schedule.

The following layout format covering a title page and all three
phases is recommended for the project.
Title page (project name, author, and date)
Phase 1: Requirement analysis
A. Problem definition
B. Issues
C. Objectives
D. Requirements
E. Constraints
F. Description of the proposed system
G. Logical model design
1. Data flow diagrams
· Context diagram
· Diagram 0
· Diagram 1 (Diagram 1 is optional)
· Descriptions of processes in each diagram
2. Descriptions of outputs/inputs/performance/security or
controls
H. Specific requirements, if any (interface, operational,
resource, performance, etc.)
Phase 2: System and database design
A. User interface
Design an overall user interface consisting of screens,
commands, controls, and features to enable users to use the
system.
1. How data will be input to the system?
· The physical layout for each input
· The input design and procedures
2. How data will be output from the system?
· The physical layout for each output
· The output design and procedures
B. Data design
Develop a plan for data organization, storage, updating, and
retrieval.

1. Database design
· Database tables with their attributes should be presented
· Primary key(s) should be identified in each table, if any
· Three steps of normalization should be included.
2. Entity-relationship diagrams
3. Data file storage and access
C. System architecture
Determine the architecture of the system as Web-based
interface, client/server architecture, Internet/Intranet interface,
network configuration, etc.
Phase 3: Project plan
A list of tasks or activities needed for implementing the
proposed system
Estimating completion time and costs
A project schedule for performing those activities (Gantt charts
or PERT charts)
Note: you are only required to use the MS Project software to
handle the scheduling part of the project and for other parts,
you can use any word editing software or any drawing tools
software.
Individual Project Rubric
The individual project will account for 25% of your total points
possible and students should use the APA format for the format
of the individual project reports. The following rubric will be
used when grading your individual project:
Qualities and Criteria
Poor [0-80)
Good [80-90)
Excellent [90-100]
Format/Layout
1. Presentation of the text and structuring of text in an
organized and thoughtful manner

1. Follows phases requirements
(Weight 20%)
Follows poorly the requirements related to format and layout.
Follows for the most part all the requirements related to format
and layout. Some requirements are not followed.
Closely follows all the requirements related to format and
layout.
Content/Information
1. All phases of the project are addressed and contents in each
phase are adequate
1. The project proposal is technically sound and realistic
1. The project is done using techniques covered in this course
1. MS Project software is used in the project plan
1. The project design can be implemented in reality
1. Activities and information are constructed in a logical pattern
among phases to support the solution
(Weight 70%)
The project does not cover all phases and it is not done for the
most part with techniques discussed in this course. The required
software is used poorly in the project plan. The project proposal
is hardly realistic and the tasks proposed can not be done easily
in reality. Activities and information among phases are badly
designed and do not support the solution.
The project covers all phases with adequate contents in each
phase for the most part and it is done with some techniques
discussed in this course. The required software is used in the
project plan for the most part. The project proposal is relatively
realistic and some proposed tasks can be done in reality.
Activities and information among phases for the most part are
designed to support the solution.
The project covers all phases with adequate contents and it is
done with techniques discussed in this course. The required
software is used in the project plan. The project proposal is
realistic and the tasks proposed can be done in reality.
Activities and information among phases are designed to
support the solution.

Quality of Writing
1. Clarity of sentences and paragraphs
1. No errors and spelling, grammar and use of English
1. Organization and coherence of ideas
1. APA style compliance
(Weight 10%)
The project is not well written, and contains many spelling
errors, and/or grammar errors and/or use of English errors. The
project is badly organized, lacks clarity and/or does not present
ideas in a coherent way and it is somehow APA style
compliance.
The project is well written for the most part, without spelling,
grammar or use of English errors. The project is for the most
part well organized, clear and presents ideas in a coherent way
and it is somehow APA style compliance.
The project is well written from start to finish, without spelling,
grammar or use of English errors. The project is well organized,
clear and presents ideas in a coherent way and it is completely
APA style compliance.

Running head MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION 1.docx

Recommended

Recommended

More Related Content

Similar to Running head MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION 1.docx

Similar to Running head MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION 1.docx (20)

More from cowinhelen

More from cowinhelen (20)

Recently uploaded

Recently uploaded (20)

Running head MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION 1.docx