Use cases и требования

Здравствуйте, byur, Вы писали:

B>Здравствуйте, Gaperton, Вы писали:

_>>>Как лучше организовать раздел 4.2 «Требования к функциям»?
_>>>Что туда лучше поместить: функциональные требования, сценарии использования в полном виде или сокращённую форму сценариев использования?

G>>Мы помещаем сокращенную форму сценариев использования в прикладных терминах (понятных неспециалисту) плюс функциональные требования (в технических терминах, с другой, «системной» группировкой). Делается так для того, чтобы

B>Тут конечно возникает вопрос про то, являются ли юзкейсы (если сценарии использования = use cases) функциями . или вы эту тему в принципе не рассматриваете?

Да нет, разумеется, не возникает такого вопроса. Функции — это описание возможностей, ответ на вопрос «что», сценарии — описание их конкретных способов их применения, ответы на вопросы «зачем» и «как». Это не одно и то же, даже в том редком случае, когда сценарии и функции соответствуют друг другу один к одному. Пример, наглядно демонстрирующий разницу между ними: фрагмент ТЗ на видеоконтроллер для, скажем, продвинутого DVD плеера.

1.Воспроизведение видео формата SD (PAL/SECAM 576х720 и NTSC 480х720) при выходном разрешении SD
a.Без коррекции.
b.С равномерным увеличением и обрезанием границ (увеличение не более чем в 2 раза).
2.Воспроизведение видео с разрешениями меньше SD (но не менее CIF) при выходном разрешении SD.
a.Без коррекции.
b.С масштабированием в SD с независимыми коэффициентами по X и Y, и преобразованием к 4:3 (обрезанием границ).
3.Воспроизведение HD видео формата 16:9 как есть, без коррекции.
4.Воспроизведение HD видео с уменьшением до SD и преобразованием к 4:3 (обрезанием границ). Преобразование развертки входного изображения не производится, т.е. тип и частота развертки входного и выходного изображений должны совпадать.

Эти сценарии легко проверить на полноту и непротиворечивость. Их них легко вывести тестплан. Из них легко посчитать количество целевых применений видеоконтроллера — объем рынка. Им даже приоритеты легко выставить, и укоцать их в случае чего — легко.

Из этих сценариев следует требование наличия блока масштабирования изображения, вот такого:

i.Независимое масштабирование разрешения изображения по горизонтали и вертикали осуществляется с программируемыми коэффициентами. Коэффициенты меняются в диапазонах:
1. Увеличение не более чем в 2 раза с обеспечением приемлемого качества изображения. Предельный случай — увеличение из CIF (288х352) в PAL/SECAM (576×720).
2. Уменьшение не более чем в 3 раза с обеспечением приемлемого качества изображения. Предельный случай — уменьшение из 1080х1920 в NTSC (480х720).

А также вот такой функции clipping-а:

i.В случае выходных разрешений 1-4 (см. таблицу 1) размер изображения в пикселах после масштабирования может быть меньше или больше выходного разрешения по одной или обеим координатам. В этом случае показывается фрагмент изображения, соответствующий выходному разрешению, выступающие части отрезаются, свободное пространство закрашивается цветом фонового слоя. Позиция фрагмента задается конфигурационными регистрами.

Несложно доказать, что данные функциональные требования необходимы и достаточны для реализации приведенных сценариев. Инженеры, работая над архитектурой, будут пользоваться только функциональными требованиями, потому что их соответствие сценариям уже доказано.

Возможно, погрязший в формализме последователь RUP назовет и то и другое use cases, и проставит между ними связь. Я предпочитаю их явно разделять терминологически. Потому, что:
1) Практика показывает, что термины «сценарий использования» и «функциональные требования» понятны всем, в том числе людям, не знакомым с RUP, а таких большинство.
2) «Сценарии» используются совсем не так, как функции. Они, на самом деле, играют важнейшую роль при управлении разработкой продукта. Именно из сценариев испольщования следует тест-план и функциональные требования. Именно к сценариям привязаны бизнес=приоритеты, именно через сценарии можно перейти от функциональных требований к бизнес-необходимости и обратно, рассчитав, скажем, объем рынка для будущего продукта, и убедившись, что технические требования соответствуют маркетинговым. Именно сценарии лишены понятны и маркетингу и техническим парням, и при этом лишены шелухи.
3)В результате, если называть и то и другое use cases, это не приводит ни к чему, кроме путаницы. Вот, например, вопросы возникают, уж не одно ли это и то же. Нет, не одно.

Use cases и требования

Приветствую всех. Имеется следующий вопрос.

1) Допустим разработка требований к системе осуществляется по Вигерсу:
Бизнес-требования — > требования пользователей (в виде сценариев использования) -> функциональные требования

2) Также допустим, имеются требования заказчика по оформлению требований к системе в виде технического задания по ГОСТ 34.

На какие пункты ТЗ должны ложиться те или иные виды требований?

С бизнес-требованиями (а точнее с образом и границами проекта) вроде бы всё просто. Это разделы 1 «Основные сведения» в части очередности создания системы и 2 «Назначение и цели создания системы».
Как лучше организовать раздел 4.2 «Требования к функциям»?
Что туда лучше поместить: функциональные требования, сценарии использования в полном виде или сокращённую форму сценариев использования?

Здравствуйте, newbie_analyst, Вы писали:

_>2) Также допустим, имеются требования заказчика по оформлению требований к системе в виде технического задания по ГОСТ 34.

_>На какие пункты ТЗ должны ложиться те или иные виды требований?

_>С бизнес-требованиями (а точнее с образом и границами проекта) вроде бы всё просто. Это разделы 1 «Основные сведения» в части очередности создания системы и 2 «Назначение и цели создания системы».
_>Как лучше организовать раздел 4.2 «Требования к функциям»?
_>Что туда лучше поместить: функциональные требования, сценарии использования в полном виде или сокращённую форму сценариев использования?

Здравствуйте, byur, Вы писали:

Сервер не найден?

Здравствуйте, Курилка, Вы писали:

К>Здравствуйте, byur, Вы писали:

К>Сервер не найден?

Спасибо, byur,
Очень познавательно.

Мы, кстати, у себя пришли точно к таким же выводам:
use cases помещаем в документ «Описание постановки задачи».
Получается, что можно относительно малой кровью быстро подготовить и согласовать ТЗ . А затем уже на этапе разработки итерировать ОПЗ.
Становится возможной итерационная модель разработки системы — требования продолжают собираться и изменяться когда уже полным ходом идёт кодирование.

ТЗ обычно выделяется отдельным этапом договора, который должен быть завершен перед этапом ТРП, на котором собственно и осуществляется разработка.
В таких условиях проблематично по ходу разработки производить бесконечные уточнения и доработки ТЗ.

Здравствуйте, newbie_analyst, Вы писали:

_>ТЗ обычно выделяется отдельным этапом договора, который должен быть завершен перед этапом ТРП, на котором собственно и осуществляется разработка.
_>В таких условиях проблематично по ходу разработки производить бесконечные уточнения и доработки ТЗ.

ТРП = ?

Здравствуйте, Курилка, Вы писали:
К>ТРП = ?

Техно-рабочий проект. Включает в себя разработку документации технического и рабочего проекта и собственно реализацию системы.

Здравствуйте, newbie_analyst, Вы писали:

_>Приветствую всех. Имеется следующий вопрос.

_>Как лучше организовать раздел 4.2 «Требования к функциям»?
_>Что туда лучше поместить: функциональные требования, сценарии использования в полном виде или сокращённую форму сценариев использования?

Мы помещаем сокращенную форму сценариев использования в прикладных терминах (понятных неспециалисту) плюс функциональные требования (в технических терминах, с другой, «системной» группировкой). Делается так для того, чтобы
1) проследить корректность перехода от прикладных сценариев к функциональным требованиям, т.е. выполнить трассировку требований простым анализом документа.
2) сценарии прямым образом задают объем тестирования, что влияет на сроки разработки и приемку, их обязательно надо включать. Кроме того, сценарии простым и понятным образом ограничивают функциональность системы — короче, это защищает как вас так и клиента.

Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, newbie_analyst, Вы писали:

_>>Приветствую всех. Имеется следующий вопрос.

_>>Как лучше организовать раздел 4.2 «Требования к функциям»?
_>>Что туда лучше поместить: функциональные требования, сценарии использования в полном виде или сокращённую форму сценариев использования?

G>Мы помещаем сокращенную форму сценариев использования в прикладных терминах (понятных неспециалисту) плюс функциональные требования (в технических терминах, с другой, «системной» группировкой).
В прикладных терминах сокращённая форма, а в технически тоже?

Здравствуйте, newbie_analyst, Вы писали:

И это правильно. Так и должно быть в случае ОКР — нечего превращать разработку в балаган. Если непонятно как делать ТЗ, то практика ГОСТ предписывает открыть сначала отдельный НИР, результатом которого и будет ТЗ. Или, действительно, делать это первым этапом. Типа, тогда получится НИОКР.

Здравствуйте, Курилка, Вы писали:

К>Здравствуйте, Gaperton, Вы писали:

G>>Здравствуйте, newbie_analyst, Вы писали:

_>>>Приветствую всех. Имеется следующий вопрос.

G>>Мы помещаем сокращенную форму сценариев использования в прикладных терминах (понятных неспециалисту) плюс функциональные требования (в технических терминах, с другой, «системной» группировкой).
К>В прикладных терминах сокращённая форма, а в технически тоже?

Другие публикации: Образец заявления в суд о разводе и разделе имущества

Она должна быть как можно короче, при этом — достаточно полна (исчерпывающе описывать scope работ), чтоб вам не впилили потом лишней работы, и обязательно непротиворечива — допускать однозначное толкование. Это очень важно, потому, что неполнота и неясности трактуется в пользу заказчика. Мне рассказывали про случаи, когда на это люди налетали — очень неприятно. Это относится ко всему ТЗ.

Здравствуйте, Gaperton, Вы писали:
G>И это правильно. Так и должно быть в случае ОКР — нечего превращать разработку в балаган. Если непонятно как делать ТЗ, то практика ГОСТ предписывает открыть сначала отдельный НИР, результатом которого и будет ТЗ. Или, действительно, делать это первым этапом. Типа, тогда получится НИОКР.

И что, в ваших НИОКРах получается организовать проект так, что ТЗ разрабатывается полностью в срок и утверждается, а потом не меняется по ходу разработки?

И ещё вопрос, в НИОКРах, на стадии формирования ТЗ, вы пишете код, создаёте прототипы?
Какое процентное соотношение длительности этапов получается (ТЗ vs ТРП)?

Здравствуйте, newbie_analyst, Вы писали:

_>Здравствуйте, Gaperton, Вы писали:
G>>И это правильно. Так и должно быть в случае ОКР — нечего превращать разработку в балаган. Если непонятно как делать ТЗ, то практика ГОСТ предписывает открыть сначала отдельный НИР, результатом которого и будет ТЗ. Или, действительно, делать это первым этапом. Типа, тогда получится НИОКР.

_>И что, в ваших НИОКРах получается организовать проект так, что ТЗ разрабатывается полностью в срок и утверждается, а потом не меняется по ходу разработки?

Оно может меняться по ходу разработки, однако количество этих изменений должно быть минимизировано, потому, что изменения в ТЗ по ходу проекта очень дорого обходятся. Да, нам удается добиваться такого.

_>И ещё вопрос, в НИОКРах, на стадии формирования ТЗ, вы пишете код, создаёте прототипы?
Это не запрещено. На стадии формирования ТЗ делается все необходимое, что помогает создать хорошее ТЗ. Если для этого необходимо написать код, сделать прототипы или макеты — это делается. Короче, никто не ограничивает вас в активностях на исследовательской фазе ТЗ, однако надо понимать, что цель этой фазы — это само ТЗ, а не код, из чего следует определенная схема расстановки приоритетов задачам. Цель кодописания на данном этапе — получение информации, необходимой для ТЗ, а не написание фрагментов конечной системы промышленного качества. Понимание этой цели позволяет радикально уменьшить объем кодописания на ней и, главное — ускорить создание ТЗ.

_>Какое процентное соотношение длительности этапов получается (ТЗ vs ТРП)?
В зависимости от работы, от степени ее неопределенности и рискованности. Я пока статистику не подводил.

Здравствуйте, Gaperton, Вы писали:

G>Мы помещаем сокращенную форму сценариев использования в прикладных терминах (понятных неспециалисту) плюс функциональные требования (в технических терминах, с другой, «системной» группировкой). Делается так для того, чтобы

Тут конечно возникает вопрос про то, являются ли юзкейсы (если сценарии использования = use cases) функциями . или вы эту тему в принципе не рассматриваете?

Здравствуйте, byur, Вы писали:

B>Здравствуйте, Gaperton, Вы писали:

Из этих сценариев следует требование наличия блока масштабирования изображения, вот такого:

А также вот такой функции clipping-а:

Здравствуйте, Gaperton, Вы писали:

G>Да нет, разумеется, не возникает такого вопроса. Функции — это описание возможностей, ответ на вопрос «что», сценарии — описание их конкретных способов их применения, ответы на вопросы «зачем» и «как». Это не одно и то же, даже в том редком случае, когда сценарии и функции соответствуют друг другу один к одному. Пример, наглядно демонстрирующий разницу между ними: фрагмент ТЗ на видеоконтроллер для, скажем, продвинутого DVD плеера.

Одно из формальных определений функции — «нечто что делает система, предположительно на основании требований к ней», по-моему это определение из книги Ian F. Alexander. Следуя тому же «формализму», требования к функциям — это таки требования . Сценарии, или юзкейсы — по большому счету функциональные требования (или функции ?) в контексте их использования. Кстати, я все-таки не понял, если у вас сценарии использования = use cases, то кто интересно будет эктором у приведенных ниже вами сценариях? Если такого отождествления нет, тогда вопрос отпадает .
Кстати, по Вигерсу, пользовательские требования описываются в частности юзкейсами.

G>1.Воспроизведение видео формата SD (PAL/SECAM 576х720 и NTSC 480х720) при выходном разрешении SD
G> a.Без коррекции.
G> b.С равномерным увеличением и обрезанием границ (увеличение не более чем в 2 раза).
G>2.Воспроизведение видео с разрешениями меньше SD (но не менее CIF) при выходном разрешении SD.
G> a.Без коррекции.
G> b.С масштабированием в SD с независимыми коэффициентами по X и Y, и преобразованием к 4:3 (обрезанием границ).
G>3.Воспроизведение HD видео формата 16:9 как есть, без коррекции.
G>4.Воспроизведение HD видео с уменьшением до SD и преобразованием к 4:3 (обрезанием границ). Преобразование развертки входного изображения не производится, т.е. тип и частота развертки входного и выходного изображений должны совпадать.

Другие публикации: Налог на прибыль пбу 17

G>Эти сценарии легко проверить на полноту и непротиворечивость. Их них легко вывести тестплан. Из них легко посчитать количество целевых применений видеоконтроллера — объем рынка. Им даже приоритеты легко выставить, и укоцать их в случае чего — легко.
G>Из этих сценариев следует требование наличия блока масштабирования изображения, вот такого:

Это достаточно очевидная вещь, когда на базе юзкейсов разрабатываются тест-кейсы, более того, на ряде проектов в Люксофте аналитики разрабатывают детальные сценарии (не могу сказать что это юзкейсы), на этапе разработки требований — и они фактически тестируются тестерами без написания тест-кейсов, если я все правильно помню. Более того, часто пользовательская документация строится на юзкейсах.

G>Возможно, погрязший в формализме последователь RUP назовет и то и другое use cases, и проставит между ними связь. Я предпочитаю их явно разделять терминологически. Потому, что:
G>1) Практика показывает, что термины «сценарий использования» и «функциональные требования» понятны всем, в том числе людям, не знакомым с RUP, а таких большинство.

Формальный RUP скорее всего не назовет это юзкейсами вообще. Но правда то, что он объединяет это в группу software requirements в которой конечно же выделит юзкейсы и suuplementary req., понимая под ними (suuplementary req)как дополнительные функциональные требования, не охваченные юзкейсами, так и нефункциональные требования.

G>2) «Сценарии» используются совсем не так, как функции. Они, на самом деле, играют важнейшую роль при управлении разработкой продукта. Именно из сценариев испольщования следует тест-план и функциональные требования. Именно к сценариям привязаны бизнес=приоритеты, именно через сценарии можно перейти от функциональных требований к бизнес-необходимости и обратно, рассчитав, скажем, объем рынка для будущего продукта, и убедившись, что технические требования соответствуют маркетинговым. Именно сценарии лишены понятны и маркетингу и техническим парням, и при этом лишены шелухи.

Классический Вигерс .

G>3)В результате, если называть и то и другое use cases, это не приводит ни к чему, кроме путаницы. Вот, например, вопросы возникают, уж не одно ли это и то же. Нет, не одно.

Вопрос на самом деле не в этом состоял, да и никто не отождествляет юзкейсы и функциональные требования . есть в конце концов классическая статья «Why use cases are not functions», и c другой стороны есть тенденция интерпретировать ГОСТ 34.602, который говорит именно про требования к функциям (или функциональные требования), коими юзкейсы не являются. Посему и странно видеть юзкейсы в этом разделе ТЗ.

Здравствуйте, Gaperton, Вы писали:

Получается, что у вас требования относящиеся к одной и той же функциональности (юзкейсы и вытекающие из них функциональные требования) совмещены в одном разделе ТЗ. А как проходит приёмка? Ведь, формально, проверка _каждого_ требования ТЗ должна быть отражена в «Программе и методике испытаний».
У Вас проверки в ПМИ пишутся для юзкейсов или для функциональных требований?

Здравствуйте, newbie_analyst, Вы писали:

_>Получается, что у вас требования относящиеся к одной и той же функциональности (юзкейсы и вытекающие из них функциональные требования) совмещены в одном разделе ТЗ. А как проходит приёмка? Ведь, формально, проверка _каждого_ требования ТЗ должна быть отражена в «Программе и методике испытаний».

Хм. Это интересный момент. Как то не ждал я в этом месте подставы совсем. В принципе, идея состоит в том, что программа испытаний покрывающая все сценарии должна полностью закрыть и функциональные требования — они ведь в известном смысле дублируют друг друга. Надеюсь, что никакой подставы с такой практикой мы не словим — мы как раз затем явно сценарии и прописываем, чтобы в последствии не раздулась программа испытаний . Дело в том, что глядя только на функциональные требования теоретически можно вдуть совершенно нереальную по объему программу испытаний, включая экзотические режимы, а этого хочется избежать. И главное — ничего потом не докажешь — нужен этот режим или нет. Со сценариями такой фокус не пройдет.

Хотя, вероятно, докопаться к нам при таком подходе все-таки можно. Чтобы было докопаться нельзя, можно попробовать из внешнего ТЗ, которое вы показываете заказчику, максимально сократить или убрать «функциональные требования», сделав акцент на сценариях и нефункциональных требования. Прокатит — хорошо.

_>У Вас проверки в ПМИ пишутся для юзкейсов или для функциональных требований?

Для юкейсов. Собственно, именно затем мы юзкейсы в ТЗ и включаем. Вообще, правила этого делать не рекомендуют (но и не запрещают), но мы решили, что нам и заказчику будет проще, если они там будут. Без них в ТЗ черт ногу сломит, его вкурить невозможно. Отсюда будет недопонимание и проблемы.

Вообще — мне надо было сразу заметить, что мы работаем не по «программным» ГОСТ, а по микроэлектронным. Изделия у нас — микроэлектронные. ГОСТЫ другие, отсюда может быть некоторая разница в деталях, хотя принципы должны быть общие. Кроме того, есть военные ГОСТ, а есть гражданские. Там тоже есть некоторая разница в правилах. Мои парни предпочитают военные версии, так как с их слов там понятнее написано.

Поэтому, я на самом деле не знаю, до какой степени можно полагаться на то, что я говорю, в случае разработки ПО по специфическим ГОСТ. No warranty, as is. Хотя, мне как программисту военные микроэлектронные ГОСТ очень нравятся — все очень разумно.

Из нюансов. Например, разработка блока-фрагмента микросхемы (которой является видеоконтроллер из приведенного мной примера) формально не является ОКР, он является НИР. Потому, что изделия никакого на выходе не получается, а также потому, что заказчик захотел, чтобы это был НИР. А порядок выполнения и приемки НИР вроде как попроще, чем ОКР.

____________________
Кстати, в порядке иллюстрации — по поводу порядка выполнения НИР и составления ТЗ. Берем ГОСТ В 28110-91 — он реально старый (92 год), зато под рукой. Новый должен быть еще лучше . Просто для информации — как делается ТЗ. Он рекомендует 4 этапа:
1) Разработка ТЗ на НИР. ТЗ помимо целей НИР и прочего устанавливает также состав дальнейших этапов и сроки их завершения. То есть это фаза планирования и целеполагания. Целью НИР может быть разработка ТЗ на ОКР, или же НИР может быть хардкорной высокорискованной поисково-исследовательской работой, или вообще чем угодно на самом деле.
2) Выбор направления исследований.
3) Теоретические и экспериментальные исследования.
4) Приемка НИР. Программа испытаний утверждается в начале данного этапа — в рамках НИР помимо отчетов вполне могут быть разработаны какие-нибудь макеты и экспериментальные образцы, это допускается.

Допускается разделение этапов, уточнение их содержания, а также устранение этапа «Выбор направления исследований». Все достаточно общо, к микроэлектронике не сильно привязано. Софтверные ГОСТ существенно более специфичны и наворочены, насколько я помню.

Порядок выполнения ОКР: Допускается разделение этапов, уточнение их содержания, а также устранение этапа «разработка эскизного проекта», в случае, если работа тупая и низкорискованная, или если данному ОКР предшествовал НИР. Данный порядок ориентирован на разработку изделий для серийного производства,
1) Разработка ТЗ. ТЗ помимо прочего устанавливает состав дальнейших этапов и сроки их завершения. Это фаза планирования совмещенная с фазой работы над требованиями. Достаточно разумно. Выход из фазы — мы знаем, что мы хотим сделать.
2) Разработка эскизного проекта. Здесь выбирают направление работы и вырабатывают решения по обеспечению требований ТЗ. Короче, это архитектурный этап. В составе которого, в частности, предписано делать, цитирую:
— изготовление и испытание макетов наиболее сложных и ответственных частей изделия (или изделия в целом), в объеме, необходимом для оценки правильности намеченных решений в соответствии с требованиями ТЗ. Бинго. Древний ГОСТ 92 года рекомендует прототипирование. Вот так-то. Критерий выхода из этапа — мы знаем, как мы это будем делать. Вторая фаза RUP.
3) Разработка технического проекта (разработка конструкции и технологии). Здесь делается основная разработка. Предписано также делать «макеты», но с другой целью: для проверки основных конструктивных решений изделия и его характеристик. Также, здесь думают, как заряжать серийное производство. Типа — альфа версию сделали.
4) Разработка рабочей КД и ТД, изготовление опытного образца, проведение предварительных испытаний.
Довели продукт до серийного качества, подготовили производство, запустили пробную серию, испытали. Получили release candidate.
5) Приемка ОКР. Это государственная приемка.

Другие публикации: Подоходный налог на уголь

Принципы организации довольно гибки, и напоминают принципы устройства цикла разработки RUP. Вот так. Мне — нравится. По моему — все очень разумно. Вот, гляжу я на это, и не понимаю, о каком-таком злом ватерфоле идет речь, если еще наши деды вели разработку вот так? Это ж самый настоящий RUP. .

Впрочем, еще раз, в ГОСТах на разработку ПО все может быть тупее и деревяннее — я подробно в них не копался.

Use cases и требования

Use Case (вариант использования, ВИ, Прецедент, юскейс) — это сценарная техника описания взаимодействия. С помощью Use Case может быть описано и пользовательское требование, и требование к взаимодействию систем, и описание взаимодействия людей и компаний в реальной жизни.

В общем случае, с помощью Use Case может описываться взаимодействие двух или большего количества участников, имеющее конкретную цель:

покупка товара в магазине (Покупатель-Продавец),
отправка письма по электронной почте (Адресант-Почтовый клиент),
запрос страницы браузером (Браузер-Web-сервер).

В разработке ПО эту технику часто применяют для проектирования и описания взаимодействия пользователя и системы, поэтому название Use Case часто воспринимает как синоним требования человека-пользователя к решению определенной задачи в системе. В статье мы будем рассматривать использование Use Case для описания взаимодействия пользователя с системой.
Исторически требования к функционированию системы описывались в виде отдельных функций. Ивар Якобсон в середине 1990-х годов предложил Use Case как альтернативу и дополнение описания функциональности системы. Описание требований к системе не в виде отдельных функций, а в виде описания контекста и последовательности действий пользователя помогает сформировать набор функциональных требований, который будет обеспечивать полноту и неизбыточность требований.

Мы можем сформулировать набор функциональных требований:

FRQ1 Система должна предоставить пользователю возможность ввести код бронирования
FRQ2 Система должна сохранить сведения о регистрации пассажира на рейс
FRQ3 Система должна предоставить пользователю возможность распечатать посадочный талон

Пока это разрозненные требования, мы не можем проверить их набор на полноту и соответствие целям пользователей, так как мы не видим:

1) контекста выполнения этих функций,
2) роли пользователя, которому должна быть доступна функция,
3) целей этого пользователя при использовании системы.

Use Case задаёт формат, в котором все эти важные факторы описываются и учитываются. И перечисленные выше функциональные требования можно объединить в один Use Case, описывающий цель пользователя.

Пример базовой части Use Case.
Регистрация пассажира на рейс

Описание решения задачи пользователя в системе в виде Use Case должно определять:

Систему, с которой описывается взаимодействие;
Основное действующее лицо: роль пользователя;
Цель основного действующего лица;
Предусловие;
Триггер;
Основной поток действий;
Результат.

В качестве взаимодействующей системы здесь рассматривается Система регистрации Пассажира на рейс. Именно с ней Пассажир — основное действующее лицо — ведёт диалог и с его помощью достигает своей цели — зарегистрироваться на рейс.

Основной поток действий Use Case описывает успешную последовательность событий, необходимую для достижения конкретной цели основного действующего лица.

Предусловие — условия, которые должны выполняться, чтобы сценарий вообще мог начаться. Мы не будем проверять это условие в процессе работы сценария, так как мы предварительно договорились, что оно истинно.

Триггер — событие, инициирующее начало сценария. Триггером, в общем случае, может быть:

действие основного действующего лица;
наступление определённого времени времени, например, если действие сценария должно происходить периодически: раз в день, раз в неделю, раз в месяц.

Триггер может предшествовать первому шагу сценария, а может являться первым шагом.

Результат — или «гарантия успеха» — след, который оставляет сценарий. Наличие результата говорит нам, что и Пассажир достиг своей цели.

Этот Use Case пишется для проектирования решения, его потребителем будет команда разработки.

Назначение Use Case для разных участников проекта

Конечно, для разработки функциональных требований к системе мы пишем целый набор Use Case, учитывающих цели пользователей нескольких ролей. Этот набор позволяет обеспечить полноту требований пользователей к системе. Набор Use Case является набором требований более высокого уровня абстракции, чем набор отдельных функциональных требований, и в то же время полностью покрывает пользовательские требования к функциональности. Поэтому он более удобен в работе.

Рассмотрим преимущество работы с набором Use Case для людей, выполняющих разные роли в проекте.

Use Case для руководителя проекта

Сам по себе Use Case — это естественный способ описывать диалог, он понятен человеку без подготовки, Use Case обычно не содержит деталей реализации и пишется на языке целей пользователей. Поэтому Use Case удобно согласовывать с Заказчиком как «единицу поставки»: элемент планирования работы над системой и сдачи проекта.

В отличие от планирования работы и сдачи результатов в виде отдельных функций (сохранять, предоставлять доступ) или элементов архитектуры (платформа, подсистема хранения данных, подсистема обработки данных, подсистема пользовательского интерфейса), согласование работ на основе Use Case гораздо прозрачнее для заказчика. Во-первых, каждый Use Case несет конечную бизнес-ценность, понятную заказчику, во-вторых, даже технически неподкованный заказчик может убедиться в наличии реализации того или иного Use Case в системе, в отличие от наличия отдельных подсистем или функций, никак не отображающихся на пользовательском интерфейсе.

То, что набор Use Case состоит из меньшего количества элементов — обычно от 5 до 20, — чем набор отдельных функциональных требований, экономит время на согласование проекта с заказчиком, а то, что заказчику понятна бизнес-ценность каждого Use Case, сильно упростит выставление приоритетов между ними.

Use Case для тестировщика

Для тестировщиков Use Case являются отличной базой для формирования тестовых сценариев — test case, — так как они описывают в каком контексте должно производиться каждое действие пользователя. Use Case, по умолчанию, являются тестируемыми требованиями так как в них всегда указана цель, которой нужно достигнуть и какие шаги надо для этого воспроизвести.

Use Case для аналитика и менеджера продукта

Для аналитика и менеджера продукта, как наиболее частых авторов, Use Case это отличный инструмент:

разработки и обеспечения полноты функциональных требований,
выявления других видов информации (нефункциональных требований), которая необходима для работы над проектом:
- ограничений;
- атрибутов качества;
- требований к пользовательскому интерфейсу;
- внутренних правил работы в предметной области (бизнес-правил);
обеспечения трассировки требований между исходными требованиями заказчика (бизнес-требованиями) и техническими требованиями (не только функциональными).

Как уже говорилось выше, хороший набор Use Case позволяет обеспечить полноту функциональных требований, следующих из потребностей пользователей.

В процессе проектирования взаимодействия с системой в виде Use Case и согласования их с заказчиком, аналитик и руководитель проекта узнают много сопутствующей информации: роли пользователей, внутренние правила работы потенциальных пользователей, которые влияют на логику Use Case и являются бизнес-правилами. В процессе расстановки приоритетов и выявления критичности тех или других Use Case формируются требования к пользовательскому интерфейсу. При определении частоты выполнения того или иного действия пользователя в системе, описанного в виде Use Case, формируются требования к производительности системы.

Так как Use Case полностью покрывают набор таких функциональных требований, и в то же время согласуются с бизнес-целями заказчика, они позволяют проследить связь от бизнес-целей заказчика до отдельной функции и связанных нефункциональных требований, т.е. обеспечить трассировку.

Use Case не обеспечивают полноту всех функциональных требований, если в систему должна быть заложена сложная бизнес-логика, т.е. обработка информации в системе зависит не только и не столько от действий пользователей, сколько от внутренних правил взаимодействия объектов.

Например, работа с системами типа «тасктрекер» задается достаточно простыми и стандартными Use Case: «Создать задачу», «Назначить задачу», «Пометить задачу, как выполненную». Однако тасктрекеров существует огромное множество, и это оправдано тем, что в каждом есть свои возможности по заданию жизненных циклов задач, их типов и взаимосвязей. И эту внутреннюю логику работы с задачами нет смысла описывать в виде Use Case.

То же касается бухгалтерских программ, систем поддержки принятия решения, профессиональных систем для проектирования и дизайна. Use Case важны для них, но не покроют и пятой части требований к функциональности.

Если эта техника вас заинтересовала, ознакомьтесь с материалами от классиков Use Case:

Книга о написании Use Case, которая считается классикой: Алистер Коберн, «Современные методы описания функциональных требований»

Современная методика проектирования и гибкого планирования разработки систем с помощью Use Case от основоположника техники, Ивара Якобсона: Use Case 2.0 Essentials Practice