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>Я вижу прямую выгоду от присутствия сценариев в ТЗ, и не вижу ровным счетом ничего существенного, что мне мешает их в ТЗ включить. Раз уж на то пошло, то я могу кому угодно доказать, что юзкейс является требованием к функциям, если это потребуется для того, чтобы включить их в ТЗ . Вопрос в любом случае мутный и казуистический, так что мне все равно, что на него отвечать, лишь бы было как мне удобно. Зачем мне в ТЗ нужны сценарии — я объяснил.
В вопросе все достаточно ясно ... и в ответе тоже. У вас не юзкейсы, а сценарии.
Функции — это описание возможностей, ответ на вопрос "что", сценарии — описание их конкретных способов их применения, ответы на вопросы "зачем" и "как". Это не одно и то же, даже в том редком случае, когда сценарии и функции соответствуют друг другу один к одному. Пример, наглядно демонстрирующий разницу между ними: фрагмент ТЗ на видеоконтроллер для, скажем, продвинутого DVD плеера.
?) в контексте их использования. Кстати, я все-таки не понял, если у вас сценарии использования = use cases, то кто интересно будет эктором у приведенных ниже вами сценариях? Если такого отождествления нет, тогда вопрос отпадает ...
.