Usage and use cases for Visio

Visio is important for product managers to comb the product's internal logic and user operations processes, especially during the product documentation process, where Visio draws user-action flowcharts that help engineers better understand product logic to implement product development. Visio's rich plug-ins can also be user-drawn Ueser case to facilitate product project team members to better understand the user and thus guide product design.

Writing user documents commonly used software is Word, where use case diagram and flowchart of the production software is commonly used in Visio, of course, also useful Axure RP software production, such as the following third step flowchart is made with Axure Rp.

Use case Documentation is a document composed of multiple use cases, mainly used for technical development and testing, he is an important auxiliary document in PRD, used to explain the functional logic of a link, such as user registration, activity registration and other functions are required use case auxiliary description. The writing time of a use case document is usually written in parallel with the PRD document after prototyping.

There are two associated files in a use case document , which are use case diagrams and flowcharts . use case diagram is a class diagram representation of UML, which describes the product function from the user's point of view, and points out the operation rights of the user in each function of the product. Flowchart is the process of describing the function of a product by means of wireframe graphics, mainly describing the sequence of execution, branching and looping logic of the function.

A complete use case document consists of the following three points, where the 3rd "use case" is the part that describes the functional logic and how many use cases are determined by the number of features.

The approximate components of the use case documentation are as follows:
1, change the record: Each change notes record, with PRD document.
2. Role Description: Describe each role in the participating system
3. Use case: The 4th step in the next step, where the flowchart in step 3rd is inserted directly into the Flowchart table item in step 4th.

The template format of a use case document is like the above three points, drawing a table from a Word document, composing a use case description in a table, formatting and styling the table, and referencing the example diagram below.

1. The first step in writing a use case document is to indicate the roles (participants) and role descriptions (roles) used in the product. (Image below)

2, the second step is the use case diagram to indicate the role in the front and back of the use case relationship. (Image below)

3. The third step is to indicate the process of the role in each function link in the way of flowchart. (see below for an example of the event registration)

4. The fourth step is to combine the above three steps with the use case document, and compose the use case description of each function link. (Image below)

Table Description:
4.1, use case name: The name of this function link
4.2. Use Case Number: The number of the use case in this product
4.3. Behavior role: Participate in or manipulate (execute) the role of the function
4.4, brief description: Use the minimum text to describe the needs of the use case
4.5. Preconditions: Participation or operation (execution) prerequisites for this function
4.6, after the condition: after the completion of the results of the conditions
4.7, Flowchart: The function of the role of the activity process (process) diagram (figure in the third step)

The use case descriptions shown above are relatively simple, are the most commonly used and basic use case descriptions, and of course have a slightly more complex case documentation that describes the usage scenarios, event streams, and information fields in detail, as well as some use case documents that insert the product interface renderings.

The usage scenario primarily describes the behavior of the role when using the product in different situations, depending on the situation or problem to give the appropriate system feedback. The event flow is similar to a flowchart, except that it describes the active process of a character by means of text. The information field is primarily the data field that is used to describe the use case.

These more descriptions depend on the individual's habits, and the ultimate goal is to describe clear product logic, so my principle is to use less text to describe the more clearly defined requirements.