The Future of Systems Engineering

 

I attended an interesting systems engineering forum this past week. A fair number of government organizations and contractors were participants. There were many interesting observations from this forum, but one presenter from a government agency said something that particularly struck me. He was saying that one of the major challenges he faced was finding people who were trained in UML and SysML. It made me think: “Why would it be difficult to find people trained in UML? Wasn’t UML a software development standard for nearly the last 20 years? Surely it must be a major part of the software engineering curriculum in all major universities?”

The Unified Modeling Language (UML) was developed in the late 1990s-early 2000s to merge competing diagrams and notations from earlier work in object-oriented analysis and design. This language was adopted by many software development organizations in the 2000s. But as the graph below shows, search traffic for UML has substantially declined since 2004.

This trend is reinforced by a simple Google search of the question: “Why do software developers not use UML anymore?”

It turns out that the software engineering community has moved on to the next big thing: Agile, which now systems engineers are also trying to morph into a systems engineering methodology, just like when they created the UML profile: Systems Modeling Language (SysML).

This made me wonder, “Do Systems Engineers try to apply software engineering techniques to perform systems engineering and thereby communicate better with the software engineers?” I suddenly realized that I have been living through many of these methodology transitions from one approach to software development and systems development to another.

My first experience in modeling was using flow charts in my freshman year class on FORTRAN. FORTRAN was the computer language used mostly by the scientific community in the 1960s through the 1990s. We created models using a standard symbol set like the one below.

Before the advent of personal computers these templates were used extensively to design and document software programs. However, as we quickly learned in our classes, it was much quicker to write-execute-debug the code than it was to draw by hand these charts. Hence, we primarily used flowcharts to document, not design the programs.

Later in life, I used a simplified version of this to convert a rather large (at the time) software program from the Cray computers to the VAX computers. I used a rectangular box for most steps and a rectangular box with a point on the side to represent decision points. This similar approach provided the same results in a much easier to read and understandable way. You didn’t have to worry about the nuanced notations or become an expert on them.

Later, after getting a personal computer (a Macintosh 128K) I discovered some inexpensive software engineering tools that were available for that platform. These tools were able to create Data Flow Diagrams (DFDs) and State Transition Diagrams (STDs). At that time, I had moved from being a software developer into project management (PM) and systems engineering (SE). So, I tried to apply these software engineering tools to my systems problem, but they never seemed to satisfy the needs of the SE and PM roles I was undertaking.

In 1989, I was introduced to a different methodology in the RDD-100 tool. It contained the places to capture my information and (automatically) produced diagrams from the information. Or I could use the diagrams to capture the information as well. All of a sudden, I had a language that really met my needs. Later CORE applied a modified version of this language and became my tool of choice. The only problem was no one had documented the language and went to the effort of making it a standard, so arguments abounded throughout the community.

In subsequent years I watched systems engineers argue between functional analysis and object-oriented methods. The UML camp was pushing object-oriented tools, such as Rational Rose, and the functional analysis tools, such as CORE. We used both on a very major project for the US Army (yes that one) and customers seems to understand and like the CORE approach better (from my perspective). On other programs, I found a number of people using a DoD Architecture Framework (DoDAF) tool called Popkin Systems Architect, which was later procured by IBM (and more recently sold off to another vendor). Popkin included two types of behavioral diagrams: IDEF0s and DFDs. IDEF0 was another software development language that was adopted by systems engineers while software developed had moved on to the object-oriented computer and modeling languages.

I hope you can now see the pattern: software engineers develop and use a language, which is later picked up by the systems engineering community; usually at a point where its popularity in the software world is declining. The systems engineering community eventually realizes the problems with that language and moves on. However, one language has endured. That is the underlying language represented in RDD-100 and CORE. It can trace its roots back to the heyday of TRW in the 1960s. That language was invented and used on programs that went from concept development to initial operational capability (IOC) in 36 months. It was used for both the systems and software development.

But the problem was, as noted above, there was no standard. A few of us realized the problems we had encountered in trying to use these various software engineering languages and wanted to create a simpler standard for use in both SE and PM. So, in 2012 a number of us got together and developed the Lifecycle Modeling Language (LML). It was based on work SPEC Innovations has done previously and this group validated and greatly enhanced the language. The committee “published” LML in an open website (www.lifecyclemodeling.org) so it could be used by anyone. But I knew even before the committee started that the language could not be easily enhanced without it being instantiated in a software tool. So, in parallel, SPEC created Innoslate®. Innoslate (pronounced “In-no-Slate”) provided the community with a tool to test and refine the language and to use it to map to other languages, including the DoDAF MetaModel 2.0 (DM2) and in 2014 SysML (included in LML v. 1.1.). Hence, LML provides a robust ontology for SysML (and UML) today. But it goes far beyond SysML. Innoslate has proven that many different diagram types (over 27 today) can be generated from the ontology, including IDEF0, N2, and many other forms of physical and behavioral models.

Someone else at the SE Forum I attended last week said something also insightful. They talked about SysML as the language of today and that “10 years from now there may be something different.” That future language can and should be LML. To quote George Allen (the long-departed coach of the LA Rams and Washington Redskins): “The Future is Now!”

 

Why MBSE Still Needs Documents

A lot of people are pushing Model-Based Systems Engineering (MBSE) in a way to just deliver models … and by models they mean drawings. The drawings can and should meet the criteria provided by the standards, be it SysML, BPMN, or IDEF. But ultimately as systems engineers we are on the hook to deliver documents. These documents (specifications) form the basis for contracts and thus have significant legal ramifications. If the specifier uses a language that everyone does not understand and only supplies drawing in the model they deliver, confusion will reign supreme. Even worse, if the tool does not enforce the standards and allows users to put anything on the diagram, then all bets are off. You can imagine that the lawyers salivate over this kind of situation.

But it’s even worse really, because not only are diagram standards routinely ignored, but so are other best practices, such as including a unique number on every entity in the database or a description of each entity. As simple as this sounds, most people ignore doing these simple things until later, if ever. This leads us to our first question:  1) Is a model a better method to specify a system?

This question requires us to look at the underlying assumption behind delivering models vs. a document. The underlying assumption is that the model provides a better communication of the complete thoughts behind the design so that the specification is easier to understand and execute. Which leads us to the next question: 2) Can a document provide the same thing?

Not if we use standard office software to produce the document. The way it is commonly done today is that someone writes up a document in a tool like MS Word and then that files is shipped around for everyone to comment on (using track changes naturally) and then all the comments are adjudicated in a “Comment Matrix.” Once that document is completed someone converts it to PDF (a simple “Save as …” in MS Word). In the worst case, someone prints the document and scans it into a PDF. Now we have lost all traceability or even the ability to hyperlink portions of the information to other parts of the design, making requirements traceability very difficult.

However, if you author your document in a tool like Innoslate, you can use its Documents View to create the document as entities in the database. You can link the individual entities using the built-in or user created relationships to trace to other database entities, such as the models in the Action Diagram, or Test Cases. This provides traceability to both a document and the models. In fact, the diagrams in Innoslate can be embedded in the document as well, thus keeping it live, reducing the configuration management problem inherent in the standard approach.

MBSE doesn’t mean the end of documents but using models to analyze data and create more informative documents. Using a tool like Innoslate lets you have the best of both worlds: documents and models in one complete, integrated package.

It’s Time for Government to Embrace the Cloud Computing Revolution

We are sometimes our own worst enemies! We want something, but at the same time put up barriers to obtain what we want. A perfect example was at an Industry Day I recently attended. The customer had put out a request for information (RFI) and was holding a day to present what was going on with the program to the potential contractors. No procurement was discussed, only information about how they wanted to implement model-based systems engineering (MBSE). In particular they wanted to know what kind of contacting language should be used to provide better requests for proposals (RFP). However, they also said that we could not have one-on-one technical conversations with the government technical personnel. I call that a “self-inflicted denial of service attack.”

Cloud computing is the most common self-inflicted denial of service we encounter. We are all familiar now with DNS (Domain Name System) attacks. They seem to be a frequent occurrence and it’s frustrating when we can’t get on our favorite website because a troll has attacked it.

Because of these trolls and all their attack vectors, many in government have resisted adopting cloud computing. They think: “clouds are dangerous … I don’t have control over my data … someone might steal it.” All the while, their corporate networks have been hacked by every major player in the world. If someone hacks into your corporate network, everything they get is related to your organization and what it does. In other words, everything they get is gold. But isn’t cloud computing, as provided by large providers like Amazon, Google, and Microsoft, more secure than your corporate networks?

Let’s take Google for example. First, they don’t tell anyone the location of their data centers. They provide complete physical security. They build all their own servers from scratch and destroy them when they have finished their useful life. They have all the firewalls and software detection capabilities needed and more. They encrypt the data at rest (and you should be sending encrypted data via HTTP, at least). They randomize the filenames, so you need a map to find anything. The meet and exceed the FedRAMP requirements.

Does your corporate (or government) network do all that? Probably not. An Amazon Web Services’ representative explained to me, “FedRAMP requires over 200 security controls, we have over 2,000 of them.” The last thing anyone from these major “public” cloud providers want is some hacker successfully penetrating their network and capturing critical user data. They could (and would) be sued.

I was talking to a gentleman from the government about cloud computing the other day and he told me, “No one has ever told me how they can clean up a spill on the cloud.” [For those not in the know, a “spill” is when you accidentally put information somewhere it doesn’t belong.] I did not have the presence of mind at the time, but I should have asked “what do you do now with your enterprise e-mail system?” I can guarantee they do not go around tracking down backup and destroying hard drives. Deleting the data results in it being written over hundreds of times in a matter of minutes.

So, it’s time to stop committing denial of service attacks on ourselves. It’s time to embrace the cloud computing revolution and get on-board. The commercial world already did this for the most part half a decade ago. If we want to speed up and improve government, they need to figure out how to use the cloud now.

How to Choose the Right MBSE Tool

Find the Model-Based Systems Engineering Tool for Your Team

A model-based systems engineering tool can provide you with accuracy and efficiency. You need a tool that can help you do your job faster, better, and cheaper. Whether you are using legacy tools like Microsoft Office or are looking for a MBSE tool that better fits your team, here are some features and capabilities you should consider.

Collaboration and Version Control

It’s 2018. The MBSE tool you are looking at should definitely have built in collaboration and version control. You want to be able to communicate quickly and effectively with your team members and customers. Simple features such as a chat system and comment fields are a great start. Workflow and version control are more complex features but very effective. Workflow is a great feature for a program manager. It allows the PM to design a process workflow for the team that sends out reminders and approvals. Version control lets users work together simultaneously on the same document, diagram, etc. If you are working in a team of 2+ people, you need a tool with version control. Otherwise you will waste a lot of time waiting for a team member to finish the document or diagram before you can work on it.

Built in Modeling Languages Such as LML, SysML, BPML, Etc.

Most systems engineers need to be able to create uniformed models. LML encompasses the necessary aspects of both SysML and BPML. If you would like to try a simpler modeling language for complex systems, LML is a great way to do that. A built in modeling language allows you to make your models correct and understandable to all stakeholders.

Executable Models

A MBSE tool needs to be much more than just a drag and drop drawing tool; the models need to be executable. Executable models ensure accurate processes through simulation. Innoslate’s activity diagram and action diagram are both executable through the discrete event and Monte Carlo simulators. With the discrete event simulator, you will not only be able to see your process models execute, but you will able to see the total time, costs, resources used, and slack. The Monte Carlo simulator will show you the standard deviation of your model’s time, cost, and resources.

Easy to Learn

It can take a lot of time and money to learn a new MBSE tool. You want a relatively short learning curve. First, look for a tool that has an easy user interface. A free trial, sandbox, or account to get started with is a major plus. This let’s you get a good feel for how easy the tool is to learn. Look for tools that provide free online training. It’s important that the tool provider is dedicated to educating their users. They should have documentation, webinars, and free or included support.

Communicates Across Stakeholders

Communication in the system/product lifecycle is imperative. Most of us work on very diverse teams. Some of us have backgrounds in electrical engineering or physics or maybe even business. You need to be able to communicate across the entire lifecycle. This means the tool should have classes that meet the needs of many different backgrounds, such as risk, cost, decisions, assets, etc. A tool that systems engineers, program managers, and customers can all understand is ideal. The Lifecycle Modeling Language (LML) is a modeling language designed to meet all the stakeholder needs.

Full Lifecycle Capability

A tool with full lifecycle capability will save you money and time. If you don’t choose a tool with all the features needed for the project’s lifecycle, you will have to purchase several different tools. Each of those tools can cost the same amount as purchasing just one full lifecycle MBSE tool. You will also have to spend money on more training since you will not be able to do large group training. Most tools do not work together, so you will have spend resources on integrating the different tools. This causes the overall project to cost a lot more. This is why Innoslate is a full lifecycle MBSE solution.

 

It’s important to find the tool that is right for your project and your team. These are just helpful guidelines to help you find the right tool for you. You might need to adjust some of these guidelines for your specific project. If you would like to see if Innoslate is the right tool for your project, get started with it today or call us to see if our solution is the good fit for you.

 

Why Do We Need Model-Based Systems Engineering?

MBSE is one of the latest buzzwords to hit the development community.

The main idea was to transform the systems engineering approach from “document-centric” to “model-centric.” Hence, the systems engineer would develop models of the system instead of documents.

But why? What does that buy us? Switching to a model-based approach helps: 1) coordinate system design activities; 2) satisfy stakeholder requirements; and 3) provide a significant return on investment.

Coordinating System Design Activities

The job of a systems engineer is in part to lead the system design and development by working with the various design disciplines to optimize the design in terms of cost, schedule, and performance. The problem with letting each discipline design the system without coordination is shown in the comic.

If each discipline optimized for their area of expertise, then the airplane (in this case) would never get off the ground. The systems engineer works with each discipline and balances the needs in each area.

MBSE can help this coordination by providing a way to capture all the information from the different disciplines and share that information with the designers and other stakeholders. Modern MBSE tools, like Innoslate, provide the means for this sharing, as long as the tool is easy for everyone to use. A good MBSE tool will have an open ontology, such as the Lifecycle Modeling Language (LML); many ways to visualize the information in different interactive diagrams (models); ability to verify the logic and modeling rules are being met; and traceability between all the information from all sources.

Satisfying Stakeholder Requirements

Another part of the systems engineers’ job is to work with the customers and end-users who are paying for the product. They have “operational requirements” that must be satisfied so that they can meet their business needs. Otherwise they will no longer have a business.

We use MBSE tools to help us analyze those requirements and manage them to ensure they are met at the end of the product development. As such, the systems engineer becomes the translator from the electrical engineers to the mechanical engineers to the computer scientists to the operator of the system to the maintainer of the system to the buyer of the system. Each speaks a different language. The idea of using models was a means to provide this communications in a simple, graphical form.

We need to recognize that many of the types of systems engineering diagrams (models) do not communicate to everyone, particularly the stakeholders. That’s why documents contain both words and pictures. They communicate not only the visual but explain the visual image to those who do not understand it. We need an ontology and a few diagrams that seem familiar to almost anyone. So, we need something that can model the system and communicate well with everyone.

Perhaps the most important thing about this combined functional and physical model is it can be tested to ensure that it works. Using discrete event simulation, this model can be executed to create timelines, identify resource usage, and cost. In other words, it allows us to optimize cost, schedule, and performance of the system through the model. Finally, we have something that helps us do our primary job. Now that’s model-based systems engineering!

Provides a Significant Return on Investment

We can understand the idea of how systems engineering provides a return on investment from the graph.

The picture shows what happens when we do not spend enough time and money on systems engineering. The result is often cost overruns, schedule slips, reduced performance, and program cancellations. Something not shown on the graph, since it is NASA-related data for unmanned satellites, is the potential loss of life due to poor systems engineering.

MBSE tools help automate the systems engineering process by providing a mechanism to not only capture the necessary information more completely and traceably, but also verify that the models work. If those tools contain simulators to execute the models and from that execution provide a means to optimize cost, schedule, and performance, then fewer errors will be introduced in the early, requirements development phase. Eliminating those errors will prevent the cost overruns and problems that might not be surfaced by traditional document-centric approaches.

Another cost reduction comes from conducting model-based reviews (MBRs). An MBR uses the information within the tool to show reviewers what they need to ensure that the review evaluation criteria are met. The MBSE tool can provide a roadmap for the review using internal document views and links and provide commenting capabilities so that the reviewers’ questions can be posted. The developers can then use the tool to answer those comments directly. By not having to print copies of the documentation for everyone for the review, and then consolidate the markups into a document for adjudication, we cut out several time-consuming steps, which reduce the labor cost of the review an order of magnitude. This MBR approach can reduce the time to review and respond to the review from weeks to days.

Bottom-line

The purpose for “model-based” systems engineering was to move away from being “document-centric.” MBSE is much more than just a buzzword. It’s an important application that allows us to develop, analyze, and test complex systems. We most importantly need MBSE because it provides a means to coordinate system design activity, satisfies stakeholder requirements and provides a significant return on investment.  The “model-based” technique is only as good the MBSE tool you use, so make sure to choose a good one.

How to Use Innoslate to Perform Failure Modes and Effects Criticality Analysis

“Failure Mode and Effects Analysis (FMEA) and Failure Modes, Effects and Criticality Analysis (FMECA) are methodologies designed to identify potential failure modes for a product or process, to assess the risk associated with those failure modes, to rank the issues in terms of importance and to identify and carry out corrective actions to address the most serious concerns.”[1]

FMECA is a critical analysis required for ensuring viability of a system during operations and support phase of the lifecycle. A major part of FMECA is understanding the failure process and its impact on the operations of the system. The figure below shows an example of how to model a process to include the potential of failure. Duration attributes, Input/Output, Cost and Resource entities can be added to this model and simulated to begin estimating metrics. You can use this with real data to understand the values of existing systems or derive the needs of the system (thresholds and objectives) by including this kind of analysis in the overall system modeling.

action diagram fmea

Step one is to build this Action Diagram (for details on how to do this please reference the Guide to Model-Based Systems Engineering. Add a loop to periodically enable the decision on whether or not a failure occurs. The time between these decisions can be adjusted by the number of iteration of the loop and the duration of the “F.11 Continue Normal Operations” action.

Adjust the number of iterations by selecting the loop action (“F.1 Continue to operate vehicle?”) and press the </>Script button (see below). A dialog appears asking you to edit the action’s script. You can use the pull-down menu to select Loop Iterations, Custom Script, Probability (Loop), and Resource (Loop). In this case, select “Loop Iterations.” The type in the number (choose 100) as see in the figure below.

Next change the duration of this action and the F.11. Since the loop decision is not a factor in this model, you can give it a nominally small time (1 minute as shown). For the “F.11 Continue Normal Operations” choose 100 hours. When combined with the branch percentage of this path of 90%, means that we have roughly 900 operating hours between failures, which is not unusual for a vehicle in a suburban environment. We could provide a more accurate estimate, including using a distribution for the normal operating hours.

The 90% branch probability comes from the script for the OR action (“F.2 Failure?”). That selection results in the dialog box below.

Now if you assume a failure occurs approximately 10% of the time you can then determine the failure modes are probabilistic in nature, the paths need to be selected based on those probabilities. The second OR action (“F.3 Failure Mode?) shows three possible failure modes. You can add more by selecting F.3 and using the “+Add Branch” button. You can use this to add more branches to represent other failure modes, such as “Driver failure,” “Hit obstacle,” “Guidance System Loss,” etc.

Note to change the default names (Yes, No, Option) to the names of the failure modes, just double click on the name and a dialog will pop-up (as on right). Just type in the name you prefer.

To finish off this model add durations to the various other actions that may result from the individual failures. The collective times represent the impact of the failure on the driver’s time. Since you do not have any data at this time for how long each of these steps would take, just estimate them by using Triangular distributions of time (see sidebar below).

This shows an estimate from a minimum of ½ hour to a maximum of 1 hour, with the mean being ¾ hour. If you do this for the other actions, you can now execute the model to determine the impacts on time.

Note, you could also accumulate costs by adding a related Cost entity to each of the actions. Simply create an overall cost entity (e.g., “Failure Costs” and then decompose it by the various costs of the repairs. Then you can assign the costs to the actions by using a Hierarchical Comparison matrix. Select the parent process action (“F Vehicle Failure Process”) and use the Open menu to select the comparison matrix (at bottom of the menu). Then you will see a sidebar that asks for the “Target Entity,” which is the “Failure Costs” you just created. Then select the “Target Relationship,” which is only one “incurs” between costs and actions, then push the blue “Generate” button to obtain the matrix. Select the intersections of the between the process steps and the costs. This creates the relationships in between the actions and the costs. The result is shown below.

hiearchical comparison matrix

If you have not already added the values of the costs, you can do it from this matrix. Just select one of the cost entities and its attributes show up on the sidebar (see below).

Note how you can add distributions here as well.

Finally, you want to see the results of the model. Execute the model using the discrete event and Monte Carlo Simulators. To access these simulators, just select “Simulate” from the Action Diagram for the main process (“F Vehicle Failure Process). You can see the results of a single discrete event simulation below. Note that the gray boxes mean that those actions were never executed. They represent the rarer failure mode of an engine failure (assume that you change your oil regularly or this would occur much more often).

To see the impact of many executions by using the Monte Carlo simulator. The results of this simulation for 1000 runs is shown below.

As a result, you can see that for about a year in operation, the owner of this vehicle can expect to spend an average of over $1560. However, you could spend as much as over $3750 in a bad year!

For more detailed analysis, you can use the “CSV Reports” to obtain the details of these runs.

[1] From http://www.weibull.com/hotwire/issue46/relbasics46.htm accessed 1/18/2017

Developing Requirements from Models – Why and How

One of the benefits of having an integrated solution for requirements management and model-based systems engineering is you can easily develop requirements from models. This is becoming an increasingly used practice in the systems engineering community. Often times as requirements managers we are given the task of updating or developing an entirely new product or system. A a great place to start in this situation is to create two models a current model and a future (proposed) model. This way you can predict where the problems are in the current systems and develop requirements from there. Innoslate has an easy way to automatically generate requirements documents from models. Below we’ll take a well known example from the aerospace industry, The FireSAT model,  to show you how you can do this.

The diagram below shows the top level of the wildfire detection and alerting system. Fires are detected and then alerts are sent. Each of these steps are then decomposed in more detail. The decomposition can be continued until most aspects of the problem and mechanisms for detection and alerting have been identified. If timing and resources are added, this model can predict where the problems are in the current system. This model can show you that most fires are detected too late to be put out before consuming large areas of forests and surrounding populated areas.

One system proposed to solve this is a dedicated satellite constellation (FireSAT ) that would detect wildfires early and alert crews for putting them out. The same system could also aid in monitoring on-going wildfires and aid in the fire suppression and property damage analysis. Such a system could even provide this service worldwide. The proposed system for the design reference mission is shown below.

The “Perform Normal Ops” is the only one decomposed, as that was the primary area of interest for this mission, which would be a short-term demonstration of the capability. Let’s decompose this step further.

Now we have a decomposition of the fire model, warning system, and response.. The fire model and response were included to provide information about the effectiveness of such a capability. The other step provides the functionality required to perform the primary element of alerting. This element is essentially the communications subsystem of the satellite system (which includes requirements for ground systems as well as space systems).

Innoslate allows you to quickly obtain a requirements document for that subsystem. The document, in the Requirements View looks like the picture below.

This model is just for a quick example, but you can see that it contains several functional requirements. This document, once the model is complete, can then provide the basis for the Communications Subsystem Requirements.

 

If you’d like to see another example of how to do this, watch our Generating Requirements video for the autonomous vehicle example.

10 Most Important Requirements Capture and Management Rules

Requirement documenting plays an important role in systems engineering. Writing high quality requirements can not only save millions of dollars, but lives. No matter how experienced you are it’s important to remind yourself of requirement writing rules and techniques.

  1.  Know Your Stakeholders

    The first and most important commandment of writing requirements is to know your stakeholders. Understand what common knowledge they have. Make sure you are all on the same page. Understand what each group of stakeholder’s priorities is and their objectives. You do not want each group to develop their own priorities and objectives separately. Separate priorities and objective result in a time consuming and expensive review process with lots of conflicts. Collaborative software that allows for continuous reviewing will help you keep up with all the stakeholders needs. You never want to give them a completely finished product and then ask for review (although that is common practice).

  2. Remember the CONOPs

    Most of you will probably not forgo the Concept of Operations (CONOPS), since it is such a valuable artifact. The CONOPS will be something that all the stakeholders understand and collaborate on together.  In this step you basically create stories that will consider different scenarios and needs. From there you will have a better understanding of where to start with your requirements. The CONOPS will help you write quality requirements by finding all the assumptions. It will help evaluate the ‘what if’ scenarios, make testing easier, and formulate your needs into the requirements.

  3.  Understand What is Really Needed

    First of all, there is a huge difference between want and need. Will the system work without a particular requirement? If you answered yes, then you can probably omit that requirement. A common mistake systems engineers make is listing possible solutions to needs rather than the actual needs. If your need is an efficient way to communicate, don’t specify cell phones, since there are many other forms of communications that may be more feasible, less expensive, or effective.  List what is actually needed; don’t list possible solutions to the needs.

  4. Be Specific (Give actual numbers. Don’t leave room for assumptions.)

    Leaving room for assumptions is leaving room for error. If you are not careful with the language you choose you could end up making costly assumptions. Using words such as minimize, maximize, etc., and/or, more efficient, forces the stakeholders to assume. Don’t let the stakeholders assume how much you want to minimize.

    • etc. can mean so many things
    • and/or causes the reader to guess whether its ‘and’ or ‘or’
    • min. max. don’t just say minimize expansion, say minimize expansion to 300
    • don’t just say quick, say how quick
    • give actual numbers
  5. Do Not Be Too Specific

    The only mistake worse than not being specific enough is over specifying. You want to be specific, but not too specific. Carefully review your requirements before baselining. During this review delete any unnecessary specifics.

    Allow scope with your numbers. If a requirement is good enough at expanding 300% +/- 10%, then give that option. Have any numbers be based on the results of analyses, not just someone’s “engineering judgment.”

  6. Give Requirements Not Instructions

    Understand what is needed and create requirements from those needs. This is why Commandment #1 is so important. If you understand your stakeholders needs writing requirements and not instructions becomes an easier task. It might be tempting to just writing instructions, but that is not what requirements are for. Requirements should provide enough information to allow the builder to provide the most cost-effective solution to the problem.

  7.  Use the Words ‘Shall’, ‘Should’, and ‘Will’

    The industry’s standard word usage for a requirement is “shall”, a goal is “should”, and a statement is “will”. If you do not use these standard word choices you will confuse other stakeholders.

  8. Include a Rationale

    A rationale justifies the inclusion of a specific requirement. Attach a rationale to each requirement by explaining the need for the requirement. The rationale provides reviewers and implementers with additional information on the intent of the requirements, thus avoiding confusion down the line.

  9. Use Proper Grammar

    You will prevent a lot of costly mistakes due to confusion if you use proper grammar. For example, run on sentences will result in two requirements appearing to be one. One technique to improve grammar is to use bullet points first and then construct sentences out of them.

  10. Use a Standard

    Use a standard to ensure consistency. Three common standards are MIL-STD-490, IEEE, and ISO. You should choose one that is right for your industry.

    MIL-STD-490: The United States Military Standard establishes the format and content for the United States Department of Defense’s objectives. It can be useful in other areas as well.

    IEEE: The Institute of Electrical and Electronics Engineers Standards Association develops the IEEE standards. Unlike the MIL-STDs, the IEEE reaches a broad range of industries, including transportation, healthcare, information technology, power, energy, and much more.

    ISO: The International Organization for Standardization develops standards for business to optimize productivity and minimize costs.

PLM Moving to the Cloud

Why Product Lifecycle Management Is Moving to the Cloud

“The cloud” means many things to many people. It’s a common misconception that the cloud is the Internet itself. They think that all the information they put on the cloud can be easily “hacked,” so they see this as a very public thing. But for those who work in cloud computing, they see it as a means to deliver safe, secure services to more people, at a lower cost. You can share computer resources, including CPU power, memory, and storage. This sharing or “on-demand” use of computer resources means that you can pay less for those resource, than when you have provisioned them on your own.

To take advantage of this resource sharing you must use applications that take this new environment into account. Just using a client-server or desktop tool with a “web front end” does not work well. The application programmers must re-architect their code to take advantage of this new capability and at the same time deal with the problems, such as latency, since now you must pass data between the servers where the data is stored and the web browser on the client machine you are using. Those servers may be down the hall or a few miles away, so there can be substantial delays in data transmission.

Scalability

Most desktop/client-server tools assume very little latency, so they grab a lot of information at a time and put it into local memory. That’s fine when you are close to the data, but in cloud computing the servers could be anywhere in the world or at least across the continent. So, when people try to use a desktop tool in this new environment, they begin to breakdown quickly in terms of response time. Another way to say this is that these tools do not scale to meet the growing needs. But the whole idea of cloud computing is to allow the application to scale to meet the needs.

Collaboration

Cloud computing also enables world-wide collaboration. So now the need to scale becomes critical, as more and more people are working together and capturing/generating more and more information. A “web-based” tool must be designed to process more information locally, including visualization of the data. Otherwise, we are back to central computing, where you had a dumb terminal connected to a computer often far away. I can still remember how slow the response was when that occurred. Even though the “bandwidth” has grown to Gigabits per second, we are trying to move Terabytes of information.

PLM on the Cloud

So, what does all this have to do with Product Lifecycle Management (PLM)? PLM today requires a large amount of data, analytical tools to transform data into information, and personnel who collaborate to create the products. Clearly, PLM would benefit the most from this new cloud computing environment. But where are the cloud computing products for this market? Legacy tool makers are reticent to re-architect 100s of thousands of lines of code. Such an effort would take years and be very expensive only to compete with themselves during the transition. So, most have created some “web front-end” to provide limited access to the information that exists in the client-server or (worst case) desktop product.

Innoslate® is the rare exception in the PLM marketplace. Innoslate was designed from scratch as a cloud computing tool. The database backend persists the data, while the web front end visualizes and performs the necessary analyses, including complex discrete event and Monte Carlo simulations. Innoslate support all areas of PLM, from Systems Engineering, to Program Management, to Product Design, to Process Management, to Data Management, and more. All this in one simple, collaborative, scalable, and easy to use tool. Check out www.innoslate.com for details.

What is Model-Based Systems Engineering?

System engineering is the discipline of engineering that endeavors to perfect systems. As such, systems engineering is a kind of meta-engineering that can be applied across all complex team-based disciplines. The idea of systems engineering is to enhance the performance of human systems. It has more to do with the engineering of team performance, engineering meetings or political agreements. It is not quite a social science, but it is the science of perfecting human outcomes.

The International Council on Systems Engineering (INCOSE) has been the organizing body for systems engineering programs. The field of systems engineering has been emerging as a discipline with its own unique training and advanced degree programs. As of 2009, there are some 80 United States institutions offering undergraduate and graduate programs in systems engineering.

Systems-centric programs treat systems engineering as a separate discipline with a specific focus on a separately developed body of the theory and practice. Domain-centric programs are imbedded within conventional engineering fields. All programs are designed to develop the capability of managing and overseeing large scale engineering projects.

The field of systems engineering has developed its own unique set of tools and methodologies that have less to do with the physics and mathematics of the hardware of the project and more to do with the process of bringing the elements of the project together. Modeling software, refers to modeling the process of creation, not so much to models of what is being created. These tools enable members of project team to better collaborate and plan the process of creating a complex finished product, such as a space station or a skyscraper.

Innoslate software has developed as an all inclusive baseline tool for modeling and managing the system of engineering projects. It includes full collaboration systems that allow all team members to work from the same information base, to contribute new information and to have access to what has been accumulated. It has a rich vocabulary of diagramming and flow-charting media to illustrate, change, and embellish the engineering process over time. It has modalities to provide clear feedback about the growth of the project, where it has achieved goals and where it lags behind.

Reposted from SPEC Innovation with permission.