Юзер кей что это
key user
Смотреть что такое «key user» в других словарях:
Key-User — Der Begriff Key User wird im Zuge der Einführung betriebswirtschaftlicher Software (z. B. ERP Systeme) genutzt. Der Key User selbst ist ein Mitarbeiter des Unternehmens, welches die betriebswirtschaftliche Software einführt. Der Key User… … Deutsch Wikipedia
Key exchange — is any method in cryptography by which cryptographic keys are exchanged between users, allowing use of a cryptographic algorithm. If Alice and Bob wish to exchange encrypted messages, each must be equipped to decrypt received messages and to… … Wikipedia
Key management — is a term used to describe two different fields; (1) cryptography, and (2) physical key management (or electronic key management) within building or campus access control.In cryptography, key management includes all of the provisions made in a… … Wikipedia
KEY-Record — KEY Resource Records dienen der Propagierung öffentlicher Schlüssel durch DNS. KEY Records wurden im Rahmen von DNSSEC (DNS Security) verwendet, ab 2004 aber durch die nahezu identischen DNSKEY Resource Records ersetzt. Inhaltsverzeichnis 1… … Deutsch Wikipedia
KEY Resource Record — KEY Resource Records dienen der Propagierung öffentlicher Schlüssel durch DNS. KEY Records wurden im Rahmen von DNSSEC (DNS Security) verwendet, ab 2004 aber durch die nahezu identischen DNSKEY Resource Records ersetzt. Inhaltsverzeichnis 1… … Deutsch Wikipedia
User environment management — (also abbreviated to UEM) is a computing term used to describe the management of a users experience within their desktop environment.The user environmentIn a modern workplace an organisation grants each user access to an operating system and the… … Wikipedia
Key Sounds Label — Key ist ein japanischer Spieleentwickler unter dem Publisher Visual Art’s und bekannt für seine dramatischen und handlungsgorientierten Ren’ai Adventures. Keys Debütwerk Kanon kombinierte eine komplexe Handlung mit moderner Anime Grafik und… … Deutsch Wikipedia
Key performance indicator — Key Performance Indicators (KPI) are financial and non financial metrics used to help an organization define and measure progress toward organizational goals [ [http://management.about.com/cs/generalmanagement/a/keyperfindic.htm Key Performance… … Wikipedia
User Datagram Protocol — (UDP) is one of the core protocols of the Internet Protocol Suite. Using UDP, programs on networked computers can send short messages sometimes known as datagrams (using Datagram Sockets) to one another. UDP is sometimes called the Universal… … Wikipedia
user key
Смотреть что такое «user key» в других словарях:
Key exchange — is any method in cryptography by which cryptographic keys are exchanged between users, allowing use of a cryptographic algorithm. If Alice and Bob wish to exchange encrypted messages, each must be equipped to decrypt received messages and to… … Wikipedia
Key management — is a term used to describe two different fields; (1) cryptography, and (2) physical key management (or electronic key management) within building or campus access control.In cryptography, key management includes all of the provisions made in a… … Wikipedia
KEY-Record — KEY Resource Records dienen der Propagierung öffentlicher Schlüssel durch DNS. KEY Records wurden im Rahmen von DNSSEC (DNS Security) verwendet, ab 2004 aber durch die nahezu identischen DNSKEY Resource Records ersetzt. Inhaltsverzeichnis 1… … Deutsch Wikipedia
KEY Resource Record — KEY Resource Records dienen der Propagierung öffentlicher Schlüssel durch DNS. KEY Records wurden im Rahmen von DNSSEC (DNS Security) verwendet, ab 2004 aber durch die nahezu identischen DNSKEY Resource Records ersetzt. Inhaltsverzeichnis 1… … Deutsch Wikipedia
User environment management — (also abbreviated to UEM) is a computing term used to describe the management of a users experience within their desktop environment.The user environmentIn a modern workplace an organisation grants each user access to an operating system and the… … Wikipedia
Key Sounds Label — Key ist ein japanischer Spieleentwickler unter dem Publisher Visual Art’s und bekannt für seine dramatischen und handlungsgorientierten Ren’ai Adventures. Keys Debütwerk Kanon kombinierte eine komplexe Handlung mit moderner Anime Grafik und… … Deutsch Wikipedia
Key performance indicator — Key Performance Indicators (KPI) are financial and non financial metrics used to help an organization define and measure progress toward organizational goals [ [http://management.about.com/cs/generalmanagement/a/keyperfindic.htm Key Performance… … Wikipedia
User Datagram Protocol — (UDP) is one of the core protocols of the Internet Protocol Suite. Using UDP, programs on networked computers can send short messages sometimes known as datagrams (using Datagram Sockets) to one another. UDP is sometimes called the Universal… … Wikipedia
Key server (software licensing) — Key server for software licensing is a colloquial or generic description that refers to a centralized computer software system which provides tokens, or keys, to client computers in order to enable licensed software to run on them.In 1989,… … Wikipedia
Key strengthening — In cryptography, key strengthening or key stretching refer to techniques used to make a possibly weak key, typically a password or passphrase, more secure against a brute force attack by increasing the time it takes to test each possible key.… … Wikipedia
user key
1 user key
Тематики
2 user key
3 user key
4 user-defined key
ключ шифрования, определяемый пользователем
ключ пользователя
—
[Л.Г.Суменко. Англо-русский словарь по информационным технологиям. М.: ГП ЦНИИС, 2003.]
Тематики
Синонимы
Тематики
5 user authentication key
абонентский аутентификационный ключ
Зашифрованная последовательность, которая обычно хранится вместе с регистрационными данными пользователя в ПЗУ абонентской станции.
[Л.М. Невдяев. Телекоммуникационные технологии. Англо-русский толковый словарь-справочник. Под редакцией Ю.М. Горностаева. Москва, 2002]
Тематики
6 user defined key
ключ пользователя (для некоторой процедуры, операции)
определенная пользователем клавиша (терминала)
—
[Е.С.Алексеев, А.А.Мячев. Англо-русский толковый словарь по системотехнике ЭВМ. Москва 1993]
Тематики
Синонимы
7 user-programmable structure key
Тематики
8 user-entered key
Тематики
9 user-selected key
Тематики
10 user-assigned key
Тематики
11 user-authorized key
Тематики
12 user-defined key
13 user-definable key
14 user-definable key
15 user-defined key
16 user-defined key
17 User Data key
18 User Sw. key
19 user’s personal key
20 user-assigned key
См. также в других словарях:
Key exchange — is any method in cryptography by which cryptographic keys are exchanged between users, allowing use of a cryptographic algorithm. If Alice and Bob wish to exchange encrypted messages, each must be equipped to decrypt received messages and to… … Wikipedia
Key management — is a term used to describe two different fields; (1) cryptography, and (2) physical key management (or electronic key management) within building or campus access control.In cryptography, key management includes all of the provisions made in a… … Wikipedia
KEY-Record — KEY Resource Records dienen der Propagierung öffentlicher Schlüssel durch DNS. KEY Records wurden im Rahmen von DNSSEC (DNS Security) verwendet, ab 2004 aber durch die nahezu identischen DNSKEY Resource Records ersetzt. Inhaltsverzeichnis 1… … Deutsch Wikipedia
KEY Resource Record — KEY Resource Records dienen der Propagierung öffentlicher Schlüssel durch DNS. KEY Records wurden im Rahmen von DNSSEC (DNS Security) verwendet, ab 2004 aber durch die nahezu identischen DNSKEY Resource Records ersetzt. Inhaltsverzeichnis 1… … Deutsch Wikipedia
User environment management — (also abbreviated to UEM) is a computing term used to describe the management of a users experience within their desktop environment.The user environmentIn a modern workplace an organisation grants each user access to an operating system and the… … Wikipedia
Key Sounds Label — Key ist ein japanischer Spieleentwickler unter dem Publisher Visual Art’s und bekannt für seine dramatischen und handlungsgorientierten Ren’ai Adventures. Keys Debütwerk Kanon kombinierte eine komplexe Handlung mit moderner Anime Grafik und… … Deutsch Wikipedia
Key performance indicator — Key Performance Indicators (KPI) are financial and non financial metrics used to help an organization define and measure progress toward organizational goals [ [http://management.about.com/cs/generalmanagement/a/keyperfindic.htm Key Performance… … Wikipedia
User Datagram Protocol — (UDP) is one of the core protocols of the Internet Protocol Suite. Using UDP, programs on networked computers can send short messages sometimes known as datagrams (using Datagram Sockets) to one another. UDP is sometimes called the Universal… … Wikipedia
Key server (software licensing) — Key server for software licensing is a colloquial or generic description that refers to a centralized computer software system which provides tokens, or keys, to client computers in order to enable licensed software to run on them.In 1989,… … Wikipedia
Key strengthening — In cryptography, key strengthening or key stretching refer to techniques used to make a possibly weak key, typically a password or passphrase, more secure against a brute force attack by increasing the time it takes to test each possible key.… … Wikipedia
Юзеркейсы: что это такое и как их писать, чтобы вам поверили
Практика показывает, что продать текстом финансовые услуги гораздо сложнее, чем швабры. Но правильно составленный юзеркейс может и то, и другое. Наш автор Саша Ежова (признанный мастер юзеркейсов) составила подробный гайд для внутренней редакции агентства, как писать достоверные пользовательские истории. Здесь публикуем его в сокращенном виде и с примерами.
Это история от первого лица, герой которой рассказывает о своем опыте покупки и использования каких угодно продуктов или услуг – начиная от кредитных карт, заканчивая онлайн-кинотеатрами и квартирой от конкретного застройщика. Что делать, если у вас нет такого опыта? Это не проблема и нет, обманывать никого не придется. Для убедительного и честного текста нужно будет только собрать «жирную» фактуру.
Опишите собственный опыт, если вы уже пользовались или пользуетесь тем самым товаром. Если же сервис или продукт вам не знакомы, обязательно попросите прислать его на тест или предоставить промо-доступ на несколько дней. С некоторыми темами, например кредитов и недвижимости, дела обстоят сложнее, но и о них я позже расскажу.
Пообщайтесь с коллегами, знакомыми, друзьями, друзьями друзей и коллег, незнакомцами в профильных группах на Facebook или Telegram. Обычно я начинаю с коллег и далее иду по цепочке. Как-то мне достался сложный юзеркейс про рефинансирование кредитов. У меня такого опыта нет, но он был у другой сотрудницы агентства. Даже если у человека нет времени на мини-интервью, можно отправить вопросы в мессенджере и в ответ получить голосовые сообщения.
Важно: опыт людей не обязательно будет на 100 % совпадать с темой материала. Это значит, что фактуру придется еще доработать с учетом информации из брифа.
В профильных группах в соцсетях не обязательно объяснять, что пишешь статью — зависит от масштабности вопроса. Если нужно уточнить какие-то мелкие детали, я просто спрашиваю в лоб в комментариях или чате, мол, ребята, а какой у вас опыт в использовании этого продукта?
Нырните во всевозможные форумы и читайте отзывы пользователей. Это особенно помогает при изучении каких-то сложных продуктов. Однажды я писала для застройщика, и герой должен был описать плюсы и минусы одного из ЖК. Вот, например, один из плюсов, на который меня вдохновил отзыв с форума:
В тех же отзывах ищите негатив и очень аккуратно добавляйте его в текст, иначе юзеркейс не получится достоверным. Минусы добавляют реалистичности, но с ними нужно быть осторожными: меньше эмоционального текста, больше коротких фактических предложений. Когда у «минуса» нет никакой эмоциональной окраски, он воспринимается легче и меньше бросается в глаза.
Позвоните в компанию под видом клиента. У того же ЖК на сайте указана возможность онлайн-бронирования квартир: описано, как это сделать, ниже – форма, но непонятно, что именно это дает покупателю (то есть нашему читателю). Такие детали обязательно стоит уточнять и объяснять в тексте.
Вот как это подали мы в статье от лица Паши, руководителя отдела разработки в одной крупной IT-компании:
Не забывайте подписывать картинки и скриншоты — да, вообще все, даже самые, казалось бы, очевидные. Это дополнительный и важный способ коммуникации с читателем.
Объясняйте, почему герой принимает то или иное решение. Здесь я говорю о сторонних вещах, которые тоже нужно пояснить. Помните, я искала плюсы ЖК? Так вот, нашелся еще один на очередном форуме по недвижимости.
Вот так было бы плохо:
А вот так уже хорошо:
Пишите практически так же, как говорили бы вслух (в рамках разумного) или писали в социальных сетях. Да, даже в самых серьезных юзеркейсах допустимы такие слова и словосочетания, как «ноут», «капец», «я в шоке», «я психую», «смотрю киношку» и так далее.
Теперь представьте себя среднестатистическим мужчиной и прочитайте текст вслух. Я отметила красным те словосочетания, которые выбиваются из тональности юзеркейса.
Здесь я упростила слова и добавила боли в мире читателя – про тот же мусорный бак и удаленку.
Старайтесь сохранять примерно одинаковую стилистику всего текста. Перевоплотитесь в героя и представьте, как он говорит в жизни. Вы ведь, когда смотрите сериал, не ожидаете, что доктор Хаус в следующей серии вдруг станет вежливым и больше не будет остроумно шутить? Вот-вот.
Подумайте над акцентом в начале. Можно сделать автора центральным героем, а можно пойти от проблемы читателя и только потом представить героя. Если вы ставите автора в центре повествования в какой-то серьезной теме, сначала нужно подкрепить его авторитет. Например, вот так мы начали один из юзеркейсов для сервиса Финолог:
Если во главе угла будет стоять проблема читателя, тот же абзац получится другим. Это будут общие рекомендации с опорой на документы и факты без лишних эмоций — просто рамка для основного материала.
Прочитайте текст через полчаса после написания. Можно даже вполголоса, чтобы понять, какие предложения звучат нескладно. Иногда перестановка или замена двух-трех слов все меняет в лучшую сторону.
Придумывайте заголовок после того, как написали текст. Не пытайтесь глядя на пустой белый экран сразу придумать привлекательный заголовок — получится «без жизни» и, скорее всего, без важной конкретики. Сначала напишите разные УТП, потом приплюсуйте к ним эмоциональные акценты и интригу. Вообще лучше максимально уходить от метафорических заголовков, которые без контекста не понятны. Заголовок типа «Занимательная история» при беглом просмотре читателю ничего не говорит — он в интернете за день видит примерно 5–10 занимательных историй. Почему именно эта должна его заинтересовать?
Вот неплохие варианты заголовков:
Здесь многое зависит от специфики текста, но если есть возможность и желание сделать юзеркейс более качественным, то вот, что можно сделать:
Фотографируйте детали в мире читателя, но не перебарщивайте. Подумайте, какие возможности сервиса клиенту интересно увидеть. Можно фоткать телефон или ноутбук со стороны, если в распоряжении есть другой смартфон или камера. Например, вот одна из фоток для приложения по фитнесу. Специально публикую в связке с текстом:
Или вот условия, в которых 90 % людей занимаются спортом дома. При этом у меня есть свободная большая комната, где можно сделать более приличные фото:
Будьте героем сами. Здесь поможет муж, жена, штатив, коллега или собственная вытянутая рука.
Нам важно, чтобы читатель себя узнал. Не забывайте, что это юзеркейс, а не продуктовая статья. Фотки не должны быть правильные, вылизанные, но и в трешак скатываться не стоит. Я просто прогоняю их через фильтры VSCO, убираю лишние детали в Snapseed.
Кстати, вот что значит скатываться в трешак:
Мы закрыли лицо картинкой — нам лишь важно показать, как делать не надо. В таком случае вы зря тратите прежде всего свое время. Что здесь не так:
фото сделаны при плохом освещении, все в шумах;
А вот хорошие примеры нескольких самостоятельных фото для этого же юзеркейса, но уже от лица девушки (меня).
Двадцать лет с юзкейсами: выжимаем практический опыт
У нас в QIWI регулярно проводятся встречи аналитиков и проектных менеджеров, где мы рассказываем друг другу о своем опыте, делимся знаниями и полезными приемами. На одной из таких встреч я рассказал о методике Use Case и о своем опыте работы с ней. Рассказ был встречен на ура, и я решил поделиться им с хабрасообществом.
Я буду использовать разговорное «юзкейс» вместо неуклюжей кальки «прецедент использования». Надеюсь, уважаемая публика меня за это простит.
Юзкейсы стали широко известны по книге Алистера Коберна, одного из авторов Agile-манифеста. Русский перевод книги вышел в 2002 году. На самом деле автор методики — Ивар Якобсон. Он опубликовал ее в середине 80-х, а разрабатывать начал еще с конца 60-х. Впоследствии Ивар Якобсон, Гради Буч и Джеймс Рамбо объединили свои подходы к описанию информационных систем, и родился UML.
Мои отношения с юзкейсами начались в 1996 году и складывались поначалу не очень хорошо. Я тогда работал на предприятии связи, и у меня был халявный интернет. По дайлапу, через телефонный модем на 9600 бод я бороздил просторы тогдашнего интернета в поисках методики, которая помогла бы мне описать функциональность комплексной информационной системы предприятия.
Дело в том, что автоматизация бизнес-процессов там была реализована на изолированных десктопных приложениях с изолированными же базами данных. Вплоть до того, что учет абонентов-физлиц и расчетов с ними был в одной БД, а учет корпоративных абонентов — в другой. И нигде не было, например, пула свободных телефонных номеров. Стояла задача всё это объединить в единую учетную систему для всех услуг. То, что сейчас называют «биллинг».
Я не знал, как начать формулировать требования к такой большой системе, и стал искать подходящий способ. Наткнулся на спецификацию UML версии 0.9, которая тогда только что вышла. В полном восторге, с горящими глазами, прочитал ее от корки до корки. Мне всё дико понравилось, я понял все схемы UML и как ими пользоваться. Кроме одной: диаграммы Use Case. Было непонятно, что это, зачем она и как ее применять. Ниже объясню, почему так произошло.
Проблему биллинга в конце концов решили — купили у стороннего вендора, потом несколько лет внедряли. Но я к тому времени уже был далеко. Юзкейсы писать тогда так и не научился и, в общем, не ощущал особого дискомфорта.
В 2004 году я пришел работать системным аналитиком в одну из больших аутсорсинговых компаний, где состоялось мое настоящее знакомство с юзкейсами. Стандартом разработки там был Rational Unified Process, все функциональные требования во всех проектах полагалось формулировать только в виде юзкейсов. Это, конечно, радикальный подход, мне он и тогда казался странным, а теперь я точно знаю, что так нельзя. Но тем не менее, прослушав пару тренингов и прочитав Коберна, я разобрался в методике и стал ее применять. С тех пор юзкейсы — мой любимый инструмент анализа и разработки требований.
Что такое юзкейс?
Есть разные определения, они на первый взгляд сильно различаются. Самое невнятное встречается у Коберна, он определяет юзкейс как «соглашение о поведении рассматриваемой системы». Правда, у Коберна была целая книжка чтобы раскрыть и уточнить свое определение.
А вот определение из глоссария UML (перевод мой).
Юзкейс — это описание набора последовательностей действий системы, в том числе вариантов таких последовательностей, в результате которых получается наблюдаемый результат, который обладает некой ценностью для кого-то из участников процесса.
Какое определение я сам стараюсь держать в голове, когда пишу юзкейс? Оно должно мне подсказывать, что я должен сделать, о чем мне надо не забыть написать:
Юзкейс — это текст,
описывающий сценарий
взаимодействия с системой,
приводящий к значимому результату.
Оно короткое, и это хорошо. Но в нем есть несколько неявных умолчаний. О которых я тоже помню, разрабатывая юзкейс. Вот полный вариант:
Юзкейс — это текст,
описывающий сценарий (возможно, не один)
взаимодействия (кого или чего?) с системой,
приводящий (возможно, не приводящий)
к значимому (для кого?) результату.
Такое определение говорит мне, что из описания юзкейса должны быть понятны:
Установка курсов для пользователей QIWI Кошелька
Что не нужно в юзкейсе
Коберн не скрывает, что его любимый формат юзкейса — Fully Dressed (как это по-русски, расфуфыренный?). Помимо основного и альтернативных сценариев в него включаются разделы:
Разрабатывая юзкейс, вы не должны накладывать преждевременных ограничений на дизайн. Взгляните на юзкейс выше. В нем нет деталей экранных форм и управляющих элементов интерфейса. Пользователь будет выбирать вариант из выпадающего списка, выбором опции или нажатием кнопки? Это сейчас не имеет значения, решения такого уровня следует отложить на потом. Не делайте работу дизайнера, он сделает ее лучше вас.
Вы скажете: ну как же, вот у тебя написано, что директор получает уведомление по электронной почте. А почему не по SMS или каким-то другим способом? Потому что мы с пользователями на тот момент уже согласовали вариант с e-mail-ом. Если бы я написал абстрактно, то у них возникло бы недоумение: как так, разве мы не решили, что это будет e-mail? Что-то изменилось? Описав пользовательский интерфейс чуть более детально, чем полагается по методике, я позаботился о читателе, чтобы он не споткнулся, читая юзкейс.
Вообще, при выборе информации для включения в юзкейс главным критерием должна быть легкость восприятия. Ради нее можно пожертвовать правилами, подробностью, иногда даже точностью. Главное — чтобы юзкейс был понятен с ходу. Если его трудно понять с ходу — это плохой юзкейс.
Что еще отсутствует в приведенном примере? В нем нет ничего о том, как курсы передаются из АБС в процессинговую систему QIWI Кошелька. Потому что это предмет другого взаимодействия и другого юзкейса. Если из-за какого-нибудь сбоя курсы не дойдут до процессинга — это не забота трейдера. Для него результат достигнут: курсы назначены и утверждены.
Не старайтесь запихнуть всё в один юзкейс. Разграничивайте их исходя из целей пользователей.
Условные конструкции
Одно из основных требований Коберна — отсутствие ветвлений в сценарии. Если есть альтернативный вариант развития событий, его полагается описать отдельно. Любую, сколь угодно сложную блок-схему с ветвлениями и циклами можно представить в виде набора линейных участков.
Я не всегда следую этому правилу. Признаюсь, я подправил свой юзкейс перед тем, как выложить его сюда в качестве примера. А в оригинале он выглядел вот так. Отличия начинаются с п.3.
Сценарий установки курсов
Бизнес-правила
Как сочетать лаконичность юзкейса с множеством деталей, которые обычно нужны, чтобы спроектировать пользовательский интерфейс и разработать код? Для этого я сопровождаю юзкейс списком бизнес-правил, которые должны учитываться при реализации сценариев.
Вот какие бизнес-правила были приложены к юзкейсу из примера.
Следует всегда внимательно оценивать, какие детали стоит включить в сценарии, а какие — вынести в список бизнес-правил.
Когда систем несколько
Одно из центральных понятий в теме юзкейсов — это «рассматриваемая система» (SuC, System under Consideration, или SuD, System under Development). Согласно классическому подходу, есть система, которую мы разрабатываем, и у нее есть граница. Всё во Вселенной делится на то, что внутри системы, и то, что вне ее. И мы рассматриваем исключительно такие взаимодействия, которые идут через границу системы. Зная, что на входе и на выходе мы можем решить, как оно должно работать внутри.
Этот подход можно назвать «одноклеточным». Мы сосредотачиваемся на том, что происходит в клеточной мембране, и игнорируем до поры до времени всё остальное.
Но в реальности мы живем в многоклеточном организме. У компании много систем, они взаимодействуют между собой и совместно реализуют множество функций бизнеса. Почти в каждом проекте мы должны удовлетворить очередную потребность компании через внесение изменений, по возможности минимальных, в несколько систем.
У Коберна такое предусматривается, там есть вариант «организация — прозрачный ящик». Но у него об этом как-то вскользь. В основном рассказ идет о том, как описать единственную рассматриваемую систему в виде черного ящика.
Я предпочитаю в своих юзкейсах не делать различий между системами, к которым мы ставим требования, и внешними акторами. Каждая из систем, которые мы модифицируем, считается таким же участником взаимодействия, как и все остальные. С точки зрения классической методики так нельзя: система — то что внутри, акторы — то что снаружи.
Зато мой подход позволяет извлечь набор функциональных требований к каждой системе по отдельности. Берем все шаги юзкейсов, в которых участвует данная система. Смотрим, существующая ли это функциональность или новая, или существующая, но с какими-то изменениями. Шаги, в которых нет изменений, выкидываем. То, что остается — передаем команде разработчиков системы для детальной технической проработки. Повторяем для каждой из систем, участвующих в юзкейсах проекта.
Сказуемое без подлежащего
Время от времени в сценариях приходится встречать такие фразы: «данные сохраняются в БД», «пользователю отправляется СМС». Не бывает действий, которые выполняются сами по себе. Их всегда выполняет кто-то или что-то.
Я полностью согласен с рекомендацией Коберна о структуре предложений в сценарии. Каждый шаг юзкейса должен начинаться с подлежащего — кто или что выполняет действие. Затем сказуемое — какое действие. Дальше всё остальное. Сказуемое должно быть в настоящем времени и в действительном залоге. «Пользователь выбирает населенный пункт», «Приложение показывает список товаров».
Пробежав глазами начальные слова шагов, легко собрать список участников. Я предпочитаю не выписывать отдельно список участников в начале юзкейса, это тормозит читателя и мешает ему скорее перейти к чтению сценария.
Неуспешные сценарии
Иногда в проектах забывают предусмотреть случаи, когда что-то происходит не так. К примеру, клиент совершил покупку, а потом захотел ее вернуть. Если об этом не подумали заранее, то приходится срочно допиливать код после запуска. А в тяжелых случаях — выбросить всё и организовать взаимодействие систем в другом порядке.
Техника юзкейсов помогает (хотя и не гарантированно) избегать подобных осложнений. Написав основной сценарий, подумайте: что может пойти не так на каждом из шагов? Что может случиться в другом месте после того, как здесь всё уже закончилось? Каждый найденный вариант отклонений нужно выписать, для начала хотя бы одной фразой. Потом, если потребуется, проработать по шагам.
Если в проекте описаны только основные сценарии юзкейсов, то велик риск, что забыли что-то важное.
Модель предметной области
Юзкейсы должны опираться на модель предметной области, которую все участники проекта понимают одинаково. Вспомним первый шаг нашего примера: «Трейдер создает заявку на установку курсов. В заявке даются все исходные курсы покупки и продажи по списку котируемых валют, а также дата и время их вступления в силу (см. форму заявки)». В одном пункте употреблено пять понятий. Некоторые из них новые, возникли только в этом проекте.
Самый известный инструмент введения в предметную область — глоссарий. Следует включать в глоссарий только те слова, которые кому-то могут быть непонятны. Если начать объяснять всё, то после первых трех пунктов читателю станет скучно и он закроет глоссарий, не добравшись до важного.
Можно писать краткие статьи, объясняющие новые понятия. Вот пример — выдержка из документации всё того же проекта:
Имеется список поддерживаемых валют. Этот список делится на две части:
Для каждой валюты также известно, котируется ли она к рублю или к доллару США. «Котируется» в данном случае означает «курс задается Казначейством».
(Считаем, что доллар котируется к рублю, но не рубль к доллару, так как курс доллара задается в рублях, а не наоборот).
Еще один классический способ описания модели предметной области — диаграммы «cущность-связь» в формате IDEF1 или статических структурных диаграмм UML.
В одном недавнем проекте я на таких картинках по часу в день, в течение двух недель, излагал команде разработки модель предметной области. В результате у всех разработчиков была единая картина понятий, что нам очень помогло в ходе проекта.
Перечень юзкейсов
Если требования описаны в форме юзкейсов, то их список становится полезным инструментом управления проектом. Например, в списке юзкейсов можно расставлять приоритеты реализации, можно измерять прогресс по количеству реализованных юзкейсов. Перечень юзкейсов может существовать в форме собственно перечня (Use Case Survey) или в виде диаграммы юзкейсов.
Перед вами перечень юзкейсов из другого проекта, он тоже про конвертацию валют. Платежная система обращается в банк чтобы обменять валюту на такую сумму, которой хватит держателям валютных кошельков и получателям платежей.
Здесь информации больше: мы видим участников взаимодействия и в каких юзкейсах они участвуют. Вопреки Коберну, в качестве участников показаны системы, к которым мы ставим требования (расчетная система, АБС), а также внешние неизменяемые системы (биржевой терминал, система бухучета) и пользователи.
Теперь я могу вам объяснить, почему юзкейс-диаграмма осталась для меня непонятной при первом знакомстве с UML. Дело в том, что все другие диаграммы UML моделируют систему, они показывают ее нам в разных «ракурсах». А юзкейс-диаграмма иллюстрирует не саму систему, а набор функциональных требований к ней. Юзкейс-диаграмма, следовательно, — модель модели. Не так просто было сразу это понять.
Заключение
Юзкейсы — уже довольно старая методология. За 20 лет появились новые подходы, которые потеснили методику юзкейсов в тех областях, в которых она когда-то была лучшей. Например, юзер стори позволяют более эффективно управлять требованиями в Agile-проектах. Методы дизайна пользовательского опыта помогают разрабатывать продукты, успешные на рынке. На мой взгляд, сегодня в сравнении с более современными методами юзкейсы находятся примерно в том же положении, какое в свое время занимали блок-схемы по сравнению с юзкейсами. Старые добрые блок-схемы — теперь диаграммы Activity в UML — используют до сих пор. Но когда-то они считались универсальным способом проектирования и описания программ, а потом их применение сузилось с появлением методик таких как Use Case, UML, BPMN.
Тем не менее юзкейсы и сейчас остаются хорошим инструментом анализа, особенно для систем, поддерживающих бизнес-процессы. Любой аналитик или проектный менеджер должен знать методику юзкейсов и уметь ее использовать. Об этом, собственно, и мой пост.