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 workshop. 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.

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 a 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.

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 powerful 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.

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 till later in the analysis phase.

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.

Element Discussions

The Collaborate 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 Collaborate window allows a modeler to initiate a discussion and others to reply. It is a perfect way for discussing requirements.

A Discussions window conveniently displays the Discussions for all elements in the repository.