Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Тема начата: bas от 01 Января 2013, 21:13:51
-
Вигерс К. "Классическая" дурацкая классификация требований
Интересно было бы в другой теме пообщаться - почему-то дурацкая и кто предложил лучше...
-
сообщение устарело
-
Странный вопрос, тем более от человека, кот занимается УТ...
Без классификации и этого понимания и получается, что в ТЗ в один поток идут и БП и пользовательские тр и системные. А про НФТ вообще забывают. Получается каша и белеберда ...
-
сообщение устарело
-
Я не борец за термины, можно называть как угодно - классификация, типы/виды тр и т.д. Но она нужна, пока лучше никто ничего не предлагал.
Будете в Питере - заходите на чай, если интересно пообщаться. Будем рады Вас видеть.
Спасибо за приглашение, как только, так сразу :)
-
сообщение устарело
-
Я готова обсуждать эти вопросы лично, но не на форуме, по многим причинам, первая которых - ограниченные возможности среды для организации конструктивного продолжительного диалога.
Будете в Питере - заходите на чай, если интересно пообщаться. Будем рады Вас видеть.
А на Analyst Days не планируете быть?
http://it-conf.ru/ru/content/597.htm
-
сообщение устарело
-
Для одного из слоев классификации я использую международный классификатор ИСО/МЭК 9126 (Есть соответствующий ГОСТ).
Уровень декомпозиции. Мне удобно оперировать уровнем, который требует для реализации менее двух дней.
-
Вот решил предложить свою классификацию:
Классификация требований. Часть 1. В общем о главном. (http://blogs.uml2.ru/node/273)
-
Ну надо ж... :) Как раз любуюсь на картинку Вигерса, и думаю, можно ли так быстренько объяснить людям, которые не в теме, эти дважды функциональные требования - а тут Ваша статья все ставит на места. ЗдОрово, в общем.
Разницу в масштабе ФТ и НФТ, мне кажется, просто проиллюстрировать - не медиану рисовать, а увести разделяющую линию вправо, будет понятно.
А вот слово 'Системные' для нижнего уровня мне не очень нравится. Во-первых, слишком уж оно общеупотребительно и вызывает разные ассоциации для разных аудиторий. (Системные требования? Это которые объем ОЗУ и мощность процессора?)
Во-вторых, мне кажется, оно не точно отражает суть этого уровня. По моим представлениям, в идеальном мире эти самые требования нижнего уровня (Functional Requirements) должны непосредственно отображаться на функции и классы программного кода связью один-ко-многим, в смысле, одно_требование - много_мест_в_коде. Если это так, то данная концепция и должна быть выражена в их названии. Вот только слово удачное трудно подобрать. Ага, по-английски можно предложить Development Requirements, Programming Requirements. На русском точный ёмкий термин так сразу в голову не пришёл, подумать надо. "Требования для разработки"?
-
Золотая рыбка,
Спасибо на добром слове :)
1. Разделить ФТ и НФТ также думал увести низ разделяющей линии вправо, но как-то некрасиво получалось :) Видимо других вариантов нет, так и сделаю.
2. Название "Системные требования" мне тоже сначала не очень нравилось. Но под Системой я понимаю "Систему, состоящую из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций." (ГОСТ 34.003-90 Автоматизированные системы. Термины и определения (http://www.it-gost.ru/content/view/22/40/)). Т.е. это не только разрабатываемое ПО, но и окружение, которые работает, как единое целое для достижения определенных ранее целей.
В связи с этим на этом уровне м.б. и требования к персоналу, орг процессу и т.д., кот. включается в ТЗ. Поэтому лучшего названия я не нашел.
Попозже я детальнее напишу, что я понимаю под СТ.
-
Вопрос "Кто предложил классификацию", конечно, странный. Вы совершенно правильно это увидели.
В необходимости классификаций нет сомнений. В том, что обсуждаемый текст не является классификацией - тоже. Поэтому любая предложенная классификация будет лучше этой, если будет действительно классификацией. Вопрос "какая из классификаций лучше, если все являются классификациями" также бесмысленнен, т.к. это зависит от задачи.
Я готова обсуждать эти вопросы лично, но не на форуме, по многим причинам, первая которых - ограниченные возможности среды для организации конструктивного продолжительного диалога.
Будете в Питере - заходите на чай, если интересно пообщаться. Будем рады Вас видеть.
Какой грубый пиар-ход )
Можно же мягче - приходите, Саша, в гости, на коньячку-с кружечку, к черту всякие там классификации - лишь бы люди были хорошие! :D
-
к черту всякие там классификации - лишь бы люди были хорошие! :D
категорически согласен, даже увековечил ;D
-
сообщение устарело
-
Вот решил предложить свою классификацию:
Классификация требований. Часть 1. В общем о главном. (http://blogs.uml2.ru/node/273)
Саша, было бы здорово, чтобы ты указал автора «недавних попыток классификации».
Причём ты почему-то указываешь фамилию того, кто собрал и процитировал чужие классификации, а того, кто предложил, условно, новую — нет :)
И я напомню на всякий случай про заметку 7-летней давности: http://beskov.livejournal.com/14493.html
-
Денис,
Сорри, исправил, указал тебя как автора новой идеи по классификации.
Ссылку на заметку 7ми летней давности не стал включать, дабы не путать еще больше людей, но ее учту также. Спасибо.
-
Странно что Юра Булуй не пишет в этой теме, он уделял этому вопросу много времени.
вот например одна из презентаций http://ocnova.ru/wp-content/uploads/Library/Yury_Buluy_(ReqClassification).zip
я как бы лично сам ни за что не агитирую, просто для информации.
-
Илья,
Я как раз эту презу Юрия и указал в своей статье :)
-
Коллеги, доброго вам времени суток.
Классификация, как мне кажется, очень увлекательное занятие. Главное, что пытаясь что-то классифицировать - ощущаешь себя причастным к чему-то великому и значимому ;-) (каюсь, сам делал несколько подходов к этому делу). Но с другой стороны, всякое знание (ну или почти всякое) начинается с упорядочивания и классификации. Именно по этому я предпочел изучить доступные мне на тот момент материалы тем или иным образом относящиеся к классификации требований, попытаться их сопоставить м/у собой и понять, что Вигерс дал вполне себе нормальную схему именно требований, относящихся к программной инженерии. Конечно можно спорить с ней, обоснованно утверждать, что не всегда имеет смысл использовать все три уровня требовании в отдельно взятом проекте и заниматься строгим контролем и трассировкой м/у уровнями (хотя это делает модель требований конкретного проекта более структурированной) ... Можно так же его критиковать за то, что у него два раза встречается название "функциональные" требования, что может вносить путаницу для неподготовленного читателя. Но в любом случае она вполне себе выполняет свою задачу, особенно если мы говорим про заказную разработку... А если чем-то можно пользоваться, и оно позволяет решать имеющиеся задачи, то зачем тратить время на изобретение? Можно конечно наплодить кучу типов требований, добавить еще шкалу времени "в туда" (с) (привязав требования, например, к ЖЦ разработки). Но ничего принципиально нового это не даст. Разве только позволит детализировать и уточнить предложенную Вигерсом схему (я упорно не называю его схему классификацией, т.к. сам Вигерс, если мне не изменяет память, сам называет ее не классификацией, а "моделью", которую он использует в своей практике), ну и конечно же позволит "размять мозги" и получить творческий азарт, куда без этого :-). Но в то же время, никто не мешает, по аналогии с Вигерсом - сделать ту схему требований, которая используется в практике конкретного специалиста. Если это помогает - вперед!
Кстати, в этой презе моей, есть очень тонкое место, которое возможно не заметно на первый взгляд, хотя я думаю многие из вас об этом подумали ... А именно сравнение ТЗ по ГОСТ 34.602 которое суть ТЗ на АС (а мы помним, что есть АС) с требованиями на собственно программное обеспечение :-). Когда рисовал эту презу, меня просто терзали сомнения, стоит ли сравнивать ... но в конечном итоге подумал, кто этим заморачивается? У нас все что делают, считают АС ... и не парятся с тонкостями.
-
У нас все что делают, считают АС ... и не парятся с тонкостями.
Юра, тонкость появляется, когда ты хочешь описать требования к разработке, например, программного каркаса(фреймверка)
-
сравнение ТЗ по ГОСТ 34.602
Да. Я еще подумала, что может быть было бы более правильно сравнивать с ГОСТ 19...
Юрий, пользуясь случаем, хотела бы уточнить - Вы в презентации сопоставляете Functional Requirements пункту ТЗ 2.6.2 (Требования к функциям (задачам)). Мне казалось, что этот пункт по уровню детализации ближе к User Requirements. Или я ошибаюсь?
-
Юра, тонкость появляется, когда ты хочешь описать требования к разработке, например, программного каркаса(фреймверка)
Эд, фреймворк - это не заказная разработка, это скорее продуктовая разработка. Весь вопрос в том, что используется для описания требований к нему и с какой степенью детализации эти требования нужно представить.
-
Да. Я еще подумала, что может быть было бы более правильно сравнивать с ГОСТ 19...
Юрий, пользуясь случаем, хотела бы уточнить - Вы в презентации сопоставляете Functional Requirements пункту ТЗ 2.6.2 (Требования к функциям (задачам)). Мне казалось, что этот пункт по уровню детализации ближе к User Requirements. Или я ошибаюсь?
Если посмотреть что понимается под функцией системы, и посмотреть на практику написания ТЗ - очень редко требования к функциям и задачам описываются в терминах пользователей ("пользователь должен иметь возможность ...."), чаще встречается "система должна иметь возможность". А это означает взгляд именно со стороны системы на внешний мир, а не со стороны пользователя на систему, что соответствует понятию функциональных требований, а не пользовательских. Т,е. тут важно какую точку зрения (в терминах архитектурного проектирования) выбирают для описания этого вида требований.
-
Если посмотреть что понимается под функцией системы, и посмотреть на практику написания ТЗ - очень редко требования к функциям и задачам описываются в терминах пользователей ("пользователь должен иметь возможность ...."), чаще встречается "система должна иметь возможность". А это означает взгляд именно со стороны системы на внешний мир, а не со стороны пользователя на систему, что соответствует понятию функциональных требований, а не пользовательских. Т,е. тут важно какую точку зрения (в терминах архитектурного проектирования) выбирают для описания этого вида требований.
Юр, смею заметить что не только точка зрения с которой формулируются требования влияет на словесную конструкцию. Допустим мы берем точку зрения пользователя. Мы можем таскать его везде за собой "система должна позволять пользователю выполнять..." или мы убрали пользователя "система должна позволять выполнять..." (держим пользователя "в уме"), или "пользователь должен иметь возможность..." или мы таскаем за собой роли и пишем "система должна позволять Продавцу выполнять..." или "Продавец должен иметь возможность выполнить..."
Точка зрения одна, конструкции отличаются - обстоятельства, культура и т.п. все знают что мы описываем поведение с точки зрения пользователя. При этом очень тяжело убрать контекст системы, ибо если она уже есть стоит очень больших усилий заставить мыслить всех вне ее рамок. А формулируем ли мы требования в каком-то одном из вышеприведенных стилей (так привыкли, или положено у нас так писать), или микс... если культура изложения слабовата.
а кто считал статистику? - что чаще а что реже, этого невооруженным взглядом увы невидно.
-
Эд, фреймворк - это не заказная разработка, это скорее продуктовая разработка. Весь вопрос в том, что используется для описания требований к нему и с какой степенью детализации эти требования нужно представить.
Правильно ли я понимаю, что ТЗ имеет смысл формировать только для заказной продукции. А фреймвёрк таковым не будет? Хотя в моем случае как раз каркас и заказывался.
-
Юр, смею заметить что не только точка зрения с которой формулируются требования влияет на словесную конструкцию. Допустим мы берем точку зрения пользователя. Мы можем таскать его везде за собой "система должна позволять пользователю выполнять..." или мы убрали пользователя "система должна позволять выполнять..." (держим пользователя "в уме"), или "пользователь должен иметь возможность..." или мы таскаем за собой роли и пишем "система должна позволять Продавцу выполнять..." или "Продавец должен иметь возможность выполнить..."
Точка зрения одна, конструкции отличаются - обстоятельства, культура и т.п. все знают что мы описываем поведение с точки зрения пользователя. При этом очень тяжело убрать контекст системы, ибо если она уже есть стоит очень больших усилий заставить мыслить всех вне ее рамок. А формулируем ли мы требования в каком-то одном из вышеприведенных стилей (так привыкли, или положено у нас так писать), или микс... если культура изложения слабовата.
а кто считал статистику? - что чаще а что реже, этого невооруженным взглядом увы невидно.
Илья, очень правильный и потенциально ожидаемый вопрос, рад что он был именно от тебя! Если таки поставить во главу угла (по аналогии с архитектурным проектированием) именно точку зрения, и плясать от нее явно, иными словами, не усложнять ее разными конструкциями, а взять за правило явно эту точку зрения отражать в конкретном типе требований посредством конкретных конструкций (аналитики, в конце концов, и должны уменьшать энтропию :-)), то выстроится вполне себе стройная система требований. Иначе будем получать мешанину ... уж если отражаем пользовательские требования - то пишем либо юзкейсы, либо "<Роль/Пользователь> должен иметь возможность ..." и далее в терминах пользователя смотрим на систему. В этом случае очень легко вводить роли и описывать требования в терминах возможностей делать что-то важное для пользователей. Иначе, если говорим про функциональные требования (в терминах Вигерса), то введение ролей нам никак не мешает ... мы можем СГРУППИРОВАТЬ требования, написанные с т.з. системы, по системным ролям (конечно, если к этому моменту они явно определены). При этом, выбор в каком виде нам писать требования - как раз зависит от ТИПА разрабатываемой системы (автоматизация бизнес-деятельности, фреймворк или иная продуктовая разработка). Культура организации - конечно фактор, но это software, а не hardware ... и она может быть изменена, если новая культура более "прогрессивна" что ли ... (в т.ч. с экономической т.з)
Другой вопрос - уже готовая система и наследие не вполне структурированных требований (зачастую в разных документах) ... тут вопрос сложнее для аналитика - либо постепенно уменьшать энтропию (почти подвиг :-)), либо плюнуть на все и делать как делали ранее ... но это отдельная тема IMHО, можно конечно порассуждать ...
По поводу статистики - я конечно же основываюсь на том, с чем мне приходилось работать (не обязательно что я делал "с нуля" ...) или с тем, что я видел в открытых источниках. Допускаю, что у других коллег, может быть "своя статистика" ... свести бы "эти статистики" - вполне себе исследовательская задачка и даже тема для диплома (анализ качества описания требований )... :-)
-
У нас еще был любопытный случай - гибкая подсистема настройки прав доступа в системе. и мы таки "таскали" слово "пользователь", а роли и права на операции были в документе который назывался "Deployment Plan". ну это я так, просто для примера.
-
У нас еще был любопытный случай - гибкая подсистема настройки прав доступа в системе. и мы таки "таскали" слово "пользователь", а роли и права на операции были в документе который назывался "Deployment Plan". ну это я так, просто для примера.
В данном случае у вас нет ролей как таковых (за исключением наверное Админа системы) до момента деплоймента этой системы. Так что вполне нормально использовать универсальную роль "Пользователь" или еще как-нибудь ее назвать. Только единственно, я бы определил в Глоссарии что мы понимаем под этой ролью.
-
Админ тоже роль, такая же как и все остальные. Одного админа создали через базу, чтобы дальше супорт мог пользоваться UI для раздачи остальных прав, так что с точки зрения требований, Админ такой же Пользователь.
-
В любом случае, на момент разработки требований, было известно, что такая роль точно должна существовать, и ее создают специальным (отличным от других ролей) способом. И, известно, что посредством именно этой роли будут раздаваться права на функциональность других ролей. Так что тут противоречий нет :-).
-
1. Разделить ФТ и НФТ также думал увести низ разделяющей линии вправо, но как-то некрасиво получалось :) Видимо других вариантов нет, так и сделаю.
сдается мне это тоже не решит проблему. У Вигерса бизнес-требования не зря были чисто функциональными, никто ведь не разрабатывает ИС для того, чтобы в ней была система хранения на 1 ПБ (к примеру)! Мне кажется бизнес-требования носят чисто функциональный характер.
-
сдается мне это тоже не решит проблему. У Вигерса бизнес-требования не зря были чисто функциональными, никто ведь не разрабатывает ИС для того, чтобы в ней была система хранения на 1 ПБ (к примеру)! Мне кажется бизнес-требования носят чисто функциональный характер.
Не согласен. НФТ на уровне БТр м.б. и законодательные акты и требования на уровне организации, что они рассматривают только такие платформы. Бизнес НФТ - это ограничения на уровне Бизнеса.
-
НФТ на уровне БТр м.б. и законодательные акты и требования на уровне организации, что они рассматривают только такие платформы.
То, о чем вы говорите, у Вигерса называется бизнес-правилами и лежит уровнем ниже, что вполне логично на мой взгляд, так как они не влияют на цели создания Системы, определяемые на уровне бизнеса. Зачем смешивать разные уровни требований?
-
Я чо-та много пропустила в ходе беседы, но кто-нибудь из классификаторов вообще заморачивается таким понятием, как признак, по которому классифицируются требования? В зависимости от этого можно наплодить столько классификаций, сколько надо.
Пример, предложенный Вигерсом, в общем случае тянет на классификацию по типу источника требований (бизнес, пользователи, система).
Никто не запрещает разным видам классификаций существовать и использоваться теми и тогда, кому и когда они удобны/уместны.
Обычный же подход к структурированию информации.
-
То, о чем вы говорите, у Вигерса называется бизнес-правилами и лежит уровнем ниже, что вполне логично на мой взгляд, так как они не влияют на цели создания Системы, определяемые на уровне бизнеса. Зачем смешивать разные уровни требований?
Цель должна быть SMART, т.е. в т.ч. и достижимая, а на это как раз и влияют бизнес ограничения.
БПр - это уже конкретное условие. На уровне бизнеса это м.б. ограниченно просто соответствием какому-то закону.
-
Я чо-та много пропустила в ходе беседы, но кто-нибудь из классификаторов вообще заморачивается таким понятием, как признак, по которому классифицируются требования? В зависимости от этого можно наплодить столько классификаций, сколько надо.
Пример, предложенный Вигерсом, в общем случае тянет на классификацию по типу источника требований (бизнес, пользователи, система).
Никто не запрещает разным видам классификаций существовать и использоваться теми и тогда, кому и когда они удобны/уместны.
Обычный же подход к структурированию информации.
Вигерс вроде как не претендовал на классификацию требований, он говорил о некоторой схеме, которую он для себя выделил и использовал ... Так что это строго говоря не классификация. Если использовался только один признак - источник требований, как в этом случае должно выглядеть множество значений данного признака (множество источников требований)?
-
У Вигерса удобно то, что все группы требований ложатся в какой-то один раздел ТЗ (если по ГОСТ 34.602). Также они упорядочены по времени сбора данных требований. А предложенную схему/классификацию/модель лично я применить на практике затрудняюсь.
-
У Вигерса удобно то, что все группы требований ложатся в какой-то один раздел ТЗ (если по ГОСТ 34.602). Также они упорядочены по времени сбора данных требований. А предложенную схему/классификацию/модель лично я применить на практике затрудняюсь.
Хотелось бы подробнее узнать, о том, какие именно группы требований в какие именно разделы ТЗ по ГОСТ 34 ложатся, можете привести схему маппинга?
А в чем именно состоят затруднения применения на практике данной схемы?
-
Если использовался только один признак - источник требований, как в этом случае должно выглядеть множество значений данного признака (множество источников требований)?
Теперь видимо я чего-то не понимаю.
Ну вот у нас есть коробка карандашей. Одни карандаши синие, другие зеленые, третьи красные. (Одни требования от мамы, другие от папы, третьи от бабушки). Вот по этим признакам мы их и раскладываем в три кучки. Соотв-но, мы договариваемся, что кучкой зеленых рисуем траву, кучкой синих - небо, а кучкой красных - солнце.
Мы об одном и том же, или о разном? )
-
Теперь видимо я чего-то не понимаю.
Ну вот у нас есть коробка карандашей. Одни карандаши синие, другие зеленые, третьи красные. (Одни требования от мамы, другие от папы, третьи от бабушки). Вот по этим признакам мы их и раскладываем в три кучки. Соотв-но, мы договариваемся, что кучкой зеленых рисуем траву, кучкой синих - небо, а кучкой красных - солнце.
Мы об одном и том же, или о разном? )
Собственно вопрос в том, чтобы перечислить эти самые источники требований ("требования от мамы", "требования от папы", ...) только в приложении к схеме Вигерса.
-
Хотелось бы подробнее узнать, о том, какие именно группы требований в какие именно разделы ТЗ по ГОСТ 34 ложатся, можете привести схему маппинга?
Как вариант:
Бизнес-требования -> Раздел 2 "НАЗНАЧЕНИЕ И ЦЕЛИ СОЗДАНИЯ (РАЗВИТИЯ) СИСТЕМЫ"
Требования пользователей -> Раздел 4.1.1. "Требования к структуре и функционированию системы"
Бизнес-правила -> Разделы 4.1.4 - 4.1.14 (4.1.4 Требования к надежности, 4.1.5 Требования безопасности, 4.1.6 Требования к эргономике и технической эстетике, 4.1.7 Требования к транспортабельности для подвижных АС, 4.1.8 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы, 4.1.9 Требования к защите информации от несанкционированного доступа, 4.1.10 Требования по сохранности информации при авариях, 4.1.11 Требования к защите от влияния внешних воздействий, 4.1.12 Требования к патентной чистоте, 4.1.13 Требования по стандартизации и унификации, 4.1.14 Дополнительные требования) в зависимости от содержания требований
Атрибуты качества -> Раздел 4.1.3"Показатели назначения"
Системные требования -> Раздел 4.3"Требования к видам обеспечения"
Функциональные требования -> Раздел 4.2 "Требования к функциям (задачам), выполняемым системой"
Внешний интерфейс -> Разделы 4.3.3 "Требования к лингвистическому обеспечению" и 4.3.4 "Требования к программному обеспечению"
Ограничения -> Раздел 4.1.14"Дополнительные требования"
А в чем именно состоят затруднения применения на практике данной схемы?
На предложенной схеме выделены 3 группы: "Бизнес-требования", "Пользовательские требования" и "Системные требования", при этом граница между функциональными и нефункциональными требованиями очень размыта (непонятно, где она должна проходить). Что дает такая схема? Какие плюсы от ее использования?
-
Как вариант:
Бизнес-требования -> Раздел 2 "НАЗНАЧЕНИЕ И ЦЕЛИ СОЗДАНИЯ (РАЗВИТИЯ) СИСТЕМЫ"
Требования пользователей -> Раздел 4.1.1. "Требования к структуре и функционированию системы"
Бизнес-правила -> Разделы 4.1.4 - 4.1.14 (4.1.4 Требования к надежности, 4.1.5 Требования безопасности, 4.1.6 Требования к эргономике и технической эстетике, 4.1.7 Требования к транспортабельности для подвижных АС, 4.1.8 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы, 4.1.9 Требования к защите информации от несанкционированного доступа, 4.1.10 Требования по сохранности информации при авариях, 4.1.11 Требования к защите от влияния внешних воздействий, 4.1.12 Требования к патентной чистоте, 4.1.13 Требования по стандартизации и унификации, 4.1.14 Дополнительные требования) в зависимости от содержания требований
Атрибуты качества -> Раздел 4.1.3"Показатели назначения"
Системные требования -> Раздел 4.3"Требования к видам обеспечения"
Функциональные требования -> Раздел 4.2 "Требования к функциям (задачам), выполняемым системой"
Внешний интерфейс -> Разделы 4.3.3 "Требования к лингвистическому обеспечению" и 4.3.4 "Требования к программному обеспечению"
Ограничения -> Раздел 4.1.14"Дополнительные требования"
На предложенной схеме выделены 3 группы: "Бизнес-требования", "Пользовательские требования" и "Системные требования", при этом граница между функциональными и нефункциональными требованиями очень размыта (непонятно, где она должна проходить). Что дает такая схема? Какие плюсы от ее использования?
По мэппингу ... Пользовательские требования (по их определению) не ложатся на "Требования к структуре и функционированию системы", т.к. они не про систему и ее структуру (суть архитектуру). Бизнес-правила, не совсем про надежность, транспортабельность и безопасность ... только если в ряде специфических предметных областей и систем их обеспечения. К ограничениям как раз можно отнести эти требования к надежности и т.п. ... В целом, не вполне корректный IMHO мэппинг.
По использованию схемы - граница м/у различными типами требований лежит в их определении и их назначении. Они вполне себе четко идентифицированы и понятно с какой point of view (в архитектурном смысле) они задаются. В ТЗ по ГОСТ, используется несколько другой подход и другая точка зрения (он не лучше и не хуже, т.е. я не даю ему оценку в данном постинге). И, как раз, если смотреть с позиции "вигерсовской схемы" на ТЗ, то как раз ТЗ будет казаться некоторым смешением точек зрения "в одном флаконе". Плюсами от использования схемы Вигерса можно считать ее понятность, для решения бизнес-задач в первую очередь и изоляцию разных точек зрения (включающих в т.ч. источники требований), что дает возможность использовать различные подходы для выявления требований, их анализа и документирования.
Интересно было бы как раз получить подобную схему для ГОСТ 34 ... где бы были классифицированы требования по их типам, т.е. по сути синтезировать по документарному отображению модель требований, лежащей в основе ГОСТ 34.
-
Пользовательские требования (по их определению) не ложатся на "Требования к структуре и функционированию системы", т.к. они не про систему и ее структуру (суть архитектуру)
По Вигерсу пользовательские требования есть варианты использования системы. Ну а где же их еще прописывать, как не в разделе "Требования к структуре и функционированию системы"? Затрудняюсь найти под эти требования другой раздел ТЗ.
Бизнес-правила, не совсем про надежность, транспортабельность и безопасность ... только если в ряде специфических предметных областей и систем их обеспечения. К ограничениям как раз можно отнести эти требования к надежности и т.п.
Вы правы, не совсем, и только в ряде случаев.
В целом, не вполне корректный IMHO мэппинг
С другой стороны, если написать ТЗ по данной схеме, вряд ли какой Заказчик будет против :) Документ получится достаточно последовательным и логичным. А что еще надо для работы?
Интересно было бы как раз получить подобную схему для ГОСТ 34 ... где бы были классифицированы требования по их типам, т.е. по сути синтезировать по документарному отображению модель требований, лежащей в основе ГОСТ 34.
можно попробовать...
-
По Вигерсу пользовательские требования есть варианты использования системы. Ну а где же их еще прописывать, как не в разделе "Требования к структуре и функционированию системы"? Затрудняюсь найти под эти требования другой раздел ТЗ.Вы правы, не совсем, и только в ряде случаев. С другой стороны, если написать ТЗ по данной схеме, вряд ли какой Заказчик будет против :) Документ получится достаточно последовательным и логичным. А что еще надо для работы?можно попробовать...
У ГОСТ 34 нет явно выраженной и выделенной в отдельную точку зрения, что что Крухтен называет в своей модели 4+1 - use case view. Поэтому пользовательские требования и не лезут никуда в ГОСТ 34.602. Можно конечно применить смекалку :-) ... но явно этого там нет. Кроме этого, мне кажется будет несколько диковато смотреться "ТЗ по ГОСТ с юзкейсами" ... хотя, "в природе встречается" - это когда очень хочется писать юзкейсы, а нужно сдавать по ГОСТ 34 :-) ....
-
Кроме этого, мне кажется будет несколько диковато смотреться "ТЗ по ГОСТ с юзкейсами" ... хотя, "в природе встречается" - это когда очень хочется писать юзкейсы, а нужно сдавать по ГОСТ 34 :-) ....
Юзкейсы - это всего лишь форма представления информации. Тоже самое можно написать словами, придать нужную окраску (благо велик и могуч русский язык) и вот оно, ТЗ по ГОСТ :)
-
Юзкейсы - это всего лишь форма представления информации. Тоже самое можно написать словами, придать нужную окраску (благо велик и могуч русский язык) и вот оно, ТЗ по ГОСТ :)
Ой, а можно примерчик?
-
Более точно - юзкейсы, это одна из форм представления пользовательских требований (взгляда на систему со стороны пользователя и его целей по отношению к ней). Пользовательские требования вполне можно писать в виде "<Пользователь/роль> должен иметь возможность делать ХХХ". У сценарного изложения в формате юзкейсов есть множество своих преимуществ и достоинств, в конкретных случаях. Но тезис заключается в другом - у схемы Вигерса есть явно выраженная точка зрения на систему с т.з. пользователя, и ясно в каком виде и документе она должна быть выражена/отражена, а в ГОСТ 34 ее как таковой - нет, приходится выкручиваться, если есть необходимость или желание такую точку зрения там получить в явном виде.
-
Ой, а можно примерчик?
Эдуард, чувствую, раскритикуете вы мой пример ;D К тому же подходы к написанию ТЗ (а также стиль изложения и форма представления информации) у всех разные, это все равно что спорить о вкусах.
а в ГОСТ 34 ее как таковой - нет
Юрий, не совсем с вами согласен. Если брать весь комплекс стандартов 34-й серии, то разработка ТЗ - это третья стадия создания Системы. При этом "ТЗ на АС разрабатывают на основании исходных данных в том числе содержащихся в итоговой документации стадии «Исследование и обоснование создания АС»" (п. 1.5 ГОСТ 34.602). В свою очередь на первой стадии есть этап 1.2. "Формирование требований пользователя к АС", на котором осуществляется "формулировка и оформление требований пользователя к АС" (ГОСТ 34.601). Это ли не описание юзкейсов? Таким образом я это вижу так: 1. На стадии обследования осуществляется разработка диаграммы вариантов использования, проводится описание ВИ и т.д., вобщем описывается (в том числе, но не только) та самая точка зрения пользователя на Систему, о которой вы говорили. Отражается это в отчете о выполненной работе по обследованию объекта автоматизации. 2. На стадии разработки ТЗ эти юзкейсы используются как входные данные, которые трансформируются в те требования к Системе, которые все привыкли видеть в ТЗ. Как-то так (ИМХО).
-
Более точно - юзкейсы, это одна из форм представления пользовательских требований (взгляда на систему со стороны пользователя и его целей по отношению к ней). Пользовательские требования вполне можно писать в виде "<Пользователь/роль> должен иметь возможность делать ХХХ". У сценарного изложения в формате юзкейсов есть множество своих преимуществ и достоинств, в конкретных случаях. Но тезис заключается в другом - у схемы Вигерса есть явно выраженная точка зрения на систему с т.з. пользователя, и ясно в каком виде и документе она должна быть выражена/отражена, а в ГОСТ 34 ее как таковой - нет, приходится выкручиваться, если есть необходимость или желание такую точку зрения там получить в явном виде.
Когда писался ГОСТ 34, в головах его разработчиков основной моделью ещё было взаимодействие с системой через консоль. Поэтому там остались такие понятия как "лингвистическое обеспечение" и "языки ввода-вывода данных", но ещё нет никаких намёков на концепцию пользовательских ролей или пошаговые процедуры взаимодействия. Конечно, ГОСТ писался умными людьми, которые заложили в него некоторые универсальные принципы, но бессмысленно искать в ГОСТе то, чего в нём никогда не было.
А это финальный слайд моего выступления на РИТ++. Смиритесь. :)
(http://m.friendfeed-media.com/62e9541cf66cb467c8d74c5ffd388818213e5d5f)
-
А это финальный слайд моего выступления на РИТ++. Смиритесь. :)
Покажите его всей нашей оборонке и государственному сектору и может быть найдутся аргументы, которые поменяют ваше мнение ;)
-
Покажите его всей нашей оборонке и государственному сектору и может быть найдутся аргументы, которые поменяют ваше мнение ;)
Да я знаю, что в госсекторе без стандартов никак. Но imho это не повод подгонять работу аналитика под устаревшие стандарты. Оформлением ТЗ по ГОСТу должны заниматься опытные техписы-крючкотворы, которым нужно платить высокую зарплату и отправлять на хорошую пенсию досрочно из-за вредности их работы.
Ну, понятно, что это в идеальном мире. Хотя я уверен, что есть компании, которые с удовольствием возьмут этот нелёгкий труд на себя - тот же Философт, например.
-
Оформлением ТЗ по ГОСТу должны заниматься опытные техписы-крючкотворы, которым нужно платить высокую зарплату и отправлять на хорошую пенсию досрочно из-за вредности их работы
Ура!!! у меня будет хорошая пенсия!!! а проездной на метро дадут бесплатно? ;D
На самом деле не пойму, чем же вам так ГОСТы не нравятся... Они прекрасно справляются со своей задачей. Вот не встречал я в жизни доку лучше, чем гостовская (конечно, при условии, что тех.писатель толковый). Другое дело нормоконтроль - вот это правда беда... но отнюдь не ГОСТов.
-
Когда писался ГОСТ 34, в головах его разработчиков основной моделью ещё было взаимодействие с системой через консоль. Поэтому там остались такие понятия как "лингвистическое обеспечение" и "языки ввода-вывода данных", но ещё нет никаких намёков на концепцию пользовательских ролей или пошаговые процедуры взаимодействия. Конечно, ГОСТ писался умными людьми, которые заложили в него некоторые универсальные принципы, но бессмысленно искать в ГОСТе то, чего в нём никогда не было.
А это финальный слайд моего выступления на РИТ++. Смиритесь. :)
(http://m.friendfeed-media.com/62e9541cf66cb467c8d74c5ffd388818213e5d5f)
"ГОСТ умер, да здравствует ГОСТ!" .... Реальность такова, что за разработку документации по ГОСТу еще платят. Раз платят, значит он еще жив :), так что с фатализмом можно еще немного повременить. Кроме этого, никто не мешает отделять такие вещи как собственно модель требований к системе и ее документарное отображение (документация требований).
Другой вопрос что разрабатывать модель требований по одной схеме и отображать ее на документацию по ГОСТ (в котором заложена несколько иная схема), задача достаточно трудоемкая и возникает вопрос, которым отметается 90% инициатив - "а нафига?". Тут вариантов несколько - либо аналитику становиться "универсальным солдатом" - т.е. понимать отличие схем и умело ими пользоваться, чтобы создавать качественную документацию требований по требуемым стандартам, либо брезгливо морщить нос при прочтении тендерной документации, в которой встречается требование оформления документации по ГОСТ 34 и не браться за такую работу. Тут уж каждому - своё.
У меня был один случай, когда мне было интересно писать юзкейсы, но в ТЗ "должен был узнаваться ГОСТ" (дословно требование заказчика :-)))). Я таки писал юзкейсы, а потом из них делал собственно требования по ГОСТу ... работка дурацкая, но юзкейсы мне позволили понять чем именно будет ценна для пользователей система... А на базе модели юзкейсов, я уже слепил список функций системы и тупо писал к ним требования, практически по юзкейсам, упражняясь "в казенности" формулировок :-). Получилось почти по Вигерсу :-))).
-
Юрий, не совсем с вами согласен. Если брать весь комплекс стандартов 34-й серии, то разработка ТЗ - это третья стадия создания Системы. При этом "ТЗ на АС разрабатывают на основании исходных данных в том числе содержащихся в итоговой документации стадии «Исследование и обоснование создания АС»" (п. 1.5 ГОСТ 34.602). В свою очередь на первой стадии есть этап 1.2. "Формирование требований пользователя к АС", на котором осуществляется "формулировка и оформление требований пользователя к АС" (ГОСТ 34.601). Это ли не описание юзкейсов? Таким образом я это вижу так: 1. На стадии обследования осуществляется разработка диаграммы вариантов использования, проводится описание ВИ и т.д., вобщем описывается (в том числе, но не только) та самая точка зрения пользователя на Систему, о которой вы говорили. Отражается это в отчете о выполненной работе по обследованию объекта автоматизации. 2. На стадии разработки ТЗ эти юзкейсы используются как входные данные, которые трансформируются в те требования к Системе, которые все привыкли видеть в ТЗ. Как-то так (ИМХО).
Это просто Ваша интерпретация ГОСТ, поэтому Вы конечно же можете быть несогласны с моей интерпретацией, это нормально. Можно посмотреть РД 50-34.698-90, где описана структура отчета, который выпускается на данной стадии, там как-то не очень про требования пользователя богато сказано - порождает еще больше вопросов.... Более того, в ГОСТ вообще НИГДЕ не определено, что понимается под "требованиями пользователя", если мне не изменяет память... Я, например, с таким же успехом могу интерпретировать это таким образом, что под требованиями пользователя в ГОСТ понимается тот набор features, которые должны быть в создаваемой системе. А строго говоря features - это не пользовательские требования по Вигерсу ... Тут полет фантазии у нас ничем не ограничен :-).
ГОСТ ни плох, ни хорош, он просто стандарт, несколько устаревший, но вполне используемый в тех же госах ... Только проблема в том, что я ОЧЕНЬ редко встречал в госах действительно классные ТЗ по ГОСТ 34.602. Думаю что их есть, не все ж ТЗ студенты пишут ... просто мне не попадались. Основной проблемой ГОСТ 34 как раз является отсутствующая модель требований. Разработчики ГОСТ создали по сути процесс создания АС и его документарное обеспечение, но ничего не сказали нам про то, что могут быть разные модели ЖЦ, ни про классификацию требований, которая лежит в его основе ... Но это стандарт на порядок создания и документирования АС, а не фреймворк, типа RUP ... И еще, в ГОСТ жутко не хватает нормального глоссария ...
-
Эдуард, чувствую, раскритикуете вы мой пример ;D К тому же подходы к написанию ТЗ (а также стиль изложения и форма представления информации) у всех разные, это все равно что спорить о вкусах.
Ну, Максим, это Вы напрасно. Не такой уж я и критикан, как меня малюют ;) На самом деле, очень интересно посмотреть.
"Формирование требований пользователя к АС", на котором осуществляется "формулировка и оформление требований пользователя к АС" (ГОСТ 34.601). Это ли не описание юзкейсов?
А свежая мысль, надо сказать. Правда забавная ситуация, у нас студенты, а их кто-то учит (не я правда) делают ВИ в ходе техно-рабочего проекта. Кстати, по-моему, и Водолей такую точку зрения разделяет.
Но ведь фактически, а где же их еще писать.
Таким образом я это вижу так: 1. На стадии обследования осуществляется разработка диаграммы вариантов использования, проводится описание ВИ и т.д., вобщем описывается (в том числе, но не только) та самая точка зрения пользователя на Систему, о которой вы говорили. Отражается это в отчете о выполненной работе по обследованию объекта автоматизации.
Звучит разумно
2. На стадии разработки ТЗ эти юзкейсы используются как входные данные, которые трансформируются в те требования к Системе, которые все привыкли видеть в ТЗ. Как-то так (ИМХО).
Ну у Вигерса очень похожие примеры с точностью то спецификации требований. Вопрос, а зачем так делать? Имхо получается какая-то лишняя работа
-
А это финальный слайд моего выступления на РИТ++. Смиритесь. :)
(http://m.friendfeed-media.com/62e9541cf66cb467c8d74c5ffd388818213e5d5f)
Твоими устами да мед пить. А у нас студентов режут, если они не по ГОСТ оформили ТЗ и проект
-
Твоими устами да мед пить. А у нас студентов режут, если они не по ГОСТ оформили ТЗ и проект
А к чему вы их там готовите?
-
Это просто Ваша интерпретация ГОСТ, поэтому Вы конечно же можете быть несогласны с моей интерпретацией, это нормально.
Прошу заметить, все в рамках дозволенного, все по честному, все по правилам ;D
Можно посмотреть РД 50-34.698-90, где описана структура отчета, который выпускается на данной стадии, там как-то не очень про требования пользователя богато сказано - порождает еще больше вопросов....
Есть в этом отчете раздел Раздел "Функции и задачи создаваемой АС", который содержит.
• 1) обоснование выбора перечня автоматизированных функций и комплексов задач с указанием очередности внедрения,
• 2) требования к характеристикам реализации функций и задач в соответствии с действующими нормативно-техническими документами, определяющими общие технические требования к АС конкретного вида;
• 3) дополнительные требования к АС в целом и ее частям, учитывающие специфику создаваемой АС.
Что вам мешает обосновать этот перечень функций путем использования вариантов использования Системы? ГОСТ не определяет методику формирования требований, он оставляет это на откуп аналитику, а там уже кому как нравится. Хочешь используй это, хочешь это... И это правильно.
Более того, в ГОСТ вообще НИГДЕ не определено, что понимается под "требованиями пользователя", если мне не изменяет память... Я, например, с таким же успехом могу интерпретировать это таким образом, что под требованиями пользователя в ГОСТ понимается тот набор features, которые должны быть в создаваемой системе. А строго говоря features - это не пользовательские требования по Вигерсу ... Тут полет фантазии у нас ничем не ограничен :-).
Давайте все-таки придерживаться здравого смысла :) Требования пользователя - это требования пользователя (согласитесь, с этим трудно поспорить ;D ). Но где вы видели пользователя, который вам сразу выдает features ?
Только проблема в том, что я ОЧЕНЬ редко встречал в госах действительно классные ТЗ по ГОСТ 34.602
ИМХО это проблема тех.писателей, а не ГОСТа
Основной проблемой ГОСТ 34 как раз является отсутствующая модель требований. Разработчики ГОСТ создали по сути процесс создания АС и его документарное обеспечение, но ничего не сказали нам про то, что могут быть разные модели ЖЦ, ни про классификацию требований, которая лежит в его основе ...
Моя точка зрения - это не проблема ГОСТа, это просто не его поле боя. Вы хотите получить от него то, для чего он просто не предназначен. 34-я серия определяет в основном перечень работ на различных стадиях и этапах разработки и перечень разрабатываемых документов. При этом, ГОСТ не запрещает вам определять свой перечень работ и документов, пожалуйста, согласовываете с заказчиком, прописываете в ТЗ и вперед. Во всем остальном вам дали свободу :)
-
Ну, Максим, это Вы напрасно. Не такой уж я и критикан, как меня малюют ;) На самом деле, очень интересно посмотреть.
Давайте может тему создадим в примерах? я бы с удовольствие поупражнялся, но хочу предупредить заранее, что я далеко не аксакал :)
у нас студенты, а их кто-то учит (не я правда) делают ВИ в ходе техно-рабочего проекта.
типичная ситуация для проекта, в котором 1-я стадия - это ТЗ, никакого обследования, никакого вникания в предметную область... Написали общих фраз и начали проектировать :) Конечно, ничего другого не остается, как разрабатывать ВИ в ходе технического проекта.
Вопрос, а зачем так делать? Имхо получается какая-то лишняя работа
могу поделиться своими догадками... Требования пользователей, как ни крути, достаточно высокоуровневые, по ним Систему не сделаешь, да и непонятно как сдавать. Что в ПМИ писать? как проверять? А вот функциональные требования - легко. В этом случае ГОСТ совершенно прав, предлагая нам сначала провести обследование, выявить пользовательские требования, а потом уже разработать функциональные требования и включить их в ТЗ. В качестве подтверждения могу процитировать Юрия: "Я таки писал юзкейсы, а потом из них делал собственно требования по ГОСТу ... работка дурацкая, но юзкейсы мне позволили понять чем именно будет ценна для пользователей система... А на базе модели юзкейсов, я уже слепил список функций системы и тупо писал к ним требования, практически по юзкейсам, упражняясь "в казенности" формулировок :-). Получилось почти по Вигерсу :-)))" (с)
-
сообщение устарело
-
А к чему вы их там готовите?
Ну у нас направление Информационные системы и технологии. Есть какое-то очень стойкое мнение, что все ИС - это АС. Ну а ГОСТ-то как раз для него.
правда так почти никто и не умеет писать Т и оформлять проекты, но зато есть хлеб у нормоконтроля
-
Ну у нас направление Информационные системы и технологии. Есть какое-то очень стойкое мнение, что все ИС - это АС. Ну а ГОСТ-то как раз для него.
правда так почти никто и не умеет писать Т и оформлять проекты, но зато есть хлеб у нормоконтроля
Стойкое мнение есть именно потому, что для АС есть ГОСТ, который легко изучать и преподавать. Там всё задокументировано и разложено по полочкам.
А за всеми современными тенденциями в разработке требований не уследишь, тем более что они всё больше переползают из технической области в гуманитарную - экономика, маркетинг, психология, вот это всё.
-
Стойкое мнение есть именно потому, что для АС есть ГОСТ, который легко изучать и преподавать.
АС (автоматизированные системы) есть одна из двух разновидностей информационных систем. Т.е. по классификации ИС делятся на автоматизированные и автоматические. Поскольку множеством автоматических систем можно пренебречь, то получается, что ИС=АС.
-
АС (автоматизированные системы) есть одна из двух разновидностей информационных систем. Т.е. по классификации ИС делятся на автоматизированные и автоматические. Поскольку множеством автоматических систем можно пренебречь, то получается, что ИС=АС.
Ага, а АС состоит из "персонала и комплекса средств автоматизации его деятельности и реализует информационную технологию выполнения установленных функций." :)
Проблема в том, что на это определение никто не обращает внимания, а оно определяет границу применимости модели, заложенной в ГОСТе. Является ли посетитель интернет-магазина "персоналом системы"? Автоматизирует ли интернет-магазин его деятельность? Если мы будем разрабатывать этот магазин по ГОСТу, то получим в результате "АРМ покупателя". С кнопками, отчётами, языками ввода-вывода данных, инструкцией по эксплуатации и т. п. :)
Понятно, что в коммерческом конкурентном сегменте такие интернет-магазины быстро и тихо загнутся, никем не замеченные. Но у нас же есть ещё гос. услуги и монополии! И вот там этот подход проявляет себя во всей красе - что на порталах государственных служб (госуслуги в первую очередь), что на сайтах РЖД и ПР.
-
сообщение устарело
-
Ага, а АС состоит из "персонала и комплекса средств автоматизации его деятельности и реализует информационную технологию выполнения установленных функций." :)
Проблема в том, что на это определение никто не обращает внимания, а оно определяет границу применимости модели, заложенной в ГОСТе
Извините, не понял, к чему это вы? Мне всегда казалось, что это одно из самых правильных определений в сфере ИТ :)
Является ли посетитель интернет-магазина "персоналом системы"?
Конечно является, ведь именно его деятельность (поиск и покупка товара) автоматизирует система.
Если мы будем разрабатывать этот магазин по ГОСТу, то получим в результате "АРМ покупателя". С кнопками, отчётами, языками ввода-вывода данных, инструкцией по эксплуатации и т. п. :)
А вот тут что посадите, то и вырастет. Хотите получить АРМ, будет у вас АРМ. А хотите получить распределенную информационную систему с архитектурой "клиент-сервер" - формулируйте соответствующие требования. Опять же, что значит выражение "разрабатывать систему по ГОСТу"? Насколько я знаю, нет отдельных ГОСТов на интернет-магазины, системы складского учета и т.д. Есть ГОСТы на документы, есть ГОСТ на стадии разработки и т.д.
-
Конечно является, ведь именно его деятельность (поиск и покупка товара) автоматизирует система. А вот тут что посадите, то и вырастет. Хотите получить АРМ, будет у вас АРМ. А хотите получить распределенную информационную систему с архитектурой "клиент-сервер" - формулируйте соответствующие требования.
Конечно, я имею в виду в первую очередь разработку и оформление требований по ГОСТу (всерьёз обсуждать этапы эскизного и технического проекта, методики и программы испытаний применительно к интернет-магазинам я пока морально не готов :)).
Нет, покупатель не является "персоналом". А если выйти немного за рамки ГОСТа, он также не является и обычным "пользователем" в концепции ролей пользователей. Его цели не выводятся логическим путём из бизнес-целей создания системы (потому что цель системы - продавать, а не покупать). И поэтому подход к выявлению потребностей покупателей и трансформации их в требования к системе нужен другой.
Проектировщиков сбивает с толку то, что некоторые побочные виды деятельности покупателя действительно хорошо автоматизируются. Например, поиск товара, как здесь было сказано, а я бы к нему добавил ещё и сравнение товаров. Они очень хорошо ложатся на диаграмму юзкейсов, по ним наработан большой опыт разработки. Результат, например, такой: я (и не только я) с удовольствием использую прекрасный интернет-магазин mvideo.ru для поиска и сравнения товаров по характеристикам, а, совершив выбор, покупаю его в другом месте (иду, например, на яндекс.маркет и там выбираю уже по цене, или заезжаю в MediaMarkt по дороге домой, чтобы подержать товар в руках перед окончательным решением о покупке).
Чтобы мотивировать меня покупать тут же, не уходя с сайта, нужны новые подходы. Они есть, конечно, и в первую очередь их прорабатывают в новой отрасли, которую сейчас называют "юзабилити" или "проектирование пользовательского взаимодействия", и которая уже тесно связана с психологией (поэтому я и говорю, что современные подходы выявления и разработки требований переползают в гуманитарную область). Но тут на первый план выходит нефункциональная сторона системы. Нефункциональные требования (юзабилити) оказываются важнее, их проработка обходится дорого, и они порождают в конечном итоге очень большую долю программного кода при разработке.
А в АС функциональная сторона по определению стоит на первом месте (реализует информационную технологию выполнения установленных функций). И ментальные модели, сформировавшиеся у людей, привыкших или обученных разрабатывать "автоматизированные системы", приводят к их осознанному или неосознанному сопротивлению. Что видно, например, на том же сайте РЖД: система отвергает попытки очеловечить интерфейс покупки билетов онлайн. Но им хорошо, они монополисты, и пока могут себе это позволить.
Но бог с ними, с интернет-магазинами. Осознание того, что нефункциональная сторона стала важнее функциональной, приходит и в энтерпрайз. Интерфейсы всех современых автоматизированных банковских систем, например, ужасны. Это бесконечные перекрывающиеся таблицы, формы из десятков элементов, огромное количество непонятных условных обозначений. И уже есть спрос на "АБС с человеческим лицом". И я думаю, что та компания-производитель АБС, которая первой решится на коренную переработку подхода к проектированию, совершит революцию в своём сегменте типа той, которую в массовом масштабе совершила Apple.
-
И ментальные модели, сформировавшиеся у людей, привыкших или обученных разрабатывать "автоматизированные системы", приводят к их осознанному или неосознанному сопротивлению
Во-во, мой мозг сейчас активно сопротивляется :)
Давайте заново, а то я запутался... Итак, говорим о классификации требований. Есть модель Вигерса, есть ГОСТ 34.602. Вигерс хорошо рассказывает, какие требования бывают и как их добыть, ГОСТ говорит, как должно быть оформлено ТЗ. Очевидно, что Вигерс на ГОСТ просто так не ложится, но иногда надо (например, госконтракт). Выше я предложил одну из схем, по всей видимости неудачно, но все же. Далее две точки зрения: 1. ГОСТ умер, 2. ГОСТ жив. Основные тезисы первой точки зрения (поправьте, если неправильно понял):
1. ГОСТ не определяет порядок разработки требований.
2. ГОСТ не определяет модель требований.
3. ГОСТ ничего не знает про требования пользователей, юзкейсы, ДВИ и т.д.
4. ГОСТ не предлагает широкий выбор моделей жизненного цикла АС.
5. ГОСТ говорит только о функциональных требованиях.
Тезисы второй точки зрения (ГОСТ жив):
1. ГОСТ предусматривает отдельную стадию для формирования требований к разрабатываемой АС. Как именно это будет происходить дается на откуп специалистам.
2. Какая-то модель требований в ГОСТ все же заложена, структура ТЗ об этом недвусмысленно намекает. Отдельно про модель нигде не говорится, потому как в то время отсутствовала необходимость (или осознание необходимости) управлять этими требованиями. Написали ТЗ и все, вперед делать. И стоит отметить, делали-то на совесть, до сих пор все работает! Еще один момент: ГОСТ предусматривает изменение/дополнение ТЗ (путем разработки доп.ТЗ, ЧТЗ), чем вам не итерационный подход? при этом нигде не говорится, сколько должна длиться одна итерация, может 10 лет, а может месяц. На этапе разработки доп.ТЗ проводится анализ требований (а как без этого), но каким способом - на усмотрение специалиста.
3. Есть три уровня требований: бизнес, пользовательские и функциональные + нефункциональные требования. Система строится по требованиям низкого уровня (функциональным требованиям) + нефункциональным требованиям, остальные 2 уровня требований нужны чтобы получить (и обосновать) этот 3-й уровень. Да, в ГОСТе нет такого деления, но что мешает его использовать? Функциональные требования в ТЗ по ГОСТ нужно как-то обосновывать, почему бы это не сделать при помощи ВИ? я не встретил явного запрета.
4. ГОСТ предлагает перечень стадий и этапов разработки АС, при этом ГОСТ 34.601 гласит: "Допускается исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая документация» в одну стадию «Технорабочий проект». В зависимости от специфики создаваемых АС и условий их создания допускается выполнять отдельные этапы работ до завершения предшествующих стадий, параллельное во времени выполнение этапов работ, включение новых этапов работ". Таким образом, путем варьирования предложенных стадий и этапов можно реализовать практически любую модель жизненного цикла и ГОСТ это разрешает. Главное с заказчиком потом все это согласовать ;D
5. ГОСТ явно не проводит деление требований на группы (классификацию), но нефункциональные требования он не обходит стороной. Так в ТЗ есть такие разделы, как Показатели назначения, Требования надежности, безопасности и т.д. Как их родить он не говорит, но его ли это задача?
Они есть, конечно, и в первую очередь их прорабатывают в новой отрасли, которую сейчас называют "юзабилити" или "проектирование пользовательского взаимодействия"
В ТЗ есть раздел "требования эргономики и технической эстетики", звучит старомодно, но это тоже самое. "2.6.1.6. В требования по эргономике и технической эстетике включают показатели АС, задающие необходимое качество взаимодействия человека с машиной и комфортность условий работы персонала". Запишите туда свои требования к интерфейсу, что вам мешает?
и которая уже тесно связана с психологией (поэтому я и говорю, что современные подходы выявления и разработки требований переползают в гуманитарную область). Но тут на первый план выходит нефункциональная сторона системы. Нефункциональные требования (юзабилити) оказываются важнее, их проработка обходится дорого, и они порождают в конечном итоге очень большую долю программного кода при разработке.
психологией занимается не система, а оператор системы. Для системы это всего лишь дополнительный функционал (или ограничение). Пригласите на этапе разработки требований психолога, получите ТЗ, учитывающее данные аспекты. Но для разработчиков это не имеет никакого значения! они получат ТЗ, в котором советы психолога будут интерпретированы аналитиком в обычные требования к системе и они будут писать такие же процедуры и функции. После реализации интернет-магазина посадите вместо обычного менеджера толкового маркетолога и вы увидите, как ваш магазин с "бесчеловечным" интерфейсом будет бить рекорды продаж!
Вобщем, не убедили вы меня :)
-
Прошу заметить, все в рамках дозволенного, все по честному, все по правилам ;DЕсть в этом отчете раздел Раздел "Функции и задачи создаваемой АС", который содержит.
• 1) обоснование выбора перечня автоматизированных функций и комплексов задач с указанием очередности внедрения,
...
Что вам мешает обосновать этот перечень функций путем использования вариантов использования Системы? ГОСТ не определяет методику формирования требований, он оставляет это на откуп аналитику, а там уже кому как нравится. Хочешь используй это, хочешь это... И это правильно.
Сорри, я не очень уловил мысль. С моей точки зрения, обоснование перечня автоматизируемых функций должно опираться, как вариант, на экономических расчетах (смотрим на процесс, автоматизируем только те функции, автоматизация которых даст в совокупности наибольший выигрыш процессу в целом, скажем, позволит сократить время/улучшить качество/ .... что в свою очередь может быть выражено в денежном эквиваленте), или на иных критериях (например безопасность). Не вполне понял как это связано с такой формой представления пользовательских требований как юзкейсы?
Давайте все-таки придерживаться здравого смысла :) Требования пользователя - это требования пользователя (согласитесь, с этим трудно поспорить ;D ). Но где вы видели пользователя, который вам сразу выдает features ?
Требования пользователя по ГОСТ <> Пользовательским требованиям по Вигерсу. Это скорее всего как раз то, что, например, в RUP называют stakeholder requests и на это есть отдельный артефакт (и шаблон документа). По сути, это набор "хотелок", который может относиться как к бизнес-процессам или к информационной системе в целом, так и к деталям ее реализации. Разного уровня и разных точек зрения.
Насчет пользователя, который сразу выдает features - это запросто. Просто пользователь может не знать, что он формулирует то, что системные аналитики называют фичей :-).
Простой пример. Пользователь говорит "хочу чтобы программа оценивала шанс продать товары из нашего каталога по выбранному клиенту на основании истории покупок и <пр. данных> о клиенте". Это по ГОСТ "требование пользователя" - очевидно, да. Это есть фича? Однозначно да, при условии, если это будет ОТЛИЧИТЕЛЬНОЙ особенностью данной системы, по сравнению с тем что было раньше или от аналогичного ПО :-).
...Моя точка зрения - это не проблема ГОСТа, это просто не его поле боя. Вы хотите получить от него то, для чего он просто не предназначен. 34-я серия определяет в основном перечень работ на различных стадиях и этапах разработки и перечень разрабатываемых документов. При этом, ГОСТ не запрещает вам определять свой перечень работ и документов, пожалуйста, согласовываете с заказчиком, прописываете в ТЗ и вперед. Во всем остальном вам дали свободу :)
Тогда какое от такого стандарта value, если я могу его кастомизировать до неузнаваемости? Я из него SCRUM с итеративной моделью ЖЦ сделаю, и что это считать ГОСТом? Тут куда не кинь - проблема ... по ГОСТ как раз написать плохо ТЗ можно, и никто не сможет доказать, что ТЗ написано плохо. В отличие от тех же юзкейсов, где есть определённые методики их написания. Возможно наличие таких методик для ГОСТа упростило бы ситуацию.
-
Коллеги, все же решил продолжить:
Классификация требований. Часть 2. Бизнес требования. (http://blogs.uml2.ru/node/284)
-
Мне кажется, неправильно вы ГОСТ готовите...
Выношу на суждение статью:
"Классификация требований по ГОСТ 34.602-89" http://blog.shumoos.com/archives/288
-
Мне кажется, неправильно вы ГОСТ готовите...
Выношу на суждение статью:
"Классификация требований по ГОСТ 34.602-89" http://blog.shumoos.com/archives/288
Плохо, что у тебя в блоге нельзя прокомментировать не зарегистрировавшись в wordpress.
Мне кажется, ты делаешь определенную ошибку, делая акцент на требования к ПО. Там не требования к ПО, а требования к системе. Все-таки это несколько разные вещи. Отсюда и диссонанс в восприятии ГОСТа.
-
Плохо, что у тебя в блоге нельзя прокомментировать не зарегистрировавшись в wordpress.
Плохо. Думаю над этим.
Мне кажется, ты делаешь определенную ошибку, делая акцент на требования к ПО. Там не требования к ПО, а требования к системе. Все-таки это несколько разные вещи. Отсюда и диссонанс в восприятии ГОСТа.
Э-э-э... Ровно это я и написал. Что это требования к системе.