What is simple but functional usability

SOPHIST BLOG

In the last part of the blog series we dealt with what a requirements list can look like and how requirements can be determined from the user-centered scenarios. This part is about completing this list from the user's point of view and documenting the user interactions in the form of processes, so-called usage processes.

Complete the list of requirements

To derive further requirements from the persona profile, simply look at the individual behavior variables and derive requirements from them. The behavior variables are also suitable with regard to the extraction of non-functional requirements, but the variables are most suitable mental model and Context of use. Examine the content for implicit requirements and write them down in the requirements list.

Here is an excerpt from the list of requirements based on the persona profile for the persona Regular guest:

Context of useconditions
Environment and background noise:
The background noise is loud to very loud, depending on the guests. Because of the conversations at each of the tables, there is always a certain volume level.
The system must offer the regular guest the opportunity to regulate the volume.

Document functional requirements as usage processes
All requirements in the requirements list form the basis of the functional and non-functional requirements from the User view.

The functional requirements correspond to the actual user interactions with the application and thus virtually describe the “functional elements” that a user needs to display or edit data. But be careful: This does not mean graphic control elements, but rather only "information or function blocks" (i.e. actions) that are important for the user! We represent these blocks as actions in the activity diagram. From all identified user interactions, the processes can then be documented from the user's point of view. And how do we do that? - Exactly: with activity diagrams of course! The flowcharts are then called usage processes and look like this, for example:

As the graphic shows, only the user interactions are modeled and no system activities. For example, the first action is not modeled as a system event, but as a (user) action.

The usage processes are created for all personas and then summarized. The usage process is thereby enriched with the individual perspectives and becomes more and more complete.

Finally, the comparison and addition of the activity diagram from requirements engineering, which has already been created as a result of the requirements collected using determination methods, then follows.

The modeling of activity diagrams is one of the components of the curriculum for the Certified Professional for Requirements Engineering in Foundation Level or Advanced Level Modeling. If you want to know more about it, you can find our training catalog here.

The result artifacts, especially the modeled usage processes, are a well-founded supply for the colleagues from the design department, who can then deal with the presentation and the specific design of the application. If you wish, you can also include in the documentation the priority with which which data is to be displayed or processed, provided this information is known. Then almost nothing can go wrong in terms of acceptance!

To round off the topic of requirements and user friendliness, in the next blog we will go into how specialist classes and attributes can be derived from the persona profiles, which then complete our RE artifact concept model (class diagram). Sounds exciting to you? Then read us again, we look forward to your visit!

Sincerely,

Your SOPHIST

Swell:
Chris Rupp, Stefan Queins and the SOPHIST: UML 2 crystal clear, Hanser Verlag, Munich 2012

Chris Rupp and the SOPHISTs: Requirements engineering and management - Professional, iterative requirements analysis for practice, Hanser Verlag, Munich 2009.

Goodwin, Kim: Designing For The Digital Age. Wiley Publishing, Inc., Indianapolis, 2009.

 

 

 

 

 

This entry was posted in Technical and tagged Diagram, Non-Functional Requirements, Personas, RE (Requirements Engineering) by Stefanie von Alt. Permanent link to the entry.