Здравствуйте, 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, это не приводит ни к чему, кроме путаницы. Вот, например, вопросы возникают, уж не одно ли это и то же. Нет, не одно.