"SysML Requirements on Excel" is a new MDG Office Integration feature that allows users to author SysML requirements using Excel. Users can seamlessly integrate SysML requirements between MS Excel and Enterprise Architect.

Key features

• Import and export SysML requirements data from Excel into Enterprise Architect.
• Ability to create SysML Compliant requirements with inter-dependencies

SysML Requirements in Enterprise Architect

Using the “SysML Requirements on Excel” menu, users can connect an Enterprise Architect Model with an Excel spreadsheet.

This will create an Excel Document with required templates to let users create SysML requirements. This will also copy any existing Enterprise Architect requirements and the derived relationships to the Excel spreadsheet, to let users update or modify these contents.

Working with Excel to author Requirements

The Excel template for SysML requirements authoring will have two spreadsheets,

1. Requirements – The requirements sheet is used to create and update SysML compliant requirements, including Id and text, the sheet also displays any derived requirements (interconnected requirement)

The Requirement Sheet has two parts: "SysML Requirements" and "Derived SysML Requirements".

SysML Requirements – It contains Name, Notes, Status, Version and Id, Text (Mandatory tags for SysML)

Derived SysML Requirements – It also contains Name, Notes, Status, Version of Derived Requirement for each SysML requirement. This part is completely non-editable.

2. Requirement Matrix – This worksheet will present all requirements in a matrix format to let users easily create derivation inter-dependencies between them.

• This sheet will be automatically updated when new requirements are added in the ‘Requirements’ worksheet
• New relationships created in this spreadsheet will also be automatically updated in the ‘Requirements’ worksheet

Insert Elements and Connectors

Insert the element in the Name Column of the Requirement Sheet (with Notes, Status, Version, ID, and text, but the Name column is mandatory). And create a connector between the newly created element and the existing element in the ‘Requirement Matrix’ sheet.

Newly created connector details are updated in the ‘Requirement’ sheet.

To sync or update the modifications to the Enterprise Architect Model, use the Excel to EA icon. The changes reflected in the Enterprise Architect Model will be shown in the preview form. To update into an Enterprise Architect Model, select Export.

New elements are created under the chosen package.

The EA to Excel icon is used to restore the produced items to their original state as in the Enterprise Architect Model.

Prior to ‘EA to Excel’

Post ‘EA to Excel’

SysML Requirements on Excel (from Excel)

MDG Integration for Microsoft Office offers integration within Microsoft Excel (Office 2007 and above), and a new feature called SysML Requirement Manager is added to the feature dropdown of the Enterprise Architect ribbon. Using this, users can easily push the contents of SysML requirements from an Excel document to an Enterprise Architect or vice versa.

To import SysML requirement data into Enterprise Architect from Excel

	Dropdown list to choose the Export to Enterprise Architect Model or the SysML Requirement Manager for the document. ‘Export to EA’: Export the elements to Enterprise Architect using Profiles ‘SysML Requirement Manager’: Import SysML Requirements from Enterprise Architect and Export SysML Requirements and their connections to Enterprise Architect.
	Allows one to select a *.eap or *.eapx or *.feap or *.qea or *.qeax or *.eadb through Local project, server Connection, or cloud connection. Local Project - To Connect Local Enterprise Architect model. Server Connection - To Connect to an Enterprise Architect repository through a database Cloud Connection - To Connect to an Enterprise Architect repository through Pro Cloud Server

Select a package

• This screen will be displayed when the Package button is clicked.
• It displays all the models and packages from the selected Enterprise Architect model, with SysML Requirement items being imported specifically.

After selecting the package and clicking ‘OK, ‘Enterprise Architect will begin exporting information to an Excel sheet and proceed with Refer "Working with Excel to author Requirements"

Check out the SysML Requirements in the Enterprise Architect video here

To know more or to request a demo, please reach out to This email address is being protected from spambots. You need JavaScript enabled to view it.

The Problem

A project chartered to deliver an IT-based solution typically begins with establishing high-level functional requirements (HLRs) which are eventually followed up with detailed functional requirements (DTRs). The problem is that there have never been clear guidelines for what constitutes ‘high-level’. And when it comes to DTRs, there are no guidelines for how much detail there should be in a given requirement statement, making it difficult to check for overall completeness and/or redundancy.

The Solution

The solution to the HLR problem is to recognize that there are five fundamental capability types for adding domain-specific functionality on top of a data management capability. A given high-level functional capability should be viewed as one of the following:

• A Report
• A User Interface
• A Data Import
• A Data Export
• An Automated Function (e.g. ‘batch job’)

A given HLR should only identify who it is that needs a specific one of those types. A properly high-level HLR should contain no ‘field-level’ details.

The solution to the DTR problem is to recognize that for each of the above five types, the necessary detail can be captured in a ‘structured’ format rather than in textual requirement statements. A single DTR, containing no more detail than its corresponding HLR, should be sufficient as an aggregation point for the capability’s structured details.

The RIC MDG Technology provides that structure. It extends the Enterprise Architecture concept of Requirement, and adds additional stereotypes to capture the detail.

The Trips-R-You Web-Based Flight Reservation System case study shows examples of HLRs, DTRs, and spreadsheet-based templates structuring the example details for each of the five capability types. The RIC extensions are described in the article Tool Support for Requirements [In Context]. Documenting functional requirements for an information system-based solution using Requirements In Context format is described in detail in the Requirements In Context Series of Articles.

NOTE: Any questions or problems with the RIC MDG Technology please contact the author.

Capturing and communicating business needs as requirements is a critical task of a Business Analyst.

Requirements Repositories allows capturing those requirements once, then have them available to you and your team for the projects lifetime and beyond. Using Requirements Management tools like Enterprise Architect, the captured business requirements can then be transformed to a formal requirements specification according to the business information needs and views of every relevant stakeholder. Also validating these specifications by tracing from the requirement specification and solution components at every level directly back to the business requirements helps you create the most accurate solutions imaginable. This webinar shows how to use Enterprise Architect for building and managing a requirements repository. You will also learn how to establish requirements traceability in Enterprise Architect thereby documenting the lineage of the requirement to its solutions.

We encourage you to register for the webinar using the link below:

https://sparxsystems.com/resources/webinar/businessanalysis/requirementsmanagement/index.html 

This year’s London EA User Group took place at the Skills Matters Code Node venue. It has been enjoyable and useful to discuss and share experiences with users via this unique dedicated SparxSystems Enterprise Architect event.

This article shares some feedback on the following presentations:

• Keynote on Enterprise Architect 14 by Peter Lieber.
• Model Driven Enterprise Knowledge with Gemalto GMOD platform by David Faus.
• My presentation on scripting with Enterprise Architect.

Keynote: Sparx Enterprise Architect 14

The keynote was an opportunity to discover some of the new features available in Enterprise Architect 14. Having started evaluating version 14 since its beta release, this presentation saved me time as I received an overview of the relevant enhancements.

A new checklist artifact is available from the common toolbox.

Once created, items can be added alongside their Boolean status (checked: true or false).

Result:

Other rendering options are available:

EA 14 has introduced the EAPX file extension, as an alternative to local EAP files, matching a Jet4 engine database. Jet4 EA projects can be created in previous EA versions within an EAP file. EAPX are useful since it is explicitly tied with Jet4 engine (this format provides enhancements on the database capacities). Note that EAPX files can be opened with earlier EA versions.

A new Cloud tab is available in the CONFIGURE > Options menu (note: the following options are available in EA 13.5).

The above Data Cache option can be enabled to create images of each diagram in the EA project database when saved in EA. These images can be used and rendered in external solutions via SparxSystems Pro Cloud Server. A create batch feature is available to generate all diagrams images.

Perspectives in EA 14 can be used to enable only the notations or languages that are relevant to the current use and context. The built-in Systems Engineering\SysML perspective can be enabled for instance so users only work with SysML 1.5 elements and diagrams, and will never come across other SysML versions, or UML, BPMN, ArchiMate and so son. Custom perspectives can be defined to select a range of technologies e.g. UML and BPMN. Note: I find perspectives very useful to scale down EA features to the ones that are needed by users through a built-in feature (instead of custom XML or registry updates by the company IT services). The Model Wizard has been redesigned in EA14; in EA 13.5 and earlier versions, it was mainly used to generate Model Patterns.

EA 14 Model Wizard runs in a view (not a popup) with redesigned model patterns. First of all, the available patterns are displayed for the selected perspective, e.g. UML, Business with BPMN, Systems Engineering with SysML, Enterprise Architecture with ArchiMate, etc.

Where the previous patterns generated a full structure with samples in each model e.g. class, use case, and so on, the logic here is to individually select and add model patterns to the local project. Patterns may include several packages, elements and diagrams.
For each pattern, a nicely illustrated explanation on the purpose is available, enhancing the usability and value delivered by Model Patterns.

EA 14 Model Patterns also include a new Process Guidance tab as an addition to EA Help. It creates a step by step process via an activity diagram e.g. to create a central database EA repository in MySQL as illustrated below.

The element properties have been integrated within views to replace the pop-up properties window. For elements, additional views provide access to the attributes, operations, etc.

Also available as a view, the diagram properties now display the Diagram GUID which can be useful:

The Compartments tab provides access to the elements visibility properties. Note: I would expect in the future to have all diagram properties in this view e.g. Features, Connectors properties.

The Diagram properties include new MetaModel options, linked with MetaModel Views, both introduced in EA 14. This Views system is aimed at restricting the available elements and connections from the diagram toolbox. MetaModel Views are either built-in or user defined (note: user defined views can be useful to combine stereotyped elements and built-in elements such as a UML class, use case and actor).

When creating a diagram, a list of built-in views is available under the diagram type, for instance a UML Class diagram illustrated below:

The resulting toolbox is different from the default UML class diagram.

This selection sets the “Applied to Metamodel” diagram option.

In addition to the toolbox content, the Filter to Metamodel diagram property is now available: when set, this option will grey out all elements that are not in the current Metamodel as illustrated below.

Another new option is the Display Lock Element Status: when enabled, locked elements will be visible accordingly on the diagram.

A smart placement feature is now available to dynamically visualize the selected element’s alignment.

Model Driven Enterprise Knowledge

Note: the following summary has been written by its author and speaker, David Faus (Gemalto).

Our goal was to build enterprise knowledge repositories based on models in several business units in Gemalto. The following diagram shows our strategy coming from the well-known Nonanaka and Takeuchi knowledge management theory:

We successfully used SPARX to build our model based KM platform called GMOD (Gemalto MODeling).

To deploy our “GMOD” adaptation of the Nonaka and Takeuchi approach, we used:

• The EA MDG to implement the “UC” method which I have been building during the last 25 years. This method is quite innovative because it is based on several domains (graphical user interface specification methods, functional analysis and also Object Oriented Programming), and is customer oriented: that means everyone is able, in few minutes of explanation, to understand a UC model.
• The EA client server architecture to allow all team members to produce UC models in parallel, what is finally relevant when building a huge model oriented knowledge base. The first big success we had was the delivery of the GBPR (Gemalto Business Process Repository): All Gemalto corporate business processes are now published and maintained thru GMOD.
• The EA java API to implement the Gemalto “SPARX Companion Tool”. This tool is complementing SPARX EA functionalities by adding reporting features, UC model integrity check, one click deployment web service…
• The Gemalto FAST & Easy knowledge management platform. This platform is based on the concept of patrimonial archiving. It is used to index any important UC diagrams produced thru GMOD. This is possible because the “SPARX Companion Tool” generates static URLs for diagrams.

As a conclusion, we are now able to retrieve model oriented knowledge by simply using a Google like search engine. Our next goal is to focus on the support functions and provide some knowledge base composed by hundreds of comprehensible use cases helpful at any level and anywhere in the company. 

Extending EA with custom scripts to cater for specific needs and user requests

It was my pleasure to be selected for the third time this year as a speaker. I offered to share my experience on defining scripts in EA over the past years to extend the tool’s features e.g. via custom Excel import/exports, save users' time in avoiding repetitive or time consuming tasks, etc.

The full presentation content is available from SlideShare.

Below is a summary with selected slides to illustrate the topics:

• Enterprise Architect can be greatly customized to cater for a client or project, and it includes creating features using the API from scripts, add-ins, Excel macros, etc.
• Where EA already provides numerous features, there is still a need to create additional ones as illustrated below.

• The choice of using Scripting was supported by the need to frequently update and deploy new versions to a large group of users.

•  Having introduced the different types of scripts (project browser, diagram, normal), I discussed the need to apply naming conventions so users can clearly find the appropriate script to run.

• The usual way to use EA API is to call methods from the Object Model, e.g. get an element’s parent package element with the following VBScript method call: set parentPkg = Repository.GetPackageByID(curElement.PackageID).

• Alternatively SQL queries can be used …
  • To run complex queries.
  • To select specific elements, preventing time consuming loops.
  • To address performance issues related. Replacing a method call with SQL update reduced the execution time for ~1000 attributes from 120 minutes down to 4 minutes.
•  SQL queries can be used on the Repository object methods:
  • Repository.GetElementSet(query,2) : returns a collection of EA elements according to the SQL query
  • Repository.SQLQuery(query) : returns an XML formatted string value (SELECT queries only)
  • Repository.Execute(query) : runs a query (UPDATE/DELETE/INSERT)
• Care should be taken when running UPDATE/DELETE/INSERT queries as it can delete or break the model.
• Moving on Scripts helpers, I shared ways to address issues both from the developer and user perspective.
• Below is the publication process that has been defined (illustrated via the first demo on EA).

• With some scripts requiring to select a source or target folder to process or generate files, a common script feature made it possible to suggest the previously selected folder. Other users’ script helpers are illustrated below and were demonstrated in EA.

• Geert Bellekens’ free EA-Matic add-in has been used to automatically trigger scripts based on configured events e.g. before creating a connector.

• Having shared a few hints, I completed the presentation with a demonstration of custom scripts defined for a number of clients.

Note: this article is available in French here.

Requirements in Context

Thursday, September 13th, 2018 at 10:00 AM Pacific (1:00 PM Eastern)

Register: https://www.modernanalyst.com/Webinars/tabid/207/ID/5074/Requirements-in-Context.aspx

Scott Ambler, a key founder of the Agile movement accurately stated:
"If a requirement was misunderstood, all modeling decisions based on that requirement are invalid,

the code written is also in question, and the testing efforts are now verifying the application under the wrong conditions".

Topics covered include:

• Requirements across the entire landscape
• The semantics of Requirements
• Reuse Requirements
• Requirements traceability
• Requirements Management tools

Featured Speaker: Ramsay Millar, Business Architect

Use Requirements Documents to Create Elements in Enterprise Architect.

In their early states, requirements are often described in MS Word documents. Using Enterprise Architect, modelers can save themselves time and effort by dragging text descriptions onto a Requirements diagrams, which Enterprise Architect then uses to automatically create requirements elements with titles and descriptions.

1. To do this, select the header and requirement description in an external application like MS Word.
2. Drag and drop the text description onto a Requirements diagram. The first line of text is given to the element name. Any other lines of text are assigned to element notes.

This small tip can really simplify downstream development when preliminary requirements have been defined in text format.

There are also a number of other options available to model requirements from text documents such as:

1. importing a comma delimited CSV file,
2. creating document artifacts, copying and pasting your requirements descriptions, and then right-click relevant words to create elements (select: create | new | requirement).

These methods are further described in the following Requirements Management whitepaper.

Requirements Checklist

by Phil Chudley, Principal Consultant

There is a hidden gem in Enterprise Architect (I am using version 13), but this gem is available in previous versions (I believe version 11 and version 12).

This is an element called a Requirements Checklist, although it could be used as a checklist for other elements.

A Requirements Checklist allows the modeller to create a list of check-boxes, which can be used against an element (or elements), to manage at least the following:

• Element completeness.
• Element quality.

This article introduces the Requirements Checklist and illustrates how such an element can be used and customised.

Default Use

A Requirements Checklist element can be added to a model diagram (the element can be found on the Requirements Diagram Toolbox) or added directly to a package within the project browser.

When added to a diagram, the Requirements Checklist has the following appearance:

Double-clicking opens the following dialog:

Clicking on a checkbox will check the checkbox as shown below:

Then upon clicking Close, the Requirements Checklist element will display on a diagram as shown below:

Using the dialog invoked via double-clicking, the appearance of the check box can be modified as shown below:

Checked Item Style <none>	Checked Item Style Strikeout	Checked Item Style Greyed

Relating to an Element (or Elements)

Elements can be related to Requirement Checklist using any of the usual techniques in Enterprise Architect, namely:

• Quicklink on a diagram.
• Toolbox relationship on a diagram.
• Relationship Matrix.

Which Relationship to Use and which direction?

Using the diagram Quicklink, the modeller is presented with the following choices:

• Dependency.
• Trace.
• Information Flow.

Which relationship to choose to up to the individual modeller, but ideally, the modeller will choose a relationship that “makes sense” to all stakeholders in the project.

My own personal choice is Dependency drawn from an Element to the Requirements Checklist.

The most important issue is:

No matter what relationship is used and no matter which direction is used, the same type of relationship and the same direction must be used consistently throughout the entire model by all modellers.

The main reason for this statement is for the production of documentation and reporting (covered in a future newsletter).

Configuring the Requirements Checklist Element

Although not immediately obvious, is the ability to customise the list and text of the check boxes.

A modeller can define their own list of checkboxes by using the following steps:

1. Double-click the Requirements Checklist to show Dialog.
   
2. Right-click on a check box entry and select Edit (to modify), Delete (to remove) this checkbox item. An example of such a modification is shown below:
   
3. Click Close to apply the changes.
   

Re-using Requirements Checklist

Different elements may require different checklist elements, therefore I recommend the following modelling strategy:

1. Create a Package in which to create / store all the different configurations of the Requirements Checklist element. (A list of “master checklists)
2. When wishing to use one of these checklist elements:
   • Right-click a checklist element (or checklist elements) and select Copy to clipboard > Full structure for duplication.
   • Select another package in the project browser, right-click and select Paste Element(s) from clipboard.

Summary

In this article I have presented an overview of an often overlooked element in Enterprise Architect, namely the Requirements Checklist. I have also described how such elements can be customised and re-used from a library of “master checklists”.

In a future article I will describe some techniques for producing documents which detail elements and their related checklists.

Phil Chudley
Principal Consultant
Dunstan Thomas Consulting
@SparxEAGuru

You’ll find lots of useful Enterprise Architect videos on our YouTube Channel.

How to combine Sparx Enterprise Architect and BABOK to manage Requirements in a modern way?

Days when Business Analyst was using only Word and Excel applications together with e-mail program are slowly fading into the past. This is a good thing. There are many tools that allow us to work faster and smarter. One of them is my favorite Sparx Enterprise Architect. The tool so powerful and versatile that it's hard to find single person who used all of its features :-)

Personally, I used Enterprise Architect in my work for past several years to design IT systems and prepare documentation of them. I used a lot of built-in features of Enterprise Architect to streamline my work and improve quality of my deliverables. Among them Relationship Matrix, powerful template functionality for document generation, extensive support for Use Case modeling. 

Requirement attributes

Among many other things, BABOK Guide defines list of commonly used requirement attributes:

• Absolute reference: provides a unique identifier. The reference is not altered or reused if the requirement is moved, changed, or deleted.
• Author: provides the name of the person who needs to be consulted should the requirement later be found to be ambiguous, unclear, or in conflict.
• Complexity: indicates how difficult the requirement will be to implement.
• Ownership: indicates the individual or group that needs the requirement or will be the business owner after the solution is implemented.
• Priority: indicates relative importance of requirements. Priority can refer to the relative value of a requirement or to the sequence in which it will be implemented.
• Risks: identifies uncertain events that may impact requirements.
• Source: identifies the origin of the requirement. The source is often consulted if the requirement changes or if more information regarding the requirement or the need that drove the requirement has to be obtained.
• Stability: indicates the maturity of the requirement.
• Status: indicates the state of the requirement, whether it is proposed, accepted, verified, postponed, cancelled, or implemented.
• Urgency: indicates how soon the requirement is needed. It is usually only necessary to specify this separately from the priority when a deadline exists for implementation.

Source: BABOK Guide V3, page 45.

As it is stated, those are most commonly used, which means that this list is not written in stone and each Analyst must decides which to use. Actually, for this exercise we have a special task  in BABOK Guide named Plan Business Analysis Information Management.

The purpose of Plan Business Analysis Information Management is to develop an approach for how business analysis information will be stored and accessed.

Source: BABOK Guide V3, page 42.

Since I read the Mastering the Requirements Process: Getting Requirements Right (which was quite sometime ago) I extended my requirement attributes list with those two:

• Justification
• Fit Criteria

Justification is a rationale for requirement. It explains why requirement is needed by stakeholder(s). It is very important attribute as it allows to distinguish between real requirements and solutions requested by stakeholders that pretend to be requirements.

Fit Criteria's aim is to make sure that requirement is verifiable.  It means that there is defined way of proofing that the requirement is met. This attribute directly addresses one of the characteristics of a good requirement which is Testable. (Have you ever seen requirements like: "System must be easy to learn" or "System must be user friendly" and wondered What the hell this means? I bet you did! :-) )

Enhanced Requirement Attributes Addin for Sparx Enterprise Architect

Sparx Enterprise Architect does not support all of the mentioned above attributes out of the box. Some are there, but not all of them. You may add missing ones as TaggedValues in requirement element, but working this way on a daily basis is hard and miserable.

To address this problem I created Enhanced Requirement Attributes Addin for Enterprise Architect. In short ERA addin (addin means plugin). It adds new properties window which is dedicated only for Requirement type. When you double click on any Requirement element this new window will be opened by default. Properties for other element types will be opened in EA's default properties window.

Sometimes you may still want to open Requirement element in default properties window, just click 'Default properties' button, or press Alt+Enter keys on the selected element.

Requirement properties window aggregates in one place all most important attributes that were described above. This makes reading and editing a requirement very easy. Requirement properties windows supports:

• Some of BABOK / Volere additional attributes
• Rich edit functionality for Description attribute
• Key shortcuts (Ctrl+S - save & close  and Ctrl+W - close without saving)

Compatibility

All of the additional attributes are stored as TaggedValues of Requirement element. This a built-in functionality of Enterprise Architect. There is no custom solution for storing information. As you can see in the picture below, you can access and edit those attributes in normal properties window.

This means you may use ERA Addin without worrying about compatibility. You can be the only person on the project or in your organization using ERA Addin and other Analysts & Architects will still be able to view and edit Requirement without problems. Of course it will not be as easy and convenient as in ERA Addin, but important thing is that you will not break anything!

ERA Addin does not use any custom UML Profile, it works with default, built-in Requirement type. So you can start using it on your already created requirement models without any conversions or problems with migration. There is also no risk, if you will not like ERA Addin you will simply uninstall it, there will be no impact on your model.

Generation of documentation

ERA Addin was created with easy reporting in mind. It comes with a Requirements Details template that is used to generate documentation about all additional requirement attributes. Here you can download sample document with generated documentation about requirements in Stakeholder package.

Practical

ERA Addin is free to use for everybody including commercial purposes. It is redistributed under Creative Commons Attribution-NoDerivatives 4.0 International Public License.

Downloads

• Installer of ERA Addin together with Requirements Details template can be downloaded from here.
• Sample Enterprise Architect project can be downloaded from here.

Hippo Software’s new ‘EA for GUI Design’ course teaches delegates how to capture end user requirements and create wireframe diagrams to design the layout of user interfaces, mobile apps or websites.

http://www.hippo-software.co.uk/pages/EAforGUIDesign.htm

Updated 9th June, 2016: Covering all new features available in Enterprise Architect 12.1

Enterprise Architect integrates Requirements Management with other software development disciplines, by creating requirements directly in the model. Requirements Management is built into the core product, solving many of the issues of traceability, interdisciplinary team divisions, integration with change and configuration management systems.  Read the following whitepaper for more information: