Кроме этого, мне кажется будет несколько диковато смотреться "ТЗ по ГОСТ с юзкейсами" ... хотя, "в природе встречается" - это когда очень хочется писать юзкейсы, а нужно сдавать по ГОСТ 34 :-) ....

Юзкейсы - это всего лишь форма представления информации. Тоже самое можно написать словами, придать нужную окраску (благо велик и могуч русский язык) и вот оно, ТЗ по ГОСТ   

Юзкейсы - это всего лишь форма представления информации. Тоже самое можно написать словами, придать нужную окраску (благо велик и могуч русский язык) и вот оно, ТЗ по ГОСТ   

Ой, а можно примерчик?

Более точно - юзкейсы, это одна из форм представления пользовательских требований (взгляда на систему со стороны пользователя и его целей по отношению к ней). Пользовательские требования вполне можно писать в виде "<Пользователь/роль> должен иметь возможность делать ХХХ". У сценарного изложения в формате юзкейсов есть множество своих преимуществ и достоинств, в конкретных случаях. Но тезис заключается в другом - у схемы Вигерса есть явно выраженная точка зрения на систему с т.з. пользователя, и ясно в каком виде и документе она должна быть выражена/отражена, а в ГОСТ 34 ее как таковой - нет, приходится выкручиваться, если есть необходимость или желание такую точку зрения там получить в явном виде.

Ой, а можно примерчик?

Эдуард, чувствую, раскритикуете вы мой пример    К тому же подходы к написанию ТЗ (а также стиль изложения и форма представления информации) у всех разные, это все равно что спорить о вкусах.

а в ГОСТ 34 ее как таковой - нет

Юрий, не совсем с вами согласен. Если брать весь комплекс стандартов 34-й серии, то разработка ТЗ - это третья стадия создания Системы. При этом "ТЗ на АС разрабатывают на основании исходных данных в том числе содержащихся в итоговой документации стадии «Исследование и обоснование создания АС»" (п. 1.5 ГОСТ 34.602). В свою очередь на первой стадии есть этап 1.2. "Формирование требований пользователя к АС", на котором осуществляется "формулировка и оформление требований пользователя к АС" (ГОСТ 34.601). Это ли не описание юзкейсов? Таким образом я это вижу так: 1. На стадии обследования осуществляется разработка диаграммы вариантов использования, проводится описание ВИ и т.д., вобщем описывается (в том числе, но не только) та самая точка зрения пользователя на Систему, о которой вы говорили. Отражается это в отчете о выполненной работе по обследованию объекта автоматизации. 2. На стадии разработки ТЗ эти юзкейсы используются как входные данные, которые трансформируются в те требования к Системе, которые все привыкли видеть в ТЗ. Как-то так (ИМХО).   

Более точно - юзкейсы, это одна из форм представления пользовательских требований (взгляда на систему со стороны пользователя и его целей по отношению к ней). Пользовательские требования вполне можно писать в виде "<Пользователь/роль> должен иметь возможность делать ХХХ". У сценарного изложения в формате юзкейсов есть множество своих преимуществ и достоинств, в конкретных случаях. Но тезис заключается в другом - у схемы Вигерса есть явно выраженная точка зрения на систему с т.з. пользователя, и ясно в каком виде и документе она должна быть выражена/отражена, а в ГОСТ 34 ее как таковой - нет, приходится выкручиваться, если есть необходимость или желание такую точку зрения там получить в явном виде.

Когда писался ГОСТ 34, в головах его разработчиков основной моделью ещё было взаимодействие с системой через консоль. Поэтому там остались такие понятия как "лингвистическое обеспечение" и "языки ввода-вывода данных", но ещё нет никаких намёков на концепцию пользовательских ролей или пошаговые процедуры взаимодействия. Конечно, ГОСТ писался умными людьми, которые заложили в него некоторые универсальные принципы, но бессмысленно искать в ГОСТе то, чего в нём никогда не было.

А это финальный слайд моего выступления на РИТ++. Смиритесь.

А это финальный слайд моего выступления на РИТ++. Смиритесь.

Покажите его всей нашей оборонке и государственному сектору и может быть найдутся аргументы, которые поменяют ваше мнение 

Покажите его всей нашей оборонке и государственному сектору и может быть найдутся аргументы, которые поменяют ваше мнение 

Да я знаю, что в госсекторе без стандартов никак. Но imho это не повод подгонять работу аналитика под устаревшие стандарты. Оформлением ТЗ по ГОСТу должны заниматься опытные техписы-крючкотворы, которым нужно платить высокую зарплату и отправлять на хорошую пенсию досрочно из-за вредности их работы.

Ну, понятно, что это в идеальном мире. Хотя я уверен, что есть компании, которые с удовольствием возьмут этот нелёгкий труд на себя - тот же Философт, например.

Оформлением ТЗ по ГОСТу должны заниматься опытные техписы-крючкотворы, которым нужно платить высокую зарплату и отправлять на хорошую пенсию досрочно из-за вредности их работы

Ура!!! у меня будет хорошая пенсия!!! а проездной на метро дадут бесплатно? 

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

Когда писался ГОСТ 34, в головах его разработчиков основной моделью ещё было взаимодействие с системой через консоль. Поэтому там остались такие понятия как "лингвистическое обеспечение" и "языки ввода-вывода данных", но ещё нет никаких намёков на концепцию пользовательских ролей или пошаговые процедуры взаимодействия. Конечно, ГОСТ писался умными людьми, которые заложили в него некоторые универсальные принципы, но бессмысленно искать в ГОСТе то, чего в нём никогда не было.

А это финальный слайд моего выступления на РИТ++. Смиритесь.

"ГОСТ умер, да здравствует ГОСТ!" .... Реальность такова, что за разработку документации по ГОСТу еще платят. Раз платят, значит он еще жив , так что с фатализмом можно еще немного повременить. Кроме этого, никто не мешает отделять такие вещи как собственно модель требований к системе и ее документарное отображение (документация требований).
Другой вопрос что разрабатывать модель требований по одной схеме и отображать ее на документацию по ГОСТ (в котором заложена несколько иная схема), задача достаточно трудоемкая и возникает вопрос, которым отметается 90% инициатив - "а нафига?". Тут вариантов несколько - либо аналитику становиться "универсальным солдатом" - т.е. понимать отличие схем и умело ими пользоваться, чтобы создавать качественную документацию требований по требуемым стандартам, либо брезгливо морщить нос при прочтении тендерной документации, в которой встречается требование оформления документации по ГОСТ 34 и не браться за такую работу. Тут уж каждому - своё.
У меня был один случай, когда мне было интересно писать юзкейсы, но в ТЗ "должен был узнаваться ГОСТ" (дословно требование заказчика :-)))). Я таки писал юзкейсы, а потом из них делал собственно требования по ГОСТу ... работка дурацкая, но юзкейсы мне позволили понять чем именно будет ценна для пользователей система... А на базе модели юзкейсов, я уже слепил список функций системы и тупо писал к ним требования, практически по юзкейсам, упражняясь "в казенности" формулировок :-). Получилось почти по Вигерсу :-))).

Юрий, не совсем с вами согласен. Если брать весь комплекс стандартов 34-й серии, то разработка ТЗ - это третья стадия создания Системы. При этом "ТЗ на АС разрабатывают на основании исходных данных в том числе содержащихся в итоговой документации стадии «Исследование и обоснование создания АС»" (п. 1.5 ГОСТ 34.602). В свою очередь на первой стадии есть этап 1.2. "Формирование требований пользователя к АС", на котором осуществляется "формулировка и оформление требований пользователя к АС" (ГОСТ 34.601). Это ли не описание юзкейсов? Таким образом я это вижу так: 1. На стадии обследования осуществляется разработка диаграммы вариантов использования, проводится описание ВИ и т.д., вобщем описывается (в том числе, но не только) та самая точка зрения пользователя на Систему, о которой вы говорили. Отражается это в отчете о выполненной работе по обследованию объекта автоматизации. 2. На стадии разработки ТЗ эти юзкейсы используются как входные данные, которые трансформируются в те требования к Системе, которые все привыкли видеть в ТЗ. Как-то так (ИМХО).   

Это просто Ваша интерпретация ГОСТ, поэтому Вы конечно же можете быть несогласны с моей интерпретацией, это нормально. Можно посмотреть РД 50-34.698-90, где описана структура отчета, который выпускается на данной стадии, там как-то не очень про требования пользователя богато сказано - порождает еще больше вопросов.... Более того, в ГОСТ вообще НИГДЕ не определено, что понимается под "требованиями пользователя", если мне не изменяет память... Я, например, с таким же успехом могу интерпретировать это таким образом, что под требованиями пользователя в ГОСТ понимается тот набор features, которые должны быть в создаваемой системе. А строго говоря features - это не пользовательские требования по Вигерсу ... Тут полет фантазии у нас ничем не ограничен :-).

ГОСТ ни плох, ни хорош, он просто стандарт, несколько устаревший, но вполне используемый в тех же госах ... Только проблема в том, что я ОЧЕНЬ редко встречал в госах действительно классные ТЗ по ГОСТ 34.602. Думаю что их есть, не все ж ТЗ студенты пишут ... просто мне не попадались. Основной проблемой ГОСТ 34 как раз является отсутствующая модель требований. Разработчики ГОСТ создали по сути процесс создания АС и его документарное обеспечение, но ничего не сказали нам про то, что могут быть разные модели ЖЦ, ни про классификацию требований, которая лежит в его основе ... Но это стандарт на порядок создания и документирования АС, а не фреймворк, типа RUP ... И еще, в ГОСТ жутко не хватает нормального глоссария ...

Эдуард, чувствую, раскритикуете вы мой пример    К тому же подходы к написанию ТЗ (а также стиль изложения и форма представления информации) у всех разные, это все равно что спорить о вкусах.

Ну, Максим, это Вы напрасно. Не такой уж я и критикан, как меня малюют На самом деле, очень интересно посмотреть.

"Формирование требований пользователя к АС", на котором осуществляется "формулировка и оформление требований пользователя к АС" (ГОСТ 34.601). Это ли не описание юзкейсов?

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

Таким образом я это вижу так: 1. На стадии обследования осуществляется разработка диаграммы вариантов использования, проводится описание ВИ и т.д., вобщем описывается (в том числе, но не только) та самая точка зрения пользователя на Систему, о которой вы говорили. Отражается это в отчете о выполненной работе по обследованию объекта автоматизации.

Звучит разумно

2. На стадии разработки ТЗ эти юзкейсы используются как входные данные, которые трансформируются в те требования к Системе, которые все привыкли видеть в ТЗ. Как-то так (ИМХО).   

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

А это финальный слайд моего выступления на РИТ++. Смиритесь.

Твоими устами да мед пить. А у нас студентов режут, если они не по ГОСТ оформили ТЗ и проект

Твоими устами да мед пить. А у нас студентов режут, если они не по ГОСТ оформили ТЗ и проект

А к чему вы их там готовите?

Это просто Ваша интерпретация ГОСТ, поэтому Вы конечно же можете быть несогласны с моей интерпретацией, это нормально.

Прошу заметить, все в рамках дозволенного, все по честному, все по правилам 

Можно посмотреть РД 50-34.698-90, где описана структура отчета, который выпускается на данной стадии, там как-то не очень про требования пользователя богато сказано - порождает еще больше вопросов....

Есть в этом отчете раздел Раздел "Функции и задачи создаваемой АС", который содержит.
•   1) обоснование выбора перечня автоматизированных функций и комплексов задач с указанием очередности внедрения,
•   2) требования к характеристикам реализации функций и задач в соответствии с действующими нормативно-техническими документами, определяющими общие технические требования к АС конкретного вида;
•   3) дополнительные требования к АС в целом и ее частям, учитывающие специфику создаваемой АС.
Что вам мешает обосновать этот перечень функций путем использования вариантов использования Системы? ГОСТ не определяет методику формирования требований, он оставляет это на откуп аналитику, а там уже кому как нравится. Хочешь используй это, хочешь это... И это правильно.

Более того, в ГОСТ вообще НИГДЕ не определено, что понимается под "требованиями пользователя", если мне не изменяет память... Я, например, с таким же успехом могу интерпретировать это таким образом, что под требованиями пользователя в ГОСТ понимается тот набор features, которые должны быть в создаваемой системе. А строго говоря features - это не пользовательские требования по Вигерсу ... Тут полет фантазии у нас ничем не ограничен :-).

Давайте все-таки придерживаться здравого смысла  Требования пользователя - это требования пользователя (согласитесь, с этим трудно поспорить  ). Но где вы видели пользователя, который вам сразу выдает features ?

Только проблема в том, что я ОЧЕНЬ редко встречал в госах действительно классные ТЗ по ГОСТ 34.602

ИМХО это проблема тех.писателей, а не ГОСТа

Основной проблемой ГОСТ 34 как раз является отсутствующая модель требований. Разработчики ГОСТ создали по сути процесс создания АС и его документарное обеспечение, но ничего не сказали нам про то, что могут быть разные модели ЖЦ, ни про классификацию требований, которая лежит в его основе ...

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

Ну, Максим, это Вы напрасно. Не такой уж я и критикан, как меня малюют На самом деле, очень интересно посмотреть.

Давайте может тему создадим в примерах? я бы с удовольствие поупражнялся, но хочу предупредить заранее, что я далеко не аксакал   

у нас студенты, а их кто-то учит (не я правда) делают ВИ в ходе техно-рабочего проекта.

типичная ситуация для проекта, в котором 1-я стадия - это ТЗ, никакого обследования, никакого вникания в предметную область... Написали общих фраз и начали проектировать  Конечно, ничего другого не остается, как разрабатывать ВИ в ходе технического проекта.

Вопрос, а зачем так делать? Имхо получается какая-то лишняя работа

могу поделиться своими догадками... Требования пользователей, как ни крути, достаточно высокоуровневые, по ним Систему не сделаешь, да и непонятно как сдавать. Что в ПМИ писать? как проверять? А вот функциональные требования - легко. В этом случае ГОСТ совершенно прав, предлагая нам сначала провести обследование, выявить пользовательские требования, а потом уже разработать функциональные требования и включить их в ТЗ. В качестве подтверждения могу процитировать Юрия: "Я таки писал юзкейсы, а потом из них делал собственно требования по ГОСТу ... работка дурацкая, но юзкейсы мне позволили понять чем именно будет ценна для пользователей система... А на базе модели юзкейсов, я уже слепил список функций системы и тупо писал к ним требования, практически по юзкейсам, упражняясь "в казенности" формулировок :-). Получилось почти по Вигерсу :-)))" (с)