Models Used to Document Requirements

One of the most important aspects of the requirements engineering discipline is to communicate knowledge and ensure that all stakeholders have a clear and unambiguous understanding of the problem and the proposed solution. This can be challenging because the stakeholders typically cross organizational boundaries and have a myriad of backgrounds spanning from senior business executives to low level engineers. This heterogeneous audience will need a variety of communication devices to ensure the various stakeholders are able to engage with the requirements and are able to understand them. Enterprise Architect is a modeling platform with a formidable range of tools and features that can be used to model requirements in almost any way. These include modeling stakeholders, requirements, user stories, user interfaces and a wide range of other models.

Requirements models

Model	Description
Textual Requirements	Textual requirements can be modeled using the Requirement element, and users can choose to work with the elements in a text tool such as the Specification Manager, directly in the Project Browser in a hierarchy, or visually in a diagram. The Requirement element can be connected to other elements to describe a hierarchy of requirements, or to business goals or Use Cases and User Interface models. Through the Specification Manager Enterprise Architect allows the modeler to create, analyze and manage requirements in a text tool that resembles working in a spread sheet but which is more powerful and gives the analyst access to other models including the glossary and the domain models.
Stakeholders	Stakeholders can be modeled using UML Classes and descriptions can be added that describe the stakeholder. Stakeholders are possibly the most important entities in the requirements engineering discipline and creating elements to represent them in the model allows them to be used as the owner of requirements and business rules. They can be placed onto diagrams allowing them to be visible in elicitation and prioritization workshops.
Glossary	A Glossary can be created and managed using the Project Glossary, ensuring that important project and domain terms are accessible right inside the model. These terms can be inserted into the Notes fields of elements including Use Case and User Story descriptions.
Use Cases	Use Cases can be modeled in a Use Case diagram and can be connected to a range of other elements including user interface models, User Requirements and Components. The Use Cases can be kept light-weight by just completing the description or they can be fully-dressed using the powerful Scenario Builder Tool. Use Cases often present a problem for the requirements analyst because the diagrams are typically drawn in a diagramming tool and the text is written in a word processor, making it inaccessible to other model elements. Using Enterprise Architect's Scenario Builder the Use Case descriptions can be completed inside the Use Case itself inside the modeling tool. The tool can also produce behavior diagrams that represent the Use Case Scenarios automatically from the model.
User Stories	User Stories can be modeled using a stereotyped Use Case element and the text of the story can be completed in the description field. The Users and Personas can also be modeled and related to the story. Enterprise Architect allows the modeler to work with the stories in text form or in diagrams. Functional requirements can be added in preparation for handing to the development team for an iteration and these can be managed inside or outside the user story.
Domain Models	Domain models can be modeled using a UML Class diagram. The important entities in the business domain can be recorded, detailed and related to other elements. Creating domain models early in a project helps stakeholders make sense of all the important entities in a domain and the models can be used to generate a Data Dictionary. The domain elements can be created as links in textual statements of requirements, creating an articulated model that facilitates communication and understanding.
Process Models	Business processes are a useful way of recording the activities of a business including the events that trigger them to happen, the information that is produced or consumed, the outcomes and the roles that carry out the work. Enterprise Architect supports BPMN, UML and SysML Activity diagrams that can be used for this purpose.
Storyboards	Storyboards can be modeled using graphic elements in diagrams and a slide-show can be created to walk through the story.
Wireframes	Wireframes can be modeled using the powerful Wireframing diagram, which has built-in support for popular hand held devices such as Apple and Android phones and tablets, and also for modeling dialog windows and web pages. Using Enterprise Architect's Wireframing tool, an analyst can create powerful models of the arrangement of the application's content, describing interface elements and navigational mechanisms. Analysts and experienced designers have typically worked in isolation from other disciplines, but using Enterprise Architect the models can be created and maintained inside the same tool as the other requirement models, allowing traces to be created between other elements and the controls and content in the Wireframes.
User Profiles and Personas	User Profiles and Personas can be modeled using a stereotyped Actor element which allows descriptions and properties to be added that describe the persona.
System Events and Responses	A system will typically respond to a number of events and can also be responsible for creating events such as raising an alert or sending a data stream. These can be modeled in Enterprise Architect using BPMN or UML and SysML Activity diagrams.
System Interfaces	System Interfaces can be modeled using Provided and Required Interfaces and Ports on a Component diagram which describe how the software or hardware system interacts with other systems or how the internal Components of a system communicate. Enterprise Architect has rich support for modeling the interfaces and error codes and other behavior can be modeled. The interfaces can be linked to data definitions and Application Programmer Interface (API) specifications and a range of model elements including Use Cases and Requirements. The Interfaces can be added to documentation such as the System Requirements Specification and this document can be automatically generated from the model.