1) Допустим разработка требований к системе осуществляется по Вигерсу:
Бизнес-требования — > требования пользователей (в виде сценариев использования) -> функциональные требования
2) Также допустим, имеются требования заказчика по оформлению требований к системе в виде технического задания по ГОСТ 34.
На какие пункты ТЗ должны ложиться те или иные виды требований?
С бизнес-требованиями (а точнее с образом и границами проекта) вроде бы всё просто. Это разделы 1 "Основные сведения" в части очередности создания системы и 2 "Назначение и цели создания системы".
Как лучше организовать раздел 4.2 "Требования к функциям"?
Что туда лучше поместить: функциональные требования, сценарии использования в полном виде или сокращённую форму сценариев использования?
Re: Бизнес-требования, use cases, фун. требования и ТЗ ГОСТ3
Здравствуйте, newbie_analyst, Вы писали:
_>2) Также допустим, имеются требования заказчика по оформлению требований к системе в виде технического задания по ГОСТ 34.
_>На какие пункты ТЗ должны ложиться те или иные виды требований?
_>С бизнес-требованиями (а точнее с образом и границами проекта) вроде бы всё просто. Это разделы 1 "Основные сведения" в части очередности создания системы и 2 "Назначение и цели создания системы". _>Как лучше организовать раздел 4.2 "Требования к функциям"? _>Что туда лучше поместить: функциональные требования, сценарии использования в полном виде или сокращённую форму сценариев использования?
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, byur, Вы писали:
B>>Кое-что вы сможете найти тут http://secr.ru/2006/upload/files/63.pdf
К>Сервер не найден?
Мы, кстати, у себя пришли точно к таким же выводам:
use cases помещаем в документ "Описание постановки задачи".
Получается, что можно относительно малой кровью быстро подготовить и согласовать ТЗ . А затем уже на этапе разработки итерировать ОПЗ.
Становится возможной итерационная модель разработки системы — требования продолжают собираться и изменяться когда уже полным ходом идёт кодирование.
ТЗ обычно выделяется отдельным этапом договора, который должен быть завершен перед этапом ТРП, на котором собственно и осуществляется разработка.
В таких условиях проблематично по ходу разработки производить бесконечные уточнения и доработки ТЗ.
Re[5]: Бизнес-требования, use cases, фун. требования и ТЗ ГО
Здравствуйте, newbie_analyst, Вы писали:
_>ТЗ обычно выделяется отдельным этапом договора, который должен быть завершен перед этапом ТРП, на котором собственно и осуществляется разработка. _>В таких условиях проблематично по ходу разработки производить бесконечные уточнения и доработки ТЗ.
ТРП = ?
Re[6]: Бизнес-требования, use cases, фун. требования и ТЗ ГО
Здравствуйте, newbie_analyst, Вы писали:
_>Приветствую всех. Имеется следующий вопрос.
_>Как лучше организовать раздел 4.2 "Требования к функциям"? _>Что туда лучше поместить: функциональные требования, сценарии использования в полном виде или сокращённую форму сценариев использования?
Мы помещаем сокращенную форму сценариев использования в прикладных терминах (понятных неспециалисту) плюс функциональные требования (в технических терминах, с другой, "системной" группировкой). Делается так для того, чтобы
1) проследить корректность перехода от прикладных сценариев к функциональным требованиям, т.е. выполнить трассировку требований простым анализом документа.
2) сценарии прямым образом задают объем тестирования, что влияет на сроки разработки и приемку, их обязательно надо включать. Кроме того, сценарии простым и понятным образом ограничивают функциональность системы — короче, это защищает как вас так и клиента.
Re[2]: Бизнес-требования, use cases, фун. требования и ТЗ ГО
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, newbie_analyst, Вы писали:
_>>Приветствую всех. Имеется следующий вопрос.
_>>Как лучше организовать раздел 4.2 "Требования к функциям"? _>>Что туда лучше поместить: функциональные требования, сценарии использования в полном виде или сокращённую форму сценариев использования?
G>Мы помещаем сокращенную форму сценариев использования в прикладных терминах (понятных неспециалисту) плюс функциональные требования (в технических терминах, с другой, "системной" группировкой).
В прикладных терминах сокращённая форма, а в технически тоже?
Re[5]: Бизнес-требования, use cases, фун. требования и ТЗ ГО
Здравствуйте, newbie_analyst, Вы писали:
_>ТЗ обычно выделяется отдельным этапом договора, который должен быть завершен перед этапом ТРП, на котором собственно и осуществляется разработка. _>В таких условиях проблематично по ходу разработки производить бесконечные уточнения и доработки ТЗ.
И это правильно. Так и должно быть в случае ОКР — нечего превращать разработку в балаган. Если непонятно как делать ТЗ, то практика ГОСТ предписывает открыть сначала отдельный НИР, результатом которого и будет ТЗ. Или, действительно, делать это первым этапом. Типа, тогда получится НИОКР.
Re[3]: Бизнес-требования, use cases, фун. требования и ТЗ ГО
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, Gaperton, Вы писали:
G>>Здравствуйте, newbie_analyst, Вы писали:
_>>>Приветствую всех. Имеется следующий вопрос.
_>>>Как лучше организовать раздел 4.2 "Требования к функциям"? _>>>Что туда лучше поместить: функциональные требования, сценарии использования в полном виде или сокращённую форму сценариев использования?
G>>Мы помещаем сокращенную форму сценариев использования в прикладных терминах (понятных неспециалисту) плюс функциональные требования (в технических терминах, с другой, "системной" группировкой). К>В прикладных терминах сокращённая форма, а в технически тоже?
Она должна быть как можно короче, при этом — достаточно полна (исчерпывающе описывать scope работ), чтоб вам не впилили потом лишней работы, и обязательно непротиворечива — допускать однозначное толкование. Это очень важно, потому, что неполнота и неясности трактуется в пользу заказчика. Мне рассказывали про случаи, когда на это люди налетали — очень неприятно. Это относится ко всему ТЗ.
Re[6]: Бизнес-требования, use cases, фун. требования и ТЗ ГО
Здравствуйте, Gaperton, Вы писали: G>И это правильно. Так и должно быть в случае ОКР — нечего превращать разработку в балаган. Если непонятно как делать ТЗ, то практика ГОСТ предписывает открыть сначала отдельный НИР, результатом которого и будет ТЗ. Или, действительно, делать это первым этапом. Типа, тогда получится НИОКР.
И что, в ваших НИОКРах получается организовать проект так, что ТЗ разрабатывается полностью в срок и утверждается, а потом не меняется по ходу разработки?
И ещё вопрос, в НИОКРах, на стадии формирования ТЗ, вы пишете код, создаёте прототипы?
Какое процентное соотношение длительности этапов получается (ТЗ vs ТРП)?
Re[7]: Бизнес-требования, use cases, фун. требования и ТЗ ГО
Здравствуйте, newbie_analyst, Вы писали:
_>Здравствуйте, Gaperton, Вы писали: G>>И это правильно. Так и должно быть в случае ОКР — нечего превращать разработку в балаган. Если непонятно как делать ТЗ, то практика ГОСТ предписывает открыть сначала отдельный НИР, результатом которого и будет ТЗ. Или, действительно, делать это первым этапом. Типа, тогда получится НИОКР.
_>И что, в ваших НИОКРах получается организовать проект так, что ТЗ разрабатывается полностью в срок и утверждается, а потом не меняется по ходу разработки?
Оно может меняться по ходу разработки, однако количество этих изменений должно быть минимизировано, потому, что изменения в ТЗ по ходу проекта очень дорого обходятся. Да, нам удается добиваться такого.
_>И ещё вопрос, в НИОКРах, на стадии формирования ТЗ, вы пишете код, создаёте прототипы?
Это не запрещено. На стадии формирования ТЗ делается все необходимое, что помогает создать хорошее ТЗ. Если для этого необходимо написать код, сделать прототипы или макеты — это делается. Короче, никто не ограничивает вас в активностях на исследовательской фазе ТЗ, однако надо понимать, что цель этой фазы — это само ТЗ, а не код, из чего следует определенная схема расстановки приоритетов задачам. Цель кодописания на данном этапе — получение информации, необходимой для ТЗ, а не написание фрагментов конечной системы промышленного качества. Понимание этой цели позволяет радикально уменьшить объем кодописания на ней и, главное — ускорить создание ТЗ.
_>Какое процентное соотношение длительности этапов получается (ТЗ vs ТРП)?
В зависимости от работы, от степени ее неопределенности и рискованности. Я пока статистику не подводил.
Re[2]: Бизнес-требования, use cases, фун. требования и ТЗ ГО
Здравствуйте, Gaperton, Вы писали:
_>>Как лучше организовать раздел 4.2 "Требования к функциям"? _>>Что туда лучше поместить: функциональные требования, сценарии использования в полном виде или сокращённую форму сценариев использования?
G>Мы помещаем сокращенную форму сценариев использования в прикладных терминах (понятных неспециалисту) плюс функциональные требования (в технических терминах, с другой, "системной" группировкой). Делается так для того, чтобы
Тут конечно возникает вопрос про то, являются ли юзкейсы (если сценарии использования = use cases) функциями ... или вы эту тему в принципе не рассматриваете?
Re[3]: Бизнес-требования, 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 (576x720).
2. Уменьшение не более чем в 3 раза с обеспечением приемлемого качества изображения. Предельный случай — уменьшение из 1080х1920 в NTSC (480х720).
А также вот такой функции clipping-а:
i.В случае выходных разрешений 1-4 (см. таблицу 1) размер изображения в пикселах после масштабирования может быть меньше или больше выходного разрешения по одной или обеим координатам. В этом случае показывается фрагмент изображения, соответствующий выходному разрешению, выступающие части отрезаются, свободное пространство закрашивается цветом фонового слоя. Позиция фрагмента задается конфигурационными регистрами.
Несложно доказать, что данные функциональные требования необходимы и достаточны для реализации приведенных сценариев. Инженеры, работая над архитектурой, будут пользоваться только функциональными требованиями, потому что их соответствие сценариям уже доказано.
Возможно, погрязший в формализме последователь RUP назовет и то и другое use cases, и проставит между ними связь. Я предпочитаю их явно разделять терминологически. Потому, что:
1) Практика показывает, что термины "сценарий использования" и "функциональные требования" понятны всем, в том числе людям, не знакомым с RUP, а таких большинство.
2) "Сценарии" используются совсем не так, как функции. Они, на самом деле, играют важнейшую роль при управлении разработкой продукта. Именно из сценариев испольщования следует тест-план и функциональные требования. Именно к сценариям привязаны бизнес=приоритеты, именно через сценарии можно перейти от функциональных требований к бизнес-необходимости и обратно, рассчитав, скажем, объем рынка для будущего продукта, и убедившись, что технические требования соответствуют маркетинговым. Именно сценарии лишены понятны и маркетингу и техническим парням, и при этом лишены шелухи.
3)В результате, если называть и то и другое use cases, это не приводит ни к чему, кроме путаницы. Вот, например, вопросы возникают, уж не одно ли это и то же. Нет, не одно.
Re[4]: Бизнес-требования, use cases, фун. требования и ТЗ ГО
Здравствуйте, Gaperton, Вы писали:
G>Да нет, разумеется, не возникает такого вопроса. Функции — это описание возможностей, ответ на вопрос "что", сценарии — описание их конкретных способов их применения, ответы на вопросы "зачем" и "как". Это не одно и то же, даже в том редком случае, когда сценарии и функции соответствуют друг другу один к одному. Пример, наглядно демонстрирующий разницу между ними: фрагмент ТЗ на видеоконтроллер для, скажем, продвинутого DVD плеера.
Одно из формальных определений функции -- "нечто что делает система, предположительно на основании требований к ней", по-моему это определение из книги Ian F. Alexander. Следуя тому же "формализму", требования к функциям — это таки требования . Сценарии, или юзкейсы -- по большому счету функциональные требования (или функции ?) в контексте их использования. Кстати, я все-таки не понял, если у вас сценарии использования = use cases, то кто интересно будет эктором у приведенных ниже вами сценариях? Если такого отождествления нет, тогда вопрос отпадает ...
Кстати, по Вигерсу, пользовательские требования описываются в частности юзкейсами.
G>
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 (обрезанием границ). Преобразование развертки входного изображения не производится, т.е. тип и частота развертки входного и выходного изображений должны совпадать.
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, который говорит именно про требования к функциям (или функциональные требования), коими юзкейсы не являются. Посему и странно видеть юзкейсы в этом разделе ТЗ.
Получается, что у вас требования относящиеся к одной и той же функциональности (юзкейсы и вытекающие из них функциональные требования) совмещены в одном разделе ТЗ. А как проходит приёмка? Ведь, формально, проверка _каждого_ требования ТЗ должна быть отражена в "Программе и методике испытаний".
У Вас проверки в ПМИ пишутся для юзкейсов или для функциональных требований?
Re[5]: Бизнес-требования, use cases, фун. требования и ТЗ ГО
Здравствуйте, 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. .
Впрочем, еще раз, в ГОСТах на разработку ПО все может быть тупее и деревяннее — я подробно в них не копался.
Re[5]: Бизнес-требования, use cases, фун. требования и ТЗ ГО
Здравствуйте, byur, Вы писали:
G>>Да нет, разумеется, не возникает такого вопроса. Функции — это описание возможностей, ответ на вопрос "что", сценарии — описание их конкретных способов их применения, ответы на вопросы "зачем" и "как". Это не одно и то же, даже в том редком случае, когда сценарии и функции соответствуют друг другу один к одному. Пример, наглядно демонстрирующий разницу между ними: фрагмент ТЗ на видеоконтроллер для, скажем, продвинутого DVD плеера.
B>Одно из формальных определений функции -- "нечто что делает система, предположительно на основании требований к ней", по-моему это определение из книги Ian F. Alexander. Следуя тому же "формализму", требования к функциям — это таки требования . Сценарии, или юзкейсы -- по большому счету функциональные требования (или функции ?) в контексте их использования.
Не понимаю, что конкретно практически полезного мне дают подобные рассуждения. Вероятно, поэтому я ими и не занят — некогда.
B> Кстати, я все-таки не понял, если у вас сценарии использования = use cases, то кто интересно будет эктором у приведенных ниже вами сценариях? Если такого отождествления нет, тогда вопрос отпадает ...
Я, во-первых, совершенно не озабочен таким отождествлением, в силу практической бесполезности оного. Пусть этим теоретики занимаются. Мне достаточно заметить сходство, и все. Во-вторых, формально говоря у видеоконтроллера "actor" один (ЦП), это не бизнес-система, где надо явно выделять роли, так что расписывать в нашем случае это просто "штоб было" и для соблюдения ритуала смысла я не вижу — пользы не много. Хотя, если уж вдуматься как следует, то экторов на более высоком уровне будет ажно три штуки.
1) Источник потокового видео. Пишет данные кадров в память и сигнализирует о готовности кадра.
2) Конфигуратор. Управляет текущим режимом через конфигурационный интерфейс.
3) Рисовальщик меню. Рисует пнимаешь, меню, работая с отдельным слоем.
Только смысла в явном выделении этих экторов в нашем случае — полный ноль (как и слепому следованию RUP в случае микроэлектроники), метафизика сплошная. Один хрен все делается из драйвера видеоконтроллера на управляющем проце.
Вместо этого, у нас прописываются отдельно:
1) Требования к окружению. Описывается минимально необходимая конфигурация окружения, в составе которого будет работать устройство.
2) Требования к интерфейсам.
Это первые две главы в нашем внутреннем документе requirements, которые, естественно, также переносятся во внешнее ТЗ. Так — правильно.
B>Кстати, по Вигерсу, пользовательские требования описываются в частности юзкейсами.
Вполне возможно. От себя могу сказать, что у нас весь документ, в котором пять секций (требования к окружению, требования к интерфейсам, сценарии использования, функциональные требования, прочие требования), и информация из которого переносится во внешнее ТЗ, называется requirements, то есть "требования".
G>>Эти сценарии легко проверить на полноту и непротиворечивость. Их них легко вывести тестплан. Из них легко посчитать количество целевых применений видеоконтроллера — объем рынка. Им даже приоритеты легко выставить, и укоцать их в случае чего — легко. G>>Из этих сценариев следует требование наличия блока масштабирования изображения, вот такого:
B>Это достаточно очевидная вещь, когда на базе юзкейсов разрабатываются тест-кейсы, более того, на ряде проектов в Люксофте аналитики разрабатывают детальные сценарии (не могу сказать что это юзкейсы), на этапе разработки требований — и они фактически тестируются тестерами без написания тест-кейсов, если я все правильно помню. Более того, часто пользовательская документация строится на юзкейсах.
Это нормально, что правильные вещи очевидны, уважаемый коллега, не находите? Мне кажется, я вообще всегда говорю только очевидные и простые вещи . Я же не ставлю себе задачи кого-либо удивить любой ценой.
G>>Возможно, погрязший в формализме последователь RUP назовет и то и другое use cases, и проставит между ними связь. Я предпочитаю их явно разделять терминологически. Потому, что: G>>1) Практика показывает, что термины "сценарий использования" и "функциональные требования" понятны всем, в том числе людям, не знакомым с RUP, а таких большинство.
B>Формальный RUP скорее всего не назовет это юзкейсами вообще. Но правда то, что он объединяет это в группу software requirements в которой конечно же выделит юзкейсы и suuplementary req., понимая под ними (suuplementary req)как дополнительные функциональные требования, не охваченные юзкейсами, так и нефункциональные требования.
Вполне вероятно, хотя мне кажется, что несложно сделать из этого system-level use cases, которые удовлетворят формальный RUP. А по вашему — как еще должны выглядеть use-cases с точки зрения формального RUP для видеоконтроллера?
Хотя, именно поэтому я и называю то "сценариями" — чтоб поменьше такими вопросами заморачиваться .
G>>2) "Сценарии" используются совсем не так, как функции. Они, на самом деле, играют важнейшую роль при управлении разработкой продукта. Именно из сценариев испольщования следует тест-план и функциональные требования. Именно к сценариям привязаны бизнес=приоритеты, именно через сценарии можно перейти от функциональных требований к бизнес-необходимости и обратно, рассчитав, скажем, объем рынка для будущего продукта, и убедившись, что технические требования соответствуют маркетинговым. Именно сценарии лишены понятны и маркетингу и техническим парням, и при этом лишены шелухи.
B>Классический Вигерс ...
Возможно.
G>>3)В результате, если называть и то и другое use cases, это не приводит ни к чему, кроме путаницы. Вот, например, вопросы возникают, уж не одно ли это и то же. Нет, не одно.
B>Вопрос на самом деле не в этом состоял, да и никто не отождествляет юзкейсы и функциональные требования ... есть в конце концов классическая статья "Why use cases are not functions", и c другой стороны есть тенденция интерпретировать ГОСТ 34.602, который говорит именно про требования к функциям (или функциональные требования), коими юзкейсы не являются. Посему и странно видеть юзкейсы в этом разделе ТЗ.
Я вижу прямую выгоду от присутствия сценариев в ТЗ, и не вижу ровным счетом ничего существенного, что мне мешает их в ТЗ включить. Раз уж на то пошло, то я могу кому угодно доказать, что юзкейс является требованием к функциям, если это потребуется для того, чтобы включить их в ТЗ . Вопрос в любом случае мутный и казуистический, так что мне все равно, что на него отвечать, лишь бы было как мне удобно. Зачем мне в ТЗ нужны сценарии — я объяснил.
Re[6]: Бизнес-требования, use cases, фун. требования и ТЗ ГО
Здравствуйте, Gaperton, Вы писали:
G>Я, во-первых, совершенно не озабочен таким отождествлением, в силу практической бесполезности оного. Пусть этим теоретики занимаются. Мне достаточно заметить сходство, и все. Во-вторых, формально говоря у видеоконтроллера "actor" один (ЦП), это не бизнес-система, где надо явно выделять роли, так что расписывать в нашем случае это просто "штоб было" и для соблюдения ритуала смысла я не вижу — пользы не много. Хотя, если уж вдуматься как следует, то экторов на более высоком уровне будет ажно три штуки.
Вобщем не столько интересна озабоченность (i.e. отождествлением) и прочия рефлексия на тему ритуалов, сколько а) используемая методология б)ее адаптация.
G>Только смысла в явном выделении этих экторов в нашем случае — полный ноль (как и слепому следованию RUP в случае микроэлектроники), метафизика сплошная. Один хрен все делается из драйвера видеоконтроллера на управляющем проце.
Речь ведь не идет о слепом следовании RUP, не так ли, коллега?
G>Мне кажется, я вообще всегда говорю только очевидные и простые вещи
Хорошо, что допускаете что это может казаться .
G>Вполне вероятно, хотя мне кажется, что несложно сделать из этого system-level use cases, которые удовлетворят формальный RUP. А по вашему — как еще должны выглядеть use-cases с точки зрения формального RUP для видеоконтроллера?
Сомневаюсь, что техника юзкейсов в этом контексте применима и будет эффективна.
G>Хотя, именно поэтому я и называю то "сценариями" — чтоб поменьше такими вопросами заморачиваться .
О чем и речь ...
G>Я вижу прямую выгоду от присутствия сценариев в ТЗ, и не вижу ровным счетом ничего существенного, что мне мешает их в ТЗ включить. Раз уж на то пошло, то я могу кому угодно доказать, что юзкейс является требованием к функциям, если это потребуется для того, чтобы включить их в ТЗ . Вопрос в любом случае мутный и казуистический, так что мне все равно, что на него отвечать, лишь бы было как мне удобно. Зачем мне в ТЗ нужны сценарии — я объяснил.
В вопросе все достаточно ясно ... и в ответе тоже. У вас не юзкейсы, а сценарии.
Re[7]: Бизнес-требования, use cases, фун. требования и ТЗ ГО
Здравствуйте, byur, Вы писали:
G>>Я, во-первых, совершенно не озабочен таким отождествлением, в силу практической бесполезности оного. Пусть этим теоретики занимаются. Мне достаточно заметить сходство, и все. Во-вторых, формально говоря у видеоконтроллера "actor" один (ЦП), это не бизнес-система, где надо явно выделять роли, так что расписывать в нашем случае это просто "штоб было" и для соблюдения ритуала смысла я не вижу — пользы не много. Хотя, если уж вдуматься как следует, то экторов на более высоком уровне будет ажно три штуки.
B>Вобщем не столько интересна озабоченность (i.e. отождествлением) и прочия рефлексия на тему ритуалов, сколько а) используемая методология б)ее адаптация.
"Адаптация методологии" предполагает, что вы выбрали методологию, и начинаете ее адаптировать. Мы не занимаемся адаптацией методологий, так что ни чем не могу помочь — подход другой, мы решаем свои проблемы по ситуациям, и выбранные методы случайно или намеренно совпадают или похожи на методы из известных "Методологий". Меня это сходства и различия совершенно не заботят — главное это эффективность для моих задач.
В наших процессах разработки есть много общего с практиками RUP и PSP/TSP. Вообще — в любой методологии есть что-то рациональное и хорошее, что можно использовать в работе (обычно если это оставить, то от толстого описания Методологии останется тоненькая брошурка). Однако — сами "методологии" не стоят того, чтобы их "внедрять". Я считаю так, кто-то может считать иначе, я не против, и никого не собираюсь переубеждать. Своим подходом готов поделиться, если кому интересно, и с удовольствием ознакомлюсь с чужим опытом. ОПЫТОМ, а не цитатами из методологий.
G>>Мне кажется, я вообще всегда говорю только очевидные и простые вещи B>Хорошо, что допускаете что это может казаться .
Зачем вы это написали? "Мне кажется" — это просто фигура речи, для вежливости, ничего больше. Если вы настаиваете, в беседе с вами могу обойтись и без них.
G>>Вполне вероятно, хотя мне кажется, что несложно сделать из этого system-level use cases, которые удовлетворят формальный RUP. А по вашему — как еще должны выглядеть use-cases с точки зрения формального RUP для видеоконтроллера?
B>Сомневаюсь, что техника юзкейсов в этом контексте применима и будет эффективна.
Смотря что понимать под техникой юзкейсов. Основная ценность RUP не в техниках, а в его основополагающих принципах, которые достаточно универсальны, чтобы быть перенесенными на любую деятельность. Никакой особенной "техники юз-кейсов", заслуживающей пристального внимания и сильно отличающейся от подходов здравого смысла, я в RUP не заметил. Может быть вы, расскажете, в чем состоит это таинство? Только пожалуйста, к мануалам и по внешним ссылкам отсылать не нужно, своими словами расскажите. Сомнения ваши не особенно интересны — они ничего полезного в разговор не привносят.
Это так же, как в боевых исскуствах. Удар ногой кикбоксера — это совсем не то же самое, что "маваши гири" каратиста — это же совсем не одно и тоже. Однако в реальной жизни применяется в тех же обстоятельствах и приводит к тому же результату . Вы спрашиваете меня — какую Методологию (школу) я применяю, однако я просто бью ногой, дружище, когда это нужно, мне думать над этим некогда . Не по высокой науке, да, но в реальном бою это мало кого интересует .
Почему так? Потому, что я не консультант-одиночка, а руководитель толпы человек в 20, которые еще и меняются переодически в зависимости от проекта. Учить их абстрактному светлому и высокому ДАО у меня нет времени, возможности, и желания. Поэтому, нужны простые и эффективные техники, свободные от зауми, а не Методологии.
G>>Я вижу прямую выгоду от присутствия сценариев в ТЗ, и не вижу ровным счетом ничего существенного, что мне мешает их в ТЗ включить. Раз уж на то пошло, то я могу кому угодно доказать, что юзкейс является требованием к функциям, если это потребуется для того, чтобы включить их в ТЗ . Вопрос в любом случае мутный и казуистический, так что мне все равно, что на него отвечать, лишь бы было как мне удобно. Зачем мне в ТЗ нужны сценарии — я объяснил.
B>В вопросе все достаточно ясно ... и в ответе тоже. У вас не юзкейсы, а сценарии.
Как вам будет угодно, сэр .
Я предпочитаю находить сходство в подходах, и извлекать из него пользу, кто-то может концентрироваться на находении различий. С моей точки зрения, сценарии несущественно отличаются от use-cases, те же, так сказать, яйца, только вид сбоку, просто менее формализовано, а процесс ГОСТ В 29110-91 до чрезвычайнсти похож на RUP-овский controlled iteration. И эти сходства я использую практически, себе на пользу.
Здравствуйте, newbie_analyst, Вы писали:
_>Здравствуйте, Gaperton, Вы писали:
_>Получается, что у вас требования относящиеся к одной и той же функциональности (юзкейсы и вытекающие из них функциональные требования) совмещены в одном разделе ТЗ. А как проходит приёмка? Ведь, формально, проверка _каждого_ требования ТЗ должна быть отражена в "Программе и методике испытаний".
Кстати, я сейчас посмотрел ТЗ. Они в разных разделах.
1. Основания для выполнения НИР
2. Цели и задачи НИР.
3. Требования к выполнению НИР
Краткая характеристика проблемы, обоснование необходимости работ.
Краткое содержание проводимых работ/исследований.
Внимание, цитирую, должны быть указаны основные технические требования к НИР, обеспечивающие выполнение поставленных задач. А именно — сюда мы пишем "должна быть обеспечена поддержка следующих сценариев использования...".
Указывается, чем должна заканчиваться работа.
4. Технические требования
А вот тут указываются
а) требования к интерфейсам
б) функуиональные требования
в) прочие требования
и так далее. Далее там про условия сохранения гостайны и прочее. ТЗ давно утверждено и подписано, так что все в порядке.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, newbie_analyst, Вы писали:
_>>Здравствуйте, Gaperton, Вы писали:
_>>Получается, что у вас требования относящиеся к одной и той же функциональности (юзкейсы и вытекающие из них функциональные требования) совмещены в одном разделе ТЗ. А как проходит приёмка? Ведь, формально, проверка _каждого_ требования ТЗ должна быть отражена в "Программе и методике испытаний".
G>Кстати, я сейчас посмотрел ТЗ. Они в разных разделах.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, Gaperton, Вы писали:
G>>Здравствуйте, newbie_analyst, Вы писали:
_>>>Здравствуйте, Gaperton, Вы писали:
_>>>Получается, что у вас требования относящиеся к одной и той же функциональности (юзкейсы и вытекающие из них функциональные требования) совмещены в одном разделе ТЗ. А как проходит приёмка? Ведь, формально, проверка _каждого_ требования ТЗ должна быть отражена в "Программе и методике испытаний".
G>>Кстати, я сейчас посмотрел ТЗ. Они в разных разделах.
К>Это по какому-то ГОСТу или ваш формат ТЗ?
Руководитель проекта пишет, что использованы справочные материалы по оформлению НИР в соответствии с последней версией ГОСТ "Система разработки и постановки продукции на производство. Порядок выполнения научно-исследовательских работ". ГОСТ не 34-й, а 15-й, сам понимаешь. Уверен, что это не принципиально, можно и в 34-м найти ходы чтобы сделать как хочется.
Здравствуйте, Gaperton, Вы писали:
B>>Сомневаюсь, что техника юзкейсов в этом контексте применима и будет эффективна.
G>Смотря что понимать под техникой юзкейсов. Основная ценность RUP не в техниках, а в его основополагающих принципах, которые достаточно универсальны, чтобы быть перенесенными на любую деятельность. Никакой особенной "техники юз-кейсов", заслуживающей пристального внимания и сильно отличающейся от подходов здравого смысла, я в RUP не заметил. Может быть вы, расскажете, в чем состоит это таинство? Только пожалуйста, к мануалам и по внешним ссылкам отсылать не нужно, своими словами расскажите. Сомнения ваши не особенно интересны — они ничего полезного в разговор не привносят.
1. Вы отождествляете юзкейсы только с RUP, что несколько удивляет. Не RUPом единым ... Да и я не понимаю, что вам объяснять -- Коберна чтоли? Вы так и не изложили те самые "основополагающие принципы", пока тоже только общие фразы слышим от вас.
2. То как лично вы интерпретируете UC -- это ваша поблема/удача ... я свою т.з. высказал -- юзкейсы скорее неприменимы в области "железа". Некие сценарии -- да, видимо можно использовать.
G>Как вам будет угодно, сэр .
Вы сама любезность, мсье.
Re[9]: Бизнес-требования, use cases, фун. требования и ТЗ ГО
Здравствуйте, byur, Вы писали:
B>Здравствуйте, Gaperton, Вы писали:
B>>>Сомневаюсь, что техника юзкейсов в этом контексте применима и будет эффективна.
G>>Смотря что понимать под техникой юзкейсов. Основная ценность RUP не в техниках, а в его основополагающих принципах, которые достаточно универсальны, чтобы быть перенесенными на любую деятельность. Никакой особенной "техники юз-кейсов", заслуживающей пристального внимания и сильно отличающейся от подходов здравого смысла, я в RUP не заметил. Может быть вы, расскажете, в чем состоит это таинство? Только пожалуйста, к мануалам и по внешним ссылкам отсылать не нужно, своими словами расскажите. Сомнения ваши не особенно интересны — они ничего полезного в разговор не привносят.
B>1. Вы отождествляете юзкейсы только с RUP, что несколько удивляет. Не RUPом единым ... Да и я не понимаю, что вам объяснять -- Коберна чтоли? Вы так и не изложили те самые "основополагающие принципы", пока тоже только общие фразы слышим от вас.
Здравствуйте, byur, Вы писали:
B>Здравствуйте, Gaperton, Вы писали:
B>>>Сомневаюсь, что техника юзкейсов в этом контексте применима и будет эффективна.
G>>Смотря что понимать под техникой юзкейсов. Основная ценность RUP не в техниках, а в его основополагающих принципах, которые достаточно универсальны, чтобы быть перенесенными на любую деятельность. Никакой особенной "техники юз-кейсов", заслуживающей пристального внимания и сильно отличающейся от подходов здравого смысла, я в RUP не заметил. Может быть вы, расскажете, в чем состоит это таинство? Только пожалуйста, к мануалам и по внешним ссылкам отсылать не нужно, своими словами расскажите. Сомнения ваши не особенно интересны — они ничего полезного в разговор не привносят.
B>1. Вы отождествляете юзкейсы только с RUP, что несколько удивляет. Не RUPом единым ...
Я нигде не говорил, что юзкейсы это только RUP. Да и какая разница?
B> Да и я не понимаю, что вам объяснять -- Коберна чтоли?
Я не просил вас ничего мне объяснять. Однако если хотити что-то объяснить — вперед, никто не держит. Знанием имен тока на понт брать не надо — это для пионеров оставьте.
B> Вы так и не изложили те самые "основополагающие принципы", пока тоже только общие фразы слышим от вас.
Неудивительно, ведь каждый слышит только то, что хочет слышать.
B>2. То как лично вы интерпретируете UC -- это ваша поблема/удача ...
Зачем вы это написали? Если для вас иметь свой собственный взгляд на вещи обязательно является либо проблемой либо редкостной удачей, Юрий, то это ваша проблема, не моя . Я к этому отношусь проще.
B>я свою т.з. высказал -- юзкейсы скорее неприменимы в области "железа". Некие сценарии -- да, видимо можно использовать.
Нивабиду, но ваша "точка зрения" не обладает для окружающих никакой ценностью, если вы не гуру вроде якобсона. мне интересны ваши рассуждения, а не точки зрения. Рассуждений у вас пока нет.
Re[10]: Бизнес-требования, use cases, фун. требования и ТЗ Г
B>> Да и я не понимаю, что вам объяснять -- Коберна чтоли?
G>Я не просил вас ничего мне объяснять. Однако если хотити что-то объяснить — вперед, никто не держит. Знанием имен тока на понт брать не надо — это для пионеров оставьте.
Тут необходимо пояснить. Я не просил вас пересказывать мне книги, их я и без вас в состоянии прочесть. Я просил вас пояснить вашу мысль. Если эта мысль у вас вообще есть, то вам не составит труда пояснить ее ход без пересказывания учебников, исходя из вашего практического опыта. На примере с живого проекта, как это сделал я. Любому практику понятна разница между цитированием мануалов и изложением личного опыта.
Вы консультант, и претендуете на особое знание? Самое время его наглядно продемонстрировать. Вы же относитесь к форумам как к площадкам для рекламы, тусовкам, в которых надо участвовать? Пожалуйста — объясните мне
1) чем изложение техники юзкейсов в RUP-related sources, над которыми работал сам Якобсон, радикально хуже по сравнению с тонной других источников.
2) В чем принципиальное практическое отличие "техники юзкейсов", от их вольной трактовки — сценариев.
Объясните понятно и доходчиво, что любому инженеру понятно станет, обещаю при случае приглашать вас в качестве консультанта, и рекомендовать знакомым — даже есть один на примете.
Ну, будем отвечать? Момент истины настал. Тока давайте ценить время друг друга — умняк накидывать не надо, и подменять объясненния мусором из терминов и фамилий. Я умею отличать понимание предмета от желания произвести впечатление, чем ваша публика, консультанты, часто грешит.
Re[11]: Бизнес-требования, use cases, фун. требования и ТЗ Г
Здравствуйте, Gaperton, Вы писали:
G>Тут необходимо пояснить. Я не просил вас пересказывать мне книги, их я и без вас в состоянии прочесть. Я просил вас пояснить вашу мысль. Если эта мысль у вас вообще есть, то вам не составит труда пояснить ее ход без пересказывания учебников, исходя из вашего практического опыта. На примере с живого проекта, как это сделал я. Любому практику понятна разница между цитированием мануалов и изложением личного опыта.
Мсье, ваш тон не располагает к дискуссии. Оставьте ваше "плавали-знаем" вашим проектам и "каким-то там пионэрам".
G>Вы консультант, и претендуете на особое знание? Самое время его наглядно продемонстрировать. Вы же относитесь к форумам как к площадкам для рекламы, тусовкам, в которых надо участвовать? Пожалуйста — объясните мне
Елене привет от меня!!!
G>1) чем изложение техники юзкейсов в RUP-related sources, над которыми работал сам Якобсон, радикально хуже по сравнению с тонной других источников.
Хто вам сказал что хуже? Это ваш домысел ...
G>2) В чем принципиальное практическое отличие "техники юзкейсов", от их вольной трактовки — сценариев.
Отличие в определении. И бардаке, который возникает если вещи не называть своими именами. Юзкейс включает в себя множество сценариев, один сценарий -- не всегда означает юзкейс. У юзкейса обязательно есть эктор, в отличие от сценария. В моей практике я это разделяю и называю своими именами и призываю это делать других. Не нужно иметь суперинтеллект, чтобы придумать как это использовать на практике. Если вы между собой и заказчиком договоритесь называть "горшок" "креслом", и будете понимать друг друга -- значит все ОК. Я как консультант просто перейду на ваш птичий язык и буду оперировать им .
G>Объясните понятно и доходчиво, что любому инженеру понятно станет, обещаю при случае приглашать вас в качестве консультанта, и рекомендовать знакомым — даже есть один на примете.
Благодарю вас мсье, но боюсь в ближайшее время я не смогу принять ваше приглашение как "консультант-одиночка" .
G>Ну, будем отвечать? Момент истины настал. Тока давайте ценить время друг друга — умняк накидывать не надо, и подменять объясненния мусором из терминов и фамилий. Я умею отличать понимание предмета от желания произвести впечатление, чем ваша публика, консультанты, часто грешит.
"Не нукай, не запряг" (с) русская поговорка. А на вопрос я ответил выше.
P.S. "А ты азартен, Парамоша" (с) ... момент истины, понимаешь ... Я плакалъ.
Re[9]: Бизнес-требования, use cases, фун. требования и ТЗ ГО
Здравствуйте, byur, Вы писали:
B> юзкейсы скорее неприменимы в области "железа". Некие сценарии -- да, видимо можно использовать.
Почему? Какая разница, в кнечном итоге, что проектируется — софт или "железо"? Механизм использования этого (того, что проектируется) всё равно можно описывать посредством юзкейсов.
Здравствуйте, byur, Вы писали:
B>Отличие в определении. И бардаке, который возникает если вещи не называть своими именами.
Мне кажется, терминологический спор не стоит и выеденного яйца. Термин юзкейс, как и множество других (например, связность или зацепление), ещё не устаканился. Одни авторы понимают одно, другие — немного другое. Поэтому, полагаю, не стоит из-за этого "ломать копья".
Из философии науки известно, что термины и определения "устаканиваются" не на заре, а на закате научной дисциплины.
B>Юзкейс включает в себя множество сценариев, один сценарий -- не всегда означает юзкейс.
Коберн в своей книге написал именно так. Но, полагаю, сторонникам точки зрения Коберна будет любопытно узнать определение сценария в прогнозировании:
"СЦЕНАРИЙ [scenario] в прогнозировании — преимущественно качественное описание возможных вариантов развития исследуемого объекта при различных сочетаниях определенных (заранее выделенных) условий. Метод С. не предназначен для “предсказания” будущего, он должен в развернутой форме лишь показать возможные варианты развития событий (для их дальнейшего анализа) и выбора наиболее реальных, благоприятных и т. п."
Если опираться на это устоявшееся определение сценария, то юзкейс корректнее переводить, как сценарий использования, потому что именно сценарий, согласно определению, содержит варианты, но не наоборот.
КЛ>Если опираться на это устоявшееся определение сценария, то юзкейс корректнее переводить, как сценарий использования, потому что именно сценарий, согласно определению, содержит варианты, но не наоборот.
Странно. Сценарий Вы определили практически буквально как в RUP, а вывод сделали противоположный. При том что "сase" зря переводят как "вариант". Имхо скорее "прецедент".
... << RSDN@Home 1.2.0 alpha rev. 787>>
Re[13]: Бизнес-требования, use cases, фун. требования и ТЗ Г
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Мне кажется, терминологический спор не стоит и выеденного яйца. Термин юзкейс, как и множество других (например, связность или зацепление), ещё не устаканился. Одни авторы понимают одно, другие — немного другое. Поэтому, полагаю, не стоит из-за этого "ломать копья".
80% споров из-за разницы в терминологии. Меня еще в аспирантуре научили бережно относится к терминам.
КЛ>Из философии науки известно, что термины и определения "устаканиваются" не на заре, а на закате научной дисциплины.
О какой науке вы говорите ... программная инженерия -- это инженерная дисциплина.
Re[14]: Бизнес-требования, use cases, фун. требования и ТЗ Г
Здравствуйте, byur, Вы писали:
B>Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>>Мне кажется, терминологический спор не стоит и выеденного яйца. Термин юзкейс, как и множество других (например, связность или зацепление), ещё не устаканился. Одни авторы понимают одно, другие — немного другое. Поэтому, полагаю, не стоит из-за этого "ломать копья".
B>80% споров из-за разницы в терминологии. Меня еще в аспирантуре научили бережно относится к терминам.
КЛ>>Из философии науки известно, что термины и определения "устаканиваются" не на заре, а на закате научной дисциплины.
B>О какой науке вы говорите ... программная инженерия -- это инженерная дисциплина.
Прикладных наук никогда не было, нет и не будет, потому что есть наука и есть ее приложения. ( Пастер, отсюда)
А споры о терминах, на мой взгляд, совершенно неконструктивны.
Re[12]: Бизнес-требования, use cases, фун. требования и ТЗ Г
Здравствуйте, byur, Вы писали:
G>>Тут необходимо пояснить. Я не просил вас пересказывать мне книги, их я и без вас в состоянии прочесть. Я просил вас пояснить вашу мысль. Если эта мысль у вас вообще есть, то вам не составит труда пояснить ее ход без пересказывания учебников, исходя из вашего практического опыта. На примере с живого проекта, как это сделал я. Любому практику понятна разница между цитированием мануалов и изложением личного опыта.
B>Мсье, ваш тон не располагает к дискуссии. Оставьте ваше "плавали-знаем" вашим проектам и "каким-то там пионэрам".
"Обиделся" — ушел от ответа на неудобный вопрос. Этот распространенный паттерн поведения не к лицу профессионалам вашего уровня, сэр. Зело "пионерский" он какой-то. Обижаться в моих словах не на что — я ж не ставил под сомнение вашу квалификацию, и не хамил. Примера из практического опыта, я так понимаю, нам от вас не дождаться?
G>>1) чем изложение техники юзкейсов в RUP-related sources, над которыми работал сам Якобсон, радикально хуже по сравнению с тонной других источников.
B>Хто вам сказал что хуже? Это ваш домысел ...
Раз не хуже, зачем тогда вы мне парой постов выше с умным видом указали, что тема юз-кейсов не ограничивается RUP? Неужто исключительно так — для красного словца, ученость свою продемонстировать? Да не надо ее демонстрировать — верю я вам, верю!
G>>2) В чем принципиальное практическое отличие "техники юзкейсов", от их вольной трактовки — сценариев.
B>Отличие в определении. И бардаке, который возникает если вещи не называть своими именами. Юзкейс включает в себя множество сценариев, один сценарий -- не всегда означает юзкейс. У юзкейса обязательно есть эктор, в отличие от сценария.
Начну с конца. Сразу, to cut off the bullshit.
Use cases do not need to be specified in a special language. They can be written in any style that suits the needs of the project.
Теперь, вы нам здесь рассказали. Пересказ общеизвестного определения use case, с которым любой желающий мжет ознакомиться в википедии, плохо переведенный на русский язык. Use case часто переводится в том числе и как "сценарии использования" (еще — как варианты использования, случаи использования), который часто в разговоре сокращают до просто "сценарии". Scenarios имеет также иногда используемый синоним "stories".
У меня в русскоязычной документации, например, это проходит именно как "сценарии использования". Также, я не пишу актора на против каждого кейса, когда он в системе один, и не считаю что от этого юзкейс перестает быть юзкейсом.
Существенная разница между scenario и use case только в уровне общности, абстракции (не в наличии и отсутсвии actor — список actors и у сценариев будет в общем случае такой же, как и у use case) — use case не обязан быть конкретным, он может описывать класс взаимодействий. И он имеет primary scenario — основной конкретный сценарий развития событий. Все. Отношение между ними блико к отношению "класс-экземпляр".
Это все, что вы хотели мне сказать? Стоило ли из-за этого разводить такой флейм? Короче, мне все ясно, и больше к вам вопросов нет.
B>В моей практике я это разделяю и называю своими именами и призываю это делать других. Не нужно иметь суперинтеллект, чтобы придумать как это использовать на практике. Если вы между собой и заказчиком договоритесь называть "горшок" "креслом", и будете понимать друг друга -- значит все ОК. Я как консультант просто перейду на ваш птичий язык и буду оперировать им . G>>Объясните понятно и доходчиво, что любому инженеру понятно станет, обещаю при случае приглашать вас в качестве консультанта, и рекомендовать знакомым — даже есть один на примете. B>Благодарю вас мсье, но боюсь в ближайшее время я не смогу принять ваше приглашение как "консультант-одиночка" .
Я сказал — буду рекомендовать, если хорошо объясните. Цитировать определение use case без собственных пояснений и с плохим переводом на русский, и напирать при этом на "называние вещей своими именами", в топике про ГОСТ... Это я нормальным объяснением не считаю (как и нормальной манерой ведения дискуссии). Не стоит оно того пафоса, который был разведен постами выше.
G>>Ну, будем отвечать? Момент истины настал. Тока давайте ценить время друг друга — умняк накидывать не надо, и подменять объясненния мусором из терминов и фамилий. Я умею отличать понимание предмета от желания произвести впечатление, чем ваша публика, консультанты, часто грешит. B>"Не нукай, не запряг" (с) русская поговорка. А на вопрос я ответил выше. B>P.S. "А ты азартен, Парамоша" (с) ... момент истины, понимаешь ... Я плакалъ.
Ну, плакать, право же, не надо. Ничего страшного. Хотя...
Re[13]: Бизнес-требования, use cases, фун. требования и ТЗ Г
Здравствуйте, Gaperton, Вы писали:
G>"Обиделся" — ушел от ответа на неудобный вопрос. Этот распространенный паттерн поведения не к лицу профессионалам вашего уровня, сэр. Зело "пионерский" он какой-то. Обижаться в моих словах не на что — я ж не ставил под сомнение вашу квалификацию, и не хамил. Примера из практического опыта, я так понимаю, нам от вас не дождаться? G>Раз не хуже, зачем тогда вы мне парой постов выше с умным видом указали, что тема юз-кейсов не ограничивается RUP? Неужто исключительно так — для красного словца, ученость свою продемонстировать? Да не надо ее демонстрировать — верю я вам, верю!
Вау .. если это не хамство ... то что тогда хамство?
Скажите, каково максимальное кол-вол юзкейсов было в ваших системах, по вашему опыту? Задайте этот вопрос широкой аудитории и сравните ответы (количество) с собственным. Вот вам и разница в подходах. Требуются дополнительные пояснения???
G>Теперь, вы нам здесь рассказали. Пересказ общеизвестного определения use case, с которым любой желающий мжет ознакомиться в википедии, плохо переведенный на русский язык. Use case часто переводится в том числе и как "сценарии использования" (еще — как варианты использования, случаи использования), который часто в разговоре сокращают до просто "сценарии". Scenarios имеет также иногда используемый синоним "stories".
Еще и прецедентами их переводят ... и что? Может вы и сокращаете в разговоре до "сценариев", а другие не сокращают ... и что другие не правы, что вкладывают в сценарий несколько иное понятие?
Следуя вашей логике Use case = сценарий (в сокращенной форме). Сценарий это stories (напрашивается сокращенная форма от user stories), получаем что Use case = user stories ... великолепно .
G>У меня в русскоязычной документации, например, это проходит именно как "сценарии использования". Также, я не пишу актора на против каждого кейса, когда он в системе один, и не считаю что от этого юзкейс перестает быть юзкейсом.
Не пишите и его наличие -- разные вещи.
G>Существенная разница между scenario и use case только в уровне общности, абстракции (не в наличии и отсутсвии actor — список actors и у сценариев будет в общем случае такой же, как и у use case) — use case не обязан быть конкретным, он может описывать класс взаимодействий. И он имеет primary scenario — основной конкретный сценарий развития событий. Все. Отношение между ними блико к отношению "класс-экземпляр".
Эта разница будет если мы примем что сценарий есть часть юзкейса. Если это не подразумевается, но есть явная последовательность действий, то это что не сценарий??? И у него не может отсутствовать эктор?
G>Я сказал — буду рекомендовать, если хорошо объясните. Цитировать определение use case без собственных пояснений и с плохим переводом на русский, и напирать при этом на "называние вещей своими именами", в топике про ГОСТ... Это я нормальным объяснением не считаю (как и нормальной манерой ведения дискуссии). Не стоит оно того пафоса, который был разведен постами выше.
Да, я жалею потраченного на этот флейм с вами времени. Честь имею кланяться, мсье.
P.S. Елене привет передали?
Re[14]: Бизнес-требования, use cases, фун. требования и ТЗ Г
Здравствуйте, byur, Вы писали:
B>Вау .. если это не хамство ...
Йоу. Вот это — не хамство. Не согласны — выделите "хамство" жирным. G>>"Обиделся" — ушел от ответа на неудобный вопрос. Этот распространенный паттерн поведения не к лицу профессионалам вашего уровня, сэр. Зело "пионерский" он какой-то. Обижаться в моих словах не на что — я ж не ставил под сомнение вашу квалификацию, и не хамил. Примера из практического опыта, я так понимаю, нам от вас не дождаться?
B>то что тогда хамство?
А вот это G>>Раз не хуже, зачем тогда вы мне парой постов выше с умным видом указали, что тема юз-кейсов не ограничивается RUP? Неужто исключительно так — для красного словца, ученость свою продемонстировать? Да не надо ее демонстрировать — верю я вам, верю!
написано в ответ на вашу хамоватую фразу: B>Хто вам сказал что хуже? Это ваш домысел...
Что хотели — то и получили, грех жаловаться. Неужто причинно-следственной связи между вашими постами и моими ответами не видите? Следите сначала за своими словами, а потом изумляйтесь "хамству".
B>Скажите, каково максимальное кол-вол юзкейсов было в ваших системах, по вашему опыту? Задайте этот вопрос широкой аудитории и сравните ответы (количество) с собственным. Вот вам и разница в подходах. Требуются дополнительные пояснения???
Да, требуются дополнительные пояснения.
Зачем я должен задавать этот вопрос широкой аудитории, и что мне делать с ответом? Цель — какая?
Каким именно образом я получу из ответов всю разницу в подходах? Какую такую "всю", в каких таких "подходах"?
Ответ на этот вопрос вообще не слишком показателен, потому что кейсы бывают разного уровня общности, и их можно детализировать до разного уровня — по желанию. А если явно выделять system-level use cases, то их станет еще больше. Поэтому, результаты этого никому не нужного опроса будут еще и невалидными.
Кейсы по "своим системам". Скажу, отчего не сказать. Мне скрывать нечего.
1. В бизнес-системах, которыми я знимался после универсистета, количество ролей не превышало 10, а количество прикладных кейсов — вероятно, сотни, не больше.
2. В системе CQG-клиент, которая умеет делать почти все, что нужно трейдерам, количество пользовательских кейсов исчисляется тысячами, а системных — десятками тысяч. Общий объем кода 50 мегабайт.
3. В системе CQG-сервер, системные кейсы порядка тысяч штук, до десятка, наверно.
Напоминаю вам, многоуважаемый сэр, свою просьбу — приведите пожалуйста конкретные примеры из своей практики, иллюстрирующие вашу точку зрения. Ведь она не сводится, вероятно, к тому, как правильно называть use case? Или это все, что вы хотите сказать? Все — так и скажите, "да, это все", и вопрос будет снят.
G>>Теперь, вы нам здесь рассказали. Пересказ общеизвестного определения use case, с которым любой желающий мжет ознакомиться в википедии, плохо переведенный на русский язык. Use case часто переводится в том числе и как "сценарии использования" (еще — как варианты использования, случаи использования), который часто в разговоре сокращают до просто "сценарии". Scenarios имеет также иногда используемый синоним "stories".
B>Еще и прецедентами их переводят ... и что? Может вы и сокращаете в разговоре до "сценариев", а другие не сокращают ... и что другие не правы, что вкладывают в сценарий несколько иное понятие? B>Следуя вашей логике Use case = сценарий (в сокращенной форме). Сценарий это stories (напрашивается сокращенная форма от user stories), получаем что Use case = user stories ... великолепно .
Это вы следуете своей логике, не моей. По моей логике — "хоть горшком назови, только в печь не ставь".
G>>У меня в русскоязычной документации, например, это проходит именно как "сценарии использования". Также, я не пишу актора на против каждого кейса, когда он в системе один, и не считаю что от этого юзкейс перестает быть юзкейсом.
B>Не пишите и его наличие -- разные вещи.
Юрий. Хотите нормально общаться — выводы из ваших общих фраз делайте пожалуйста сами, явно, и озвучивайте их сами, не надо обрывать рассуждение в начале и заставлять собеседника догадываться, что вы хотите сказать. Есть что сказать по существу — договаривайте до конца, этот ореол таинственности и загадочности вокруг элементарных вещей, который вы создаете, задолбал уже, если честно.
G>>Существенная разница между scenario и use case только в уровне общности, абстракции (не в наличии и отсутсвии actor — список actors и у сценариев будет в общем случае такой же, как и у use case) — use case не обязан быть конкретным, он может описывать класс взаимодействий. И он имеет primary scenario — основной конкретный сценарий развития событий. Все. Отношение между ними блико к отношению "класс-экземпляр".
B>Эта разница будет если мы примем что сценарий есть часть юзкейса. Если это не подразумевается, но есть явная последовательность действий, то это что не сценарий??? И у него не может отсутствовать эктор?
1. Вы выполните мою просьбу, сэр, и приведете пример сценария из вашей практики, у которого отсутствует "эктор" — для иллюстрации вашей мысли? Что может быть проще?
2. actor is something or someone who supplies a stimulus to the system. An actor cannot be controlled by the system and is defined as being outside the system. Любой сценарий начинается с внешнего по отношению к рассматриваемой подсистеме стимула, который исходит от эктора, находящегося в рамках внешней подсистемы. Ваш "сценарий без эктора" обязательно будет относится к system-level use case, у которого обязательно будут "экторы", хотите вы этого, или нет. Тот факт, что вы можете пропустить этот кейс при анализе — сути дела не меняет, это простая неаккуратность.
3. Правильнее было бы сказать, "если мы примем, что сценарий относится к юзкейсу". "Является частью" — только одно из отношений между сущностями (довольно специфическое), и по отношению к сценариям и кейсам это отношение некорректно на мой взгляд.
G>>Я сказал — буду рекомендовать, если хорошо объясните. Цитировать определение use case без собственных пояснений и с плохим переводом на русский, и напирать при этом на "называние вещей своими именами", в топике про ГОСТ... Это я нормальным объяснением не считаю (как и нормальной манерой ведения дискуссии). Не стоит оно того пафоса, который был разведен постами выше.
B>Да, я жалею потраченного на этот флейм с вами времени. Честь имею кланяться, мсье.
Прошу простить меня, сэр, за такое замечание, ничего личного — но вы сами это затеяли, и по моим данным прекрасно знали, на что идете. Хороший был повод для вас продемонстрировать свои познания в технике юзкейсов и свой опыт — но вы почему-то не захотели, предпочли пофлеймить и откланяться. Зачем? Непонятно.
B>P.S. Елене привет передали?
Многотысячная аудитория с замиранием серца следит за нашей дискуссией — так что вы вполне можете сами пользуясь случаем передавать приветы друзьям, родным, близким, и знакомым.
Я вот, например, пользуясь случаем передаю сердечный привет своему давнему другу dbg, известному также как Изя Рнет , и приглашаю его к себе в гости!
P.S.: Юрий, вы близко к серцу это все не принимайте пожалуйста . И правда ведь знали, на что идете .
Коллега, есть к Вам вопрос практического характера, как специалисту.
Необходимо разработать сервис, который бы периодически (например, 10 раз в сек.) получал результаты измерений некоторых параметров (5 шт.) от продвинутой железяки по специализированному протоколу поверх TCP/IP.
Сервис должен осуществлять усреднение этих параметров на периоде 1 сек. и хранение их в оперативной памяти.
Этим сервисом будут пользоваться другие компоненты. Используя API, предоставляемый сервисом, они будут запрашивать набор осреднённых значений за какой-то интервал (10-15 сек).
Плюс, сервис должен реализовать некоторый дополнительный функционал — такой, как сброс архивов работы на жёсткий диск, сигнализация о том, что одна или несколько железяк ничего не присылают и т.д.
Встаёт задача разработки ТЗ.Вернее встаёт вопрос эффективности использования вариантов использования (простите за каламбур) для описания функциональности этого сервиса.
После беглого анализа получается, что акторами для этого сервиса будут:
— железяка, которая посылает результаты измерений
— другой сервис, который, используя API, будет запрашивать усреднённые значения.
Исходя из этого, можно сформулировать два варианта использования:
1)Железяка подключается к сервису. Железяка посылает сервису значения параметров, сервис их принимает и подтверждает получение.
2)Сторонний сервис подключается к сервису, указывает интервал (опционально, если не указывается, используется значение по умолчанию — 15 сек), за который хочет получить информацию и состав параметров (опционально, если не указывается, считается, что сторонний сервис запросил значения всех параметров). Сервис возвращает запрошенные результаты.
Куда девать описание функциональности усреднения данных на интервале? Задачу усреднения сервис выполняет самостоятельно, по своей инициативе.
Актора тут никакого нет и в вариант использования это на запихнёшь. Также сервис сам занимается задачами архивирования данных, оповещения администратора о сбоях и т.д.
Получается, здесь варианты использования не применимы?
P.S. Описание системы специально очень сильно упрощено, чтобы ухватить суть.
Здравствуйте, newbie_analyst, Вы писали:
_>Необходимо разработать сервис, который бы периодически (например, 10 раз в сек.) получал результаты измерений некоторых параметров (5 шт.) от продвинутой железяки по специализированному протоколу поверх TCP/IP. _>Сервис должен осуществлять усреднение этих параметров на периоде 1 сек. и хранение их в оперативной памяти.
Понятно. Формулируете вы "объектно", поэтому сразу рефлекторно пишем CRC-Card, который фиксирует функциональность — для того, чтобы понятно стало. Формат:
+ выполняемая функция (с кем общается для ее выполнения)
Name: Service
+ Умеет получать параметры на периодической основе (Железяка)
+ Знает усредненные параметры на периоде 1 сек.
_>Этим сервисом будут пользоваться другие компоненты. Используя API, предоставляемый сервисом, они будут запрашивать набор осреднённых значений за какой-то интервал (10-15 сек).
+ Знает N последних усредненных значений.
Занятно, напоминает сервер обработки котировок.
_>Плюс, сервис должен реализовать некоторый дополнительный функционал — такой, как сброс архивов работы на жёсткий диск, сигнализация о том, что одна или несколько железяк ничего не присылают и т.д.
+ Умеет сохранять историю [усредненных] значений на диск (DiskStorage)
+ Умеет уведомлять о событиях (Listener)
_>Встаёт задача разработки ТЗ.Вернее встаёт вопрос эффективности использования вариантов использования (простите за каламбур) для описания функциональности этого сервиса.
_>После беглого анализа получается, что акторами для этого сервиса будут: _> — железяка, которая посылает результаты измерений _> — другой сервис, который, используя API, будет запрашивать усреднённые значения.
Допустим.
_>Исходя из этого, можно сформулировать два варианта использования:
_>1)Железяка подключается к сервису. Железяка посылает сервису значения параметров, сервис их принимает и подтверждает получение.
Вот как? Здесь вы сообщили мне существенно больше информации, чем раньше. Тогда правим CRC-карту — пока вы не сообщили кейс, я предполагал, что это сервис опрашивает железяку. Вместо
+ Умеет получать параметры на периодической основе (Железяка)
Пишем
+ Умеет получать новые значения параметров.
Вариант использования с эктором "Источник данных" назовем, скажем, "Получение параметров". Все, CRC-Card выбрасываем — он был нужен мне чтобы структурировать ваши слова и для иллюстрации, что кейсы дают в чем-то больше информации чем описание функциональности . Однако (хозяйке на заметку) — CRC-Card чрезвычайно мощный метод описания функциональности на мелком уровне — совершенно уникальное промежуточное представление между требованиями и дизайном.
_>2)Сторонний сервис подключается к сервису, указывает интервал (опционально, если не указывается, используется значение по умолчанию — 15 сек), за который хочет получить информацию и состав параметров (опционально, если не указывается, считается, что сторонний сервис запросил значения всех параметров). Сервис возвращает запрошенные результаты.
Замечание:
— возвращается однократно, без подписки на обновление? Или можно и так и так? Если да, то тут не один, а два кейса.
— что насчет подписки на события?
Эктор "Клиент"
1. Получить усредненные значения параметров (агрегаты — термин вводим, определим в другом месте) за заданный период.
_>Куда девать описание функциональности усреднения данных на интервале? Задачу усреднения сервис выполняет самостоятельно, по своей инициативе.
Сначала скажу, как бы сделал я, и как советую сделать вам. В функциональных требованиях раскрыть отдельным пунктом — как считаются "агрегаты", вернее — дать им там точно определение, включающее их способ расчета. use cases характеризует сценарии взаимодействия с внешним миром/способы использования вашей штуковины, отвечая на вопросы "зачем ваша штука нужна", "как и для чего она будет использоваться". Ваш сервис знает усредненные значения, и все, этого достаточно для описания кейса.
Кейсы, с одной стороны дают больше информации по сравнению с функциональными требованиями — и одновременно меньше. Парадокса никакого нет — объясняю.
Все виды структурирования информации о вашей системе — будь то кейсы, функциональные требования, тестовые сценарии (конструктивное выражение требований), разные виды спецификаций — это модели, ни одна из которых по отдельности не дает полной информации о системе. Но все они в совокупности дают достаточно полное покрытие.
Пример из дизайна/архитектуры: есть статические модели (например, диаграммы классов), поведенческие модели (например, диаграммы переходов состояний), и функциональные модели (например, диаграмма потоков данных). Они — ортогональны, то есть каждый из них описывает систему со своего угла зрения, под которым видны ее разные аспекты. "Главной" точки зрения нет — они дополняют, а не заменяют друг друга. Диаграмма классов дает информацию о структуре системы, интерфейсах составны частей, и связях между компонентами системы. Но она не дает никакой информации о поведении системы, и протоколах взаимодействия ее составных частей. В ней нет времени, она статическая. Диаграмма переходов состояний класса — задает протокол его работы, но не дает информации о его связях с соседями и роли в системе — время в ней есть, но нет структуры и связей. Диаграмма потока данных показывает, каким образом информация трансформируется и проходит через систему, и в каком порядке происходит обработка, какие данные от каких зависят и т.д. Однако, в ней нет ни времени, ни структуры. Только три типа моделей в совокупности адекватно опишут систему.
То же самое имеет место быть с разными вариантами представления требований. Вы не должны использовать какой-то один вариант — вам надо смело комбинировать все доступные варианты с целью добится максимально простого, понятного, и непротиворечивого описания вашей системы. Главное — именно это, от вас требуется хорошее ТЗ, а не точное соответствие правилам оформления use cases и правильность выполнения других техник.
В этом вся суть — не надо сдвигать акцент с разработки продукта на разработку документации и соответствие каким либо формальным правилам. Пусть теоретики и прочая публика кто на этом зарабатывает этим занимается. Не полагайтесь на формальные техники — понимание сути ваших проблем и умение объясняться простып и понятным человеческим языком гораздо важнее. Техники, которые лично вам помогают добиться главной цели — простого и понятного ТЗ применяйте. Которые не помогают — нахер, пишите как умеете концетрируясь на сути ваших проблем.
Не позволяет вам use case записать алгоритм усреднения? Любая другая проблема? К черту техники, пишите как вам кажется правильным. Тоже мне, проблема. Что, работать хуже будет, если некошерно, не по учебникам документацию написать, чтоли? Да все ровно наоборот .
_>Актора тут никакого нет и в вариант использования это на запихнёшь. Также сервис сам занимается задачами архивирования данных, оповещения администратора о сбоях и т.д.
В функциональных требованиях описать. Кстати, административный интерфейс неплохо также описать кейсами каким-нить. "Администратор" — это очень похоже на эктора.
_>Получается, здесь варианты использования не применимы?
Да вот еще. С какой стати? Просто не надо чудес от этой "техники" ждать. Потому что нет там никакой особой техники на самом деле — не техника приводит вас к успеху, а ваши мозги и понимание проблем. "Варианты использования" — это всего лишь один из способов представления требований, иногда полезный — не более того.
Для пищи к размышлению — даю свою форму документа требований, который после разработки креативно копипастится в ГОСТ-овское ТЗ.
1. Требования к окружению — в каком окружении ваша штука будет работать. Структурная схема типового окружения, описание вольным текстом — в составе какой системы/комплекса то должно функционировать.
2. Требования к внешним интерфейсам (если они есть). Тут не надо ничего выдумывать — либо специальные требования есть, либо их нет. У вас, скажем, требования — TCP/IP.
3. Сценарии/способы использования.
Отвечает на вопрос — как ваша штука будет использоваться.
Сюда узкейсы вольным текстом — простым и человеческим, в терминах окружения.
4. Фукциональные требования
"Определение" вашей штуки. Что она умеет делать.
5. Прочие требования.
Все, что не влезло в предыдущие секции, но существенно.
Этот простенький пример я привёл для того, чтобы проиллюстрировать, что достаточно большая часть функционала (в этом случае одна треть или больше) системы не покрывается вариантами использования.
Но, наверное, это действительно не страшно, и дыры можно закрывать функциональными требованиями.
И всё-таки один вопрос меня мучает.
Как мне организовать раздел ТЗ № 4.2 "Требования к функциям системы"? Сваливать туда вперемешку варианты использования, функциональные требования, вытекающие из вариантов использования, и функциональные требования, возникшие сами по себе?
Либо только варианты использования и самостоятельные функциональные требования, чтобы не дублировать описание одной и той же функциональности и не путать заказчика?
Здравствуйте, newbie_analyst, Вы писали:
_>Этот простенький пример я привёл для того, чтобы проиллюстрировать, что достаточно большая часть функционала (в этом случае одна треть или больше) системы не покрывается вариантами использования. _>Но, наверное, это действительно не страшно, и дыры можно закрывать функциональными требованиями.
Конечно не страшно. Главное здесь — не употреблять слов вроде "эктор", а писать по человечески. Скажем, "получение параметров от источника". Как только начнете писать человеческим языком — выяснится, что "варианты использования" — это не совсем человеческое описание вашего текста. Не литературно. У незнакомого с понятием Use case человека вызовет недоумение — смысл этого словосочетания на русском предполагает РАЗНЫЕ варианты использования одной штуки (спичкой можно плиту зажигать и в ухе ковыряться), а у вас они не самостоятельны, а взаимодополняющие. Более по человечески будет написать "сценарии взаимодействия" на мой взгляд, или еще как нибудь. Как я и заставил писать своих — в результате читатели моего тз все понимают и счастливы, и до сих пор не обременены знанием "техники юзкейсов". Так и должно быть.
_>Как мне организовать раздел ТЗ № 4.2 "Требования к функциям системы"? Сваливать туда вперемешку варианты использования, функциональные требования, вытекающие из вариантов использования, и функциональные требования, возникшие сами по себе? _>Либо только варианты использования и самостоятельные функциональные требования, чтобы не дублировать описание одной и той же функциональности и не путать заказчика?
Можно успешно аргументировать за оба варианта. Вообще — когда есть два варианта, как делать, и вы не уверены как лучше — выбирайте простейший. В вашем случае второй.
G>Для пищи к размышлению — даю свою форму документа требований, который после разработки креативно копипастится в ГОСТ-овское ТЗ. G>1. Требования к окружению — в каком окружении ваша штука будет работать. Структурная схема типового окружения, описание вольным текстом — в составе какой системы/комплекса то должно функционировать.
G>2. Требования к внешним интерфейсам (если они есть). Тут не надо ничего выдумывать — либо специальные требования есть, либо их нет. У вас, скажем, требования — TCP/IP.
G>3. Сценарии/способы использования. G>Отвечает на вопрос — как ваша штука будет использоваться. G>Сюда узкейсы вольным текстом — простым и человеческим, в терминах окружения.
G>4. Фукциональные требования G>"Определение" вашей штуки. Что она умеет делать.
G>5. Прочие требования. G>Все, что не влезло в предыдущие секции, но существенно.
И будьте уверены — я поправлю эту свою форму при малейших подозрениях, что она мне мешает или плохо подходит для какой-то задачи. Форма — то не более чем удобная группировка информации, помогающая пониманию сути материала. Если эта группировка станет не помогять, а мешать — сделаю другую.
Функции — это описание возможностей, ответ на вопрос "что", сценарии — описание их конкретных способов их применения, ответы на вопросы "зачем" и "как". Это не одно и то же, даже в том редком случае, когда сценарии и функции соответствуют друг другу один к одному. Пример, наглядно демонстрирующий разницу между ними: фрагмент ТЗ на видеоконтроллер для, скажем, продвинутого DVD плеера.
?) в контексте их использования. Кстати, я все-таки не понял, если у вас сценарии использования = use cases, то кто интересно будет эктором у приведенных ниже вами сценариях? Если такого отождествления нет, тогда вопрос отпадает ...
.
, и приглашаю его к себе в гости! 