Форум Сообщества Аналитиков

×


Классификация требований(Прочитано 52352 раз)
Re: Классификация требований Ответ #45 : 20 Мая 2013, 17:57:06
Цитировать
Кроме этого, мне кажется будет несколько диковато смотреться "ТЗ по ГОСТ с юзкейсами" ... хотя, "в природе встречается" - это когда очень хочется писать юзкейсы, а нужно сдавать по ГОСТ 34 :-) ....
Юзкейсы - это всего лишь форма представления информации. Тоже самое можно написать словами, придать нужную окраску (благо велик и могуч русский язык) и вот оно, ТЗ по ГОСТ  :) 



Re: Классификация требований Ответ #46 : 20 Мая 2013, 23:00:16
Юзкейсы - это всего лишь форма представления информации. Тоже самое можно написать словами, придать нужную окраску (благо велик и могуч русский язык) и вот оно, ТЗ по ГОСТ  :) 
Ой, а можно примерчик?



Re: Классификация требований Ответ #47 : 20 Мая 2013, 23:55:11
Более точно - юзкейсы, это одна из форм представления пользовательских требований (взгляда на систему со стороны пользователя и его целей по отношению к ней). Пользовательские требования вполне можно писать в виде "<Пользователь/роль> должен иметь возможность делать ХХХ". У сценарного изложения в формате юзкейсов есть множество своих преимуществ и достоинств, в конкретных случаях. Но тезис заключается в другом - у схемы Вигерса есть явно выраженная точка зрения на систему с т.з. пользователя, и ясно в каком виде и документе она должна быть выражена/отражена, а в ГОСТ 34 ее как таковой - нет, приходится выкручиваться, если есть необходимость или желание такую точку зрения там получить в явном виде.
« Последнее редактирование: 21 Мая 2013, 00:03:40 от Юрий Булуй »
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



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



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

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

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

greesha.ru

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



Re: Классификация требований Ответ #50 : 21 Мая 2013, 15:13:28
Цитировать
А это финальный слайд моего выступления на РИТ++. Смиритесь. :)
Покажите его всей нашей оборонке и государственному сектору и может быть найдутся аргументы, которые поменяют ваше мнение  ;)



Re: Классификация требований Ответ #51 : 21 Мая 2013, 15:58:12
Покажите его всей нашей оборонке и государственному сектору и может быть найдутся аргументы, которые поменяют ваше мнение  ;)

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

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

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



Re: Классификация требований Ответ #52 : 21 Мая 2013, 16:12:10
Цитировать
Оформлением ТЗ по ГОСТу должны заниматься опытные техписы-крючкотворы, которым нужно платить высокую зарплату и отправлять на хорошую пенсию досрочно из-за вредности их работы
Ура!!! у меня будет хорошая пенсия!!! а проездной на метро дадут бесплатно?  ;D

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



Re: Классификация требований Ответ #53 : 21 Мая 2013, 22:48:18
Когда писался ГОСТ 34, в головах его разработчиков основной моделью ещё было взаимодействие с системой через консоль. Поэтому там остались такие понятия как "лингвистическое обеспечение" и "языки ввода-вывода данных", но ещё нет никаких намёков на концепцию пользовательских ролей или пошаговые процедуры взаимодействия. Конечно, ГОСТ писался умными людьми, которые заложили в него некоторые универсальные принципы, но бессмысленно искать в ГОСТе то, чего в нём никогда не было.

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



"ГОСТ умер, да здравствует ГОСТ!" .... Реальность такова, что за разработку документации по ГОСТу еще платят. Раз платят, значит он еще жив :), так что с фатализмом можно еще немного повременить. Кроме этого, никто не мешает отделять такие вещи как собственно модель требований к системе и ее документарное отображение (документация требований).
Другой вопрос что разрабатывать модель требований по одной схеме и отображать ее на документацию по ГОСТ (в котором заложена несколько иная схема), задача достаточно трудоемкая и возникает вопрос, которым отметается 90% инициатив - "а нафига?". Тут вариантов несколько - либо аналитику становиться "универсальным солдатом" - т.е. понимать отличие схем и умело ими пользоваться, чтобы создавать качественную документацию требований по требуемым стандартам, либо брезгливо морщить нос при прочтении тендерной документации, в которой встречается требование оформления документации по ГОСТ 34 и не браться за такую работу. Тут уж каждому - своё.
У меня был один случай, когда мне было интересно писать юзкейсы, но в ТЗ "должен был узнаваться ГОСТ" (дословно требование заказчика :-)))). Я таки писал юзкейсы, а потом из них делал собственно требования по ГОСТу ... работка дурацкая, но юзкейсы мне позволили понять чем именно будет ценна для пользователей система... А на базе модели юзкейсов, я уже слепил список функций системы и тупо писал к ним требования, практически по юзкейсам, упражняясь "в казенности" формулировок :-). Получилось почти по Вигерсу :-))).
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



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

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

ГОСТ ни плох, ни хорош, он просто стандарт, несколько устаревший, но вполне используемый в тех же госах ... Только проблема в том, что я ОЧЕНЬ редко встречал в госах действительно классные ТЗ по ГОСТ 34.602. Думаю что их есть, не все ж ТЗ студенты пишут ... просто мне не попадались. Основной проблемой ГОСТ 34 как раз является отсутствующая модель требований. Разработчики ГОСТ создали по сути процесс создания АС и его документарное обеспечение, но ничего не сказали нам про то, что могут быть разные модели ЖЦ, ни про классификацию требований, которая лежит в его основе ... Но это стандарт на порядок создания и документирования АС, а не фреймворк, типа RUP ... И еще, в ГОСТ жутко не хватает нормального глоссария ...
« Последнее редактирование: 21 Мая 2013, 23:20:43 от Юрий Булуй »
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



Re: Классификация требований Ответ #55 : 21 Мая 2013, 23:14:22
Эдуард, чувствую, раскритикуете вы мой пример  ;D  К тому же подходы к написанию ТЗ (а также стиль изложения и форма представления информации) у всех разные, это все равно что спорить о вкусах.
Ну, Максим, это Вы напрасно. Не такой уж я и критикан, как меня малюют ;) На самом деле, очень интересно посмотреть.

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

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

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



Re: Классификация требований Ответ #56 : 21 Мая 2013, 23:16:09
А это финальный слайд моего выступления на РИТ++. Смиритесь. :)


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



Re: Классификация требований Ответ #57 : 22 Мая 2013, 10:40:41
Твоими устами да мед пить. А у нас студентов режут, если они не по ГОСТ оформили ТЗ и проект

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

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



Re: Классификация требований Ответ #58 : 22 Мая 2013, 10:59:32
Цитировать
Это просто Ваша интерпретация ГОСТ, поэтому Вы конечно же можете быть несогласны с моей интерпретацией, это нормально.
Прошу заметить, все в рамках дозволенного, все по честному, все по правилам  ;D
Цитировать
Можно посмотреть РД 50-34.698-90, где описана структура отчета, который выпускается на данной стадии, там как-то не очень про требования пользователя богато сказано - порождает еще больше вопросов....
Есть в этом отчете раздел Раздел "Функции и задачи создаваемой АС", который содержит.
•   1) обоснование выбора перечня автоматизированных функций и комплексов задач с указанием очередности внедрения,
•   2) требования к характеристикам реализации функций и задач в соответствии с действующими нормативно-техническими документами, определяющими общие технические требования к АС конкретного вида;
•   3) дополнительные требования к АС в целом и ее частям, учитывающие специфику создаваемой АС.
Что вам мешает обосновать этот перечень функций путем использования вариантов использования Системы? ГОСТ не определяет методику формирования требований, он оставляет это на откуп аналитику, а там уже кому как нравится. Хочешь используй это, хочешь это... И это правильно.
Цитировать
Более того, в ГОСТ вообще НИГДЕ не определено, что понимается под "требованиями пользователя", если мне не изменяет память... Я, например, с таким же успехом могу интерпретировать это таким образом, что под требованиями пользователя в ГОСТ понимается тот набор features, которые должны быть в создаваемой системе. А строго говоря features - это не пользовательские требования по Вигерсу ... Тут полет фантазии у нас ничем не ограничен :-).
Давайте все-таки придерживаться здравого смысла  :) Требования пользователя - это требования пользователя (согласитесь, с этим трудно поспорить  ;D ). Но где вы видели пользователя, который вам сразу выдает features ?
Цитировать
Только проблема в том, что я ОЧЕНЬ редко встречал в госах действительно классные ТЗ по ГОСТ 34.602
ИМХО это проблема тех.писателей, а не ГОСТа
Цитировать
Основной проблемой ГОСТ 34 как раз является отсутствующая модель требований. Разработчики ГОСТ создали по сути процесс создания АС и его документарное обеспечение, но ничего не сказали нам про то, что могут быть разные модели ЖЦ, ни про классификацию требований, которая лежит в его основе ...
Моя точка зрения - это не проблема ГОСТа, это просто не его поле боя. Вы хотите получить от него то, для чего он просто не предназначен. 34-я серия определяет в основном перечень работ на различных стадиях и этапах разработки и перечень разрабатываемых документов. При этом, ГОСТ не запрещает вам определять свой перечень работ и документов, пожалуйста, согласовываете с заказчиком, прописываете в ТЗ и вперед. Во всем остальном вам дали свободу  :)



Re: Классификация требований Ответ #59 : 22 Мая 2013, 11:16:16
Цитировать
Ну, Максим, это Вы напрасно. Не такой уж я и критикан, как меня малюют ;) На самом деле, очень интересно посмотреть.
Давайте может тему создадим в примерах? я бы с удовольствие поупражнялся, но хочу предупредить заранее, что я далеко не аксакал   :)
Цитировать
у нас студенты, а их кто-то учит (не я правда) делают ВИ в ходе техно-рабочего проекта.
типичная ситуация для проекта, в котором 1-я стадия - это ТЗ, никакого обследования, никакого вникания в предметную область... Написали общих фраз и начали проектировать  :) Конечно, ничего другого не остается, как разрабатывать ВИ в ходе технического проекта.
Цитировать
Вопрос, а зачем так делать? Имхо получается какая-то лишняя работа
могу поделиться своими догадками... Требования пользователей, как ни крути, достаточно высокоуровневые, по ним Систему не сделаешь, да и непонятно как сдавать. Что в ПМИ писать? как проверять? А вот функциональные требования - легко. В этом случае ГОСТ совершенно прав, предлагая нам сначала провести обследование, выявить пользовательские требования, а потом уже разработать функциональные требования и включить их в ТЗ. В качестве подтверждения могу процитировать Юрия: "Я таки писал юзкейсы, а потом из них делал собственно требования по ГОСТу ... работка дурацкая, но юзкейсы мне позволили понять чем именно будет ценна для пользователей система... А на базе модели юзкейсов, я уже слепил список функций системы и тупо писал к ним требования, практически по юзкейсам, упражняясь "в казенности" формулировок :-). Получилось почти по Вигерсу :-)))" (с)
« Последнее редактирование: 22 Мая 2013, 11:18:49 от Briezzz »




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19