Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Тема начата: Михаил Курбасов от 26 Сентября 2007, 18:32:53
-
Коллеги, вопрос к сообществу состоит в следующем:
Какими методами проверки качества требований вы пользуетесь на практике?
Теоретические вопросы качества требований вполне хорошо изложены в литературе, в т.ч. краткая выжимка по теме качества есть и на данном сайте: http://www.uml2.ru/index.php?option=com_smf&Itemid=45&topic=341.0 (http://www.uml2.ru/index.php?option=com_smf&Itemid=45&topic=341.0)
Однако теория - теорией, а что в жизни? Вот приходит некий аналитик и говорит: "Я провел обследование заказчика и написал ТЗ". Как вы на практике решаете вопрос, как понять, это хорошее ТЗ или не очень?
Предвижу такой вариант ответов - дать кому-нибудь прочитать и согласовать (заказчику, техническому менеджеру, ведущему разработчику, привлеченному эксперту). Для тех, кто так делает, сразу два дополнительных вопроса:
а) как вы учитываете/боретесь с возможным субъективизмом согласующего?
б) как вы учитываете/боретесь с возможной незаинтересованностью согласующего (как бы он ни читал, ответственность-то все равно на аналитике)?
Или, может, еще что-то используете?
-
Я занимался экспертизой ТЗ как архитектор. Задача поступала от моего руководителя, ему я сдавал отчёт, он с чем-то соглашался или несоглашался и добавлял своё.
Но это фактически было только согласование технических требований, функциональные мы в принципе согласовывать не имели права, хотя постоянно в документах были явные проблемы с целеполаганием и подложенными под него функциональными требованиями, о чём приходилось заявлять так или иначе.
-
Пользователям, согласующим ТЗ можно пригрозить, что то, что они сейчас согласуют, в том работать и будут потом.
Не получается так, что запуганные пользователи после этого затягивают согласование до бесконечности, и пытаются впихнуть в ТЗ все, что нужно и что не нужно, лишь бы, не дай бог, не осталось что-то за кадром, что может понадобиться, даже и чисто гипотетически?
-
....Вот приходит некий аналитик и говорит: "Я провел обследование заказчика и написал ТЗ". Как вы на практике решаете вопрос, как понять, это хорошее ТЗ или не очень?
....
....ответственность-то все равно на аналитике)?
Пожалуйста, не могли бы Вы уточнить:
Насколько я понял - Аналитик (который писал ТЗ) - специалист Исполнителя.
Согласующий (с субъективизмом которого нужно разобраться) - специалист Заказчика или Исполнителя?
В Вашей практике ответственность за содержание (написание) технического задания в большей степени лежит на Исполнителе, а не на Заказчике системы?
-
Не получается так, что запуганные пользователи после этого затягивают согласование до бесконечности, и пытаются впихнуть в ТЗ все, что нужно и что не нужно, лишь бы, не дай бог, не осталось что-то за кадром, что может понадобиться, даже и чисто гипотетически?
А это зависит от выбранной модели жизненного цикла. Если модель каскадная (сначала собираем все-все-все требования, а после этого начинаем разработку и требования больше не меняем), то могут и запугаться.
Если пользователи (точнее, заказчики) знают, что модель позволяет им добавлять или изменять требования в процессе разработки, то нужно это им объяснить. Но последовательность этапов разработки или итераций должна быть определена достаточно чётко, чтобы они не вообразили, что могут менять требования туда-обратно в любой момент с немедленным результатом.
-
ревью архитектора, r&d и v&v + итеративный подход
-
Пожалуйста, не могли бы Вы уточнить:
Насколько я понял - Аналитик (который писал ТЗ) - специалист Исполнителя.
Согласующий (с субъективизмом которого нужно разобраться) - специалист Заказчика или Исполнителя?
В Вашей практике ответственность за содержание (написание) технического задания в большей степени лежит на Исполнителе, а не на Заказчике системы?
Насчет ответственности - да, в нашей практике именно так.
Насчет субъективизма, поясню вопрос. Человек, который согласует документ требований, может сказать, что "как же вы не учли то-то и то-то, это очень важно!", и настоит, чтобы эти требования, которые он считает важными, были добавлены. Однако, где гарантия, что это действительно важные требования для всех пользователей, а не только его личные пристрастия? Тут, по опыту, не принципиально, будет ли данный "эксперт" со стороны заказчика или со стороны исполнителя. Такие сюрпризы могут быть и в том, и в другом случае. Есть ли у вас silver bullet для таких случаев?
-
Насчет ответственности - да, в нашей практике именно так.
Насчет субъективизма, поясню вопрос. Человек, который согласует документ требований, может сказать, что "как же вы не учли то-то и то-то, это очень важно!", и настоит, чтобы эти требования, которые он считает важными, были добавлены. Однако, где гарантия, что это действительно важные требования для всех пользователей, а не только его личные пристрастия? Тут, по опыту, не принципиально, будет ли данный "эксперт" со стороны заказчика или со стороны исполнителя. Такие сюрпризы могут быть и в том, и в другом случае. Есть ли у вас silver bullet для таких случаев?
Ситуацию, при которой Исполнитель вынужден отгадывать желания пользователя и нести ответственность за правильность такого отгадывания нельзя признать нормальной. Если система нужна Заказчику то он по крайней мере должен нести ответственность за то, что он постарался быть правильно понятым Исполнителем.
Характерна ситуация с закупкой (созданием) системы для крупной (государственной) организации. Обычно Исполнитель выбирается по конкурсу (возможность конкретного Исполнителя "договориться" с Заказчиком и пр. "обходные пути" пока не обсуждаем - рассмотрим схему в принципе).
Конкурс выполняется на основании требований Заказчика (фактически - ТЗ).
ТЗ для конкурса пишется Заказчиком или по отдельному договору сторонней организацией, которая не обязательно будет Исполнителем проекта. Заказчик (принимающий работы по написанию ТЗ) целиком несет ответственность за то, под чем он подписался, принимая ТЗ.
Потом объявляется конкурс и Исполнители обязаны выполнять то, что написано в ТЗ.
С точки зрения Исполнителя важно, чтобы в ТЗ не появлялись требования, которые:
1. взаимно противоречат друг другу или не могут быть реализованы по чисто техническим (физическим) причинам и в требуемые сроки, с прибылью.
2. были настолько расплывчаты, что под них на приемочных испытаниях может быть подведено все, что угодно. Требования (функции) должны быть "проверябельны". Например, важно, чтобы результат работы функции можно было продемонстрарировать средствами штатного интерфейса, без "выковыривания" результата хитрыми запросами средствами нештатного ПО, установленного на компьютере на время испытаний.
Если Заказчик "навертел" в ТЗ "бантиков", которые пользователям не нужны, то пытаться помешать этому важно, если это создает перечисленные ваше риски для Вас:
1. "бантики" делают для Вас проект убыточным (при уже согласованной сумме договора)
2. на стороне Заказчика есть пользователи прямо незаинтересованные в реализации некоторых функций ("бантиков"). В результате внутренних раздоров у Заказчика Вам устраивают проблемы при испытаниях по приведенному выше п.2
3....
Странно, если согласующий пытается сам вставить в ТЗ какую-нибудь отсебятину, обычно он все-таки отсылает вниз, к конкретным пользователям системы и визирует только то, что они уже подписали. В крупных организациях в ТЗ в конце есть лист согласований, пока там все не подпишутся, большие начальники на титульном листе свою подпись не поставят.
-
Заказчик (принимающий работы по написанию ТЗ) целиком несет ответственность за то, под чем он подписался, принимая ТЗ.
Как говорил один наш заказчик, "ну и что, что я подписал ТЗ?! моя подпись на документе не означает, что мы теперь не можем ничего изменить".
Это я к тому, что вы можете, конечно, считать, что Заказчик "целиком несет ответственность за то, под чем он подписался". Но я ставил вопрос немного по-другому, как проверить качество требований? Если мы написали плохие требования, и каким-то образом добыли подпись заказчика под этими требованиями, то они от этого не станут качественными. И можно, наверное, сделать дальше кривую систему по кривым требованиям, прийти к заказчику и заявить: "это ты сам так хотел, вот твоя подпись". Но я не думаю, что это хорошая ситуация, и что нам надо стремиться именно к этому. Все-таки правильнее, на мой взгляд, сначала самим убедиться, что требования, которые мы сделали, - качественные, и уже тогда с чистой совестью идти визировать. Вот как это проверить, в этом и вопрос.
-
Как говорил один наш заказчик, "ну и что, что я подписал ТЗ?! моя подпись на документе не означает, что мы теперь не можем ничего изменить".
Это я к тому, что вы можете, конечно, считать, что Заказчик "целиком несет ответственность за то, под чем он подписался".
Если Заказчик Вам такое заявил - плохо дело. Как правило, такие заявления - это начало конца (провала) проекта. С безответственными людьми нельзя работать. Если уж человек не держит письменно зафиксированных обещаний, то что уж говорить о том, как он выполняет устные договоренности (которые неизбежно возникают в любом проекте)! Можно обсуждать необходимость дополнений к ТЗ, и это должно зависеть от доброй воли обеих сторон... Но просто отказываться от своих обязательств - это совсем беда.
Но я ставил вопрос немного по-другому, как проверить качество требований? Если мы написали плохие требования, и каким-то образом добыли подпись заказчика под этими требованиями, то они от этого не станут качественными.
Тут вопрос - с чьей точки зрения требования "плохие". Для Заказчика они могут быть очень даже хорошие а для Исполнителя просто нереалистичные. И наоборот. И по жизни потом можно услышать: "Мы сделали Заказчику такую суперсистему, такие передовые решения применили, а они (Заказчики) такие тупые, ну никак не научатся на ней правильно работать. Требования элементарные, в ТЗ записанные, не соблюдают...." . А Заказчик жалуется: "Тут мне ребята систему сделали. Умные ребята, но в нашем деле ничего не понимают. Наш опыт и знания ни во что не ставят. Простые вещи сделали сложно, требования наши просто, похоже, не понимают... Вот поработали бы с мое лет 20 в нашей отрасли, а потому уже учили всех, что требуется".
И можно, наверное, сделать дальше кривую систему по кривым требованиям, прийти к заказчику и заявить: "это ты сам так хотел, вот твоя подпись". Но я не думаю, что это хорошая ситуация, и что нам надо стремиться именно к этому. Все-таки правильнее, на мой взгляд, сначала самим убедиться, что требования, которые мы сделали, - качественные, и уже тогда с чистой совестью идти визировать. Вот как это проверить, в этом и вопрос.
Если Вы формулируете требования, которые должны быть качественными с точки зрения Заказчика, то то, что конкретный Заказчик считает правильным, то и будет качественными требованиями. Без итерационного уточнения позиции Заказчика по этому вопросу как правило, обойтись не удается. Вы полагаете, что можно сделать хорошую систему в рамках конкретного проекта для конкретного Заказчика вопреки его косноязычию и изменчивости его позиции? Или ставится цель выполняя конкретный проект фактически реализовать систему "не для этого Заказчика", а для тех, кто сможет её по настоящему оценить (для рынка)?
-
Вы полагаете, что можно сделать хорошую систему в рамках конкретного проекта для конкретного Заказчика вопреки его косноязычию и изменчивости его позиции?
Ну, в общем, да. Я полагаю, что трудно, но принципиально это возможно. И в изменчивости позиции ничего криминального, в общем, нет. Вам разве не приходилось никогда в жизни понимать, что то, в чем вы были так уверены когда-то, на самом деле было ошибкой?
Если Вы формулируете требования, которые должны быть качественными с точки зрения Заказчика, то то, что конкретный Заказчик считает правильным, то и будет качественными требованиями.
С этой позицией я бы не согласился. Задача аналитика не сводится к тому, чтобы быть ходячим диктофоном. Надо информацию не только записывать, но и анализировать. Например, "конкретный заказчик" может считать правильным что-то, что противоречит законодательству (при этом он может считать тех, кто этот закон разрабатывал, недоумками, не знающими жизни, ну и т.п.). Разве это будет достаточным основанием делать систему, которая нарушает требования законодательства?! А если требования, которые выдвигает "конкретный заказчик 1" противоречат требованиям, которые выдвигает "конкретный заказчик 2", то что? Соответствие чьим словам будет тогда критерием качества?..
-
Ну, в общем, да. Я полагаю, что трудно, но принципиально это возможно.
Вы не могли бы попытаться сформулировать какие именно трудности Вас ожидают при попытке создать хорошую систему при отсутствии внятного Заказчика?
Насколько общим является ваше утверждение о возможности создания такой системы?
1. Относится ли оно преимущественно к системам для которых знание специфики конкретной предметной области не очень существенно (типа операционных систем)?
2. Или Вы полагаете, что, например, можно создать хорошую ERP-систему честно отрабатывая изменяющиеся требования Заказчика в процессе реализации проекта и не будучи до конца уверенными, что Вы его правильно пониматете из-за его косноязычия?
И в изменчивости позиции ничего криминального, в общем, нет. Вам разве не приходилось никогда в жизни понимать, что то, в чем вы были так уверены когда-то, на самом деле было ошибкой?
Не стоит так расширять контекст начального обсуждения. Речь шла не об ошибках, а об ответственности человека за его обязательства перед другими людьми. Составлено ТЗ, Заказчик его утвердил, взял на себя юридически значимые обязательства, Исполнители вложили деньги в проект, идет разработка, а Заказчик вдруг заявляет: "Я передумал. Так делать не будем. Я типа ошибся".
Существенно, каким именно образом стороны выходят из ситуации, когда нужно вносить изменения в ТЗ. Во всяком случае недопустимо, чтобы Заказчик принимал решение сам о праыке ТЗ как он хочет и когда хочет, да еще если такое положение просачиватся в условия договора. А если Заказчик действует вопреки условиям договора можно ли не считать его действия криминалом?
С этой позицией я бы не согласился. Задача аналитика не сводится к тому, чтобы быть ходячим диктофоном. Надо информацию не только записывать, но и анализировать. Например, "конкретный заказчик" может считать правильным что-то, что противоречит законодательству (при этом он может считать тех, кто этот закон разрабатывал, недоумками, не знающими жизни, ну и т.п.). Разве это будет достаточным основанием делать систему, которая нарушает требования законодательства?!
Мое утверждение, с которым Вы не согласились, не случайно начиналось словами "если Вы формулируете требования, которые должны быть качественными с точки зрения Заказчика". Можно попытаться сконструировать "групповой критерий" правильности: "Правильно то, с чем согласны и Заказчик и Исполнитель". Но надо быть готовым, что при таком критерии "правильное ТЗ" достижимо не всегда. Не достигли консенсуса - проект прекращается, Заказчик и Исполнитель разбегаются в разные стороны.
Кроме того, Вы ранее писали - "Все-таки правильнее, на мой взгляд, сначала самим убедиться, что требования, которые мы сделали, - качественные". Если исходить из "группового критерия", не могли бы Вы уточнить - проблема в том, что
1. Вы затрудняетесь сформулировать (в части "...убедиться") , что является правильным с Вашей (Исполнителя) точки зрения для данного проекта?
2. Или в том, что Вы выдвигаете требования (строго соответствия законодательству), с которыми Заказчик заведомо не согласится?
А если требования, которые выдвигает "конкретный заказчик 1" противоречат требованиям, которые выдвигает "конкретный заказчик 2", то что? Соответствие чьим словам будет тогда критерием качества?..
Это большая беда. У проекта должен быть один Заказчик. Процесс "приведения к общему знаменателю" подчиненных Заказчика происходит в любом проекте и не всегда с привлечением Большого Начальника Заказчика. Но если Вы хотите иметь гарантированный результат в проекте, в который Вы вкладываете деньги, у Заказчика должен быть один Большой Начальник. Он нужен, по крайней мере, для принятия решений, когда возможности компромисса между его подчиненными исчерпаны. Принцип единоначалия, сформулированный Файолем еще в 19 веке, никому отменить пока не удалось.
-
Отвечая на корневой вопрос ...
1. Требования к ПО это всегда субъективная оценка в той или иной степени. Прежде чем говорить о качетсве требований, нужно как минимум определить что мы под ним подразумеваем в данном конкретном случае.
2. "Хорошие" требования, это те которые отражают все проанализированные потребности пользователя и которые ДОВЕДЕНЫ до заказчика как правило проактивным способом.
3. Именно поэтому рулят agile методы и интерационность, причем крайне желательно чтобы еще и на пару с time&materials, чтобы заказчик чуствовал ответственность за свои решения.
4. Подписанное ТЗ отнюдь не гарант неизменности ... ставить заказчика в тупик тем что подписали и все, никаких изменений - глупо. Просто изменения должны быть контролируемыми и просчитанными с т.з. оценки стоимости.
-
<...>Какими методами проверки качества требований вы пользуетесь на практике?<...>
До разработки - отправляем требования на пересмотр лояльным представителям заказчика, собственным внедренцам, другим системным аналитикам, менеджеру проекта и архитектору, которым предстоит их реализовывать. Почти всегда должны присутствовать нефункциональные требования относительно определённых аспектов ПО. Если требования касаются архитектуры и реализации - это вызывает дополнительные вопросы, действительно ли заказчик хочет так, или это системный аналитик полез не в своё дело. PM замечательно может отсечь требования, выходящие за рамки системы, и "бантики", а архитектор и ведущие программисты - увидеть нереализуемые требования и требования, необоснованно ограничивающие реализацию.
Конечно, для этого требования должны быть максимум на 30 страниц 10-го Times New Roman, быть чётко структурированными не более, чем на 3-х уровнях, и изложенными языком, понятным нетехническим специалистам, знакомым с предметной областью. Ещё в них должно быть минимум ссылок на другие требования.
Во время разработки - следим за вопросами, которые возникают у архитекторов, программистов и тестировщиков (да, писать тестовые последовательности задолго до разработки у нас не получается). И следим за количеством изменений в требованиях, которые исходят от заказчиков и внедренцев. Если вопросов или изменений слишком много - улучшаем требования, вызывающие их.
После разработки - проверяем состояние своего счёта :) .
-
...не могли бы Вы уточнить...
Уважаемый Shur! Мне кажется, Вы хотели бы подискутировать на тему "ответственность Заказчика vs ответственность Исполнителя". Я понимаю, что это важная тема, и в другой ветке форума готов был бы продолжить данный диалог. Но здесь я задавал исходный вопрос немного по-другому. По теме "можно ли считать подпись Заказчика достаточным критерием качества ТЗ?" Вы свою точку зрения высказали, я свою - тоже. Стало понятно, что у нас с Вами разные точки зрения... :)
-
По моему должна быть такая проверка:
1. Эксперт по качеству/тестированию, кот. проверяет полноту ТЗ и соответствие ТЗ принятым нормам, да и хотя бы что бы было понятно, что аналитик имел ввиду.
2. Архитектор/ст. разработчик, кот. проверяет на реализуемость
3. Специалист ИТ, кот. проверяет не функциональные требования
4. Заказчик, кот. проверяет на свои хотелки.
5. Ну и по желанию спец по ГУИ
-
2 All: Я так понял, что экспертное вычитывание рулит.
Однако, как вы учитываете возможный субъективизм вычитывающего?
Мы, что греха таить, регулярно на эти грабли наступаем... В новой для себя предметной области, где мы далеко еще не эксперты, привлечение внешних консультантов для вычитки ТЗ зачастую приводит к тому, что помимо указания на наши явные ляпы (за что, конечно, спасибо!) эксперты привносят некоторые новые требования, которые впоследствии оказываются, к сожалению, ничем иным, как личными, субъективными пожеланиями данного конкретного эксперта. Вносятся эти требования, разумеется, из сугубо благих намерений ("чтобы делать систему не вчерашнего дня, а современную, передовую"), вот только внедрить этот фукционал потом крайне трудно, если не невозможно. Эксперт с грустью констатирует, что "пользователи пока не готовы" к его передовым идеям. А мы сидим и думаем, "ну и зачем это надо было???". Потом - очередная новая предметная область, очередной новый эксперт, и все снова...
Кто-нибудь имеет успешный опыт избегания таких проблем?
-
Михаил, ну а Вы на что?? Или Вы слепо принимает, что скажет эксперт/заказчик/архитектор? А у вас не было ситуации, что Архитектор/ст разработчик говорит, что это не возможно сделать, а заказчик хочет?? Что Вы делаете в этой ситуации?? Либо бьете архитектора, что он лентяй, либо говорите заказчику, что будет это стоить в два раза больше.
З.Ы. От полного субъективизма Вы не уйдете. Это как в программирование, одно и то же можно реализовать 10ью способами, чем квалифицированнее программист или его контролирующий программист, тем он это сделает оптимальнее, но не идеально.
-
Boatman, семь бед - один ответ )
-
Мне понравилась мысль boatman'a о трассировании требований к целям как о методе проверки необходимости требований. Правда, встает вопрос о качестве и адекватности описания целей...
Мне приходилось от весьма опытных и успешных менеджеров слышать что-то вроде: "главное, определиться с техничнскими требованиями, что нам сделать надо, а цели можно откуда-нибудь скопипастить, их все равно никто не читает"...
-
Всем привет!
Коллеги, хочу с Вами посоветоваться.
А что если для проверки качества требований, описанных в техническом задании применить следующую модель:
1. Для каждого требования задать некоторые атрибуты качества, например, полнота,
непротиворечивость понятность, возможность реализации и тд.
2. Для каждого типа атрибута задать некоторые коэффициенты (вербальные или числовые).
Например. Атрибут "возможность реализации" имеет значения "возможно реализовать",
"не возможно реализовать", "возможно, но не полностью" и тд.
3. Человек, согласующий ТЗ, для каждого требования выбирает значение атрибутов качества
и добавляет комментарий (замечание, предложение и др.).
Разные люди (заказчик, системный архитектор) могут выставлять значения для разных атрибутов.
4. После того, как все атрибуты описаны, с помощью допустим алгоритмов нечеткой логики
или других механизмов обработать результаты полученных данных и для каждого требования
определить некий показатель качества. Например, требование UC234Регистрация
пользователя имеет показатель качества "70%" и выводы почему + комментарии.
5. Аналитик может за меньшее время оценить результаты и сделать выводы и если нужно внести
изменения.
Я конечно понимаю, что Вам может данная идея показаться бредовой :), но я хочу посоветоваться
имеет ли такая идея право на жизнь или не стоит об этом даже думать!
Пожалуйста, Ваша критика и замечания. 8)
-
Насколько я знаю, предлагаемые на рынке системы управления требованиями (например тот же RaQuest) имеет встрроенные системы расчета количественного показателя для требования, что входит в общую систему оценки. И в частности:
1. Для каждого требования задать некоторые атрибуты качества, например, полнота,
непротиворечивость понятность, возможность реализации и тд.
Такая возможность есть и она широко применяется на практике
2. Для каждого типа атрибута задать некоторые коэффициенты (вербальные или числовые).
Например. Атрибут "возможность реализации" имеет значения "возможно реализовать",
"не возможно реализовать", "возможно, но не полностью" и тд.
Именно так и делается
3. Человек, согласующий ТЗ, для каждого требования выбирает значение атрибутов качества
и добавляет комментарий (замечание, предложение и др.).
Разные люди (заказчик, системный архитектор) могут выставлять значения для разных атрибутов.
По поводу 1 это так, второе предложение тоже возможно, но оно будет заменять текущее значение на значение выставляемое проверяющим, и конечно будет отражать мнение этого проверяющего
4. После того, как все атрибуты описаны, с помощью допустим алгоритмов нечеткой логики
или других механизмов обработать результаты полученных данных и для каждого требования
определить некий показатель качества. Например, требование UC234Регистрация
пользователя имеет показатель качества "70%" и выводы почему + комментарии.
В принципе это и делается, хотя надо сказать не всегда это возможно. Хотя в одной книге предлагается широкое использование шаблонов формулировки требований
5. Аналитик может за меньшее время оценить результаты и сделать выводы и если нужно внести
изменения.
Думаю это возможно через обратную связь
-
1. На практике с требованием работает Аналитик (1 чел) + Заказчик (1-2 чел.) + Ревьюер (1 чел, и то не всегда). Как вы хотите получить качественную оценку от 2-3 человек?
2. Кто все это будет поддерживать и обновлять?