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 

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.

A series of global knowledge exchange sessions will be held during the month of July, the inaugural Sparx University Week will be hosted by Sparx Systems Japan, Sparx Systems Central Europe, and Sparx Services North America.

The format of each course will be varied, depending on the subject, audience and location; sessions being held in July feature a mix of both online and face-to-face seminars and courses.

It is anticipated that Sparx University Week will be run on a global basis every few months, in conjunction with Sparx Systems Sister and Services Partner network.

Seminars being held in Japan have already proved to be popular, requiring an additional seminar scheduled for early August to cater for market demand.

Sparx University Week Schedule:

Requirements are fundamentally important as they are about building the right system.

Yet the failure of requirements is the primary cause of project failure.

How many times do we forget passwords AND user names? This is a clear example of the risk associated with the reliability of the human memory and associated human error. Let's consider the management of the myriad detail accumulated throughout the requirements planning process and the steps of Eliciting, Documenting, Analysing and Communicating. Oh, and let's not forget Tracking, Validating and Verifying!

So spare a thought for the Business Analyst, whose whole focus is on capturing requirements, to ensure successful project outcomes. Or to put it another way, the task of translating the needs, wants and expectations, of all user stakeholders, into technical language for the developers and others, to ensure that they - the users - are are going to get the functionality, that they need, want and expect from a system. This is not a petty task and it can take months. Meanwhile, there is the probability, due to complexity, that not all of the requirements are going to be addressed because of a number of factors, not least, their having been lost or forgotten.

However if effectively managed, requirements identification and supporting traceability improves the overall project outcome, simply because time will be saved, less money will be spent, and most importantly, the customer will be happier.

The Requirements management process has seen much change in the past 20 years and two of the most obvious are the involvement of the customer in all phases of the process and that the requirements process itself is now dynamically linked into an agile culture of continuous integration and delivery. The increase in software defined business, is driving the growth and importance of application delivery within encumbent enterprise and with ever more startups disrupting their industries, enterprise needs greater levels of automation to compete and to deliver quality, quicker than competitors.

In the past Requirements were captured in hand written paper documents, which in time, were augmented with spreadsheets and word documents. The rigour of the process left space for improvement. Today, requirements associated material is held in a central repository and updates are visible to all stakeholders. Enterprise Architect can capture all of the different information that records requirements information, be it from Word, Excel, Visio, handwritten notes, video or audio.

In the past Requirements was an isolated process that had built in “wait” or handover periods before being consumed by the other phases of the project life cycle. Today these gaps are closed with automation and requirements are integrated across the development life cycle, with many other functions. The end result is less time to delivery.

Organisational cultures of resistance to change, identified by a bulwark of divisional and departmental silos and a reluctance to co-operate, increased the risk of failure for the change process. Today, technology based collaborative platforms are increasingly being adopted as they are inclusive, breaking open silos, empowering stakeholders and drawing them together.

The progress of development projects lacked transparency for most key stakeholders, right to the point when business took delivery. Whatever visibility the stakeholders had, was gathered from assumptions, rather than from objective data. Today, key stakeholders form an integral part of the development team and have access to progress charts and dashboard metrics.

In the past, the management of shareholder supported organisations held tightly to the overarching goal of ensuring change was minimised or avoided, so as to maintain the value of their shares. Today the digital imperative, as opposed to the business imperative, says be prepared to change, or risk oblivion.

These examples are a reflection of the changes in the Requirements Management process, which in the development model of today, supports iterative requirements gathering and continuous delivery of software. It has become an Agile practice approach, being adopted to address the challenge of digital transformation. This collaborative, iteration based business lifecycle, between requirements and stakeholders, has given rise to DevOps, a strategy for managing continuous change.

Enterprise Architect is unique in its ability to support Requirements throughout the development lifecycle and to deliver the benefits of the Agile practice approach. Requirements can be defined in the model, or imported from other tools including Visio.

Recently, through agreement with IIBA, Sparx Systems is in the process of developing the Enterprise Architect Guide to BABOK Implementation. Through the power of this collaborative, visual modeling platform, the extension provides the Business Analyst with a fully augmented BABOK user experience.

On March 29, 2017, the public Beta launch of Tools & Techniques for BABOK Guide v3 was announced - please visit the Sparx Systems website for more details.

Enterprise Architect provides many features for requirements management. It allows team to create and update requirements, trace their solution, maintain whole requirement life cycle.

We need sometimes work with requirements “outside” the Enterprise Architect. Especially when we discuss them with customers. We can of course generate documents from RTF templates as basis for meeting, which is suitable for most cases. At the level of project management, when it comes to project scope and overall state of requirements, is better to have requirement list in form of an Excel spreadsheet. Project manager can clear report requirement status to the customer and quickly change the list according to the results of the meeting. Next step is to save changed list back to Enterprise Architect.

We tried package CSV Import/Export utility but it was not suitable for us. CSV format is prone to data errors and we needed to split some data cells into more requirement properties.

So we decided to write our own bridge for requirement data interchange between Excel spreadsheet and Enterprise architect repository.

Solution

Our Excel requirements template has several columns. Mapping to requirement attributes is as follows:

The bridge is implemented as Excel addin. It is written in Visual Basic and stored in Requirements.xlam file. When you add it to Excel, new tab CCA appears in ribbon. It has two commands “to Excel” for importing requirements from Enterprise architect repository to Excel spreadsheet and “to EA” for saving requirements from Excel back to EAP.

Importing requirements to Excel

Bridge is written for requirements template MyProjectREQ.xlsm. Copy it into new file and open this file. Press “to Excel”.

File open dialog appears, choose your project EAP file. Program then show “Enter prefix” dialog to filter imported attributes. Enter the prefix (for example “REQ”) or leave the value empty for all requirements. Program uses standard Enterprise Architect search “Requirements”.

Sheet is filled with requirements. Notice the cell D3 – it contains EAP filename. When you run command “to Excel” again, you will be not asked for EAP file name, the file in cell will be used. The same applies for saving cells back to Enterprise Architect.

Column “J” is hidden – it contains requirement GUIDs for subsequent updates.

Saving requirements to Enterprise Architect

After you made changes in requirement list in your spreadsheet, you can save them directly to project EAP file. Press “to EA”.

Program shows dialog with EAP package structure. Choose your requirements root package. New requirements (requirements without GIUD) will be inserted into this package.

Saving starts immediately after your select the package.

Data transformations

In our Excel template we use ID and Description for requirement code and description. In Enterprise architect we use Requirement name and notes. Enterprise architect has an alias attribute, which can store requirement code, but it is not useful, because we have to see this code in Project browser. So we have to transform

to

This is done using simple VBA functions. Code is delimited by “-“ character. Requirement name is derived from first sentence in description.

Conclusion

This article is mentioned as other example of extending Enterprise architect. It is a real life example, we use it in our company for many projects.

If it is suitable for you, use it! Any comments are welcome!

Petr Přibyl

CCA Group a.s.

This email address is being protected from spambots. You need JavaScript enabled to view it.

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:

July Webinar Announced by Sparx Systems, register Today:

http://www.sparxsystems.com/resources/webinar/webinar-registration.html

Business requirements are often stored as text documents, resulting in poor traceability, lost requirements and flawed software design. The Specification Manager in Enterprise Architect 11 can help address issues of traceability while providing the convenience of a simple in-place text editor. Create, edit and review elements as text representations of objects in the model, using a process that is well understood and familiar to business analysts and management professionals alike.

In this webinar you will learn how to:

As practicing Enterprise Architect consultants, we have the opportunity to interact with various corporates for training, consulting and providing Enterprise Architect demonstrations. We encounter the following standard queries:

“We have lots of Requirements and Use Cases in Microsoft Word ™ documents. Can we import them into Enterprise Architect “?

“Can our Business Analysts continue to work in Microsoft Word™ which they are familiar with and then have the artifacts imported into EA?

These queries highlighted the need for a standard Word importer that helps the Enterprise Architect users to

Import the existing Requirements and Use Case Models in Microsoft Word ™ format into Enterprise Architect as elements.

Enable the Business Analysts to work with the Microsoft Word Documents™ and still leverage the power of Enterprise Architect for Traceability, Impact analysis, Version control and much more……

EAWI (Enterprise Architect Word Importer) is here to address the above challenges.

*EA Word Importer lets you import your requirements, Use Cases and other information from your Word documents into Enterprise Architect as model elements.*

      What do we solve?

How does it work?

Check out the listing on the Sparx Systems website:
 
http://www.sparxsystems.com/products/3rdparty.html#WordImporter

or Visit:

www.eamwordimporter.com