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

×


Классификация требований(Прочитано 51515 раз)
Re: Классификация требований Ответ #15 : 25 Апреля 2013, 23:33:10
Вот решил предложить свою классификацию:
Классификация требований. Часть 1. В общем о главном.
Саша, было бы здорово, чтобы ты указал автора «недавних попыток классификации».

Причём ты почему-то указываешь фамилию того, кто собрал и процитировал чужие классификации, а того, кто предложил, условно, новую — нет :)

И я напомню на всякий случай про заметку 7-летней давности: http://beskov.livejournal.com/14493.html
« Последнее редактирование: 25 Апреля 2013, 23:35:24 от Denis Beskov »



Re: Классификация требований Ответ #16 : 26 Апреля 2013, 12:55:28
Денис,

Сорри, исправил, указал тебя как автора новой идеи по классификации.
Ссылку на заметку 7ми летней давности не стал включать, дабы не путать еще больше людей, но ее учту также. Спасибо.
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Re: Классификация требований Ответ #17 : 28 Апреля 2013, 11:04:42
Странно что Юра Булуй не пишет в этой теме, он уделял этому вопросу много времени.
вот например одна из презентаций http://ocnova.ru/wp-content/uploads/Library/Yury_Buluy_(ReqClassification).zip
я как бы лично сам ни за что не агитирую, просто для информации.



Re: Классификация требований Ответ #18 : 29 Апреля 2013, 10:32:09
Илья,

Я как раз эту презу Юрия и указал в своей статье :)
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Re: Классификация требований Ответ #19 : 29 Апреля 2013, 23:48:55
Коллеги, доброго вам времени суток.
Классификация, как мне кажется, очень увлекательное занятие. Главное, что пытаясь что-то классифицировать - ощущаешь себя причастным к чему-то великому и значимому ;-) (каюсь, сам делал несколько подходов к этому делу). Но с другой стороны, всякое знание (ну или почти всякое) начинается с упорядочивания и классификации. Именно по этому я предпочел изучить доступные мне на тот момент материалы тем или иным образом относящиеся к классификации требований, попытаться их сопоставить м/у собой и понять, что  Вигерс дал вполне себе нормальную схему именно требований, относящихся к программной инженерии. Конечно можно спорить с ней, обоснованно утверждать, что не всегда имеет смысл использовать все три уровня требовании в отдельно взятом проекте и заниматься строгим контролем и трассировкой м/у уровнями (хотя это делает модель требований конкретного проекта более структурированной) ... Можно так же его критиковать за то, что у него два раза встречается название "функциональные" требования, что может вносить путаницу для неподготовленного читателя. Но в любом случае она вполне себе выполняет свою задачу, особенно если мы говорим про заказную разработку... А если чем-то можно пользоваться, и оно позволяет решать имеющиеся задачи, то зачем тратить время на изобретение? Можно конечно наплодить кучу типов требований, добавить еще шкалу времени "в туда" (с) (привязав требования, например, к ЖЦ разработки). Но ничего принципиально нового это не даст. Разве только позволит детализировать и уточнить предложенную Вигерсом схему (я упорно не называю его схему классификацией, т.к. сам Вигерс, если мне не изменяет память, сам называет ее не классификацией, а  "моделью", которую он использует в своей практике), ну и конечно же позволит "размять мозги" и получить творческий азарт, куда без этого :-). Но в то же время, никто не мешает, по аналогии с Вигерсом - сделать ту схему требований, которая используется в практике конкретного специалиста. Если это помогает - вперед!

Кстати, в этой презе моей, есть очень тонкое место, которое возможно не заметно на первый взгляд, хотя я думаю многие из вас об этом подумали ... А именно сравнение ТЗ по ГОСТ 34.602 которое суть ТЗ на АС (а мы помним, что есть АС) с требованиями на собственно программное обеспечение :-). Когда рисовал эту презу, меня просто терзали сомнения, стоит ли сравнивать ... но в конечном итоге подумал, кто этим заморачивается? У нас все что делают, считают АС ... и не парятся с тонкостями.
« Последнее редактирование: 29 Апреля 2013, 23:52:08 от Юрий Булуй »
"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: Классификация требований Ответ #20 : 30 Апреля 2013, 09:01:38
У нас все что делают, считают АС ... и не парятся с тонкостями.
Юра, тонкость появляется, когда ты хочешь описать требования к разработке, например, программного каркаса(фреймверка)



Re: Классификация требований Ответ #21 : 30 Апреля 2013, 09:52:40
Цитировать
сравнение ТЗ по ГОСТ 34.602
Да. Я еще подумала, что может быть было бы более правильно сравнивать с ГОСТ 19...

Юрий, пользуясь случаем, хотела бы уточнить - Вы в презентации сопоставляете Functional Requirements пункту ТЗ 2.6.2 (Требования к функциям (задачам)). Мне казалось, что этот пункт по уровню детализации ближе к User Requirements. Или я ошибаюсь?



Re: Классификация требований Ответ #22 : 03 Мая 2013, 21:17:19
Юра, тонкость появляется, когда ты хочешь описать требования к разработке, например, программного каркаса(фреймверка)

Эд, фреймворк - это не заказная разработка, это скорее продуктовая разработка. Весь вопрос в том, что используется для описания требований к нему и с какой степенью детализации эти требования нужно представить.
"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: Классификация требований Ответ #23 : 03 Мая 2013, 21:26:00
Да. Я еще подумала, что может быть было бы более правильно сравнивать с ГОСТ 19...

Юрий, пользуясь случаем, хотела бы уточнить - Вы в презентации сопоставляете Functional Requirements пункту ТЗ 2.6.2 (Требования к функциям (задачам)). Мне казалось, что этот пункт по уровню детализации ближе к User Requirements. Или я ошибаюсь?

Если посмотреть что понимается под функцией системы, и посмотреть на практику написания ТЗ - очень редко требования к функциям и задачам описываются в терминах пользователей ("пользователь должен иметь возможность ...."), чаще встречается "система должна иметь возможность". А это означает взгляд именно со стороны системы на внешний мир, а не со стороны пользователя на систему, что соответствует понятию функциональных требований, а не пользовательских. Т,е. тут важно какую точку зрения (в терминах архитектурного проектирования) выбирают для описания этого вида требований.
"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: Классификация требований Ответ #24 : 03 Мая 2013, 21:48:26
Если посмотреть что понимается под функцией системы, и посмотреть на практику написания ТЗ - очень редко требования к функциям и задачам описываются в терминах пользователей ("пользователь должен иметь возможность ...."), чаще встречается "система должна иметь возможность". А это означает взгляд именно со стороны системы на внешний мир, а не со стороны пользователя на систему, что соответствует понятию функциональных требований, а не пользовательских. Т,е. тут важно какую точку зрения (в терминах архитектурного проектирования) выбирают для описания этого вида требований.
Юр, смею заметить что не только точка зрения с которой формулируются требования влияет на словесную конструкцию. Допустим мы берем точку зрения пользователя. Мы можем таскать его везде за собой "система должна позволять пользователю выполнять..." или мы убрали пользователя "система должна позволять выполнять..." (держим пользователя "в уме"), или "пользователь должен иметь возможность..."  или мы таскаем за собой роли и пишем "система должна позволять Продавцу выполнять..." или "Продавец должен иметь возможность выполнить..."
Точка зрения одна, конструкции отличаются - обстоятельства, культура и т.п. все знают что мы описываем поведение с точки зрения пользователя. При этом очень тяжело убрать контекст системы, ибо если она уже есть стоит очень больших усилий заставить мыслить всех вне ее рамок. А формулируем ли мы требования в каком-то одном из вышеприведенных стилей (так привыкли, или положено у нас так писать), или микс... если культура изложения слабовата.
а кто считал статистику? - что чаще а что реже, этого невооруженным взглядом увы невидно.



Re: Классификация требований Ответ #25 : 03 Мая 2013, 22:36:06
Эд, фреймворк - это не заказная разработка, это скорее продуктовая разработка. Весь вопрос в том, что используется для описания требований к нему и с какой степенью детализации эти требования нужно представить.
Правильно ли я понимаю, что ТЗ имеет смысл формировать только для заказной продукции. А фреймвёрк таковым не будет? Хотя в моем случае как раз каркас и заказывался.



Re: Классификация требований Ответ #26 : 06 Мая 2013, 23:00:03
Юр, смею заметить что не только точка зрения с которой формулируются требования влияет на словесную конструкцию. Допустим мы берем точку зрения пользователя. Мы можем таскать его везде за собой "система должна позволять пользователю выполнять..." или мы убрали пользователя "система должна позволять выполнять..." (держим пользователя "в уме"), или "пользователь должен иметь возможность..."  или мы таскаем за собой роли и пишем "система должна позволять Продавцу выполнять..." или "Продавец должен иметь возможность выполнить..."
Точка зрения одна, конструкции отличаются - обстоятельства, культура и т.п. все знают что мы описываем поведение с точки зрения пользователя. При этом очень тяжело убрать контекст системы, ибо если она уже есть стоит очень больших усилий заставить мыслить всех вне ее рамок. А формулируем ли мы требования в каком-то одном из вышеприведенных стилей (так привыкли, или положено у нас так писать), или микс... если культура изложения слабовата.
а кто считал статистику? - что чаще а что реже, этого невооруженным взглядом увы невидно.

Илья, очень правильный и потенциально ожидаемый вопрос, рад что он был именно от тебя! Если таки поставить во главу угла (по аналогии с архитектурным проектированием) именно точку зрения, и плясать от нее явно, иными словами, не усложнять ее разными конструкциями, а взять за правило явно эту точку зрения отражать в конкретном типе требований посредством конкретных конструкций (аналитики, в конце концов, и должны уменьшать энтропию :-)), то выстроится вполне себе стройная система требований. Иначе будем получать мешанину ... уж если отражаем пользовательские требования - то пишем либо юзкейсы, либо "<Роль/Пользователь> должен иметь возможность ..." и далее в терминах пользователя смотрим на систему. В этом случае очень легко вводить роли и описывать требования в терминах возможностей делать что-то важное для пользователей. Иначе, если говорим про функциональные требования (в терминах Вигерса), то введение ролей нам никак не мешает ... мы можем СГРУППИРОВАТЬ требования, написанные с т.з. системы, по системным ролям (конечно, если к этому моменту они явно определены). При этом, выбор в каком виде нам писать требования - как раз зависит от ТИПА разрабатываемой системы (автоматизация бизнес-деятельности, фреймворк или иная продуктовая разработка). Культура организации - конечно фактор, но это software, а не hardware ... и она может быть изменена, если новая культура более "прогрессивна" что ли ... (в т.ч. с экономической т.з)

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

По поводу статистики - я конечно же основываюсь на том, с чем мне приходилось работать (не обязательно что я делал "с нуля" ...) или с тем, что я видел в открытых источниках. Допускаю, что у других коллег, может быть "своя статистика" ... свести бы "эти статистики" - вполне себе исследовательская задачка и даже тема для диплома (анализ качества описания требований )... :-)
"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: Классификация требований Ответ #27 : 07 Мая 2013, 23:02:04
У нас еще был любопытный случай - гибкая подсистема настройки прав доступа  в системе. и мы таки "таскали" слово "пользователь", а роли и права на операции были в документе который назывался "Deployment Plan". ну это я так, просто для примера.



Re: Классификация требований Ответ #28 : 07 Мая 2013, 23:19:06
У нас еще был любопытный случай - гибкая подсистема настройки прав доступа  в системе. и мы таки "таскали" слово "пользователь", а роли и права на операции были в документе который назывался "Deployment Plan". ну это я так, просто для примера.

В данном случае у вас нет ролей как таковых (за исключением наверное Админа системы) до момента деплоймента этой системы. Так что вполне нормально использовать универсальную роль "Пользователь" или еще как-нибудь ее назвать. Только единственно, я бы определил в Глоссарии что мы понимаем под этой ролью.
"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: Классификация требований Ответ #29 : 07 Мая 2013, 23:44:51
Админ тоже роль, такая же как и все остальные. Одного админа создали через базу, чтобы дальше супорт мог пользоваться UI для раздачи остальных прав, так что с точки зрения требований, Админ такой же Пользователь.




 

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