Book a Demo

Please note : This help page is not for the latest version of Enterprise Architect. The latest help can be found here.

Prev Next

Stakeholder Workshops

The requirements analyst or business analysis is charged with the difficult task of eliciting requirements, which necessitates excellent communication with the stakeholders, including the customer and the analysis team. One very successful way of facilitating the elicitation of the stakeholders' needs is to run a workshop with all the key stakeholders present. The analyst's skills as a communicator, diplomat and mediator are important to create a collaborative and respectful environment conducive to the exploration of the stakeholders' needs and concerns. It is imperative that the analyst uses terminology that the stakeholders understand and displays an understanding or a willingness to learn the elements that make up the domain.

There is sometimes a misconception that what will be articulated is a set of clearly defined requirements that can be entered into the tool as Stakeholder Requirements; this is far from the reality of what happens. Stakeholders will typically articulate a wide range of ideas, including Policies, Business Rules, Data definitions, Project Management Constraints, Functional Requirements, Business Requirements, existing system problems and even suggested solutions. Even when an external consultant is used to run these meetings the analyst will not have time to categorize all of these statements in the meetings. What is needed is a way for the scribe who is tasked with documenting the statements to get them into the tool without any concern for what type of information is being recorded. Having them recorded in the tool rather than scribbled in the analyst's notebook is best practice because it allows them to be displayed during the meeting and for stakeholders to see each others' comments.

Enterprise Architect has a number of facilities that can help with these workshops. One method that is very effective is to use the MindMapping diagram to record the stakeholders statements, which is very effective because it is a well known method and doesn't introduce any of the formality that comes with modeling languages such as UML.

MindMapping MDG Technology in Sparx Systems Enterprise Architect.

As important terms are uncovered they could be entered into the Project Glossary, and even if there is not time to discuss and debate the agreed meaning, the words will act as an initial list of important entities in the domain. Alternatively, the terms could be created in a Domain Model and related to each other with connectors that describe the important relationships between the terms.

The stakeholders can also be modeled and their organizational relationship to each other can be described in a diagram. This is a useful technique that allows key stakeholders to locate themselves in the models, which creates buy-in.

There are a number of situations where it is useful to define requirements inside an element. Requirements are typically created as elements in the Specification Manager, or as part of a Requirements diagrams or directly in the Project Browser. Enterprise Architect allows you to move (copy) an External Requirement into an element creating an Internal Requirement. This is quite commonly done so down-process workers like developers can see the Functional and Non Functional Requirements when working with a Use Case or Component. It can also be used as a device to list a series of applicable requirements under an element in a report. For example high level Business Requirements could be moved internal to a Business Process and if a report were generated the Business Requirements would be listed directly under the Business Process.

Mind Mapping Diagram

A Mind Mapping diagram can be used to record the stakeholder's statements during an elicitation workshop. The statements are not categorized but simply recorded and later during the analysis phase of Requirement's development they can be converted to the appropriate elements or retained and the Requirements can be traced back to the topics effectively creating a record of how the Requirement was derived. This is a useful technique that shields the stakeholders from needing to know the modeling languages and allows them to concentrate on articulating their needs, it also frees the analyst up from concerns about which element to use to model the statements. This step is usually performed in the analysis phase of the Requirement's Development process.

Mind Mapping diagram modeling Business Stakeholder Collaboration in Sparx Systems Enterprise Architect

Glossary

Prior to a workshop an analyst can populate the Project Glossary with the existing terms and their meanings that have been gleaned from reading project documentation such as a Business Case or Vision Document. During the workshops, as new terms are uncovered they can be added to the Glossary and their definitions can be discussed and entered or deferred until later in the analysis phase.

Entering a glossary item in the Glossary Item Details dialog.

Domain Model

A domain model will act as a guiding model for discussions with many stakeholders and ideally a skeleton model should be created prior to the commencement of any workshops. The Domain Model should be kept simple and domain elements should be given a name and a description or a responsibility and initially only important connections should be made between elements. As the workshop progresses new elements will be uncovered and can be added directly to the model giving the stakeholders confidence that their needs and concerns are being addressed and managed well. Enterprise Architect allows domain models to be created using the UML Class diagram.

Business Modeling, Domain models in Sparx Systems Enterprise Architect

Discussions

The Discuss & Review window is a convenient facility that allows commentary to be made on elements without contaminating the notes with discussions that ultimately don't contribute to the integrity of the model. Modelers often place notes on diagrams or write questions in the element Notes fields, and these are distracting and must be removed when formal documentation is generated from the model. The Discuss & Review window allows a modeler to initiate a discussion and others to reply. It is a perfect way to discuss requirements.

The Element Discussion facility can be used to discuss requirements, in Sparx Systems Enterprise Architect.

The Discuss & Review window conveniently displays the Discussions for all elements in the repository.