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

Дисциплины => Системный Анализ и Требования => Тема начата: Galogen от 04 Ноября 2007, 14:43:00

Название: Управление требованиями
Отправлено: Galogen от 04 Ноября 2007, 14:43:00
Хотел бы задать вопрос общественности форума, особенно той ее части, которая реально работает с требованиями на практике и имеет насущную потребность в управлении ими.

Что хотелось бы узнать:

Каким образом Вы управляете требованиями?

Что Вы понимаете под управлением требованиями?

Какие системы управления требованиями Вы пользуетесь и как?

Как обеспечивается управление требованиями в стиле прецедентов и стиле списков свойств системы?

Какой подход в формулировке требований Вы обычно используете: водопадный или итерационный?

Какое место занимает в Вашем случае моделирование?

Используете ли Вы для проверки и анализа требований имитационное или математическое моделирование?

Какие требования к системе управления требованиями Вы лично предъявляете?

Вот некоторые ссылки для затравки:
Обсуждение на форуме sql.ru (http://www.sql.ru/forum/actualthread.aspx?bid=58&tid=284045&pg=-1#2759094)
Статья "Управление требованиями и автоматизация этого процесса" (http://www.yurivolkov.com/articles/Requirements_management_automation_ru.html)
Новые приемы управления требованиями с помощью Rational RequisitePro: Часть 1. Использование архитектурных методов (http://www.ibm.com/developerworks/ru/library/ar-reqframe1/index.html)
Название: Re: Управление требованиями
Отправлено: bas от 04 Ноября 2007, 23:08:52
>> Что Вы понимаете под управлением требованиями?
>> Какие требования к системе управления требованиями Вы лично предъявляете?
1. Удобство ввода и учета требований
2. Присвоение атрибутов для требований
3. Трассировка требований между собой
4. Трасировка требований к задачам и наоборот
5. Трасировка требований к элемнтам модели и инаоборот
6. Шаблоны требований, документов, и т.д.
7. Генерация актуальных документов на основе репозитария требований

>> Каким образом Вы управляете требованиями?
>> Какие системы управления требованиями Вы пользуетесь и как?
Сейчас пытаемся внедрить Вики для УТ

>> Как обеспечивается управление ребованиями в стиле прецедентов и стиле списков свойств системы?
И так и так

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

>> Какое место занимает в Вашем случае моделирование?
ДВИ, ДС, Архитектура

>> Используете ли Вы для проверки и анализа требований имитационное или математическое моделирование?
нет
Название: Re: Управление требованиями
Отправлено: Galogen от 04 Ноября 2007, 23:58:23
Саша, спасибо за ответ. Однако если это не коммерческая тайна, хотелось бы по подробнее узнать о самой организации этого процесса., проблемах с которыми вы сталкиваетесь, с трудностями и конкретикой.
Например. Для сбора функциональных требований вы используете прецеденты. Как это делается, что первично, что вторично? Как это фиксируется, отслеживается, изменяется? Как их этого получаются нужные документы? Какие документы?
Фиксируете ли вы в репозитории видение и дополнительные требования, или фиксируете только спецификацию требований к ПО, а видение, прецеденты и т.п. являются первоисточниками?
Название: Re: Управление требованиями
Отправлено: bas от 05 Ноября 2007, 00:05:46
Мы учитываем все: и видение и непосредственные требования. Есть иерархия требований, где учитываются цели, проблемы, БТр (БВИ), СВИ, функц. и нефункц. требования.
Основные проблемы:
1. Трудно поддерживать трассировку
2. Трудно назначать атрибуты для требований
3. Нельзя трасировать требования к эл. моделям
Название: Re: Управление требованиями
Отправлено: Galogen от 05 Ноября 2007, 14:31:58
Мы учитываем все: и видение и непосредственные требования. Есть иерархия требований, где учитываются цели, проблемы, БТр (БВИ), СВИ, функц. и нефункц. требования.
Основные проблемы:
1. Трудно поддерживать трассировку
2. Трудно назначать атрибуты для требований
3. Нельзя трасировать требования к эл. моделям

А-ха. Трудности есть! Тот случай, который требует консилиума и выбора метода лечения.

1. В чем трудность поддержания трасировки? Трассировка между чем и чем, пожалуйста, поэлементно. Предлагаю взять за основу небольшой пример (кейс я предоставлю без проблем) и разыграть деловую игру. Понимаю не так много времени, но нас не должна тревожить точность требований, полнота их описания, а сам процесс!!!

2. Что значит трудно назначать атрибуты? В чем сложность?

3. Где нельзя трассировать требования к элементам моделей?
Название: Re: Управление требованиями
Отправлено: bas от 05 Ноября 2007, 22:30:14
1. Трассировка между требрваниями, т.е. ФТр1 следует из БТр1
2. Ну Тр могут иметь атрибуты (статус, сложность, приоритет и т.д.), так вот чтобы назначить эти атрибуты в Вики для требования (страница в Вики) нужно извратиться, причем отчет получить по требованиям (например сколько требований потвержденно) невозможно
3. В Вики нельзя, я сейчас говорю о ней. Хотя это тоже решается с помощью генеарции html страниц из модели (Rose, EA, Pasedon, ...) и вставки прямых ссылок на эти странички.
Название: Re: Управление требованиями
Отправлено: Galogen от 06 Ноября 2007, 08:13:48
Саша, тема, как мне думается , очень интересна многим.

Поскольку тут много профессионалов, но еще больше непрофессионалов и людей, возможно пытающихся ими стать, есть смысл обсудить это в деталях. Когда читаешь многие книги : Вигерса, Лиффенгуэлла или др. - много можно подчерпнуть, но не то как же это осуществялется на практике, от А до Я.

Ты пишешь - функциональные требования трассируются к бизнес-требованиям ибо их реализуют. А к чему трассируются бизнес-требования? Как эти требования получаются? Просто формируется список, на основании анализа первичных документов  (интервью, тех.документация, наблюдение etc)? Либо бизнес-требования формируются в ходе бизнес-моделирования?

Что значит формирование функциональных требования на основе бизнес-требований? В каком виде формируются функциональные требования? Если функциональные требования в основном фиксируются в виде прецедентов - как организовано у вас документирование и моделирование? Прецеденты являются лишь основанием для формирования списка требований или сами позиционируются как требования?
Название: Re: Управление требованиями
Отправлено: Григорий Печенкин от 06 Ноября 2007, 15:34:02
Хотел бы задать вопрос общественности форума, особенно той ее части, которая реально работает с требованиями на практике и имеет насущную потребность в управлении ими.

Я реально работаю с требованиями, и в нашей полсотне проектов есть роль "Аналитик", которую делят примерно поровну два человека. При этом значение слов "Требования" и "Аналитик" понимаю, пожалуй, только я, причём не факт, что правильно. :)

На самом деле, "управление требованиями" у нас в зачаточном состоянии, хотя раздел "Требования" в нашем внутреннем трекере задач существует уже года два. Ситуация такая: специального образования аналитика ни у кого нет, я пытаюсь быть локомотивом внедрения более-менее внятных подходов к разработке. Собственно, это в моих интересах и входит в мои обязанности. :)


Каким образом Вы управляете требованиями?

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

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

Использование трекера пока не является обязательным, но "настоятельно рекомендуется". Постепенно все привыкают к тому, что это удобно.

Что Вы понимаете под управлением требованиями?

Учёт и отслеживание выполняемости. Это если в двух словах.

Какие системы управления требованиями Вы пользуетесь и как?

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

Самые очевидные недостатки, которые будем исправлять в ближайшее время:
- отсутствует автоматическая трассировка требований на тесты и релизы - требования хранятся "сами по себе", без связи с другими объектами учёта;
- при изменении требований не сохраняются старые версии.


Как обеспечивается управление требованиями в стиле прецедентов и стиле списков свойств системы?

Никак не обеспечивается, и необходимость в этом пока не обнаруживалась.

Какой подход в формулировке требований Вы обычно используете: водопадный или итерационный?

Даже слов таких не знаю. :) То есть слова знаю, но применительно к разработке программ, а не формулировке требований.

Какое место занимает в Вашем случае моделирование?

Последнее. Максимум, что иногда используем - подобие диаграммы развёртывания при объяснениях с заказчиком. Иногда, в сложных для понимания вопросах, используем диаграммы состояний "на салфетках", которые после обсуждения выбрасываются.

Чаще всего используются старые добрые блок-схемы алгоритмов, в том числе в тех ситуациях, где вроде бы самое подходящее место для вариантов использования.

Используете ли Вы для проверки и анализа требований имитационное или математическое моделирование?

Нет.

Какие требования к системе управления требованиями Вы лично предъявляете?

В двух словах не выразить, а на подробное изложение сейчас нет времени.
Название: Re: Управление требованиями
Отправлено: Galogen от 06 Ноября 2007, 16:27:13
Спасибо за развернутый ответ и подробные комментарии.

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

Цитировать
Никак не обеспечивается, и необходимость в этом пока не обнаруживалась.
А  в чем нет необходимости

в ведении требований по прецедентам? (тут я понял Вы прецеденты используете мало или вообще не используете. Это может быть вполне обусловлено решаемыми задачами. По крайней мере Лифеннгуэлл пишет об этом достаточно подробно).

или и в ведении списков свойств системы? т.е. вы никак не фиксируете требования?

Цитировать
Даже слов таких не знаю. :) То есть слова знаю, но применительно к разработке программ, а не формулировке требований.
Тут имелось в виду сам способ разработки. сначал требования кровь из носу, потом проект и реализация. Либо все в перемежку по спирале?

Цитировать
Последнее. Максимум, что иногда используем - подобие диаграммы развёртывания при объяснениях с заказчиком. Иногда, в сложных для понимания вопросах, используем диаграммы состояний "на салфетках", которые после обсуждения выбрасываются.
Ну нормальной гибкий подход :) А если решение удачное, репозиторий не ведёте?

Цитировать
Чаще всего используются старые добрые блок-схемы алгоритмов, в том числе в тех ситуациях, где вроде бы самое подходящее место для вариантов использования.
А например?

Название: Re: Управление требованиями
Отправлено: Григорий Печенкин от 06 Ноября 2007, 17:07:30
А  в чем нет необходимости

в ведении требований по прецедентам? (тут я понял Вы прецеденты используете мало или вообще не используете. Это может быть вполне обусловлено решаемыми задачами. По крайней мере Лифеннгуэлл пишет об этом достаточно подробно).

Вот только не надо меня своей бандой пугать. :)

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

Тут имелось в виду сам способ разработки. сначал требования кровь из носу, потом проект и реализация. Либо все в перемежку по спирале?

Наша ситуация примерно описана вот здесь:
http://www.uml2.ru/forum/index.php?topic=219.msg4016#msg4016

С августа не очень много изменилось, но какие-то подвижки, конечно, есть.

Ну нормальной гибкий подход :) А если решение удачное, репозиторий не ведёте?

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


А например?

Порылся в документах, не нашёл.

Зато нашёл вот такую диаграмму в концептуальном документе. Просто для иллюстрации. Интересно, если использовать только UML, какая диаграмма здесь должна быть и как она выглядела бы?

(http://www.greesha.ru/Files/Encryption.jpg)
Название: Re: Управление требованиями
Отправлено: Galogen от 06 Ноября 2007, 18:52:09
Вот только не надо меня своей бандой пугать. :)
Да Лиффенгуэлл вроде не из банды. Он вроде сам по себе, хотя и о том же...

Цитировать
прецеденты (не люблю я это слово)

Мне тоже не совсем нравится. Просто слово компактнее варианта использования

Цитировать
Зато нашёл вот такую диаграмму в концептуальном документе. Просто для иллюстрации. Интересно, если использовать только UML, какая диаграмма здесь должна быть и как она выглядела бы?
[skip] тут диаграмма смотри в предыдущем посте [/skip]
Диаграмму такую сделать наверное возможно. Она как я понял отражает некий объектный поток наложенный на красивую картинку размещения. В принципе такие картинки UML-CASE позволяют сделать например с использованием activity diagram или communication diagram
Название: Re: Управление требованиями
Отправлено: bas от 07 Ноября 2007, 11:29:23
Гриша,

Просто надо всех заставить говорить только на ЮМЛ, тогда и будут все картинки в ЮМЛ, а не художественные изыски (это к теме про безмолвное моделирование)
Название: Re: Управление требованиями
Отправлено: Григорий Печенкин от 07 Ноября 2007, 12:48:26
Просто надо всех заставить говорить только на ЮМЛ, тогда и будут все картинки в ЮМЛ, а не художественные изыски (это к теме про безмолвное моделирование)

А зачем? По этой картинке ни у одного из клиентов не возникало вопросов.
Название: Re: Управление требованиями
Отправлено: bas от 07 Ноября 2007, 13:05:49
Я не хочу спорить в этой теме, т.к. отклоняемся от темы дискуссии, но скажу последнее слово:
Нотации и придуманы для того, чтобы все говорили на одном языке. Данная картинка получилась удачная, но где гарантия того, что др. человек не будет рисовать просто красивые, а не смысловые картинки, с помощью непонятных символов.
Название: Re: Управление требованиями
Отправлено: Gevorg от 07 Ноября 2007, 17:18:35
Хотел бы задать вопрос общественности форума, особенно той ее части, которая реально работает с требованиями на практике и имеет насущную потребность в управлении ими.
Мне повезло на прошлой работе в этом смысле:
- Софтовая фирма,
- один постоянный Заказчик,
- основная масса работ - сопровождение унаследованного ПО,
- ПО реально необходимо, активно и широко используется,
- требования на доработки поступают постоянно и в большом количестве,
- сроки их реализации очень жёсткие,
- ситема большая, досталась в наследство от нескольких компаний-разработчиков,
- сотавляющие компоненты разнородные по всем направлениям: среда разработки, культура разработчиков, архитектурные принципы,
- что их объединяет: общий заказчик-потребитель, общая предметная область, общий на данный момент разработчик,
- но сами требования на доработку достаточно простые и маленькие по объёму.

От руководства пришло задание: сконструировать и внедрить автоматизированный процесс управления всем этим зверинцем.
StarTeam и Caliber, как инструменты, были в качестве необсуждаемой данности.

3 месяца укрощения средств и войны с партизанскими инициативами от местных очень активных и не менее дремучих аналитиков дали кучу интересных результатов.
Работа для меня была очень интересная, рассказывать можно много, пока приведу тезисы, в порядке их всплывания в памяти.

1. Опытно проявилась правильность принципа из CMMi: управление требованиями осваивается на ступеньку раньше, чем дизайн требований.
процесс управления требованиями уже был поставлен и даже был принят аналитиками, а до толкового дизайна, тем более - с использованием диаграмм, - было ещё ой как далеко.
Самое кино было в том, что наиболе резвые из аналитиков ухватились за Caliber, как за свой родной инструмент, и давай его активно применять для всего, чего угодно, кроме главного: дизайна требований.
Ладно,управление требованиями, - это родное,
но умудриться притянуть за уши Caliber для менеджмента проектных задач, учёта трудозатрат исполнителей и в качестве системы управления версиями всех артефактов - это уже было слишком.
Ещё раз, "опыт военных действий" подтверждает теорию: менеджмент требований осваивается раньше, чем дизайн оных.

2. Без системы управления версиями реального мнеджмента требований - нет, есть только игрушка.
Версионность требования - раньше трассировки.

3. Трассировка между требованиями - задача менее приоритетная,
чем трассировка от требования - к коду и тест-кейсу, которые это требование закрывают и проверяют,
и к проектным задачам, имеющим какое-то отношение к требованию.

4. Заявленная Борландом совместимость приобретённых продуктов для пресловутой полной поддержки цикла ALM на деле имеет кучу хомутов и граблей.
Нужно крепко исхитриться, чтобы заставить эти средства (в моём случае: StarTeam, Caliber, Delphi, MS-Project) согласованно работать по обеспечению цикла разработки ПО.

5. Если задачу версионного управления и трассировки более-менее удалось решить родными Борландовскими средствами, то задачи отчётности без примочек-доработок оказались практически НЕ решаемыми.
Спрашивал у знающих людей из Питера - они тоже с этим намучились.

6. Те же знающие люди рассказывали легенды про решение аналогичной мощности на базе интеграции СабВершин-Джира-Телелоджик Дорз.
Но доработки по обеспечению этой интеграции обошлись компании в хорошую копеечку.
Название: Re: Управление требованиями
Отправлено: bas от 07 Ноября 2007, 18:04:56
Gevorg,

Надеюсь, Вы присоединитесь к нашему ноябрьскому семинару и поделитесь своим опытом во время дискуссии.
Название: Re: Управление требованиями
Отправлено: Gevorg от 07 Ноября 2007, 19:44:37
Gevorg,
Надеюсь, Вы присоединитесь к нашему ноябрьскому семинару и поделитесь своим опытом во время дискуссии.
Дак я ж в Киеве работаю :-(
Название: Re: Управление требованиями
Отправлено: bas от 07 Ноября 2007, 19:49:26
Жаль.
Дак я ж в Киеве работаю :-(
Жаль... Надо делать транслирование через веб, а то много народу из др. городов остается не охваченным
Название: Re: Управление требованиями
Отправлено: Galogen от 07 Ноября 2007, 20:24:21
Интересный опыт. Gevorg

2. Без системы управления версиями реального мнеджмента требований - нет, есть только игрушка.
Версионность требования - раньше трассировки.
насколько я понимаю - это фиксация baseline? Если да например в RaQuest есть такой инструмент как сохранения таких baselines и версионный контроль.

Цитировать
3. Трассировка между требованиями - задача менее приоритетная,
чем трассировка от требования - к коду и тест-кейсу, которые это требование закрывают и проверяют,
и к проектным задачам, имеющим какое-то отношение к требованию.
В RaQuest вместе с EA существует многопрофильная трассировка. Требования к требованиям. Требования к вариантам использования, Требования к элементам UML, где в качестве элементов могут выступать и тест-кейсы.

Цитировать
6. Те же знающие люди рассказывали легенды про решение аналогичной мощности на базе интеграции СабВершин-Джира-Телелоджик Дорз.
Но доработки по обеспечению этой интеграции обошлись компании в хорошую копеечку.
Да цена на ДООРС неслабая. Но как инструмент - действительно можная вещь. особенно в интеграции с System Architectи другой линейки от Telelogic. Но цены....

Название: Re: Управление требованиями
Отправлено: Gevorg от 08 Ноября 2007, 14:43:31
насколько я понимаю - это фиксация baseline? Если да например в RaQuest есть такой инструмент как сохранения таких baselines и версионный контроль.
дак и в калибере baselines имеют место быть, НО практика показала, что:
 нужен ЦЕНТРАЛИЗОВАННЫЙ версионный контроль всех артефактов
(в нашем случае мне пришлось вести целую войну с отщепенцами-аналитиками, чтобы приучить их хранить версии своих требований в StarTeam-е - общем для всех хранилище артефактов ),
благо - из Калибера можно вызывАть Стартимовские формы для работы с требованиями и строить в ём матрицу трассировки как между родными элементами, так и между хранящимися в СтарТиме.
Между прочим, Питерцы тоже столкнулись с этой же проблемой, только решили её заранее и кардинально:
Увидели, что аналитики сторят свой отдельный курятник - и полностью закрыли им работу в Калибере.


поймите меня правильно: я отнюдь не апологет Борландовских продуктов, они мне достались без каких-либо вариантов выбора и намучился я немеряно.
Многое из очевидной функциональности приходилось либо конструировать на механизме дополнительных пользовательских полей и ручной работы с ними,
либо дорабатывать свои "примочки".
Но в этом процессе родилось понимание как общеметодических принципов так и преимуществ Борландовской ALM-концепции и пакета приложений для её реализации.

Так вот, все красивости Калибера (трейс-мэтриксы, бейз-лайны, дизайн-туллзы) оказались менее знАчимыми, чем возможность требованиям "жить" в одном хранилище с другими артефактами.

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

В RaQuest вместе с EA существует многопрофильная трассировка. Требования к требованиям. Требования к вариантам использования, Требования к элементам UML, где в качестве элементов могут выступать и тест-кейсы.
А вот это действительно замечательно в Архитекте и чего нет в помине у Борланда:
Создать требование, а потом "показать пальцем" на соответствующий элемент поясняющей диаграммы - это круто.
EA рулит своей гениальной простотой:
- есть ЮМЛ-модель, состоящая из Элементов,
- для модели есть проекции-вьювы: диаграммы,
- есть возможность связать трассировочной связью требование и соответствующий набор Элементов Модели,
- если для требования нет специально разработанной диаграммы, (которую тоже можно при желании притрассировать к требованию),
- то для каждого из притрассированного к требованию элемента модели остаётся возможность увидеть список диаграмм, где он присутствует и выбрать подходящую диаграмму для просмотра.

НО! вспомним пункт из моего предыдущего поста:
Менеджмент требований раньше дизайна!
Т.е. многопрофильная трассировка раньше нужна для связывания ВЕРСИЙ задач, результатов их выполнения и результатов тестирования в их самом простом виде, но в комплексе.

Насколько я знаю - версионность для ЕА - вещь внешняя, хотя и возможная в интеграции с другим соответствующим туллзом.

Вот и получается, что для проджект-манагера и других тим-мемберов нужно вначале обеспечить возможность комплексной работы с требованием в самой примитивной форме его существования: текстовое описание.
А уже потом, для "избранных", давать возможность дизайна: моделирования и трассировки требований к элементам модели.

Насколько я знаю - эволюция Телелоджиковских продуктов  тоже шла по этому пути: вначале были абзацы текста со своими ИД-шками и линками на другие абзацы, а диаграммы с моделями появились намного позже.
Название: Re: Управление требованиями
Отправлено: Irr от 08 Ноября 2007, 17:56:07
нужен ЦЕНТРАЛИЗОВАННЫЙ версионный контроль всех артефактов
Мне кажется, в случае с EA это может прокатить, только если задействовать его же менеджерские вещи - issue, tasks. И все это вогнать под бейзлайны, но такое может и не получиться, не копалась.
Насколько я знаю - версионность для ЕА - вещь внешняя, хотя и возможная в интеграции с другим соответствующим туллзом.
У них есть внутренняя версионность по пакетам. но она не такая удобная, как поэлементная.
В общем, есть над чем подумать.
Cпасибо, Gevorg!
Название: Re: Управление требованиями
Отправлено: Galogen от 08 Ноября 2007, 18:29:44
Но в этом процессе родилось понимание как общеметодических принципов так и преимуществ Борландовской ALM-концепции и пакета приложений для её реализации.
А поделиться пониманием? Надо же формировать качественный контент на сайте. Отличная задача. Хотя понимаю - время!

Цитировать
Вот и получается, что для проджект-манагера и других тим-мемберов нужно вначале обеспечить возможность комплексной работы с требованием в самой примитивной форме его существования: текстовое описание.
А уже потом, для "избранных", давать возможность дизайна: моделирования и трассировки требований к элементам модели.
Насколько я знаю - эволюция Телелоджиковских продуктов  тоже шла по этому пути: вначале были абзацы текста со своими ИД-шками и линками на другие абзацы, а диаграммы с моделями появились намного позже.
Насколько я понял в RaQuest есть именно возможность работы с текстами требований до дизайна. Причем как в собственном типе файла, так и в интегрированном. Правда RaQuest имхо сыроват еще, многие функци обозначены, но не реализованы.
Название: Re: Управление требованиями
Отправлено: Григорий Печенкин от 08 Ноября 2007, 19:34:37
Цитировать
Чаще всего используются старые добрые блок-схемы алгоритмов, в том числе в тех ситуациях, где вроде бы самое подходящее место для вариантов использования.
А например?

Читаю очередные обновления спецификаций EMV, увидел блок-схему и вспомнил это "например".
http://emvco.com/documents/bulletin/view/AN35_Draft%20DCC%20Clarification%20v1.0.pdf (http://emvco.com/documents/bulletin/view/AN35_Draft%20DCC%20Clarification%20v1.0.pdf)

Может, пример не совсем в тему (речь шла о блок-схемах вместо вариантов использования), но если покопаться, в тему тоже можно найти.
По этим спецификациям, без преувеличения, работают десятки (если не сотни) тысяч людей. Блок-схемы ещё очень нескоро "выйдут из моды".
Название: Re: Управление требованиями
Отправлено: Galogen от 08 Ноября 2007, 20:45:58
По этим спецификациям, без преувеличения, работают десятки (если не сотни) тысяч людей. Блок-схемы ещё очень нескоро "выйдут из моды".
А кто спорит. Вещь надежная. Структурный подход однако никто не отменял. а компутеры в реале последовательные машины Тьюринга пока :)
Название: Re: Управление требованиями
Отправлено: Юрий Булуй от 08 Ноября 2007, 23:59:50
2Gevorg
Если честно, не припомню вас в клиентах Борланда, которые бы к нам в офис обращались с такой проблемой в 2006 г :-). Второй важный вопрос, какие версии инструментария вы использовали ... ? Кстати, у Борланд был написанный консультантами неплохой модуль интеграции с MS Project :-) ... при соответствующих коммуникациях с нами, этот модуль можно было получить забесплатно :-). Еще один вопрос -- так это собственно КАК у вас был организован процесс разработки ПО и КАКУЮ отчетность вы собирали ... т.к. действительно можно придумать множество отчетов, которых нет ни в одном инструментарии.
Насчет доработки -- которая стала в копеечку я не скажу, таки зависит от того что вы хотели делать :-) ... но я написал через API на Delphi off-line клиента для Caliber 2005 SP2 с базовой функциональностью за неполных 3 дня :-).
Название: Re: Управление требованиями
Отправлено: Gevorg от 12 Ноября 2007, 12:54:14
Если честно, не припомню вас в клиентах Борланда,
которые бы к нам в офис обращались с такой проблемой в 2006 г :-).
дак и не были мы в клиентах Борланда, токо теребили шефа насчёт покупки стартима :-(
"Дельпи", правда, был честно куплен, ещё в 90-ых, задолго до меня.

и не 2006-м, а весной 2007-го это было,
и были попытки проконсультироваться у манагеров Киевского представительства,
закосив под заинтересовавшихся потенциальных покупателей,
тягающих триал-версии и недоумевающих по имеющимся или остсутствующим возможностям,

так они затянули довгу чумацьку пісню:
"Вы нам опишите в почту техническую суть Ваших вопросов - мы перешлём в Москву...." ну, и далее - понятно.

Нашёл Питерцев, у которых СтарТим был честно куплен американским хед-офисом и навязан всем филиалам, у них и через них
в Борландовском саппорте справлялся по техническим деталям.


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

А свою интеграцию Борландовских продуктов мы делали своими силами, как полагается, "топором и на коленях". :-(
Не знаю, стоит ли сразу выносить на форум обсуждение технических деталей по граблям, на которые пришлось понаступать?
Может, для начала лучше в почту, а уж полезные результаты - на форум, для общественности?
Название: Re: Управление требованиями
Отправлено: Gevorg от 12 Ноября 2007, 13:28:37
А поделиться пониманием? Надо же формировать качественный контент на сайте. Отличная задача. Хотя понимаю - время!
Вот, пытаюсь.

А насчёт времени -так точно:
два предыдущих поста с самыми поверхностными тезисами - в сумме 2,5 часа затянули, специально время засекал :-(

Искренне изумляюсь, как участники форума успевают вести такую обширную переписку:
тут читать не успеваешь, а они успевают написать.....

Название: Re: Управление требованиями
Отправлено: Gevorg от 12 Ноября 2007, 13:59:57
(речь шла о блок-схемах вместо вариантов использования), ....
   ... Блок-схемы ещё очень нескоро "выйдут из моды".

ЫМХО: Активити-диаграммы в UML - есть результат эволюции блок-схем.

А я всю свою сознательную жизнь Аналитика писал текстовые сценарии в описаниях ВИ исключительно в ключе прямого мэппинга каждого шага сценария на  квадратик в диаграмме активности.
Была даже одна курьёзная, но реальная задача на работе: убрать из ТЗ блок-схемы и заменить их текстовыми описаниями в стандарте ЮзКейсов(!!!)
Заказчик наотрез отказывался изучать блок-схемы, описывающие логику взаимодействия Пользователя с Системой, - и легко принял UC-стандарт текстовых сценариев :-)

Для меня активити-диаграмма, объединяющая сценарии по одному или нескольким близким Юз-Кейсам, всегда была естественным следующим шагом уточнения требований после написания ВИ-шек.

Так что в этом смысле для дилемма ВИ\блок-схема вообще не стоит:

- одно другому не противоречит, а второе является результатом развития первого,
- первое - ближе Заказчику, второе - Разработчику,
- в зависимости от специфики проекта, одного из них может не быть.
Название: Re: Управление требованиями
Отправлено: Gevorg от 12 Ноября 2007, 14:25:59
Кстати, у Борланд был написанный консультантами неплохой модуль интеграции с MS Project :-)
... при соответствующих коммуникациях с нами, этот модуль можно было получить забесплатно :-)
Был у нас этот модуль, где-то админ заполучил.
Действительно, замечательная штука, благодаря ей таски заносили в Проджекте и экспортились в СтарТим для трейсинга с остальными объектами процесса разработки:
Версиями Требований, Версиями ТестКейзов, Версиями исходников и версиями сборок.

И даже механизм обратного экспорта из СтарТима в Проджект данных по прогрессу выполнения тасок укротили:
реально программеры заносили свои трудозатраты в Works-ах по Task-ам в StarTeam-е, и это всё дело синхронизировалось с ходом выполнения задач в Проджекте.

Были свои трудности и недостающие возможности, сейчас в деталях не вспомню. Если надо - подниму старые документы и коллег, которые остались работать с этим.
Название: Re: Управление требованиями
Отправлено: Galogen от 12 Ноября 2007, 15:08:19
ЫМХО: Активити-диаграммы в UML - есть результат эволюции блок-схем.
Так что в этом смысле для дилемма ВИ\блок-схема вообще не стоит:
- одно другому не противоречит, а второе является результатом развития первого,
- первое - ближе Заказчику, второе - Разработчику,
- в зависимости от специфики проекта, одного из них может не быть.
Согласен. Но применять диаграммы видо деятельности или нет должно истекать из того, оправдано это или нет.

Если ВИ достаточно прост и понятен, вряд ли стоит его фиксировать в виде ДД. Ведь это все-таки лишняя работа. И кто-то за нее платит. Если же ВИ большой с развитой структурой алтернатив и исключений - тут вероятно без ДД сложнее.

Опять же ДД может и предшедствовать ВИ. Есть такой интересный пример у Шмуллера "Освой UML за 24 часа".
Аналитик берет интервью у администратора и по ходу дела рисует ДД. Затем по ДД рассказывает ему, что он понял и администратор вдруг видит какие-то слабые или некорректные места.

Анализ же ДД позволяет выделить задачи участников и скомбинировать из этой большой ДД массу ВИ и соотвественно небольших ДД.

Т.е. сначала ДД используется на уровне бизнеса, как некая сложная комбинация блок-схемы, IDEF3 и возможно DFD.

Затем реализуются уже ВИ к системе и соотвественно ДД системы.

Ларман рекомендует использовать для анализа ВИ системные диаграммы последовательности с целью выявления системных событий, системных операций.

Например в VP-UML даже есть инструментарий перевода ВИ в системную диаграмме последовательности. Правда ВИ нужно набиратьпрямо в спецификации ВИ (там используется табличный шаблон ВИ). При этом поддерживается round-trip сопровождение. Но это естественно касается анализа требований. А не самого формирование требований
Название: Re: Управление требованиями
Отправлено: Юрий Булуй от 12 Ноября 2007, 15:34:31
дак и не были мы в клиентах Борланда, токо теребили шефа насчёт покупки стартима :-(
"Дельпи", правда, был честно куплен, ещё в 90-ых, задолго до меня.

Как водиться одну коробку на всю компанию :-) ....

Цитата: Gevorg
и не 2006-м, а весной 2007-го это было,
и были попытки проконсультироваться у манагеров Киевского представительства,
закосив под заинтересовавшихся потенциальных покупателей,
тягающих триал-версии и недоумевающих по имеющимся или остсутствующим возможностям,
так они затянули довгу чумацьку пісню:
"Вы нам опишите в почту техническую суть Ваших вопросов - мы перешлём в Москву...." ну, и далее - понятно.

Удивительно что они вам что-то пообщали ... но к этому моменту в Москве был только офис CodeGear, который по ALM тулам не работает. Ну да ладно :-).

Цитата: Gevorg
Про большую копеечку - это относительно аналогичной связки: Джира-Сабвершин-Доорз, слухи про которую я передавал в посте.

Мне на самом деле было бы интересно узнать более подробно об этой связке и ее возможностях. Если есть информация, какие-либо материалы, я бы с удовольствием посмотрел на них.

Цитата: Gevorg
А свою интеграцию Борландовских продуктов мы делали своими силами, как полагается, "топором и на коленях". :-(
Не знаю, стоит ли сразу выносить на форум обсуждение технических деталей по граблям, на которые пришлось понаступать?
Может, для начала лучше в почту, а уж полезные результаты - на форум, для общественности?

Думаю стоит описать в кратце процесс в рамках которого использовалась интеграция инструментария. Какая информация откуда куда поступала и почему. Т.е. каков был регламент работы с инструментарием. Это было бы думаю многим интересно.
Название: Re: Управление требованиями
Отправлено: Gevorg от 12 Ноября 2007, 16:53:52
Т.е. сначала ДД используется на уровне бизнеса, как некая сложная комбинация блок-схемы, IDEF3 и возможно DFD.
  Затем реализуются уже ВИ к системе и соотвественно ДД системы.
тогда точнее будет так:
- сначала ДД или БВИ на бизнес-уровне, а затем
- снова ДД или СВИ на уровне пользовательских требований?

всего по комбинаторному принципу получается 4 возможных варианта :-)
Название: Re: Управление требованиями
Отправлено: Gevorg от 12 Ноября 2007, 17:10:31
Согласен. Но применять диаграммы ВИ до деятельности или нет должно истекать из того, оправдано это или нет.
А "оправданность" использования нужно оценивать из того, что требует бОльшей проработки:
контекст процесса или сам процесс.

Хочу обратить внимание на "рулёзные" особенности ВИ:
- хорошее, а местами - единственное в своём роде, описание  КОНТЕКСТА процесса: пред-, пост-условие, ДЛ-ы, Заинтересованные Лица с их интересами и т.д.
(единственное в своём роде - в том смысле, что других мест для описания всего этого в стандартах на структуру соответствующих документов иногда вообще нет)
- СОЗНАТЕЛЬНО снижены требования к строгости и детальности описания САМОГО процесса.

В противовес(а точнее - в дополнение) к ВИ, ДД рулит:
- обеспечивает строгость и наглядность представления именно ПРОЦЕССА,
- даёт возможность учитывать в явном и стандартизированном виде поток входных\выходных объектов, да ещё и отслеживать их состояния на входе и на выходе каждой активности,
- показывает исполнителей каждой активности (свим-лайны),
- СОЗНАТЕЛЬНО абстрагируется от контекста: Интересы и Заинтересованные Лица, Цели ДЛ-ов и т.д.
Название: Re: Управление требованиями
Отправлено: Galogen от 12 Ноября 2007, 17:27:59
тогда точнее будет так:
- сначала ДД или БВИ на бизнес-уровне, а затем
- снова ДД или СВИ на уровне пользовательских требований?
всего по комбинаторному принципу получается 4 возможных варианта :-)
Да вариантов не много :-) Дело и в вариантах,а в удобстве. Главное все равно в понимании  того, что нужно сделать. И совершенно не важно как и что. Главное чтобы все разговаривали на одном языке, так ведь?
Название: Re: Управление требованиями
Отправлено: Galogen от 12 Ноября 2007, 17:36:48
Хочу обратить внимание на "рулёзные" особенности ВИ:
- хорошее, а местами - единственное в своём роде, описание  КОНТЕКСТА процесса: пред-, пост-условие, ДЛ-ы, Заинтересованные Лица с их интересами и т.д.
(единственное в своём роде - в том смысле, что других мест для описания всего этого в стандартах на структуру соответствующих документов иногда вообще нет)
- СОЗНАТЕЛЬНО снижены требования к строгости и детальности описания САМОГО процесса
Да согласен. Причем определенная направленность прецедента играет хорошую роль при обучении. Мои студенты в общем достаточно быстро прочухали что к чему. Правда главным образом при описании бизнес-процессов, причем прозрачных.
А вот переход к системным дался им с большим трудом, я бы даже сказал так и не дался. Понять, что в системном ВИ следует описывать некий концептуаьный диалог пользователя с системой, почему-то оказалось для них совершенно сложным.

Цитировать
В противовес(а точнее - в дополнение) к ВИ, ДД рулит:
- обеспечивает строгость и наглядность представления именно ПРОЦЕССА,
особенно когда ВИ сложный

Цитировать
- даёт возможность учитывать в явном и стандартизированном виде поток входных\выходных объектов, да ещё и отслеживать их состояния на входе и на выходе каждой активности,
Но эта особенность появилась только в UML2 я имею в виду объекты, просто мы пользовались Розой, а она потоки объектов не разрешала размещать. Правда до UML2 ДД была подмножеством диаграмм состояний. А вот в UML2, ДД имеют совершенно иную интерпретацию, и построены на теории сетей Петри со всеми вытекающими отсюда особенностями логики переходов, правил срабатывания переходов, чтения диаграмм, проверки безопасности, живости сети. хотя мне кажется ценнее было бы E-сети, поскольку они безопасны по определению

Цитировать
- СОЗНАТЕЛЬНО абстрагируется от контекста: Интересы и Заинтересованные Лица, Цели ДЛ-ов и т.д.
Т.е. Вы полагаете - это зер гут? А почему если не секрет
Название: Re: Управление требованиями
Отправлено: Galogen от 12 Ноября 2007, 17:50:50
Очень рад, что начал эту тему. Дело в том, что в ходе своей дейятельности мне не удается организовать управление требованиями. А хотелось бы поставить такую задачу в рамках практикума.

Поскольку занятия довольно ограничены по времени и имеют дурную привычку совершаться через неделю, я бы хотел весь практикума по управлению требованиями переместить на летнюю практику для 3 курса.

Выбрать неочень сложную, но обязательно коллективную задачу. Обыграть роли, распределить обязанности и посмотреть, что из этого получиться. Здесь я буду работать примерно неделю по 5-6 академических часов в день. так что следует успеть.

Что это будет за задача пока не понятно. Ясно, что некие предварительные материалы по ней будут. Хотелось бы расмотреть пусть не все - но некоторые этапы фиксации, управления и работы с требованиями.

Главное мне не очень понятно с чего все-таки начать.Предположим я буду использовать RaQuest или нечто другое (будет зависить от возможности приобретения лицензии на вуз, личная у меня есть).

В самом общем понимании что нужно будет делать:?
1. осуществить сбор требований
2. осуществить извлечение требований
3. осуществить ранжирование требований
4. осуществить моделирование части требований
5. осуществить фиксацию базовой линии

Предположим бизнес-цели или цели создания у нас будут поставлены.
мы будим формировать Видение. Сразу вопрос имеет ли смысл фиксировать бизнес-требования в системе управления требованиями? Если да то как грамотно это делать, Если нет то почему?

Далее функциональные требования будем в первую очередь описывать через прецеденты. Вопрос - ВИ и есть функциональные требования? имеет ли смысл разбивать ВИ на списки требований и фиксировать их в RaQuest? Или в RaQuest описать фичи? выделенные при создании Видения, а сами прецеденты описывать в рамках ЕА (Enterprise Arcitect) с трассировкой их к фичам описанным в RaQuest
Название: Re: Управление требованиями
Отправлено: Gevorg от 12 Ноября 2007, 18:07:46
особенно когда ВИ сложный
точнее - его процесс: не следует забывать, что ВИ может иметь простой процесс и сложное окружение :-)
а если сложное и то и другое - то:
-  пишем вначале ВИ с детальным описанием сложного окружения и простым,поверхностным описанием процесса,
- рисуем ДД с детальной визуализацией всей сложности процесса.
Название: Re: Управление требованиями
Отправлено: Gevorg от 12 Ноября 2007, 18:13:18
Дело в том, что в ходе своей дейятельности мне не удается организовать управление требованиями. А хотелось бы поставить такую задачу в рамках практикума.

Главное мне не очень понятно с чего все-таки начать.

Прежде всего - уточнить программу, чтобы она соответствовала названию практикума:
- управление требованиями (2 уровень СММ)
- или дизайн требований (3 уровень СММ)

а то в названии - управление,
а в программе - и то и другое
Название: Re: Управление требованиями
Отправлено: Gevorg от 12 Ноября 2007, 18:22:28
управление требованиями.
 А хотелось бы поставить такую задачу в рамках практикума.

 Предположим я буду использовать RaQuest или нечто другое
Гиблое это дело: одновременно учить студентов концепциям и средству автоматизации...
если хотим научить, что такое Требование и как им управлять - бумагу с карандашом в руки, да ещё и нелинованную :-)
И ДУМАТЬ-ДУМАТЬ-ДУМАТЬ, а компьютер - отобрать, чтоб не мешал.
Название: Re: Управление требованиями
Отправлено: Galogen от 12 Ноября 2007, 18:32:54
Прежде всего - уточнить программу, чтобы она соответствовала названию практикума:
- управление требованиями (2 уровень СММ)
- или дизайн требований (3 уровень СММ)
а то в названии - управление,
а в программе - и то и другое
Да нет никакой программы - есть мысли вслух.
По идее описывать требования я планирую их в рамках курса, где собираюсь дать что такое ребования их классификацию и правила работы с сними- вернее как правильно формулировать

По идее мне самому это шибко интересно.Вконце концов не получится в коллективе группы - я вполне могу этим заниматься кулуарно при ведение бакалавских и дипломных работ. Благо сейчас бакалавриат на 4 курсе а диплом на 5 - в результате грамотно поставленной работы у меня 2 года, да каждый год можно вовлекать потихоньку народ
Название: Re: Управление требованиями
Отправлено: Gevorg от 12 Ноября 2007, 18:35:42
- ДД СОЗНАТЕЛЬНО абстрагируется от контекста: Интересы и Заинтересованные Лица, Цели ДЛ-ов и т.д.
Т.е. Вы полагаете - это зер гут? А почему если не секрет
да потому, что абстракция - один из основных приёмов моделирования,
нельзя впихивать в одну диаграмму все детали:  ДД и так уже "напакована" возможностями под завязку
Название: Re: Управление требованиями
Отправлено: Galogen от 12 Ноября 2007, 18:35:46
- или дизайн требований (3 уровень СММ)
А что есть дизайн? если проектирование системы по требованиям, то можно до него не доходить, или ограничить все это - как в гибкой методологии
Если это есть анализ требований - вот мне он и нужен, но анализ может затрагивать и дизайн. А какже иначе?
Название: Re: Управление требованиями
Отправлено: Galogen от 12 Ноября 2007, 18:41:17
Гиблое это дело: одновременно учить студентов концепциям и средству автоматизации...
если хотим научить, что такое Требование и как им управлять - бумагу с карандашом в руки, да ещё и нелинованную :-)
И ДУМАТЬ-ДУМАТЬ-ДУМАТЬ, а компьютер - отобрать, чтоб не мешал.
Ну возможно. А что с бумагой и нелиновоной тут делается?

да потому, что абстракция - один из основных приёмов моделирования,
нельзя впихивать в одну диаграмму все детали:  ДД и так уже "напакована" возможностями под завязку
Это я понимаю. ясно что любая модель отражает некоторые существенные моменты и  вданом случае сосредоточена на потоке работ и объектов если нужно, однако контектс все равно отсается, хотя бы теже свимлайны
Название: Re: Управление требованиями
Отправлено: Gevorg от 12 Ноября 2007, 18:44:26
Думаю стоит описать в кратце процесс в рамках которого использовалась интеграция инструментария.
вот, собрал осколки документации, да ещё и не последней версии, но приблизительную картину должно дать
Название: Re: Управление требованиями
Отправлено: Gevorg от 12 Ноября 2007, 19:05:21
А что есть дизайн?
управление требованиями предполагает, что требования, как таковые, появляются\обнаруживаются, формулируются, как-то документируются кем-то извне, что мы сами ещё этому не научились.

управление требованиями предполагает искусство укрощать уже известные требования, с уже известными связями или поток изменений в требованиях, но опять же, сущность этих изменений уже предполагается определённой, нужно только уметь с ними управиться в рамках общего управления проектом.
А в этих рамках кроме пачки требований, которые нужно "разложить по полочкам" есть ещё и пачка соответствующих компонент продукта, тестов, доки, задач, исполнителей,заинтересованных лиц.
Сами объекты, связи между ними и динамика процесса разработки в проекте.

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

В этом смысле, дизайн требований - суть оставшееся после того, как все вышеописанные задачи менеджмента решены :-)
Название: Re: Управление требованиями
Отправлено: Gevorg от 12 Ноября 2007, 19:20:13
Это я понимаю. ясно что любая модель отражает некоторые существенные моменты и  вданом случае сосредоточена на потоке работ и объектов если нужно,
однако контектс все равно отсается, хотя бы теже свимлайны
- контекст как таковой, кончно же остаётся,
- в ДД он показан существенно меньше, чем ВИ  - и это хрошо, чтоб не мешал понимать сам процесс,
- свим лайны и Пользователи Системы - не одно и то же:
-- свим-лайны - всего лишь инструмент визуализации, который
-- может иметь и другую смысловую нагрузку, например - этапы деятельности.
Название: Re: Управление требованиями
Отправлено: Gevorg от 12 Ноября 2007, 19:36:05
Гиблое это дело: одновременно учить студентов концепциям и средству автоматизации...
если хотим научить, что такое Требование и как им управлять - бумагу с карандашом в руки, да ещё и нелинованную :-)
И ДУМАТЬ-ДУМАТЬ-ДУМАТЬ, а компьютер - отобрать, чтоб не мешал.
Ну возможно. А что с бумагой и нелиновоной тут делается?
да по-сути, то же самое, что и при обучении ЮМЛу или бухгалтерии:

- записываются десяток простых требований,
-- каждое из которых состоит из 1-2 предложений,
-- заполняются нужные атрибуты,
-- рисуются связи к другим требованиям, задачам, пользователям,
- строится 4х3 матрица связей между ними

студент вынужденно остаётся без подсказок, а концепция, которая должна уложиться в его голове - без костылей и подпорок
Название: Re: Управление требованиями
Отправлено: Galogen от 12 Ноября 2007, 19:56:40
А в этих рамках кроме пачки требований, которые нужно "разложить по полочкам" есть ещё и пачка соответствующих компонент продукта, тестов, доки, задач, исполнителей,заинтересованных лиц.
Сами объекты, связи между ними и динамика процесса разработки в проекте.
А вы не путаете управление требований с управлением проектом или процессом разработки в целом?

да по-сути, то же самое, что и при обучении ЮМЛу или бухгалтерии:

студент вынужденно остаётся без подсказок, а концепция, которая должна уложиться в его голове - без костылей и подпорок
такой подход интересный, только почему по сути тоже самое?
Вообще напридумывать кучу требований на 30 студентов - это очень сложная по-моему задачка.
Далее, естественно при чтении этих требований логика комбинации у всех своя, и варианты возможны самые разнообразные.
У нас уже с этим были проблемы. Преподаватель дал задачу - некий набор существительных и глаголов и сказал постройте семантические связи. Ну все стали строить: кто-то выбрал в качестве критерия минимальность связей, кто-то сделал группировки по своему. В результате оценка у всех 2 - типа не сходится с ответом у преподаателя.
Например еще, в рамках задачи были заданы такие слова музыка медведь сцена. Практически все написали, что типа цирк приехал и медведь танцует на сцене - всем 2. Поскольку преподаватель сказал, что какие вы дураки, какой медведь. Это группа "медведь" выступала.

Помоему точно так же будет и с обучением требований, UML если все вырвано из контекста. К тому же UML - просто символы. В требованиях коннчг больше смылса не спорю, может с ними и прокатит, только интересно где найти 300 требований, а по идее и еще больше :-)

управление требованиями предполагает, что требования, как таковые, появляются\обнаруживаются, формулируются, как-то документируются кем-то извне, что мы сами ещё этому не научились.
Вообще по классике, управление нуждается в объекте управлением - в данном случае требованиями и определяется функциями: сбор, учет, контроль, анализ, прогноз, планирование, оперативное управление (изменение), организация и координация, доведение до исполнителя.

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

Кроме того в РУП записано: "управление требованиями - систематизированных подход к поиску, документированию, организации и отслеживанию изменчивых требований к системе" К.Ларман "Применение UML2 и шаблонов проектирования" 3-е издание. М.:Вильямс, 2007, стр. 90
Название: Re: Управление требованиями
Отправлено: Gevorg от 13 Ноября 2007, 11:00:11
А вы не путаете управление требований с управлением проектом или процессом разработки в целом?
стараюсь не путать, но наверняка ошибки в представлениях имеются
поэтому давайте разделим мою задачу на форуме (поделиться опытом) по таким направлениям:
- правильно его изложить, как есть,
- проанализировать и выделить действительно стОящие части,
- оформить их в удобном для пользования другими.
Название: Re: Управление требованиями
Отправлено: Galogen от 13 Ноября 2007, 11:06:10
Gevorg, на самом деле любой опыт полезен:
а/ если он верный - то им можно воспользоваться
б/ если в нем есть ошибки - то их можно понять

Кроме того любая попытка описать что-либо сразу вызывает потребность обдумать и сформулировать, а главное донести свое понимание. И тут сразу вылезают и собственные заблуждения и какие-то нелогичности.

Я поднял эту тему, поскольку попытался осмыслить, а что есть управление требованиями вообще. Как, когда и с помощью чего его применять на практике. И обнаружил, что вопросов больше, чем ответов. Более того - даже не сумел опеределиться, а когда же оно начинается и как выражается...

Потому практический опыт очень ценен... Такчто, чтобы Вы не предприняли - уже хорошо. А обсуждая, мы можем вместе прийти к лучшему пониманию, и возможно Вам будет польза
Название: Re: Управление требованиями
Отправлено: Galogen от 13 Ноября 2007, 11:10:41
- правильно его изложить, как есть,
Да думаю именно так и нужно - это будет опорная точка

- проанализировать и выделить действительно стОящие части,
т.е. те интересные фишки, которые стоит развивать?

- оформить их в удобном для пользования другими.
Будет нужна помощь, обращайтесь
Название: Re: Управление требованиями
Отправлено: Gevorg от 13 Ноября 2007, 11:20:01
такой подход интересный, только почему по сути тоже самое?

по сути процесса обучения :-)

в примерах от меня студенту нужно освоить:
- процесс моделирования с помощью инструмента "система UML" (графические элементы, ООП-абстракции, шаблоны...),
- процесс бухучёта с помощью инструмента "система бухучёта" (план счетов, двойной учёт, дебет\кредит, актив\пассив...)

в нашем примере нужно осваивать
- процесс управления требованиями,
- с помощью инструмента....????

вот, чтобы эффективно задать этот вопрос студенту и необходима "орг-мера":
Дать инструменты работы с требованиями в "чистом" виде, а не упакованными в пусть даже золотое ПО.
Название: Re: Управление требованиями
Отправлено: Gevorg от 13 Ноября 2007, 11:32:45
Вообще напридумывать кучу требований на 30 студентов - это очень сложная по-моему задачка.
она облегчается тем, что сущность требований должна быть примитивной, чтобы эти требования:
- легко "придумывались",
- однозначно понимались,
- однозначно трассировались,
- были легки в управлении (менеджменте),
- не интересны по смыслу (не отвлекали от менеджмента).
Название: Re: Управление требованиями
Отправлено: Gevorg от 13 Ноября 2007, 12:42:50
Вообще по классике, управление нуждается в объекте управлением - в данном случае требованиями и определяется функциями: сбор, учет, контроль, анализ, прогноз, планирование, оперативное управление (изменение), организация и координация, доведение до исполнителя.
здесь я для себя провожу аналогию с понятиями производство - логистика.
Мои бытовые представления позволяют легко отличать
процессы по добыче\переработке сырья или изготовлению устройства (дизайн требований) от
процессов по оценке качества, упаковке, маркировке, транспортировке, хранению (менеджмент требований)

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


Кроме того в РУП записано: "управление требованиями - систематизированных подход к поиску, документированию, организации и отслеживанию изменчивых требований к системе" К.Ларман "Применение UML2 и шаблонов проектирования" 3-е издание. М.:Вильямс, 2007, стр. 90
кажется, я со своим наивным логистическим толкованием не погрешил против РУП-вских канонов :-)
в цитате я вижу:
- акцент на систематизированность подхода,
- набор деятельностей, не включающий какого-либо производства требования, одна логистика.


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


     ...не нам же их придумывать самим.
и такое случалось :-)
 причём - на полном серъёзе: в рамках работы над ТЗ пришлось
 продумывать и предлагать бизнес-процессы для только зарождающейся деятельности Заказчика,
 чтобы хоть как-то зафиксировать, а что же, собственно, будет автоматизироваться...

Вообще по классике, управление нуждается в объекте управлением - в данном случае требованиями
а поскольку управление требованиями идёт в контексте комплексного управления ВСЕМИ объектами процесса управления разработкой ПО,
то здесь же следует рассматривать и контекст из других объектов, так или иначе связанных или связываемых с требованиями.


если пойти дальше в распутывании терминологической паутины, то мне видится такое:
процесс разработки ПО состоит из:
- производственного процесса, для которого требование является
-- артефактом (в моём примитивном понимании - продуктом), и
- процесса управления, для которого требование - один из
-- объектов управления.

ЫМХО: Процесс управления разработкой ПО не получается разбить на несколько слабо связанных подпроцессов и рассматривать их по-отдельности,
уж сильно они переплетаются и много взаимосвязей.
Эффективным получается только рассмотрение Проекций этого процесса на различные оси по объектам управления:
 требований, кода\сборок, тест-кейсов\репортов, задачам и т.д.
Название: Re: Управление требованиями
Отправлено: Gevorg от 13 Ноября 2007, 13:05:23
... на самом деле любой опыт полезен:
...осмыслить, а что есть управление требованиями вообще. Как, когда и с помощью чего его применять на практике.
... вопросов больше, чем ответов.
Потому практический опыт очень ценен...
кроме практического опыта в использовании, у меня за прошедшие выходные появился ещё и небольшой опыт преподавания :-)
курса по управлению требованиями.

опыт показал, что уже есть большой спрос на практические техники,
что широкая ИТ-общественность уже созрела к потреблению результатов теоретической и методической проработки.

Времена радиолюбителей-академиков, собирающих по сараям свои приёмники, -  давно прошли.
Теория полупроводников и радиосхемы уже никого не интересуют, все спрашивают:
- где магазин?
- какой производитель и какая модель лучше?
- где ручки у приёмника и как их крутить?
Название: Re: Управление требованиями
Отправлено: Григорий Печенкин от 13 Ноября 2007, 13:10:01
она облегчается тем, что сущность требований должна быть примитивной, чтобы эти требования:
- легко "придумывались",
- однозначно понимались,
- однозначно трассировались,
- были легки в управлении (менеджменте),
- не интересны по смыслу (не отвлекали от менеджмента).

- отражали реальные потребности заказчика
- были проверяемы (в том числе правильно понимались тестировщиками, потому что "однозначное понимание" всё-таки существенно различается для программистов, тестировщиков, заказчиков, продавцов и маркетологов).

Добавляю исключительно по поговорке "у кого что болит, тот о том и говорит". :)
Название: Re: Управление требованиями
Отправлено: Григорий Печенкин от 13 Ноября 2007, 13:12:06
Странный движок всё-таки. Ввёл пост, нажал "отправить". Он говорит: "пока вы писали ответ, в теме появились новые сообщения".
Исправил свой пост, нажал "отправить". Так движок зачем-то перед отправкой отменил все мои изменения. Зачем тогда спрашивал, интересно?
Название: Re: Управление требованиями
Отправлено: Gevorg от 13 Ноября 2007, 13:29:16
- отражали реальные потребности заказчика
Добавляю исключительно по поговорке "у кого что болит, тот о том и говорит". :)

ой, кумо, і нэ кажіть....
один проект был завален именно на этих граблях:
по функциональному направлению требование нужно было реализовать  - ну просто обязательно, иначе вся система окзывалась игрушкой,
а по качественному - так Заказчик реально справлялся с имеющимся потоком задач примитивным набором возможностей одного Екселла.

как мы ошиблись, когда взялись делать настоящую, а не игрушечную функциональность.....
Название: Re: Управление требованиями
Отправлено: Galogen от 13 Ноября 2007, 13:34:30
Странный движок всё-таки. Ввёл пост, нажал "отправить". Он говорит: "пока вы писали ответ, в теме появились новые сообщения".
Исправил свой пост, нажал "отправить". Так движок зачем-то перед отправкой отменил все мои изменения. Зачем тогда спрашивал, интересно?
Гриша, ну и что Вы испугались? Надо было продолжать и дело с концом. У меня такое частенько бывает, когда я пишу ответ и появляется некоторое новое сообщение. А то что не сохранил изменения - богу весть.
Название: Re: Управление требованиями
Отправлено: Galogen от 13 Ноября 2007, 13:36:43
Gevorg, Вы это greesha  в пику или в одобрение казали?
Название: Re: Управление требованиями
Отправлено: Galogen от 13 Ноября 2007, 13:44:20
она облегчается тем, что сущность требований должна быть примитивной, чтобы эти требования:
- легко "придумывались",
- однозначно понимались,
- однозначно трассировались,
- были легки в управлении (менеджменте),
- не интересны по смыслу (не отвлекали от менеджмента).
Вашими бы устами да мёд пить.

Легко придумывались штук 300 требований? Да еще однозначно понимались? Да еще однозначно трассировались? и были не интересны? - может сразу все сделать и выдать готовый результат? :-)

Если честно я не очень понимаю в чем проблема связи требований?

Мне кажется есть проблема извлечения, формулировки требований.

Однако связывать их, тем более когда они однозначно понимаемые и однозначно трассируемые - не проблема.

Я конечно понимаю Ваш тезис. Главное не в навороченности системы, красивости и удобстве ее. Главное в умение и понимании, а оно безусловно достигается не использованием инструментов, хотя и помогает этому.

Изучая UML(в графическом его смысле), совершенно нельзя научиться объектному проектированию.

Значит справедливо и утверждение - использование систем управления требованиями - по сути не научит делать требования и управлять ими.
Название: Re: Управление требованиями
Отправлено: Gevorg от 13 Ноября 2007, 13:45:56
Gevorg, Вы это greesha  в пику или в одобрение казали?
дак он про грабли, да про то, что болит у каждого своё, а мне соль на раны...
решил поделиться, мол, и у меня такое было :-)

а по сути вопроса, так однозначно - одобрение,
очень стОящее свойство требования, хорошо, что greesha напомнил
Название: Re: Управление требованиями
Отправлено: Galogen от 13 Ноября 2007, 13:58:09
здесь я для себя провожу аналогию с понятиями производство - логистика.
процессы по добыче\переработке сырья или изготовлению устройства (дизайн требований) от
Почему добыча требования - это его дизайн?

Цитировать
процессов по оценке качества, упаковке, маркировке, транспортировке, хранению (менеджмент требований)
Т.е. производством мы не управляем?


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

Цитировать
- акцент на систематизированность подхода,
Так куда же пбез систематизированости, только мне кажется Вы тут попутали системный подход с систематизированностью

Цитировать
- набор деятельностей, не включающий какого-либо производства требования, одна логистика.
а поиск - это что по Вашему? Разве в приложение к нашему контексту это не есть производство требования?
Производство - это перобразования сырья в продукт: сырье - это интервью, словесная шелуха, документы, результаты наблюдений,невербальные аспекты, догадки и т.п., а продукт - качественно сформулированное требование

 
Цитировать
причём - на полном серъёзе: в рамках работы над ТЗ пришлось
 продумывать и предлагать бизнес-процессы для только зарождающейся деятельности Заказчика,
Ну это возможно и это никак не противоречит намшей дискуссии

Цитировать
а поскольку управление требованиями идёт в контексте комплексного управления ВСЕМИ объектами процесса управления разработкой ПО,
Да вообщем, тут и обсуждать нечего - совершенного естественно. Тем более, что в рамках итеративного подхода требования определятся практически на всем протяжении проекта.

Цитировать
- производственного процесса, для которого требование является
-- артефактом (в моём примитивном понимании - продуктом), и

требования являются, по-моему, заданием - производственным заданием. И на разных уровнях оно разное. Токарю - выдаете чертеж и технологическую карту, чертежнику-конструктору - более общие задания.

Название: Re: Управление требованиями
Отправлено: Galogen от 13 Ноября 2007, 14:18:12
Помещу, вот ссылочку чтобы не забыть: http://www.pmexpert.ru/services/training/moscow/detail.php?ID=107.

Ключевое слово для будущего поиска: рюшечка
Название: Re: Управление требованиями
Отправлено: Gevorg от 13 Ноября 2007, 14:31:30
Легко придумывались штук 300 требований? ...
- может сразу все сделать и выдать готовый результат? :-)
Именно это я и предлагаю: "выдать готовый результат", в смысле - сАми требования.
И дальше - показать студенту, что даже когда требования УЖЕ классно описаны и связи между ними - определены
-- Всё равно остаётся куча проблем в работе с ними.
Их решение - и будет предметом курсовой работы именно по УПРАВЛЕНИЮ требованиями.


Однако связывать их, тем более когда они однозначно понимаемые и однозначно трассируемые - не проблема.
так мы о теории говорим или о практическом опыте?
Проблема, ещё какая проблема! И не одна.
Только не научные эти проблемы, а инженерные и манагерские.
Согласования терминов и сути в наборе из различных, но тесно связанных технологий,
Интеграция средств автоматизации,
Регламентирование и документирование самого процесса,
Саботаж персонала.

Если честно я не очень понимаю в чем проблема связи требований?
а в нашем случае её и не должно быть,
наши обсуждаемые проблемы - совсем в другой плоскости:
- разобраться, что такое менеджмент требований в чистом виде,
- дать полученное понимание студентам.


Значит справедливо и утверждение - использование систем управления требованиями - по сути не научит делать требования и управлять ими.
ЫМХО, справедливы след.2  утверждения:

использование _ПО_ для управления требованиями - по сути не научит делать требования и управлять ими.

использование _КОНЦЕПТУАЛЬНОЙ СИСТЕМЫ_  как раз-то и научит делать требования и управлять ими как по-сути, так и по-форме.
Название: Re: Управление требованиями
Отправлено: Galogen от 13 Ноября 2007, 15:00:28
Gevorg? давай уж эти свои 10 требований :) и начнем их обсуждать. Я буду с использованием раквеста чур...
Название: Re: Управление требованиями
Отправлено: Gevorg от 13 Ноября 2007, 15:05:55
Т.е. производством мы не управляем?
да управляем,или по крайней мере, - должны управлять,
только в рамках управления требованиями - намеренно абстрагируемся, считаем, что на производстве уже всё так, как нам надо


А я полагал, что для дизайна выходной продукт - решение.
Да, конечно, между требованием и решением много общего.
Здесь должен помочь Джереми Дик - один из соавторов известной книжки от Телелоджика (преревод Ильи Корнипаева),
 со своей формализованной моделью требования в общем виде.
Там у него идея, что решение, закрывающее проблему из требования на верхнем уровне в свою очередь является  требованием на нижнем уровне.
Отсюда и терминологическая путаница в терминах дизайн-решение.
В нашей частной переписке Илья делился со мной, что книга кишит концептуальными и терминологическими неточностями, очень нуждается в пере- и доработке,
но тем не менее, для меня - она всё равно как "луч света в тёмном царстве", до сих пор я лучшего не нашёл.
Название: Re: Управление требованиями
Отправлено: Shur от 13 Ноября 2007, 15:22:36
здесь я для себя провожу аналогию с понятиями производство - логистика.
...получается, что
для менеджмента  - требование является объектом управления, а
для дизайна - выходным продуктом.

ИМХО, чтобы более нагладно представить суть обсуждаемого предмета  попытался представить ваше утверждение в IDEF0, но возникают некоторые трудности: IDEF не предполагает управление артефакатами (требваниями), а только управление функциями. Поэтому воспроизвести Ваше утверждение на приаттаченной схеме буквально (вариант 1) - не получилось. Вы имели в виду вариант 2 или вариант 3?


Название: Re: Управление требованиями
Отправлено: Григорий Печенкин от 13 Ноября 2007, 15:25:14
(наивно) А направление движения справа налево - это очередное новведение UML? :)
Название: Re: Управление требованиями
Отправлено: Shur от 13 Ноября 2007, 15:59:02
2 greesha: sorry, поправил (IDEF3 попутал :)).
Название: Re: Управление требованиями
Отправлено: Gevorg от 13 Ноября 2007, 17:09:01
Gevorg? давай уж эти свои 10 требований :) и начнем их обсуждать. Я буду с использованием раквеста чур...
Вот, на вскидку:

1. Система должна обеспечивать учёт скрэтч-карт.
2. Система должна поддерживать интеграцию с Клиент-Банком.
3. Необходимо использование БАР-кодов для номеров скретч-карт.
4. Необходимо использование БАР-кодов для секретных кодов скретч-карт.
5. Необходимо применять EAN-систему бар-кодирования, поскольку это является корпоративным стандартом.
6. Система должна позволять регистрировать набор номеров скрэтч-карт путём ввода начального и конечного значения диапазона номеров.
7. Система должна давать возможность вводить номера карт, которые попадают в диапазон номеров для регистрации, но которые являются исключением, и регистрации не подлежат.
8. Регистрация в Системе прихода средств на счёт компании должна выполняться на основании информации из банка.
9. Регистрация в Системе прихода средств на счёт компании должна выполняться на основании телефонного звонка от финансового директора.
10. Система должна обеспечивать отчётность о текущем состоянии счёта компании.
11. Необходимо применять EAN-систему бар-кодирования, поскольку имеющееся в компании оборудование поддерживает только этот стандарт.
12. Необходима интеграция с внешними системами считывания бар-кодов.
13. Необходима интеграция с переносной системой считывания бар-кодов компании Х.
14. Система должна обеспечивать отчётность об истории прихода денег на счёт компании.
15. Система должна обеспечивать отчётность только по тем приходам, которые были зарегистрированы по звонку от финдиректора.

Нужно бы ещё придумать для них авторов, других заинтересованных лиц и их интересы, степень важности.

Набросок списка первых заданий студенту:
- классифицировать требования по 3-м уровням.
- Определить наличие и тип простейших зависимостей между требованиями одного уровня (детализация\агрегирование).
- Определить наличие связей проблема-решение между требованиями различных уровней.

и указать, что описывать требования так, чтобы эти задания легко можно было выполнить - проблема дизайнера требований.
Дело менеджера оных должно свестись к простой регистрации в определённом формате.
В нашем случае - заведению в РаКвесте.
Название: Re: Управление требованиями
Отправлено: Galogen от 13 Ноября 2007, 17:15:34
да управляем,или по крайней мере, - должны управлять,
только в рамках управления требованиями - намеренно абстрагируемся, считаем, что на производстве уже всё так, как нам надо
Т.е. мы имеем некий массив требований в каком-то виде. интересно в каком?
И уже управляем им, ничего, не прибавляя, но возможно убавляя. И как это процесс представляется?
Чем мы в данном контексте управляем? Версией? Статусом? Текстом требования?

Здесь должен помочь Джереми Дик - один из соавторов известной книжки от Телелоджика (преревод Ильи Корнипаева),
Книгу знаю, читаю. Нахожу много интересного.

Отсюда и терминологическая путаница в терминах дизайн-решение.
Давайте определятся с терминологией. Насколько я знаю создание глоссарие и единое понимание терминов - важнейшая часть любого проекта.
Название: Re: Управление требованиями
Отправлено: Galogen от 13 Ноября 2007, 17:26:41
Ага пошла живая работа. Правда я бы точна таких требований не напридумывал студентам :)
В лучшем случае что-то из области вуза.

Нужно бы ещё придумать для них авторов, других заинтересованных лиц и их интересы, степень важности.
т.е. список требований уже ранжирован изначально? типа это не работа управленца по требованиям?
Сразу вопрос, а какие роли проектные следует в таком случае выделять?


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


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


- Определить наличие связей проблема-решение между требованиями различных уровней.
А это что за связь?


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


Дело менеджера оных должно свестись к простой регистрации в определённом формате.
В нашем случае - заведению в РаКвесте.
Менеджера чего? Т.е. лица отвественного за требования, тот кто их формирует и утверждает?
Название: Re: Управление требованиями
Отправлено: Григорий Печенкин от 13 Ноября 2007, 17:26:50
Вот, на вскидку:

1. Система должна обеспечивать учёт скрэтч-карт.

Вах, какая сладкая тема!

Вопрос: что такое "регистрация"?

Ещё вопрос: что такое "учёт"? Предполагается ли учёт статуса карт - "загружена"/"продана"/"активирована"/...

Самый Главный Вопрос: "За что ему деньги плОтят?" Как связан cash flow со статусами карт? (Всю последнюю неделю стоим на ушах, из-за того что заказчик поменял схему расчётов с провайдером, применив способ, изначально никем не предусмотренный, огрёб из-за этого серьёзные финансовые претензии и попытался свалить их на нас).

Клиент-Банк - это вообще отдельная тема со своими требованиями, которые по сложности могут превысить основной функционал.


В общем, начинать надо, как написано в букварях, с составления глоссария и выявления бизнес-схем, используемых заказчиком.
Название: Re: Управление требованиями
Отправлено: Gevorg от 13 Ноября 2007, 17:56:03
Т.е. мы имеем некий массив требований в каком-то виде. интересно в каком?
И уже управляем им, ничего, не прибавляя, но возможно убавляя. И как это процесс представляется?
Чем мы в данном контексте управляем? Версией? Статусом? Текстом требования?
Появление новых требований в этой схеме тоже возможно.
Вот приблизительный возможный сценарий:

Для начала роли персон андер дискашшинз:
- Менджер требований (RM): центральная фигура, в фокусе нашего внимания,
- Дизайнер требований (RD): некий Умный и Всезнающий Дядя (УВД), способный закрыть любую дыру в проблемах с требованиями. Как работает - неизвестно, Что делает - не понятно, но проблему решает любую.
- Представитель Заказчика (CR): некая совсем уж обобщённая роль для любых действий, предполагаемых от Заказчика.

1. (CR): Звонит на фирму, просит выслушать его очередную хотелку.
2. (RM):
- Принимает звонок,
- регистрирует новое требование во внутренней системе управления Требованиями (СУТ).
- Признаётся, что ничего не понимает в словах (CR)-а,
- договаривается с ним и
- регистрирует в СУТ задачу для (RD): провести интервью и извлечь требование:
    "Поди туда, ЗНАЮ, куда, - возьми то, НЕ_ЗНАЮ, что.
3. (RD):
- Проводит интервью,
- уж неизвестно как изощряется, но
- приносит формулировку нового требования,
- его классификацию и связи с другими.
4. (RM):
- регистрирует выполнение задачи (RD)-мом,
- Регистрирует принесённые результаты в СУТ,
- обнаруживает, что (RD) забыл определить список заинтересованных лиц,
- ПЫТАЕТ оного по данному вопросу.
5. (RD):
- отделывается выбором заинтересованных лиц из списка уже имеющихся в СУТ,
- отбивается, чтобы не решать задачу формулировки их интересов по данному требованию.
6. (RM):
- регистрирует заинтересованных лиц, фиксирует напоминалку, что список заинтересованных лиц не проверен на полноту,
- регистрирует напоминалку, что список интересов по требованию не определён,
Название: Re: Управление требованиями
Отправлено: Galogen от 13 Ноября 2007, 18:08:11
Здорово.

Но...

Примерил это на RaQuest, и (его возможности пока знаю плохо, т.к. совершенно нет возможности проверить работу на коллективность - но зато есть стимул), думается мне, это там не возможно. Разве только в опции обсуждения.

Судя из контекста сценария - система управления требованиями должна также поддерживать и управление поручений и задач?
Название: Re: Управление требованиями
Отправлено: Irr от 13 Ноября 2007, 18:25:06
Примерил это на RaQuest, и (его возможности пока знаю плохо, т.к. совершенно нет возможности проверить работу на коллективность - но зато есть стимул), думается мне, это там не возможно. Разве только в опции обсуждения.
система статусов и групповая работа, в т.ч. и обсуждения имхо спасут и тебя, и отца русской демократии.
Судя из контекста сценария - система управления требованиями должна также поддерживать и управление поручений и задач?
В EA это есть, правда не юзала.
Название: Re: Управление требованиями
Отправлено: Galogen от 13 Ноября 2007, 18:31:33
система статусов и групповая работа, в т.ч. и обсуждения имхо спасут и тебя, и отца русской демократии.
Стоп стоп стоп. Ты хочешь сказать, что в RaQueste есть нечто под понятием раздача задач и поручений? Или это просто смена статуса ПМ?
Название: Re: Управление требованиями
Отправлено: Irr от 13 Ноября 2007, 18:38:40
EA и RQ близнецы братья, кто больше матери истории ценен... (покорябанный c)
Если есть в EA, то я могу набить требование в RQ, открыть EA и прицепить к нему что-нибудь еще, таск или баг.
Смена статуса возможна для требований, и режим обсуждений есть прям для требований - и вот это все есть в RQ
Название: Re: Управление требованиями
Отправлено: Gevorg от 13 Ноября 2007, 18:42:59
В общем, начинать надо, как написано в букварях, с составления глоссария и выявления бизнес-схем, используемых заказчиком.
ага, я тоже раньше так думал :-)
На самом деле  - требования рождаются ЗАДОЛГО до того, как появляется возможность подружить их в цельной картине глоссария и бизнес-процессов!
И первое дело - не помирить этот зоопарк, а распихать его насельников по соответствующим клеткам и террариумам, чтоб служащим не страшно (и вообще - возможно) было свою работу исполнять
и звери между собой потасовку не учинили. 
Название: Re: Управление требованиями
Отправлено: Gevorg от 13 Ноября 2007, 18:51:03
Вопрос: что такое "регистрация"?
Ещё вопрос: что такое "учёт"? Предполагается ли учёт статуса карт - "загружена"/"продана"/"активирована"/...
Клиент-Банк - это вообще отдельная тема со своими требованиями, которые по сложности могут превысить основной функционал.
Узнаю хватку и максимализм аналитика:
Пока требование не прояснено до конца - оно не имеет право на жизнь!!!
(а аналитик на спокойный сон) :-)

Название: Re: Управление требованиями
Отправлено: Gevorg от 13 Ноября 2007, 18:56:56
Но...
Примерил это на RaQuest, и (его возможности пока знаю плохо,
так ото-ж :-)
или мы укладываем в голове, ЧТО нужно делать с требованиями
или мучимся применить для этого любимое средство
Название: Re: Управление требованиями
Отправлено: Григорий Печенкин от 13 Ноября 2007, 19:16:11
Узнаю хватку и максимализм аналитика:
Пока требование не прояснено до конца - оно не имеет право на жизнь!!!
(а аналитик на спокойный сон) :-)

Я не аналитик, я только учусь. :) Пока преимущественно на своих ошибках. :(

Пока не определена терминология, а над проектом работает больше одного человека, требование может (и обязательно будет) истолковано неправильно.

Будет побольше времени - добавлю пару свежих примеров в ветку "Просчёты аналитиков".
Название: Re: Управление требованиями
Отправлено: Gevorg от 13 Ноября 2007, 19:32:03
т.е. список требований уже ранжирован изначально? типа это не работа управленца по требованиям?
именно, это работа дизайнера требований, которую преподаватель должен предварительно выполнить в подаваемом студенту варианте задания.


Сразу вопрос, а какие роли проектные следует в таком случае выделять?

Несовсем понял, что вы имеете в виду? И кто такой дизайнер требований?
Менеджера чего? Т.е. лица отвественного за требования, тот кто их формирует и утверждает?
О! вот это уже точно по нашей теме!
Начало - в моём наброске сценария приёма требования.
И если мы хотим что-то толковое родить в наших дискуссиях - то в этом должна обязательно присутствовать тщательно проработанная часть:
роли в процессе управления требованиями и их классификация

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

а если одно требование реализует несколько требований более высокого уровня, т.е. нет строгой иерархии
- Определить наличие связей проблема-решение между требованиями различных уровней.
А это что за связь?

это и есть упоминаемая Вами связь между требованиями различных уровней

и модель со связью: много_проблем - ко - многим_решениям, где Требование является классом-связью, реализующим эту связь многие-ко многим,
Гуры сознательно или подсознательно упрощают до: ОДНА_проблема- ко -многим_решениям, где требование строится путём добавления нужных атрибутов Проблеме.
Отсюда и двойственность в толковании терминов проблема и требование.
В последней модели: требование - это то же самое, что и проблема, только ещё с дополнительными атрибутами и прицепленным набором решения проблемы.
Название: Re: Управление требованиями
Отправлено: Gevorg от 13 Ноября 2007, 19:41:01
Пока не определена терминология, а над проектом работает больше одного человека, требование может (и обязательно будет) истолковано неправильно.
а никто и не спорит,
но прежде, чем требование будет истолковано неправильно (или будет создан глоссарий для его  однозначной ПЕРЕФОРМУЛИРОВКИ) - оно должно родиться и прожить какое-то время.
так что, пусть бомжует весь этот период?
или вообще займёмся "планированием семьи" требований, пока глоссарий и описание бизнес-процессов не подготовим? :-)
Название: Re: Управление требованиями
Отправлено: Григорий Печенкин от 13 Ноября 2007, 19:57:37
а никто и не спорит,
но прежде, чем требование будет истолковано неправильно (или будет создан глоссарий для его  однозначной ПЕРЕФОРМУЛИРОВКИ) - оно должно родиться и прожить какое-то время.
так что, пусть бомжует весь этот период?
или вообще займёмся "планированием семьи" требований, пока глоссарий и описание бизнес-процессов не подготовим? :-)


Это вопрос курицы и яйца. :)

Глоссарий формируется по мере формулирования требований, стандартными запросами "Переведи!" и "Шо конкретно вы имели в виду?"
Некоторые авторитеты рекомендуют, чтобы документ с требованиями (если такой имеется) оформлял один человек, но при этом он обязательно должен советоваться со всеми, кто этот документ собирается использовать.

Я сейчас одну крамольную вещь скажу. Мы вообще никаких глоссариев до сих пор не готовили. Не было необходимости. Все специалисты "в курсе" узкоспециальной терминологии, потому что имеют многолетний опыт работы в этой предметной области. Но при обработке требований обнаружились разночтения в понимании самых обычных, не жаргонных, слов русского языка. :)

То есть аналитик пишет, например: "данные операции должны учитываться при сверке итогов по тем же правилам, что и продажи". Разногласия возникли при интерпретации слова "данные". :)
Название: Re: Управление требованиями
Отправлено: Galogen от 13 Ноября 2007, 20:17:35
7. Система должна давать возможность вводить номера карт, которые попадают в диапазон номеров для регистрации, но которые являются исключением, и регистрации не подлежат.
Неясное требование. Что же должна делать система? Отлавливать карты с разрешенным диапазоном кодов, но какие-то бракованные?
Название: Re: Управление требованиями
Отправлено: Galogen от 13 Ноября 2007, 20:42:43
Что-то туго у меня с классификацией.

Потому пока вот такой расклад. Я не учитель, я ученик в требованиях

1.   Работа со скрэтч-картами
   a.   Система должна обеспечивать учёт скрэтч-карт.
   b.   Система должна поддерживать интеграцию с Клиент-Банком.
   c.   Необходимо применять EAN-систему бар-кодирования, поскольку это является корпоративным стандартом.
       i.   Необходимо применять EAN-систему бар-кодирования, поскольку имеющееся в компании оборудование поддерживает только этот стандарт.
       ii.   Необходимо использование БАР-кодов для номеров скретч-карт.
       iii.   Необходимо использование БАР-кодов для секретных кодов скретч-карт.
       iv.   Необходима интеграция с внешними системами считывания бар-кодов.
       v.   Необходима интеграция с переносной системой считывания бар-кодов компании Х.
   d.   Система должна позволять регистрировать набор номеров скрэтч-карт путём ввода начального и конечного значения диапазона номеров.
       i.   Система должна давать возможность вводить номера карт, которые попадают в диапазон номеров для регистрации, но которые являются исключением, и регистрации не подлежат.

2.   Приход средств
   a.   Регистрация в Системе прихода средств на счёт компании должна выполняться на основании информации из банка.
   b.   Регистрация в Системе прихода средств на счёт компании должна выполняться на основании телефонного звонка от финансового директора.

3.   Отчетность по счету
   a.   Система должна обеспечивать отчётность о текущем состоянии счёта компании.
   b.   Система должна обеспечивать отчётность об истории прихода денег на счёт компании.
   c.   Система должна обеспечивать отчётность только по тем приходам, которые были зарегистрированы по звонку от финдиректора.

Несовсем понял из задания. Нужно ли самому придумать, если нет, но подразумеваются: бизнес требования, требования пользователей? Или нужно действовать в жестких рамках предложеного списка, не добавляя и не убавляя
Название: Re: Управление требованиями
Отправлено: Galogen от 13 Ноября 2007, 22:23:21
Вот так всегда. Начинаешься кучу книг, кажется, все знаешь. Но стоит столкнуться с реальной задачей и пасуешь.

Однако на ум приходит фраза из детства. Был такой журнал. Что-то типа:
"Орешек знаний тверд. Но расколоть его поможет киножурнал 'Хочу все знать'"

Так что попытка №2. Классификация

Скажем так нужды
3. Необходимо использование БАР-кодов для номеров скретч-карт.
4. Необходимо использование БАР-кодов для секретных кодов скретч-карт.
5. Необходимо применять EAN-систему бар-кодирования, поскольку это является корпоративным стандартом.
11. Необходимо применять EAN-систему бар-кодирования, поскольку имеющееся в компании оборудование поддерживает только этот стандарт.
12. Необходима интеграция с внешними системами считывания бар-кодов.
13. Необходима интеграция с переносной системой считывания бар-кодов компании Х.


Системные требования
1. Система должна обеспечивать учёт скрэтч-карт.
2. Система должна поддерживать интеграцию с Клиент-Банком.
6. Система должна позволять регистрировать набор номеров скрэтч-карт путём ввода начального и конечного значения диапазона номеров.
7. Система должна давать возможность вводить номера карт, которые попадают в диапазон номеров для регистрации, но которые являются исключением, и регистрации не подлежат.
8. Регистрация в Системе прихода средств на счёт компании должна выполняться на основании информации из банка.
9. Регистрация в Системе прихода средств на счёт компании должна выполняться на основании телефонного звонка от финансового директора.
10. Система должна обеспечивать отчётность о текущем состоянии счёта компании.
14. Система должна обеспечивать отчётность об истории прихода денег на счёт компании.
15. Система должна обеспечивать отчётность только по тем приходам, которые были зарегистрированы по звонку от финдиректора.

Продолжим издевательства над требованиями:

3. Необходимо использование БАР-кодов для номеров скретч-карт.
4. Необходимо использование БАР-кодов для секретных кодов скретч-карт.

5. Необходимо применять EAN-систему бар-кодирования, поскольку это является корпоративным стандартом.
    11. Необходимо применять EAN-систему бар-кодирования, поскольку имеющееся в
         компании оборудование поддерживает только этот стандарт.
{хотя неочень четко понимаю разницу - и это как-то ближе к бизнес-правилу, по карйней мере что касается требования 5}

12. Необходима интеграция с внешними системами считывания бар-кодов.
      13. Необходима интеграция с переносной системой считывания бар-кодов компании Х.



1. Система должна обеспечивать учёт скрэтч-карт.
    6. Система должна позволять регистрировать набор номеров скрэтч-карт путём ввода начального и конечного значения диапазона номеров.
    7. Система должна давать возможность вводить номера карт, которые попадают в диапазон номеров для регистрации, но которые являются исключением, и регистрации не подлежат.


8. Регистрация в Системе прихода средств на счёт компании должна выполняться на основании информации из банка.
    2. Система должна поддерживать интеграцию с Клиент-Банком.

9. Регистрация в Системе прихода средств на счёт компании должна выполняться на основании телефонного звонка от финансового директора.

10. Система должна обеспечивать отчётность о текущем состоянии счёта компании.
14. Система должна обеспечивать отчётность об истории прихода денег на счёт компании.
15. Система должна обеспечивать отчётность только по тем приходам, которые были зарегистрированы по звонку от финдиректора.
Название: Re: Управление требованиями
Отправлено: Gevorg от 14 Ноября 2007, 11:14:35
Неясное требование. Что же должна делать система? Отлавливать карты с разрешенным диапазоном кодов, но какие-то бракованные?
:-) ОК, я, типа, ТОП от Заказчика, Вы - обескураженный Аналитик:
ну чё непАнатнАга? :
сидит девка, заносит в систему приход новой пачки карт:
клац штрих-сканнером спереди- номер первой карточки,
клац сззади - номер последней,
пАсьмАтрела - на пачке написана бракованная карточка, которую выкинули,
вбила её номер пальцами.
Всё: все карточки из пачки шоб в системе были, а бракованной - шоб не было.
Название: Re: Управление требованиями
Отправлено: Gevorg от 14 Ноября 2007, 11:41:07
Вот так всегда. Начинаешься кучу книг, кажется, все знаешь. Но стоит столкнуться с реальной задачей и пасуешь.

Однако на ум приходит фраза из детства. Был такой журнал. Что-то типа:
"Орешек знаний тверд. Но расколоть его поможет киножурнал 'Хочу все знать'"
да и орешек НЕ слабый на самом деле:
давайте нанесём первый удар в плоскости уровней: Бизнес-Юзер-Систем,
без разбору остальной классификации.

З.Ы. я хоть и старался каждое из них писать удобным для однозначной классификации, но возможны и ляпы, так что заранее прошу не пинать ногами :-)
всегда готов исправиться, если увидим чего не так.
тем более, что пример учебный и можно себе позволить некоторый волюнтаризм...
но на то и greesha на форуме, чтоб Gevorg не дремал... :-)
Название: Re: Управление требованиями
Отправлено: Gevorg от 14 Ноября 2007, 11:46:35
Несовсем понял из задания. Нужно ли самому придумать, если нет, но подразумеваются: бизнес требования, требования пользователей? Или нужно действовать в жестких рамках предложеного списка, не добавляя и не убавляя
пока новых требований придумывать не надо, и без того мороки хватит,
да и новых уровней постараемся не вводить, я когда придумывал требования, ориентировался только на 3: B-U-S
Название: Re: Управление требованиями
Отправлено: Gevorg от 14 Ноября 2007, 12:21:22
Это вопрос курицы и яйца. :)
полностью согласен про рекурсию с уточнениями ОПИСАНИЯ_СУЩНОСТИ_требований и глоссария, и что в разных проектах её началом может быть как одно, так и другое.
но как быть со случаем в моём примере сценария, когда Требование уже зарегистрировано, а его описания, как такового, пока нет вААще?
это я снова стараюсь обратить внимание на то, что у требования, кроме его описания и смысла, который за ним стоит, - есть ещё целая пачка важных атрибутов.

чтобы далеко не ходить:
Всю последнюю неделю стоим на ушах, из-за того что заказчик поменял схему расчётов с провайдером, применив способ, изначально никем не предусмотренный, огрёб из-за этого серьёзные финансовые претензии и попытался свалить их на нас.
а по нашей теме: где здесь требования?
если я правильно понял, то:
- Заказчик изменил бизнес-процесс, и не сообщил об этом Разработчику,
- Заказчик использовал имеющийся в системе набор решений для реализации какого-то нового или обновлённого фрагмента в изменённом бизнес-процессе,
   (заметим: снова не сообщил об этом Разработчику)
- как результат - Заказчик получил проблему в области своего бизнеса,
- Заказчик пытается разделить или полностью перенести на Разработчика ответственность за возникновение проблемы и за её решение.

Так где здесь проблемы НЕДопонимания или разночтения сути требования?
Здесь чистой воды ряд убийственных просчётов в области МЕНЕДЖМЕНТА оных.
Название: Re: Управление требованиями
Отправлено: Gevorg от 14 Ноября 2007, 12:39:29
Клиент-Банк - это вообще отдельная тема со своими требованиями, которые по сложности могут превысить основной функционал.
Дак Эдуарду как раз и нужно МНОГО требований,
точнее МНОГО вариантов для набора требований,
достаточно отличающихся между собой, чтобы затруднить списывание и плагиат.

Итак, нам нужен достаточно большой, но без примитивного фанатизма (300шт - занадто и НЕ здраво) набор простых требований,
позволяющий скомбинировать из них 30 мало пересекающихся вариантов набора требований,
 как материала для заданий по курсу управления требованиями.
Название: Re: Управление требованиями
Отправлено: Gevorg от 14 Ноября 2007, 13:13:16
Вопрос: что такое "регистрация"?
Эдуард, берите в коллекцию!
 возникла задача менеджмента требований:
-  уточнить термин  "регистрация"
- внести необходимые правки в описание требований: 6,8,9, содержащих эти требования, возможно,-
- провести ревизию описаний остальных требований на предмет использования синонимов.

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


Ещё вопрос: что такое "учёт"? Предполагается ли учёт статуса карт - "загружена"/"продана"/"активирована"/...
Эдуард, ещё находка: Появилось новое требование.
По нему задача: зарегистрить в СУТ.


Результатом должно быть что-то в роде:

Требование
№: 15.
Описание: В учёте отслеживать статус карт: "загружена"/"продана"/"активирована"/...
Автор: greesha (роль в проекте: сторонний консультант),
Статус: предложено,
Связь: подтребование(составная часть) от тр1.
Важность для Заказчика: 100%
Ответственность: Galogen (роль в проекте: регистратор изменений в требованиях)

Название: Re: Управление требованиями
Отправлено: Григорий Печенкин от 14 Ноября 2007, 14:53:50
О, меня уже посчитали. :)

Как сторонний консультант, прошу для начала разъяснить бизнес-логику.
Прежде всего прошу ответа на такие вопросы.

1. Чем занимается Компания-закзачик:
- производством скретч-карт
- предоставлением услуг, оплачиваемых с помощью скретч-карт
- распространением скретч-карт как основным бизнесом
- перепродажей скретч-карт в дополнение к основному бизнесу
- утилизаций использованных скретч-карт ;)
- распространением ворованных и поддельных карт ;)
- другое

2. Как "поступление средств" на счёт компании связано с учётом карт (ответ на предыдущий вопрос может содержать ответ на этот вопрос. Но может и не содержать, особенно учитывая загадочное требование "на основании телефонного звонка от финансового директора").

3. Для чего используются скретч-карты (оплата мобильной связи, оплата междугородной связи, доступ в интернет, web-деньги, другое...)
Предполагается обработка карт только одного типа или разных типов?

4. Существуют ли разные номиналы скретч-карт и зависит ли обработка от номиналов? Какие вообще атрибуты есть у карт, кроме серийного номер, и как они влияют на обработку (предельная дата активации, срок действия, ссылки на других провайдеров или лоялти-программы и т. п.)?

5. Предполагаемый объём базы данных - сколько ориентировочно карт может быть учтено и в течение какого периода?
Название: Re: Управление требованиями
Отправлено: Galogen от 14 Ноября 2007, 14:59:50
Gevorg давайте (а может на ты, проще общаца) не будем торопица.

Еще не все ладно с классификацией, тем более нужно сразу сконфигурировать хранилище, которое я буду делать в RaQuest.

Я уже начал его формировать и сделал структуру: Бизнес-требования, Пользовательские требования, Функциональные требования

Далее предполагаю пораскидать требования по структуре. Пока никаких пакетов внутри данной структуры не делаю - просто иерархический список требований - если таков возможен.

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

То есть требование Система должна обеспечивать учёт скрэтч-карт превращается в Обеспечить учет срэтч-карт с описанием Система должна обеспечивать учёт скрэтч-карт.

Далее что с нумерацией? придерживаться предложенной Вами? или разрешить автонумерацию?

Потом я включу Ваши указания по требованиям
Название: Re: Управление требованиями
Отправлено: Galogen от 14 Ноября 2007, 15:00:39
Да - а что такое срэтч-карта (простите за наивность)
Название: Re: Управление требованиями
Отправлено: Григорий Печенкин от 14 Ноября 2007, 15:07:24
Да - а что такое срэтч-карта (простите за наивность)

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

Как мне представляется, скретч-карта - это карточка с секретным кодом, скрытым под защитным слоем. Клиент приобретает эту карту, стирает защитный слой и каким-то образом использует секретный код для доступа к какой-либо услуге.
Название: Re: Управление требованиями
Отправлено: Григорий Печенкин от 14 Ноября 2007, 15:08:49
Или это была просто шутка юмора, как комментарий к опечатке? :)
Название: Re: Управление требованиями
Отправлено: Gevorg от 14 Ноября 2007, 15:14:24
Gevorg давайте (а может на ты, проще общаца) не будем торопица.

Огромное сорри!
>общаца и торопица
это только в плане стёба над спецификой общения с ТОПами,
и только в пределах одного пОста,
в личном плане - ничего подобного и в мыслях не было,
да и по отношению к себе не люблю.
Название: Re: Управление требованиями
Отправлено: Galogen от 14 Ноября 2007, 15:18:40
Как мне представляется, скретч-карта - это карточка с секретным кодом, скрытым под защитным слоем. Клиент приобретает эту карту, стирает защитный слой и каким-то образом использует секретный код для доступа к какой-либо услуге.
Ага, теперь понятно, было что-то в подсознании из опыта использования интернет-карт
Название: Re: Управление требованиями
Отправлено: Galogen от 14 Ноября 2007, 15:20:29
Огромное сорри!
>общаца и торопица
это только в плане стёба над спецификой общения с ТОПами,
и только в пределах одного пОста,
в личном плане - ничего подобного и в мыслях не было,
да и по отношению к себе не люблю.
Это Вы что, типа обиделись?
Название: Re: Управление требованиями
Отправлено: Gevorg от 14 Ноября 2007, 15:33:06
Еще не все ладно с классификацией,
и у меня не всё ладно, это как раз то, что нам надо:
- с классификацией требований - проблемы,
- общей картины по бизнесу нет, одни осколки,
- СУТЬ, описанная в документе с требованиями, - не выдерживает никакой критики,
- хамовитый ТОП наезжает со своими манерами общения,
и т.д.

задача курса: создать Систему работы с требованиями - чтобы эти проблемы были - как на ладони, и чтобы она помогала решать эти проблемы.
Название: Re: Управление требованиями
Отправлено: Gevorg от 14 Ноября 2007, 15:38:52
Это Вы что, типа обиделись?
да пока не было малейшего повода обижаться,
я только хотел сказать, что сам не люблю фамильярности
и очень боюсь проявлять оную по отношению к другим,
а тем более - на людях, т.е. на форуме.
Название: Re: Управление требованиями
Отправлено: Gevorg от 14 Ноября 2007, 16:07:45
А то у меня уже почти сложилось мнение, что аналитики - это такие волшебники, которые могут проанализировать и смоделировать что угодно, не вникая в физическую сущность проблемы.
greesha, мне тоже очень нравится "вникать в физическую сущность проблемы", честно,
еле сдерживаюсь, чтобы самому не пОстить свои соображения по моделированию этой сАмой "физической сущности".

у нас уже обзначилось распределение ролей в изучаемом нами процессе управления требованиями по участникам обсуждения:
- Вы, greesha, - законный эксперт по формулировкам и пониманию СУТИ каждого требования,
- я взял себе роль ведущего манагера по требованиям, которому просто губительно вникать в суть требований, и без того вокруг них работы полно,
- Galogen добровольно (и очень добросовестно) взялся за работу моего подчинённого-исполнителя,
но на самом деле - это для него должно быть только в режиме парт-тайма,
его главная роль - ВНЕ самого процесса: учредитель проекта,
в рамках которого нужно:
-  построить и запустить "стендовый" процесс управления требованиями,
-  собрать на результатах методический материал для проведения курса своим студентам.
Название: Re: Управление требованиями
Отправлено: Gevorg от 14 Ноября 2007, 16:20:28
Как мне представляется, скретч-карта - это карточка с секретным кодом, скрытым под защитным слоем. Клиент приобретает эту карту, стирает защитный слой и каким-то образом использует секретный код для доступа к какой-либо услуге.
Galogen, ещё +1, в буквальном смысле, -  золотой самородок в Вашу копилку метод-материалов:
для менеджмента требований - это то, что обязательно должно быть внесено в Глоссарий, и на что обязательно нужно проставить ссылки из описаний соответствующих требований.

для курса по дизайну - это образец ответа на 5баллов из пяти,
по вопросу "что такое сретч-карта":
коротко, точно, ёмко, понятно.
Название: Re: Управление требованиями
Отправлено: Григорий Печенкин от 14 Ноября 2007, 16:50:59
- я взял себе роль ведущего манагера по требованиям, которому просто губительно вникать в суть требований, и без того вокруг них работы полно,

Я до сих пор не верю, что это возможно в успешных проектах - управлять требованиями, не вникая в их суть.


Задача стоит, конечно, учебная, и мои вопросы вполне могуть быть лишними. Но посмотрите внимательно на начальные "зарегистрированные" десять требований и варианты ответа на мой первый вопрос "Чем занимается Заказчик?"

Разные ответы на этот вопрос ведут к созданию разных систем. Отвечающих одим и тем же требованиям. Это означает, конечно, что требования неполны.


Вы говорите об "управлении требованиями" как о втором уровне зрелости CMMI (вон каких я умных слов нахватался :) ), когда предполагается, что требования разработаны заказчиком. Но пример, похоже, не соответствует этому условию - первые требования появляются из общей концепции системы, которую мы пропустили (или только я пропустил?) Эти начальные требования отсутствуют - значит, либо нужно их тоже перечислить (смоделировав второй уровень), либо разработать самостоятельно, выявив реальные потребности заказчика (третий уровень).

Обе задачи, наверное, могут использоваться как учебные.
Название: Re: Управление требованиями
Отправлено: Gevorg от 14 Ноября 2007, 18:28:12
Я до сих пор не верю, что это возможно в успешных проектах - управлять требованиями, не вникая в их суть.
полностью согласен, более того,
я уже опытно знаю, что это - просто ересь.

похоже - нужно уточнить так:
мне нужно абстрагироваться от РЕШЕНИЯ проблем с вниканием в суть,
а "пользоваться готовеньким"  - так это  обязательно:
эдак озадачить Вас и других участников форума, чтоб проясняли и детализировали, что значит каждая формулировка в описании требований,
и самому - собирать и оценивать результаты,
а черновую работу по занесению и отслеживанию актуальности данных по требованиям переложить на Эдуарда в роли своего помощника.

Название: Re: Управление требованиями
Отправлено: Galogen от 14 Ноября 2007, 18:49:44
а черновую работу по занесению и отслеживанию актуальности данных по требованиям переложить на Эдуарда в роли своего помощника.
Окей окей, я уже тружусь в поте лица. Однако как мы будем обмениваться информацией хотя бы. Есть ли у коллег RaQuest в каком-либо виде?

Или я пока требования фиксирую скажем в Excel? И выкладываю.

С чем сразу нужно определиться?
1. типы требований (по-русски | по-ангельски)
2. статусы требований (аналогично)
3. приоритеты требований (аналогично)
4. риски (аналогично)
5. сложность (аналогично)
6. стабильность (аналогично)
7. дополнительные атрибуты по требованиям?
8. формировать ли требования по группам с соотвествующей нумерацией внутри группы или делать сквозную нумерацию без префикса группы, а группировать через тип требования

Название: Re: Управление требованиями
Отправлено: Galogen от 14 Ноября 2007, 18:55:11
Вы говорите об "управлении требованиями" как о втором уровне зрелости CMMI (вон каких я умных слов нахватался :) ), когда предполагается, что требования разработаны заказчиком. Но пример, похоже, не соответствует этому условию - первые требования появляются из общей концепции системы, которую мы пропустили (или только я пропустил?) Эти начальные требования отсутствуют - значит, либо нужно их тоже перечислить (смоделировав второй уровень), либо разработать самостоятельно, выявив реальные потребности заказчика (третий уровень).
Обе задачи, наверное, могут использоваться как учебные.
Первая задача более или менее возможна к исполнению.
Вторая задача исключена - нет реального заказчика, либо его роль должен буду играть я, а для этого я должен иметь хорошо прописанный смоделированнный бизнес-кейс.

Каков риск - логика и опыт у каждого свои, соотвественно будут совершенно разные формулировки, оценить правильность или неправильность которых может оказаться сложной задачей.
Название: Re: Управление требованиями
Отправлено: Galogen от 14 Ноября 2007, 19:51:53
Ну и для наглядности

Ну пока типа бизнес требования в некоторой соподчиненности
(http://www.isuct.ru/~ivt/foruml2/Бизнес-требования.png)

Это функциональные требования. Выбраны по признаку "система должна"
(http://www.isuct.ru/~ivt/foruml2/ФункциональныеТребования.png)
Название: Re: Управление требованиями
Отправлено: Gevorg от 14 Ноября 2007, 20:07:12
...как мы будем обмениваться информацией хотя бы. Есть ли у коллег RaQuest в каком-либо виде?
на д.м. у меня есть ЕА, что нужно, чтобы подключить к нему RaQuest и смотреть результаты "вживую"?
Название: Re: Управление требованиями
Отправлено: Gevorg от 14 Ноября 2007, 20:30:06
нет реального заказчика, либо его роль должен буду играть я, а для этого я должен иметь хорошо прописанный смоделированнный бизнес-кейс.

Каков риск - логика и опыт у каждого свои, соотвественно будут совершенно разные формулировки, оценить правильность или неправильность которых может оказаться сложной задачей.
Galogen, здесь у нас есть greesha: експерт по любым нашим вопросам, касающимся сущности бизнеса, правильности бизнес-кейзов и формулировок в описании любых требований.
Вы только, как Учредитель Проекта и Потребитель его результата, дайте визу на функциональные обязанности нашим ролям в процессе управления требованиями:
Ему:
- прояснЯть обнаруженные вопросы по бизнес-кейзу,
- и другим вопросам, касательно "физической сути" требований,
- формулировать описание требования,
- оценивать качество этого описания,
- оценивать правильность и неправильность формулировок и т.д.

а мне:
- регистрить для него задачи,
- принимать от него и регистрить в СУТ результаты,
- принимать решения на основании этих результатов.
Название: Re: Управление требованиями
Отправлено: Galogen от 14 Ноября 2007, 20:34:28
на д.м. е меня есть ЕА, что нужно, чтобы подключить к нему RaQuest и смотреть результаты "вживую"?
Ничего не нужно кроме лицензии. Однако, елси мы управимся за месяц можно спокойно скачать оценочную месячную версию с сайта производителя www.raquest.com

Затем установить программу и все.

Сейчас я использую RaQuest 2.4 (лицензионный) академическая лицензия обошлась в 75 долларов.
и ЕА 7.0 815 билд (пока не лицензионный) академ лицензия стоит 65 долларов. Но после покупки раквеста подожду.

я сформировал список требований в RaQuest используя формат rde. Другой тип форматов eap. Несовсем точно понимаю в чем их отличие. Оба хорошо открываются с помощью Access.
В rde файле фактически хранятся текстовые описания.Однако если в меню выбрать Tools/Run EA, то автоматически загружается EA и все текстовые требования превращаются в графическое представление.
Далее я создаю в каждом пакете требования по графической диаграмме и перетаскиваю требования.
Если создавать графические связи в ЕА, то эти связи потом будут отображаться и в матрице трассировки требований в раквесте.

Таким образом можно упростить связывание и редактирование связей в ЕА и иметь возможность отбора и манипулирования требованиями в раквесте
Название: Re: Управление требованиями
Отправлено: Galogen от 14 Ноября 2007, 20:43:04
Вы только, как Учредитель Проекта и Потребитель его результата, дайте визу на функциональные обязанности нашим ролям в процессе управления требованиями:
Gevorg, а мы согласие greesha получили на экзекуцию?

Однако когда я писал ему ответ, я имел в виду немного другой аспект. А именно организацию практических занятий с моим личным участием и участием студентов. Greesha и ВАС рядом не будет. Буду только я азм есть.

Обратите внимание, какая интересная дискуссия возникла между нами, т.е. среди команды, в которой:
Gevorg - ясно представляет, что мы делаем
Greesha - отлично разбирается в предмете разговора и тоже не мальчик
Galogen - самый недоразвитый, но все-таки высоко мотивированный и очень начитанный

Забавная троица 3G, может нам домен срочно забронировать под таким соусом? :)

Ключевой фразой, триггером понимания проблемы служит слово "мотивированный".

Очень сложно студента мотивировать.

Дополнительный аспект это жизненный опыт - который играет страшно немаловажную роль.
Название: Re: Управление требованиями
Отправлено: Galogen от 14 Ноября 2007, 20:45:16
Вы как Учредитель Проекта и Потребитель его результата, дайте визу

Ему:

а мне:

Может еще раз обсудим объявим обязанности каждой стороны, ее ограничения. Например мне не совсем понятна моя роль.
Название: Re: Управление требованиями
Отправлено: Galogen от 15 Ноября 2007, 10:08:24
Вопросы по требованиям:

003 Необходимо использование БАР-кодов для номеров скретч-карт
      1. Что такое БАР-код

004 Необходимо использование БАР-кодов для секретных кодов скретч-карт
      2. Каким образом считывается секретный код, т.е. как определяется считывание именно секретного кода, а не номера карточки

006 Система должна позволять регистрировать набор номеров скрэтч-карт путём ввода начального и конечного значения диапазона номеров
013 Система должна давать возможность вводить номера карт, которые попадают в диапазон номеров для регистрации, но которые являются исключением, и регистрации не подлежат
      3. в пояснении было написано, что регистратор вводит вручную номер бракованной карты - неясность с БАР-кодом и использованием оборудования для его ввода

002 Система должна поддерживать интеграцию с Клиент-Банком
      4. Да все-таки, что такое Клиент-Банк, название реального банка с которым сотрудничает корпорация или один из многих банков-клиентом

008 Регистрация в Системе прихода средств на счёт компании должна выполняться на основании информации из банка
      5. Предлагется переформулировка - Система должна регистрировать приход средств на счёт компании на основании информации из банка
      6. Уточнить что такое информация из банка (квитанция, переданная каким-либо образом, автоподтверждение ИС банка)

009 Регистрация в Системе прихода средств на счёт компании должна выполняться на основании телефонного звонка от финансового директора
      7. Чем отличается регистрация по звонку финдиректора, когда она происходит, чем отличается от требования 008. Вопрос коррелирует и к требованию 015
      8. Переформулировка: Система должна регистрировать приход средств на счёт компании на основании
телефонного звонка финансового директора

      9. Чем отличаются кроме формулировки требования 005 и 011
Название: Re: Управление требованиями
Отправлено: Gevorg от 15 Ноября 2007, 11:12:02
Может еще раз обсудим объявим обязанности каждой стороны, ее ограничения. Например мне не совсем понятна моя роль.
распределения ещё не было, объявления - тоже,
я по-осторожничал, и написал, что ОБОЗНАЧИЛИСЬ роли и их распределение между участниками форума :-)
1. Вы, как инициатор темы и заявитель Основной своей Потребности -
получаетесь и Спонсор, и Инициатор зародившегося проекта:
- Это именно Вам в первую очередь нужно собрать методический материал для ВУЗ-овского курса "Управление требованиями".
- именно Вашей активностью на форуме держится вся работа вокруг этого,
- именно в контексте Ваших интересов и пожеланий должна вестись работа в рамках данной темы.

2. С другой стороны - Вы взяли на себя часть работ по управлению требованиями:
- настроить соответствующее ПО,
- научиться им пользоваться и научить других,
- вносить туда, в это хранилице, требования, из процесса, который мы строим на форуме,
- поддерживать требования в актуальном состоянии и доносить все изменения до остальных участников проекта.
А это всё - обязанности Менеджера Требований, но только часть, поэтому пришлось ввести роль Джуниор Реквайеремент-манагера и открыто сказать, что фактически - Вы её уже исполняете.

И та и та роль в контексте Исполнитель - Заказчик нашей гипотетической разработки ПО лежит в области Исполнителя.
по первой роли, Вы - Инициатор ВНУТРЕННЕГО проекта,
по второй -  "рабочее звено" во внешнем проекте: написание заказного ПО.
Название: Re: Управление требованиями
Отправлено: Irr от 15 Ноября 2007, 11:15:33
Есть ли у коллег RaQuest в каком-либо виде?
Или я пока требования фиксирую скажем в Excel? И выкладываю.
Даже если у коллег нет RaQuest'а, тебе не зачем фиксировать все в Excel, ведь raQuest умеет делать экспорт в эксель. И импорт из csv. Заодно и проверим, хорошо ли он это умеет делать. Так что не надо мучицца ;-)
Название: Re: Управление требованиями
Отправлено: Galogen от 15 Ноября 2007, 11:24:42
Даже если у коллег нет RaQuest'а, тебе не зачем фиксировать все в Excel, ведь raQuest умеет делать экспорт в эксель. И импорт из csv. Заодно и проверим, хорошо ли он это умеет делать. Так что не надо мучицца ;-)
Солнышко, я и делал экспорт в Эксель и совершенно не мучился :)
Название: Re: Управление требованиями
Отправлено: Irr от 15 Ноября 2007, 11:30:59
Солнышко, я и делал экспорт в Эксель и совершенно не мучился :)
(Ковыряя носком туфельки паркет) - ну я так, на всякий случай, ибо мало ли чего...
Название: Re: Управление требованиями
Отправлено: Gevorg от 15 Ноября 2007, 11:50:54
Вопросы по требованиям:
 1. - 9.
RM(Gevorg) to JRM(Galogen):
у нас не более 2-х десятков требований,
по некоторым из них есть
- вопросы-ответы (т.е. внутреннее обсуждение между исполнителями),
- есть дополнительные разъяснения от Заказчика,
- есть  уточнения формулировок и Заключения от Аналитика-Консультанта(Greesha)
По-секрету от Заказчика и коллег по разработке честно признаЮсь Вам,
что я уже НЕ в состоянии это всё держать под контролем.

Что там РаКвест? Вы можете в ём как-то форумное обсуждение разместить и оттрассировать пОсты и требования?
Название: Re: Управление требованиями
Отправлено: Gevorg от 15 Ноября 2007, 12:10:24
Gevorg(во всех ролях на форуме)  To ALL участников  обсуждения и простых читателей:
заранее прошу прощения за возможные задержки с ответами в теме.

Моя передышка на работе подходит к концу, завтра - старт нового проекта,
поэтому могу вообще на целый день выпасть из нашего виртуального проекта на форуме.

Всю следующую неделю тоже не могу гарантировать стабильную не то что работу на форуме, но даже и пассивное чтение.
Возможно, что-то получится сделать на этих выходных.


Название: Re: Управление требованиями
Отправлено: Gevorg от 15 Ноября 2007, 12:53:49
RM(Gevorg) to \
                       \JRM(Galogen):
По-секрету от Заказчика и коллег по разработке честно признаЮсь Вам,
что я уже НЕ в состоянии это всё держать под контролем.

Что там РаКвест? Вы можете в ём как-то форумное обсуждение разместить и оттрассировать пОсты и требования?
Gevorg(в роли ПМ проекта по сбору метод-материала для студенотов) to
 Galogen(в роли учредителя проекта):

вот ещё пример студентам:

ошибка в менеджменте требований:
RM(Gevorg) НЕ замечает общую КОНЦЕПТУАЛЬНУЮ проблему,
 пытается подменить её частной задачей трассировки и решить её с помощью РаКвест.

А проблема в том, что RM(Gevorg) до сих пор ещё не вооружён КОНЦЕПТУАЛЬНОЙ_МОДЕЛЬЮ и регламентом процесса по управлению требованиями.
Он не просто не в состоянии "разложить по полочкам" очень быстро накопившийся материал,
у него нет САМИХ полочек, у него даже нет ещё отчётливого понимания, какими они должны быть.

Отсюда и робкий вопрос подчинённому вместо уверенного отдавания распоряжения,
отсюда и судорожные попытки "закрыть дыру" своими средствами.

Правильные действия в этом случае - идти "наверх",
не к подчинённому, а руководству:

                      /ProcessRequirementBoss(Galogen):
RM(Gevorg) to /

Проект разработки ПО уже давно стартонул,
работы по сбору и анализу требований уже ведутся полным ходом,
самИх требований ещё совсем мало,
а по ним уже накопилась куча материала,
ещё немного - и работа над сбором и анализом требований превратится в хаотический и безрезультатный процесс.

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

Срочно нужно всё упорядочивать:
- рисовать диаграммы моделей процесса управления требованиями в нашем случае,
- писать по ним инструкции и регламент и
- ставить этот процесс на рельсы.

Иначе - утонем в, на самом деле, умных дебатах о "физической сути" каждого из требований.
Название: Re: Управление требованиями
Отправлено: Григорий Печенкин от 15 Ноября 2007, 13:47:56
Да не утонем. Надо сначала парой абзацев описать назначение разрабатываемой системы (к вопросу о целеполагании), а потом уже приводить примеры требований. Иначе студенты попытаются заполнить пробелы в понимании самостоятельно (те, кто пытается думать, конечно) и насинтезируют заказчику таких потребностей...

А то я тут ещё один вариант скретч-карт вспомнил, не подходящий под данее раньше определение. :) Есть такие карты, которые выдаются клиенту бесплатно, и содержат при этом не один, а несколько десятков скретч-кодов (например, для совершения удалённо операций с банковским счётом). Имеем ещё один вариант системы, удовлетворяющий перечисленным требованиям, но совершенно не похожий на все остальные.
Название: Re: Управление требованиями
Отправлено: Gevorg от 15 Ноября 2007, 15:48:12
Да не утонем.
если проект такой, что не утонем
- то и управление требованиями в том моём понимании, каким я хотел поделиться, не нужно,
только лишние ресурсы у Разработчика  съест


Надо сначала парой абзацев описать назначение разрабатываемой системы (к вопросу о целеполагании), а потом уже приводить примеры требований.
кажется, я начинаю понимать сущность наших разногласий с greesha:

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

а greesha в соответствии со своими законными обязанностями на работе - тут же на них набрасывается и "приговаривает к расстрелу"

вот и сейчас:
ситуация с отсутствием вижина - явно неправильная для проекта по разработке ПО,
а для нашего с Galogen-ом - так законный пример, который нужно далее развить:
вот начальна НЕправильная ситуация, а вот - как её исправлять и что должно получиться,
к вопросу о целеполагании
для greesha - главная цель: построить кондиционные требования,
а для меня - смоделировать проблему при работе с требованием, и показать, как она решается или вообще НЕ возникает, если правильно построить менеджмент.

Название: Re: Управление требованиями
Отправлено: Григорий Печенкин от 15 Ноября 2007, 16:01:55
кажется, я начинаю понимать сущность наших разногласий с greesha:

ситуация с отсутствием вижина - явно неправильная для проекта по разработке ПО,
а для нашего с Galogen-ом - так законный пример, который нужно далее развить:

Может, причина наших разногласий в том, что мы по-разному поняли Концепцию проекта "Практикум по управлению требованиями"? ;)

Тогда обращаемся к первоисточнику:
http://www.uml2.ru/forum/index.php?topic=487.msg5535#msg5535
и пытаемся уточнить потребности Заказчика (в роли которого в данном случае выступает Galogen).
Название: Re: Управление требованиями
Отправлено: Gevorg от 15 Ноября 2007, 16:11:19
А то я тут ещё один вариант скретч-карт вспомнил, не подходящий под данее раньше определение. :)
я предлагаю это зафиксировать в качестве варианта, как второе предположение(версия) Эксперта по требованим относительно термина Срэтч-Карта.
а в плане учебно-показательном ПОКА принять третий, совершенно неожиданный, но облегчающий всем жизнь вариант:

Заказчик, с его бизнесом, на деле оказался примитивным торгашом:

Скрэтч-карты для него примитивный лист пластика, имеющий свою крупно-оптовую и мелко-оптовую цену.

Которые он получает в столице от очень толстого предОставителя услуг крупным оптом и перепродаёт затем мелким оптом  приезжим торгашам из провинциальных городов.

И вот, на этих прОцентах, да на больших оборотах он и живёт.
Название: Re: Управление требованиями
Отправлено: Gevorg от 15 Ноября 2007, 16:22:09
Может, причина наших разногласий в том, что мы по-разному поняли Концепцию проекта "Практикум по управлению требованиями"? ;)

Тогда обращаемся к первоисточнику:
http://www.uml2.ru/forum/index.php?topic=487.msg5535#msg5535
и пытаемся уточнить потребности Заказчика (в роли которого в данном случае выступает Galogen).
а вот здесь у меня - никаких разногласий с greesha:
это мой прокол, как ПМ-а, который подрядился для Galogen-а проект выполнить :-)
судя из контекста переписки на форуме, мне уже удалось склонить его к работе в соответствии со своим, нигде не задокументированным вижином, а изначальные его запросы так и остались в качестве единственного документа...

Общий вывод: подход от целеполагания - рулёз!

Вывод мне как ПМ - наёмнику у Galogen-а:
Срочно бросать всё - и докумментировать-утверждать с ним актуальную версию вижина нашего проекта и продукта!
Название: Re: Управление требованиями
Отправлено: Galogen от 15 Ноября 2007, 17:00:10
Братцы. Сорри. Я был вне дискуссии. Проходил медосмотр текущий.

Так же в скором времени должен отбыть.

Прочитал, уяснил, расстерялся.

Попытка №2. Постановка задачи.

1. Сформировать программу "Практикума управления требованиями" для студентов специальности 230201 "Информационные системы и технологии" на базе Ивановского государственного химико-технологического университета в рамках летней учебной практики студентов 3 курса. Ориентировочное количество часов: 30 по 6 часов в день. Курсы долны быть рассчитаны на 1 неделю.
Предусловие: студенты должны знать теоретические основы работы с требованиями, иметь навыки работы с инструментарием RaQuest и Enterprise Architect.
 
2. Отработать принципы, регламент и порядок работы по управлению требованиями по предложенной Gevorg программе с возможным использованием RaQuest

3. Написать статью (или цикл статей) по управлению требованиями в соавторстве 3 G. Разместить публикацию на сайте www.uml2.ru, в популярных IT-журналах.

Для реализации всех выше перечисленных целей необходимо проработать пример, сформировать референтный процесс (если получится).

Задачи:
1. определится с терминологий требований и уточнить что команда 3 G и присоединившиеся понимают под БТ, ПТ.
2. определить признаки бизнес-требований и пользовательских требований для их однозначной интерпретации
3. уяснить роль и обязанности каждого из участников

anything else?

Прикладываю файл Raquest. две части архива - в силу ограничений вложения
Название: Re: Управление требованиями
Отправлено: Gevorg от 15 Ноября 2007, 17:38:20
Прикладываю файл Raquest. две части архива - в силу ограничений вложения
gevorg.part1.rar (878.91 Кб - загружено 0 раз.)
это шутка такая: тыцаю загрузить файл, а вываливаюсь в тему голосования за баннеры? :-)
Название: Re: Управление требованиями
Отправлено: Galogen от 15 Ноября 2007, 19:43:22
gevorg.part1.rar (878.91 Кб - загружено 0 раз.)
это шутка такая: тыцаю загрузить файл, а вываливаюсь в тему голосования за баннеры? :-)

Gevorg, очень советую посмотреть как вы заходите на форум.
Рекомендованнный вход.

1. явно выйти с форума или сайта, обнулить кукис.
2.  явно удалить кукис (см настройки браузера www.uml2.ru)
3. набрать в строке соединения
либо http://www.uml2.ru
авторизироваться в форме
кликнуть в верхнем меню на Форум
после перехода на форум - сохранить ссылку в закладках или если поьзуетесь оперой создать элемент быстрого доступа

либо http://www.uml2.ru/forum/
авторизироваться и сохранить закладку

Боюсь проблема получается из-за интеграции joomla и форума. Причем работа неустойчивая и ошибка не понятна, то все работет замечательно, то происходят какие-то нарушения в SSI включении.

Потому, не теряя общей интеграции с форумом и сайтом (поддержка базы пользователй, один логин и пароль на все ресусры форума и сайта), просто зайди прямо на форум и в будущем всегда используйте такой путь.

У меня все работает безукоризненно
Попробуйте явные ссылки
1. http://www.uml2.ru/forum/index.php?action=dlattach;topic=487.0;attach=482
2. http://www.uml2.ru/forum/index.php?action=dlattach;topic=487.0;attach=483
Название: Re: Управление требованиями
Отправлено: Galogen от 15 Ноября 2007, 21:29:59
Хочу все-таки довести классификацию до конца

1. Система должна обеспечивать учёт скрэтч-карт.
Системное требование. Фича системы. Возможно бизнес-требование

2. Система должна поддерживать интеграцию с Клиент-Банком.
Системное требование. Функциональное.

3. Необходимо использование БАР-кодов для номеров скретч-карт.
Больше похоже на бизнес-правило.

4. Необходимо использование БАР-кодов для секретных кодов скретч-карт.
Больше похоже на бизнес-правило.

5. Необходимо применять EAN-систему бар-кодирования, поскольку это является корпоративным стандартом.
Бизнес-правило однозначно.

6. Система должна позволять регистрировать набор номеров скрэтч-карт путём ввода начального и конечного значения диапазона номеров.
Системное требование или даже программное требование

7. Система должна давать возможность вводить номера карт, которые попадают в диапазон номеров для регистрации, но которые являются исключением, и регистрации не подлежат.
Системное требование или даже программное требование

8. Регистрация в Системе прихода средств на счёт компании должна выполняться на основании информации из банка.
Системное требование или даже программное требование с ограничением. Возможное бизнес-правило, т.е. то что должно выполняться не зависимо от реализации

9. Регистрация в Системе прихода средств на счёт компании должна выполняться на основании телефонного звонка от финансового директора.
Системное требование или даже программное требование с ограничением. Возможное бизнес-правило

10. Система должна обеспечивать отчётность о текущем состоянии счёта компании.
Фича, системное требование

11. Необходимо применять EAN-систему бар-кодирования, поскольку имеющееся в компании оборудование поддерживает только этот стандарт.
Системное требование коррелирующее с бизнес-правилом. Либо бизнес-правило

12. Необходима интеграция с внешними системами считывания бар-кодов.
Системное требования фича

13. Необходима интеграция с переносной системой считывания бар-кодов компании Х.
Системно требование, фича, может программное требование

14. Система должна обеспечивать отчётность об истории прихода денег на счёт компании.
Системное требование

15. Система должна обеспечивать отчётность только по тем приходам, которые были зарегистрированы по звонку от финдиректора.
Системное требование
Название: Re: Управление требованиями
Отправлено: Григорий Печенкин от 16 Ноября 2007, 11:37:03
3. Необходимо использование БАР-кодов для номеров скретч-карт.
Больше похоже на бизнес-правило.

4. Необходимо использование БАР-кодов для секретных кодов скретч-карт.
Больше похоже на бизнес-правило.

5. Необходимо применять EAN-систему бар-кодирования, поскольку это является корпоративным стандартом.
Бизнес-правило однозначно.

Бар-код - это нерусское название штрих-кода. Номер карты, представленный в виде штрих-кода, вводится при помощи сканера гораздо быстрее и с меньшей вероятностью ошибки, чем при ручном вводе.

Насколько мне известно, все более-менее массовые сканеры штрих-кодов поддерживают стандарт EAN.

Бизнес-правила это или технические ограничения - не могу сказать, так как в данном случае не владею терминологией.

Название: Re: Управление требованиями
Отправлено: Galogen от 16 Ноября 2007, 17:49:26
Greesha, моя классификация вовсе не претендует на истину. Скорее это попытка хоть что-то предприянть в данной ситуации.

События начинают развиваться в хаотическом порядке. Сначала Gevorg выставил набор требований и заданий к ним. Однако так и не понятно, нужно ли было все-таки сначала выполнить это задание. или автор и сам не уверен в его правильности.

В любом случае стало очевидным, что (о чем я говорил с самого начала) простой набор требований, даже взаимосвязанный имеет множетсво интерпретаций.

Кроме того, пока все сводится к анализу требований, а не управлению.

Что есть управление - пока остается за кадром. По крайней мере у меня складывается впечатление, что управление требованиями включает контроль исполнения поручений, контроль изменений.

При этом не понятны роли и обязанности участников. Кто же все-таки у нас кто.

Если все-таки мы в данном контексте сосредоточены на исполнении поручений, тогда можно предложить такую ролевую расстановку:

Автор задачи, поручения, или автор требования. Генерирует требование.
Менеджер. Принимает задачу, определяет исполнителя, контролирует выполнение
Исполнитель: выполняет задачу, анализирует требование, принимает по нему решение
Рецензент: проверяет требование (возможно это и есть автор задачи)

Хотелось бы так же понять каков цикл работ.

Я не знаю как это происходит или как это должно происходить, могу пока только предполагать.

Прежде чем начинается управление, наверное нужно определиться с концепцией, сформировать единое мнение на проект участников. Естественно какая-то общая оценочная информация к тому времени будет собрана, определены основные фичи системы. Они-то и будут той отправной точкой в рамках, которых и будут определяться все остальные требования.
Поскольку у нас отсутствуют сведения об исполнителях, их задачах, сложно сказать где тут пользовательские требования.
Название: Re: Управление требованиями
Отправлено: Denis Beskov от 16 Ноября 2007, 18:42:06
Смотрите пример регламента и распределения ответственности ролей в документе Апланы: http://pmprofy.ru/content/rus/58/588-article.asp
Название: Re: Управление требованиями
Отправлено: Григорий Печенкин от 16 Ноября 2007, 20:13:20
Greesha, моя классификация вовсе не претендует на истину. Скорее это попытка хоть что-то предприянть в данной ситуации.

Да почему бы ей и не претендовать на истину. Я не знаю, откуда взялась эта классификация, потому что вообще ни с какой классификацией не знаком. Взята она из какой-то всем известной модели, или из документации к используемому инструменту, или как обобщение каких-то работ - во всём этом я пока полный профан (модели не изучал, коммерческими инструментами не пользовался, прочитал только пару книжек по управлению проектами, причём в не самых лучших переводах).

У меня накопился уже довольно значительный опыт разработки, есть некоторый опыт управления проектами (в том числе отрицательный), но почти нет теоретических знаний - собственно, в их поиске я на этот форум и попал.


События начинают развиваться в хаотическом порядке. Сначала Gevorg выставил набор требований и заданий к ним. Однако так и не понятно, нужно ли было все-таки сначала выполнить это задание. или автор и сам не уверен в его правильности.

Мне не кажется, что события развиваются в хаотическом порядке. Всего-то нужно дать начальные данные (vision) по проекту "учёт карт" - главным образом, с какой целью разрабатывается система. Gevorg ответил, что она заказчик - коммерсант, он закупает карты крупным оптом по одной цене и продаёт мелким оптом по другой. Осталось выяснить цели создания "системы учёта карт" и взаимосвязь этого учёта с поступлением средств на счёт компании. (Если взаимосвязи нет, то получается, что разрабатываются две разные системы).

Если рассматривать разработку этой системы учёта как проект, то получается, что мы пропустили самый главный, начальный этап - постановку цели и выработку общего представления о создаваемом продукте. Как только это представление (то самое vision) будет сформировано, требования сразу из хаотичного на первый взгляд "списка пожеланий" превратятся в осмысленный набор, которым уже можно управлять.
Название: Re: Управление требованиями
Отправлено: Galogen от 16 Ноября 2007, 20:27:13
Вернемся чуть-чуть назад.

После некоторой дискуссии с Gevorg, он предложил. что занятия по управлению требованиями должны состоять примерно в следующем:
1. дается некоторый набор требований (10-15) однозначно понимаемых, трассируемых
2. студенту предлагается классифицировать требования
3. составить матрицу трассировки
4. задать вопросы

Я высказался в том смысле, что требования без конкретного контекста и цели могут быть интерпритированны совершенно по разному и необязательно неверно

Кажется мы пришли к мнению, что это действительно так.

Возникает проблема определения корректного видения хорошо понимаемого студентом, что вызывает у меня затруднение и опаску...

Хотелось бы все-таки понять с чего начинается управление требованиями и каков примерный порядок действий по их управлению, а также какие действия сюда следует включать, и как это можно оформить с помощью каких-либо инструментов (в частности RaQuest)
Название: Re: Управление требованиями
Отправлено: Григорий Печенкин от 19 Ноября 2007, 12:40:58
А чему вообще студентов учим? Специальность "Информационные системы и технологии" - это слишком общее название. На какую деятельность ориентировано обучение по этой специальности, какие знания и навыки им нужно приобрести в ходе практикума, какие знания у них уже есть к концу третьего курса?

Здесь ведь тоже возможны разные подходы. Можно сконцентрировать внимание именно на приёмах управления требованиями (что-то вроде рисования палочек в прописи), а можно рассматривать управление требованиями в рамках всего жизненного цикла проекта (если они уже знакомы с моделями ЖЦ). Соответственно, и задачи практикума разные.

И пара уточняющих вопросов по пунктам.

1. дается некоторый набор требований (10-15) однозначно понимаемых, трассируемых

Сопровождается ли этот набор требований описанием концепции разрабатываемой системы (что именно автоматизируем и с какой целью).
Или студенты должны додумать (задавать уточняющие вопросы) самостоятельно, в процессе работы с требованиями?

2. студенту предлагается классифицировать требования

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

3. составить матрицу трассировки

Имеется в виду трассировка требований на тесты?

Я высказался в том смысле, что требования без конкретного контекста и цели могут быть интерпритированны совершенно по разному и необязательно неверно

Кажется мы пришли к мнению, что это действительно так.

Возникает проблема определения корректного видения хорошо понимаемого студентом, что вызывает у меня затруднение и опаску...

У меня вызывает опаску как раз "управление требованиями" без корректного видения. У студента может сложиться впечатление, что "управлять требованиями" можно и без чёткого понимания того, что именно разрабатывается.

Кстати, такой подход тоже можно использовать в качестве учебной задачи - дать студентам самостоятельно "додумать" концепцию, а потом предъявить им свою, заранее подготовленную. И проанализировать ошибки и их причины - такие "разборы полётов", по моему опыту, в обучении очень эффективны. Собственные ошибки запоминаются надолго, намного дольше, чем правильно выполненные задания.
Название: Re: Управление требованиями
Отправлено: Galogen от 19 Ноября 2007, 14:55:32
А чему вообще студентов учим? Специальность "Информационные системы и технологии" - это слишком общее название. На какую деятельность ориентировано обучение по этой специальности, какие знания и навыки им нужно приобрести в ходе практикума, какие знания у них уже есть к концу третьего курса?
Вопрос интересный и непраздный. Однако точно я на него ответить не могу, я лично вижу направление такое: специалисты в базах данных, специалистов в области построения ИС, причем без явного направления в предметной области. Хотя все-таки можно сказать, что это скорее системы для бизнеса. Т.е. не критические системы, не системы реального времени. Вообще этим должен заниматься заведующий кафедрой. Я не зав. Хотя я и многое ему советую, но он как начальник вовсе не обязан ко мне прислушиваться.
Анализ предметов может подсказать, что мы разваиваемся в области проектной деятельности в первую очередь. Такие вопросы как программирование(реализация), тестирование - остаются за рамками. К сожалению нет выделения по архитектурным решениям.
Я свою миссию вижу в развитии аналитических способностей и навыков, анализ требования, приложения, баз данных.

Цитировать
Здесь ведь тоже возможны разные подходы. Можно сконцентрировать внимание именно на приёмах управления требованиями (что-то вроде рисования палочек в прописи), а можно рассматривать управление требованиями в рамках всего жизненного цикла проекта (если они уже знакомы с моделями ЖЦ). Соответственно, и задачи практикума разные.
Согласен, но одного без другого не бывает. Нет занятия по рисованию палочками, откуда же научиться чисто писать?

Цитировать
Сопровождается ли этот набор требований описанием концепции разрабатываемой системы (что именно автоматизируем и с какой целью).
Или студенты должны додумать (задавать уточняющие вопросы) самостоятельно, в процессе работы с требованиями?
Гриша, еще раз напомню, задание не придумано мною. Я не знаю как его проводить, я не знаю буду ли его проводить. Я хочу выяснить а как надо его проводить. Gevorg предложил набор требований из воздуха - мне это кажется сомнительным. Скорее всего требования должны сопровождаться описанием общей концепции. Но я боюсь, что и в этом случае - это мало поможет. Судя по собственному опыту студент либо слишком ленив, либо просто не хватает жизненного опыта.


Цитировать
Исходя из некоторых систем классификации, которые им уже знакомы из теоретического курса?
Да это предположение. Я буду читать курс по анализу требований и собираю под него материал и ищу способ его подачи.

Цитировать
Или из системы классификации, предлагаемой используемым инструментом?
Вообще RaQuest не предлагает никакой классификации. CaliberRM - предлагет. Здесь можно основываться на SWEBOK.

Цитировать
Или выбрать классификационные признаки самостоятельно, исходя из каких-то особенностей создаваемой системы?
Вероятно - это было бы лучшим способом, но мне неизвестна классификация требований, контекстно зависящая от конкретики задачи. Существуют разные признаки для классификации: по статусу, по стабильности, по сложности - это управляемые классификации, есть классификация FRUPS+ - которая мне понятна и близка. Есть классификация вигерса, лиффенгуэлла и им подобным. Разница на мой взгляд не принципиальная, можно оттолкнуться от той которую мы выработаем.

Цитировать
Имеется в виду трассировка требований на тесты?
Ну не обязательно. Матрица трассировки требований между собой, между требованиями и UC, между требованиями и проектными решениями, между требованиями и тестами. Последнее конечно самое важное.

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

Цитировать
Кстати, такой подход тоже можно использовать в качестве учебной задачи - дать студентам самостоятельно "додумать" концепцию, а потом предъявить им свою, заранее подготовленную. И проанализировать ошибки и их причины - такие "разборы полётов", по моему опыту, в обучении очень эффективны. Собственные ошибки запоминаются надолго, намного дольше, чем правильно выполненные задания.
Да - это интересное предложение, имеет смысл подумать, этакий реинжиниринг концепции, по отрывкам требований :-)
Более того, это может быть доказательством многовариантности ответов. Вообще - задача сложная, но благородная. И очень похожа на ситуацию. Текст на русском - первеод на китайский - перевод на русский - сравнение :-)
Или даже скорее текст на китайском - перевод на руссский - перевод на китайский.

Идея практикума по управлению, возникла у меня под впечатлением дискуссий в этой теме. Ясно что сложно выделить управление требованиями без управления процессом и без самого процесса.

Скорее всего нужно будет дать описание такого процесса.

Но с другой стороны, можно поступить и так вот:
поскольку я все-таки буду более или менее знаком с ребятами, то могу выделить сильных и им поручить одну роль, более слабым можно поручить менее отвественную, но и более регламентированную роль.
Таким образом разделив студентов по группам, внутри каждой из которых определить ролевое распределение обязанностей, предоставить процесс взаимодействия таких ролей и далее разыгрывать эту деловую игру.

Поскольку практика фактически не оценивается, у студентов не будет прессинга оценки. Правда задача должна быть интересная и результативная, тогда будет стимул заниматься без понукания.

Как это организовать пока не знаю. Работу в команде пока внедрить не удается, хотя и пытаюсь.

В частности, в следующем году планирую для каждой группы создать собственный вики-репозиторий, в котором они накапливают артефакты своей деятельности, поскольку вход в репзиторий авторизован будет критерий для оценки активности и общего вклада в работу проекта. Итоговая оценка всем ставится на основании успешности проекта с учетом к.т.у.
Название: Re: Управление требованиями
Отправлено: Gevorg от 22 Ноября 2007, 11:18:58
ещё раз приношу извинения за отсутствие на форуме, тема очень интересная и очень хочется завершить начатое,

полный цейтнот на работе, надеюсь за  выходные что-то успею



Название: Re: Управление требованиями
Отправлено: Galogen от 22 Ноября 2007, 15:40:49
ещё раз приношу извинения за отсутствие на форуме, тема очень интересная и очень хочется завершить начатое,
полный цейтнот на работе, надеюсь за  выходные что-то успею
Gevorg, все нормально. Сами часто втаких ситуациях бываем и будем...
Но ждем Вашей руководящей линии
Название: Re: Управление требованиями
Отправлено: Gevorg от 27 Ноября 2007, 13:35:37

У меня вызывает опаску как раз "управление требованиями" без корректного видения. У студента может сложиться впечатление, что "управлять требованиями" можно и без чёткого понимания того, что именно разрабатывается.

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

не успеваю охватить и собрать все накопившееся за время моего отсутствия,
и управлять развитием "детективных сюжетов",
уже боюсь дальше напрягать своими задержками общественность,
поэтому выкладываю задумки по частям, и как есть, в черновом варианте.


по нашему стендовому проекту 
"Разработка заказного ПО для торговца пластиковыми карточками".

Краткое описание деятельности Заказчика:
Крупнооптовая закупка скрэтч-карт от крупного провайдера услуг в Столице
и мелкооптовая ПЕРЕпродажа мелким реализаторам карточек из провинциальных городов.
Финансовые потоки между Провайдером и Фирмой просты и прозрачны, уже автоматизированы в бухгалтерском ПО.
Между Фирмой и реализаторами существуют 2 вида денежных потоков:
- БНР, тоже автоматизированный в бухгалтерском ПО и
- рассчёт наличными, особо больное место в бизнесе, ведётся на грани нарушения законодательства,
крайне нуждается в реинжиринге, правильном учёте и автоматизации.
--!! Управленческий учёт отсутствует, сведение отчёта по какому-либо из Реализаторов
- всегда проблема, решение которой не обходится без скандала.

Роли у Заказчика:
- ТОП. Хозяин бизнеса, Раздражителен, скандален, даже временами хамлив.
Скрывает особенности своих бизнес-процессов, поскольку имеет с ними ряд серъёзных проблем.
Реально - под видом разработки и внедрения заказного ПО хочет провести реинжиринг своего бизнеса.


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

Бухгалтер.
Добросовестно сводит балланс по безналичным рассчётам и отбивается всеми способами
от попыток нагрузить её учётом движения наличных средств и карточек.
Разрабатываемую систему рассматривает как инструмент агрессии в свою сторону.

Менеджеры. По совместительству - кладовщики-учётчики карт и налички.
Ведут реальный учёт вручную, издёрганы скандалами при сведении отчётов по должникам.
Ждут-не-дождутся наведения порядка и автоматизации в своей работе.

Финансовый и бизнес-аналитик. Появляется намного позже.
Занимается построением полноценного управленческого учёта
на основе уже реализованной в нашем ПО функциональности и своих дополнительных хотелок.
Одна из них - возможность принимать от Провайдера и учитывать номера использованных скретч-карт.
Счастливая находка для эффективного обнаружения фактов задержки Реализаторами средств от уже проданных карт.

Роли у Разработчика:
- Менеджер требований(RM). В полном смысле должнен быть "держателем" самих требований и работы с ними.
Пребывает в полной уверенности, что 80% работы с требованиями не несут в себе проблем касательно их сути,
Требования либо уже понятны, либо работа с ними требует только поверхностного понимания сути
при большой важности глубокого понимания контекста в проекте.
из оставшихся 20%  надеется часть спихнуть на энергичного и начитанного (а главное - низкооплачиваемого) помощника,
а что останется из уж совсем трудного - пригласит (на сэкономленные средства) стороннего эксперта-аналитика.
Ленивый прагматик до мозка костей.

- Младший менеджер требований(jRM).
Имеет большой теоретический багаж, опыт работы c CASE-средствами, энергичен и работоспособен.
При недостатке опыта в работе с требованиями и отсутствии "груза ответственности за конечный результат",
активно и добросовестно берётся за любую посильную черновую работу.

- Сеньёр эксперт по требованиям(SRX).
Прекрасно знает предметную область вообще, на высоком уровне понимает и формулирует требования по-сути.
Требует от остальных такого же высокого уровня понимания, если не находит - тут же берётся дотягивать.
Находится вне организационного контекста нашего (стендового) проекта, многие трудности и провалы не то что не хочет
воспринимать, но даже и не догадывается об их существовании.
Имеет опыт по своим прошлым и текущим проектам, которым охотно делится (за соответствующую немалую плату).
За конечный результат проекта (стендового) не отвечает вообще, отвечает за высокий профессионализм и точность своих
консультаций по выделенным вопросам.

Это пока только моё представление по стендовому проекту.
Дальше обещаюсь изложить своё понимание ролей в проекте, учредителем которого является Galogen, как инициатор темы.
Здесь мне уже не получится быть в роли ленивого и полуграмотного по части понимания "физической сути" требований :-)
Название: Re: Управление требованиями
Отправлено: Galogen от 27 Ноября 2007, 14:11:55
не успеваю охватить и собрать все накопившееся за время моего отсутствия,
и управлять развитием "детективных сюжетов",
уже боюсь дальше напрягать своими задержками общественность,
поэтому выкладываю задумки по частям, и как есть, в черновом варианте.

Отлично, Gevorg. Очень интригующая постановка.

Особенно мне понравился момент про низкооплачиваемого добросовестного помощника, видать с меня писался, а гуру-эксперт не иначе greesha.

По существу.
Я буду по совместительству стенографистом нашей команды. есть ли пожелания по стилю оформления.
Данный документ я полагаю можно назвать как характеристика объекта автоматизации. Только для внутреннего использования.

Кстати задачи и роли, а также возможно характеристики можно фиксировать в gantt project, где то на сайте есть ссылка: в поиски набрать gantt project/

По поводу ролей заказчика - очень похоже на реалии жизни, да нет это и есть реалии. Прямо узнаю одного моего работодателя, который посчитал в один из дней, что моя система каким-то образом ворует у него деньги (вернее это я с сообщницей ворую), поняв что доказательств нет, решил надавить на меня на предмет того, чтобы система ему начала самостоятельно приносить прибыль
Название: Re: Управление требованиями
Отправлено: Григорий Печенкин от 27 Ноября 2007, 14:35:50
а гуру-эксперт не иначе greesha.

"Царь у вас какой получился типичный... На нашего Буншу похож!"

Прямо как в жизни - в эксперты записали человека, который что-то где-то когда-то краем уха слышал о предмете разговора. :)
Название: Re: Управление требованиями
Отправлено: Galogen от 27 Ноября 2007, 14:42:15
"Царь у вас какой получился типичный... На нашего Буншу похож!"

Прямо как в жизни - в эксперты записали человека, который что-то где-то когда-то краем уха слышал о предмете разговора. :)
Greesha, это мое предположение, возможно ошибочное
Название: Re: Управление требованиями
Отправлено: Григорий Печенкин от 27 Ноября 2007, 15:00:29
Самое главное, что после десяти страниц флуда мы наконец-то увидели концепцию проекта в первом приближении, обозначили заинтересованных лиц и примерно понимаем цель создания системы. :) Согласитесь, что представленные ранее требования теперь, с концепцией в кармане, допускают намного меньше "детективных" интерпретаций.
Название: Re: Управление требованиями
Отправлено: Galogen от 27 Ноября 2007, 15:09:25
Самое главное, что после десяти страниц флуда мы наконец-то увидели концепцию проекта в первом приближении, обозначили заинтересованных лиц и примерно понимаем цель создания системы. :) Согласитесь, что представленные ранее требования теперь, с концепцией в кармане, допускают намного меньше "детективных" интерпретаций.
Абсолютно. Причем кажется это уже обозначилось даже раньше, чме просто были опубликованы требования. Но наверное это неизбежный процесс притирки, а может gevorg нас проверял.
Название: Re: Управление требованиями
Отправлено: Gevorg от 27 Ноября 2007, 18:27:50
Причем кажется это уже обозначилось даже раньше, чме просто были опубликованы требования.
Не совсем понимаю, что именно обозначилось раньше?

Если речь идёт о том, что общие представления о деятельности Заказчика были у меня в голове ДО того, как я писал список требований?
То да, часть представлений уже была, но часть пришлось додумывать  и упрощать по ходу обсуждения в “10-и страницах флуда”.

Или о том, что участники форума уже сами пришли к тому же представлению, а я только повторил?

Название: Re: Управление требованиями
Отправлено: Galogen от 27 Ноября 2007, 18:32:27
Не совсем понимаю, что именно обозначилось раньше?

Если речь идёт о том, что общие представления о деятельности Заказчика были у меня в голове ДО того, как я писал список требований?
То да, часть представлений уже была, но часть пришлось додумывать  и упрощать по ходу обсуждения в “10-и страницах флуда”.

Или о том, что участники форума уже сами пришли к тому же представлению, а я только повторил?
Нет, Gevorg, не повторили, а как раз обозначили то, что, вероятно, нужно было сделать с самого начала. Вы молодец. Мы Вас не критикуем.
Название: Re: Управление требованиями
Отправлено: Gevorg от 27 Ноября 2007, 18:57:38
Но наверное это неизбежный процесс притирки, а может gevorg нас проверял.

В каком смысле “проверял”?
Я добросовестно старался продвинуть для изучения проблемную ситуацию из жизни,  когда набор требований уже есть, а общее представление о деятельности Заказчика весьма смутное, и основанное больше на здравом смысле и предыдущем опыте разработчика, или его, этого представления,  вообще может не быть.

С целью проявить те стороны требований, с которыми можно и следует работать даже в такой ситуации, ещё до того, как будет получено общее понимание.

В обсуждении родились примеры, как неожиданно и как сильно могут по ходу проекта меняться представления аналитика о сущности бизнеса у заказчика.
Название: Re: Управление требованиями
Отправлено: Григорий Печенкин от 27 Ноября 2007, 19:17:02
С целью проявить те стороны требований, с которыми можно и следует работать даже в такой ситуации, ещё до того, как будет получено общее понимание.

В обсуждении родились примеры, как неожиданно и как сильно могут по ходу проекта меняться представления аналитика о сущности бизнеса у заказчика.

Эти примеры только лишний раз проиллюстрировали, что нельзя перескакивать через необходимые этапы проектирования.

И я по-прежнему считаю, что нельзя "работать" с требованиями в отсутствие принятой всеми концепции. Их можно, разве что, накапливать для последующей обработки.
Название: Re: Управление требованиями
Отправлено: Galogen от 27 Ноября 2007, 19:39:13
В каком смысле “проверял”?
Я говорю может. Не принимайте все так всерьез. И извините, если ненароком обидел.

Думаю эту тему мы уже обсудили и закрыли. Идет нормальная живая работа. Притирка разных "здравых смыслов"
Название: Re: Управление требованиями
Отправлено: Galogen от 04 Декабря 2007, 17:44:32
Уважаемый Gevorg, мы все Вас с нетерпением ждем. Будет ли продолжение урока? все-таки интерес к теме 1615 просмотров
Название: Re: Управление требованиями
Отправлено: Gevorg от 05 Декабря 2007, 13:15:54
Уважаемый Gevorg, мы все Вас с нетерпением ждем. Будет ли продолжение урока? все-таки интерес к теме 1615 просмотров
thnx всем писателям и читателям темы за интерес,
продолжение обязательно, уже есть части.

к сожалению, не успеваю собрать их в нечто цельное,
буду от правлять по частям, как есть
Название: Re: Управление требованиями
Отправлено: Gevorg от 05 Декабря 2007, 16:31:46
В первую очередь нужно описать свою концептуальную наработку:
Разнесение понятий элемента модели и требования на каждом из уровней.
Меня этот принцип особенно выручал на 2-х верхних уровнях: бизнес и пользовательском.

Поясню это по ходу изложения своей классификации наших требований по уровням.

Итак, требование
1. Система должна обеспечивать учёт скрэтч-карт.

Какую проблему должно закрывать его удовлетворение?
- Карт много, менеджеры не справляются с учётом.

Какая модель, на которую должно опираться требование?
- Текстовое описание бизнеса у Заказчика (не случайно его отсутствие так возмущало Greesh-у).

Какие элементы этой модели связываем с Требованием1 вообще и с его Проблемой в частности?
- Строчки из описания бизнеса:
-- Ведётся учёт скрэтч-карт.
-- На д.м. оборот: 10тыс карт в месяц, планируется – 200тыс.(привязываем к проблеме)
-- Скрэтч-карта имеет номер и БАР-код этого номера.

Какой набор решений предлагается для удовлетворения требования?
- Строчки из документа, описывающего модель взаимодействия пользователей с системой:
-- пользователь должен руками вбивать номера карточек для регистрации,
-- пользователь может задать набор регистрируемых карточек с непрерывным диапазоном номеров,
--- пользователь может вводить номера изъятых из диапазона карточек,
-- для ускорения набора номера карточки пользователь может задействовать систему считывания бар-кода.

Хочу обратить внимание, что строчки-элементы моделей совсем не обязаны находиться рядом или даже на одном уровне детализации в рамках своей модели.

Кроме того, модель может содержать диаграммы  и мы можем трассировать требование к набору элементов этих диаграмм. Например – квадратик, изображающий карточку с атрибутом “БАР-код номера”. На уровне модели взаимодействия пользователя с системой  - это могут быть строчки сценария из ВИ или строки примитивного списка тезисов.

И ещё один момент. До сих пор я старался использовать только сведения, собранные в тексте самих требований, без учёта общей картины бизнеса, изложенной позже по запросу  Greesh-ы и других участников форума. 

Это ни в коем случае не в пику Greesh-е, а  в прояснение сути кажущегося противостояния наших позиций.
- С одной стороны, пробелы и противоречия в представлениях о бизнесе Заказчика  - неизбежное явление на всех стадиях разработки.
Рвение и максимализм аналитиков к максимальному прояснению картины и устранению противоречий часто приводит к ситуации, когда Разработчик вынужден выполнять для Заказчика бизнес-анализ и бизнес-дизайн.
И самое страшное не то, что Разработчику приходится это делать за свой счёт, а то, что этим он вторгается в “чужую парафию”, становится эдаким агрессором-обличителем по отношению к Заказчику, который и от себя-то скрывает дыры в своём бизнесе, а тем более – будет всячески саботировать обнародование их в документах от Разработчика.

- с другой стороны, - требования не могут “болтаться” в воздухе, они обязательно должны опираться на модели соответствующих уровней (уровень проблемы и уровень решений по ней). На начальных этапах сбора и анализа требований не следует ожидать, что такие модели будут цельными, согласованными, полными, - приходится  довольствоваться тем, что объективно есть на текущий момент и выжимать из него всё, что можно. 
Название: Re: Управление требованиями
Отправлено: Galogen от 05 Декабря 2007, 20:30:18
Спасибо, Gevorg. Очень познавательно

Цитировать
с другой стороны, - требования не могут “болтаться” в воздухе, они обязательно должны опираться на модели соответствующих уровней (уровень проблемы и уровень решений по ней). На начальных этапах сбора и анализа требований не следует ожидать, что такие модели будут цельными, согласованными, полными, - приходится  довольствоваться тем, что объективно есть на текущий момент и выжимать из него всё, что можно.

Полностью согласен. Это также согласуется с моим пониманием управления требованиями и фактами из жизни проектов. Взять хотябы данные из книги Лармана Применение UML, где он описывает сущность итерационной разработки (стр. 89 русского 3-го издания от Вильямс):
25 % требований изменяются в ходе разработки;
45 % требований определенных до начала проектирования (каскадный подход) - не используются
19 % - используются редко
16 % - используются редко
13 % - часто используются
7 % - всегда используются
т.е. 64 % требований просто выбрасываются

Потому например в RUP очень четко определено и принудительно ограничено, что к первой точке следует определить и проанализировать не более 10% прецедентов и аркитектурно значимых нефункциональных требований.

Таким образом на первом этапе следует выделить наиболее значимые прецеденты, функциональные и не функциональные требования и  их обработать, далее по нарастающей в итерационной манере идет выполенение 90% требований к первому устойчивому выпуску, на каждой итерации набор требований стабилизируется после анализа и формируется как я понимаю baseline
Название: Re: Управление требованиями
Отправлено: Gevorg от 13 Декабря 2007, 12:00:04
вот, прочитал в соседней теме:
------------------------------------------------------
bas  Re: И все таки вариант использования - это функция :P
---------------
ВИ - это пользовательские требования, как написано, например, у Вигерса.
------------ -------------------------------------------------
так у меня здесь всё та же наработка
В первую очередь нужно описать свою концептуальную наработку:
Разнесение понятий элемента модели и требования на каждом из уровней.
Меня этот принцип особенно выручал на 2-х верхних уровнях: бизнес и пользовательском.
Для меня ВИ - это не совсем требования, это элементы модели уровня пользовательского взаимодействия с системой.
А требования - это:
RQ№ххх,
Уровень: пользовательский,
Автор: Analyst1,
Источник: должностная инструкция Менеджеру отдела Х,
Необходимость:....
Описание: должен быть реализован ВИ000ХХ.
и т.д.

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

кстати, посоветуйте, как правильно вставить цитату из соседней темы?
Название: Re: Управление требованиями
Отправлено: Galogen от 13 Декабря 2007, 13:16:28
Можно просто сделать ссылку на соответствующее сообщение форума.
Или вернуться в ту тему, выбрать цитировать - скопировать полученный текст
возвратится в другую тему и начать писать ответ.
Название: Re: Управление требованиями
Отправлено: bas от 13 Декабря 2007, 14:37:48
Описание: должен быть реализован ВИ000ХХ.
и т.д.
т.е. обеспечиваем себе возможность нарисовать стройную картину взаимодействия пользователя с системой, а затем по ней указать только те ВИ, которые требуется реализовать в текущей разработке.
А Вы не путаете планирование с требованием? Это уже больше похоже на планирование, что Вы сказали. Я просто не пойму зачем 100 раз одно и тоже дублировать, а потом еще и поддерживать целостность?
В каких Вы книжках это прочитали?? И как это вас спасало?

И увидеть, насколько ущербной окажется разработка без ВИ, оставшихся за бортом. (К слову об антипрецедентах).
Поясните свой ответ. И вообще дайте плиз определение антипрецеденту, или ткните где почитать.
Название: Re: Управление требованиями
Отправлено: Gevorg от 13 Декабря 2007, 18:03:12
И вообще дайте плиз определение антипрецеденту, или ткните где почитать.
http://www.osp.ru/os/2005/04/185537/
не гуру, конечно, но идея мне понравилась
Название: Re: Управление требованиями
Отправлено: Gevorg от 13 Декабря 2007, 18:41:50
В каких Вы книжках это прочитали?? И как это вас спасало?
Поясните свой ответ.
дак речь у нас не о книжках, а о "поделиться опытом" и получить критику от форумчан, в том числе и в плане есть\нет в книжках, может я велосипед изобрёл :-)

по существу вопроса: откуду такие конструкции?
так от практики с нашими любимыми средствами работы  с требованиями, в частности, от ЭА:

там есть в явном виде объекты под названием "требования" и отдельно - ЮзКейсы и другие элементы UML-моделирования,
да ещё и трассировочные связи между ними обеспечиваются.

да и Борландовские продукты (CaliberRM and StarTeam) работают с требованиями и ЮзКейсы таковыми не называют, а согласовать это очень хочется...

вот и родилась описанная конструкция.
Название: Re: Управление требованиями
Отправлено: Galogen от 13 Декабря 2007, 20:31:56
некоторые итоги
Название: Re: Управление требованиями
Отправлено: Gevorg от 14 Декабря 2007, 13:36:17
некоторые итоги
Galogen, очень уместная инициатива, искренне благодарен.

По содержанию документа есть замечания и пожелания по дальнейшему развитию:

- источник требований не один Gevorg, но и обсуждения и результаты с форума,
- в документ попали только первоначальные формулировки требований, а дополнительное требование относительно
-- учёта состояния карт (от Greesh-ы) и
-- хамовитые "разъяснения" от ТОПа относительно учёта номеров бракованных карточек в упаковке (от меня)
 в документе (или приложении) не отражены.

- смарт-карта, описанная в документе - это несколько другое, отличное от того, что я изначально имел в виду и что было подхвачено Greesh-ей.
Скрэтч-карта намного более примитивная вещь, но она имеет секретный код, которого касается одно из интересных для нас в поучительном плане требование.

Нужны следующие ближайшие доработки документа:
исправить глоссарий:
- заменить описание смарт-карты на описание скрэтч-карты от Greesh-ы (2 варианта скрэтч-карт)
- добавить описание скрэтч-кода.
- добавить результаты обсуждения требований хотя бы в виде вопрос-ответ.
- добавить варианты ПЕРЕформулировок, предложенных Вами.

сорри, что перегружаю эту работу на Вас, я ещё неделю буду очень стеснён временем.

К сожалению, я сам не успел, а мои студенты так и не смогли открыть Раквестный файл с Вашими результатами, но это направление меня живо интересует, я обязательно хочу "руками посмотреть" возможности связки Раквест+ЭА.

Название: Re: Управление требованиями
Отправлено: bas от 14 Декабря 2007, 13:47:21
дак речь у нас не о книжках, а о "поделиться опытом" и получить критику от форумчан, в том числе и в плане есть\нет в книжках, может я велосипед изобрёл :-)

Gevorg (кстати, а как вас/тебя зовут?),
Во-первых, ни в коем случае не хотел обидеть. М.б. немного резковато выразил свою т.з.
Во-вторых, Ну не вижу смысла дублировать требования, ведь ВИ - это пользовательское требование. А что реализовывать или нет и когда, - это уже планирование. Если надо детализировать ВИ, то создаем системное требование и трассируем к ВИ и все. Я делаю так.

З.Ы. Дальнейшее обсуждение имеет смысл перенести в соседнюю ветку (http://www.uml2.ru/forum/index.php?topic=547.0), т.к. тут обсуждается пример.
Название: Re: Управление требованиями
Отправлено: Galogen от 14 Декабря 2007, 17:55:16
По содержанию документа есть замечания и пожелания по дальнейшему развитию:
- источник требований не один Gevorg, но и обсуждения и результаты с форума,
Да, можно поправить. Тем более это же черновой вариант.

Цитировать
- в документ попали только первоначальные формулировки требований, а дополнительное требование относительно
-- учёта состояния карт (от Greesh-ы) и
-- хамовитые "разъяснения" от ТОПа относительно учёта номеров бракованных карточек в упаковке (от меня)
 в документе (или приложении) не отражены.
Да, я просто зафиксировал исходные данные, остально решил пока не трогать. Но можно и добавить, правда это так много!

Цитировать
- смарт-карта, описанная в документе - это несколько другое, отличное от того, что я изначально имел в виду и что было подхвачено Greesh-ей.
Скрэтч-карта намного более примитивная вещь, но она имеет секретный код, которого касается одно из интересных для нас в поучительном плане требование.
Моя ошибка, сложно понять почему самрт-карты а не скрэтч.

Цитировать
Нужны следующие ближайшие доработки документа:
исправить глоссарий:
- заменить описание смарт-карты на описание скрэтч-карты от Greesh-ы (2 варианта скрэтч-карт)
Заменю

Цитировать
- добавить описание скрэтч-кода.
Добавлю

Цитировать
- добавить результаты обсуждения требований хотя бы в виде вопрос-ответ.
попробую

Цитировать
- добавить варианты ПЕРЕформулировок, предложенных Вами.
Я что-то переформулировал? Поправлю

Цитировать
сорри, что перегружаю эту работу на Вас, я ещё неделю буду очень стеснён временем.
С Вас арманьяк :)

Цитировать
К сожалению, я сам не успел, а мои студенты так и не смогли открыть Раквестный файл с Вашими результатами, но это направление меня живо интересует, я обязательно хочу "руками посмотреть" возможности связки Раквест+ЭА.
странно, я все проверил, все открывается - файл представляет собой два тома.
В общем, во избежания ошибок, и чтобы не перегружать сайт избыточной информацией, я выложу файл архива на своем ресурсе и дам ссылку для скачивания.
Документ также будет хранится там, а ссылку доступа я буду постить на форуме


Ссылка для просмотра файлов проекта (RaQuest и MS Word) (http://www.isuct.ru/~ivt/g3project/). Участники проекта думаю могут вносить все нужные изменения.

В RaQuest я создал новую команду и троих участников Galogen, Gevorg, Greesha. Все требования внесены от лица Galogen, кроме 16, которое внесено от лица Greesha, т.е. автора.
Название: Re: Управление требованиями
Отправлено: Gevorg от 19 Декабря 2007, 14:03:06
В каких Вы книжках это прочитали?? И как это вас спасало?

дак речь у нас не о книжках, а о "поделиться опытом" и получить критику от форумчан, в том числе и в плане есть\нет в книжках, может я велосипед изобрёл :-)

Во-первых, ни в коем случае не хотел обидеть. М.б. немного резковато выразил свою т.з.

thnx лично Вам, как модератору и всем участникам за поддержание высокой культуры общения на форуме.
такой подход обещает дать серъёзные результаты.

к примеру, - наша текущая ситуация:

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

а проблема, ЫМХО, в том, что теория требований
до сих пор отстаёт и не выдерживает проверки практикой.
Стоит только начать попытки её применять - как обнаруживаюся дыры,
при попытке самостоятельно залатать которые сильно рискуешь попасть на подозрение в ереси и неуважении мировых Гуру.

Чего мне стоило вытянуть признание Galogen-а:
"Коберн к сожалению относится к картинкам халатно - потому у него стрелочки теряют свою информативность"
http://www.uml2.ru/forum/index.php?topic=194.0

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

Но это уже явно отклонение от текущей темы.
Здесь бы справиться с намного меньшей задачей: толком изложить свой частный опыт.

Может, заведём отдельную тему:
"Известные разногласия и рассогласования мировых учений о требованиях"?
Название: Re: Управление требованиями
Отправлено: Григорий Печенкин от 19 Декабря 2007, 14:51:56
Стоит только начать попытки её применять - как обнаруживаюся дыры,
при попытке самостоятельно залатать которые сильно рискуешь попасть на подозрение в ереси и неуважении мировых Гуру.

Поправочка: подозрение в неуважении к мировым Гуру со стороны их фанатичных последователей. ;) Сами Гуру, как правило, постоянно оговариваются в стиле "марксизм - не догма, а руководство к действию".

Я, кстати, все разновидности стрелочек UML лично для себя, извините за выражение, похерил. Если я пытаюсь кому-то что-то объяснить с помощью диаграммы, я не могу полагаться на то, что он понимает значение всех типов наконечников стрелок всех версий UML, а демонстрация собственных знаний обычно не является моей целью. Поэтому рисую, какие придётся - главное убедиться, что собеседник в этот момент понимает их назначение так же, как я.
Название: Re: Управление требованиями
Отправлено: bas от 19 Декабря 2007, 17:20:55
Поэтому рисую, какие придётся - главное убедиться, что собеседник в этот момент понимает их назначение так же, как я.
Гриша, не хочу спорить в этой ветке, т.к. она совсем не причем. Но свою тз выскажу (если будут вопросы, то вынесем это отдельно):
Вот ты нарисовал и что?? В корзину? А потом пришел новый разработчик или с другого проекта, посмотрел на стрелочку и исправил в коде, как нарисовано и никто кроме закзчика - это не узнал.
Стандартизация для того и придумана, чтобы минимизировать чел фактор. Почу когда мы делаем чертеж (пускай той самой платы для карточки), то мы делаем это в соответсвии с ГОСТ (линии, шрифт и т.д.)
А вот в разработке ПО почему-то каждый хочет изобрести велик.
Название: Re: Управление требованиями
Отправлено: Galogen от 19 Декабря 2007, 18:05:02
Да, прошу прекратить разговоры,  неотносящиеся к управлению требованиями.

Заводите новую тему типа "Стандартизация: нужна или нет?"
Название: Re: Управление требованиями
Отправлено: Gevorg от 08 Января 2008, 22:18:45
уфф, появилась маленькая передышка на работе.
попробовал "на зуб" РаКвэст и его связку с ЭА, вот первые впечатления.

По ЭА.

1. Странно, создаю в ЭА требование и класс, который его реализует, создаю связь.
Открываю свойства класса,  в закладке Links вижу связь с требованием.
Открываю свойства требования - закладки Links нет вААще.

2. А где же полноценные диаграммы коммуникации в ЭА?
Сиквенс-есть, а коммуникации - нету, а тем более автоматического преобразования их друг в друга.
Что это? Я чего-то не нахожу, или у меня старая версия ЭА? (v7.08)

3. Странно, а какое назначение закладки "Сценарии" у многих элементов, не имеющих ничего общего с ВИ?
Например - свим-лайны, артефакты, актёры, бизнес-ентити.

4. Ещё про сценарии. Очень хочется выделить сценарии ЮзКейса отдельными элементами диаграммы,
чтобы ссылаться на них трассировочными связями от требований или других элементов диаграмм.
Например, чтобы можно было наглядно показать, что подключение отдельной дополнительной
компоненты необходимо для реализации только одного альтернативного сценария (или нескольких, но из разных ВИ).
Пока не вижу в ЭА стандартных средств для этого.
И уж совсем очевидная потребность:
связать определённый сценарий ВИ хотя бы с соответствующей Сиквенс-диаграммой, раз уж нет полноценных диаграмм коммуникации.


5. Вот, хотелось чтобы требование типа
"Система должна обеспечивать до 3тыс позиций у одной товарной накладной"
Можно было явно притрассировать к мощности связи на диаграмме классов, ан-нет, -
трассировать требование можно только к "квадратику или овальчику".
Даже просто на связь сослаться трассировкой ниЗЗя, хотя требований типа
"Интерфейс Z между компонентами А и Б должен удовлетворять требованиям стандарта Х" - море.
В Визио - там есть возможность создать на линии "точку привязки"
и цеплять к ней конец другой стрелочки, неужели Архитект не даёт подобных возможностей?.


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


По РаКвесту.

1. Нет Ишьёв и чейндж-ревестОв.
Если в ЭА велось обсуждение проблемы, или было заказано изменение требования в чейндж-реквесте,
то всего этого не увидишь в РаКвесте.

2. Возможность генерации классов по элементам глоссария порадовала, но есть ли дальнейшая синхронизация?
К примеру, если я заметил грамматическую ошибку в названии соответствующего класса -  и тут же на месте её исправил,
то что нужно проделать для исправления оной в РаКвестном глоссарии?
И как я могу увидеть трассировки от требований к строчке глоссария? Есть такое в РаКвесте?
Или только в ЭА вручную проставлять трассировки от требований к соответствующему строке глоссария классу?

3. Сильно раздражает отсутсвие  прав на редактирование диаграмм зависимости требований.
Не гарантирую чистоту эксперимента, но у меня получалась такая досадная ситуация:
Открываю диаграмму зависимости требований в РаКвесте - автоматически сгененрированная картинка не нравится.
Открываю ЭА, нахожу соответствующую диаграмму, правлю расположение, сохраняю.
Открываю эту же картинку снова в РаКвесте - он снова её переделывает на свой автоматический манер.
Снова иду в ЭА, смотрю картинку там, надеюсь увидеть свой сохранённый вариант размещения алементов,
 но оказывается, РаКвест и её "подправил".

4. Какой смысл в дереве иерархии требований?
Что это за связь между ними такая, что есть в структуре дерева проекта и никак не отображается в матрице?
У меня есть свои соображения по этому поводу, опять же, как результат неявно предлагаемой разработчиками ЭА концепции.
Как дойдут руки - напишу, а пока просто не буду использовать эту возможность.

Название: Re: Управление требованиями
Отправлено: Galogen от 09 Января 2008, 10:47:08
Gevorg, рад что Вы снова с нами :)
Вообще у нас главный специалисто по ЕА - Irr, подождем ее ответов. Где-то у нас ведется тема типа FAQ, советую повторить пост там, и подождать, что скажет наш ЕА гуру.
Тем не менее беру на себя смелость прокомментировать
1. Странно, создаю в ЭА требование и класс, который его реализует, создаю связь.
Открываю свойства класса,  в закладке Links вижу связь с требованием.
Открываю свойства требования - закладки Links нет вААще.
Да это так. Возможно в этом есть некоторый смысл, поскольку класс реализует требование, а не наоборот. Однако, у Вас практический опыт, и Вы сразу видите непорядок.

Цитировать
2. А где же полноценные диаграммы коммуникации в ЭА?
Сиквенс-есть, а коммуникации - нету, а тем более автоматического преобразования их друг в друга.
Что это? Я чего-то не нахожу, или у меня старая версия ЭА? (v7.08)
Ну не знаю, диаграмма communication есть. Другое дело, что автопреобразование как в розе, к сожалению нет. Почему - вопрос к ЕА. Однако чтобы задать этот вопрос, нужно быть владельцем.
Предлагаю скинуться и купить на мое имя академическую лицензию (требуется доказательство) :) Тогда я от вашего имени могу задавать вопросы ЕА.


Цитировать
3. Странно, а какое назначение закладки "Сценарии" у многих элементов, не имеющих ничего общего с ВИ?
Например - свим-лайны, артефакты, актёры, бизнес-ентити.
Наверное никакого. Скорее всего просто такова метамодель в ЕА.

Цитировать
4. Ещё про сценарии. Очень хочется выделить сценарии ЮзКейса отдельными элементами диаграммы,
чтобы ссылаться на них трассировочными связями от требований или других элементов диаграмм.
Например, чтобы можно было наглядно показать, что подключение отдельной дополнительной
компоненты необходимо для реализации только одного альтернативного сценария (или нескольких, но из разных ВИ).
Пока не вижу в ЭА стандартных средств для этого.
И уж совсем очевидная потребность:
связать определённый сценарий ВИ хотя бы с соответствующей Сиквенс-диаграммой, раз уж нет полноценных диаграмм коммуникации.
Да такого явно нет, однако можно использовать обновляемые нотации (может это поможет как-то: http://www.uml2.ru/index.php?option=com_content&task=view&id=119&Itemid=48)



Цитировать
5. Вот, хотелось чтобы требование типа
"Система должна обеспечивать до 3тыс позиций у одной товарной накладной"
Можно было явно притрассировать к мощности связи на диаграмме классов, ан-нет, -
трассировать требование можно только к "квадратику или овальчику".
Даже просто на связь сослаться трассировкой ниЗЗя, хотя требований типа
"Интерфейс Z между компонентами А и Б должен удовлетворять требованиям стандарта Х" - море.
В Визио - там есть возможность создать на линии "точку привязки"
и цеплять к ней конец другой стрелочки, неужели Архитект не даёт подобных возможностей?.
по всей видимости в ЕА такое сделать нельзя, либо просто трассировать к реализуемому классу


Цитировать
6. Требования, ишью и реквесты в ЭА нарисованы одинаковой фигурой
- наталкивает на мысль, что между ними должно быть много общего.
Не случайно, наверное, многие изобретательные разработчики приспосабливают баг-трекеры к управлению требованиями.
В СтарТиме - так там баг трекер прямо так и оперирует не с БАГом, а с чейндж-реквестом.
ачто такое реквесты? Я что-то не нашел такого элемента. Вы имели в виду feature? Или change?

Цитировать
По РаКвесту.

1. Нет Ишьёв и чейндж-ревестОв.
Если в ЭА велось обсуждение проблемы, или было заказано изменение требования в чейндж-реквесте,
то всего этого не увидишь в РаКвесте.
Давайте сформулируем вопрос поточнее с примером, я задам в службе поддержки раквеста, поскольку авторизованный пользователь

Цитировать
2. Возможность генерации классов по элементам глоссария порадовала, но есть ли дальнейшая синхронизация?
К примеру, если я заметил грамматическую ошибку в названии соответствующего класса -  и тут же на месте её исправил,
то что нужно проделать для исправления оной в РаКвестном глоссарии?
И как я могу увидеть трассировки от требований к строчке глоссария? Есть такое в РаКвесте?
Или только в ЭА вручную проставлять трассировки от требований к соответствующему строке глоссария классу?
аналогично

Цитировать
3. Сильно раздражает отсутсвие  прав на редактирование диаграмм зависимости требований.
Не гарантирую чистоту эксперимента, но у меня получалась такая досадная ситуация:
Открываю диаграмму зависимости требований в РаКвесте - автоматически сгененрированная картинка не нравится.
Открываю ЭА, нахожу соответствующую диаграмму, правлю расположение, сохраняю.
Открываю эту же картинку снова в РаКвесте - он снова её переделывает на свой автоматический манер.
Снова иду в ЭА, смотрю картинку там, надеюсь увидеть свой сохранённый вариант размещения алементов,
 но оказывается, РаКвест и её "подправил".
Можно пример. И опять зададим вопрос, только по четче его нужно сформулировать.

Цитировать
4. Какой смысл в дереве иерархии требований?
Что это за связь между ними такая, что есть в структуре дерева проекта и никак не отображается в матрице?
У меня есть свои соображения по этому поводу, опять же, как результат неявно предлагаемой разработчиками ЭА концепции.
Как дойдут руки - напишу, а пока просто не буду использовать эту возможность.
Опять же пример - и формулировка вопроса. Отправлю разрабочикам и буду ждать ответа


Название: Re: Управление требованиями
Отправлено: Gevorg от 09 Января 2008, 12:22:38
Ну не знаю, диаграмма communication есть. Другое дело, что автопреобразование как в розе, к сожалению нет.
 Почему - вопрос к ЕА. Однако чтобы задать этот вопрос, нужно быть владельцем.
да я сам видел возможность создать диаграммы с таким названием,
только попробуйте в ней мессиджи прикрепить к коммуникативным ассоциациям.... :-)
я не нашёл, поэтому и выразился в порыве возмущения, что нет диаграмм коммуникации.
Irr, что, действительно всё так печально в ЭА, или я чего-то не замечаю?
Название: Re: Управление требованиями
Отправлено: Galogen от 09 Января 2008, 13:33:42
Строите модель объектов в communication.
Далее проводите ассоциации.
ПКМ по ассоциации выбираем добавит собщение от ... к
вносите сообщение, либо создаете операцию

Как использоватьто что уже сделано в sequence точно не знаю, искал долго.

Знаю только что мессаджи не сохраняются, а вот операции да, но тоже как-то странно. В общем нужно разбираться
Название: Re: Управление требованиями
Отправлено: Galogen от 09 Января 2008, 15:23:48
Осуществляя бешенный поиск в справке и в интернете, обнаружил на форуме самого EA презабавное сообщение.
Оказывается есть некий аддонс, позволяющий конвертировать communication в sequence, но кажется не наоброт. При этом какие-то траблы при работе в 7 версии, типа в 6.5 усе корректно. Однако все равно есть проблемы с синхронизацией.

Интересно на что же рассчитывает ЕА? Или это такой коммерческий ход. Насколько я понял аддонсы многие становятся доступны после покупки струмента
Название: Re: Управление требованиями
Отправлено: Gevorg от 09 Января 2008, 19:39:37
два вопроса:
1. Триал-период в раквесте закончился, как работать дальше?
2. Куда и как выкладывать свои правки в раквестном файле, который я открываю и всю работу по-сути делаю в ЭА?



Название: Re: Управление требованиями
Отправлено: Galogen от 09 Января 2008, 20:22:36
Свяжитесь со мной лично. Я дам Вам некоторые цу.

Для выкладывания скорее всего подойдет такая ситуация - вы мне почтой я кладу на свой ресурс. Либо можно сделать иначе, я пишу крипт, чтобы Вы могли закачивать туда файлик, так и будем работать. Идет?
Название: Re: Управление требованиями
Отправлено: Юрий Булуй от 10 Января 2008, 10:38:36
Почитал дискуссию. Некоторые соображения.
По тому считать или нет ВИ требованиями. Зависит от той модели которую вы для себя приняли и как интерпретируете ВИ и даже то, как вы их пишите. Лично мне не очень понятно для чего нужно дополнительное ТРЕБОВАНИЕ: "Реализовать UC12", хотя прошу заметить, что это ВОВСЕ не требование (по определению требований), а чистой воды TASK, который как правило уже относиться к заданию на проектирование или реализацию и по сути это уже отнсится к конфигуправлению.
Название: Re: Управление требованиями
Отправлено: Gevorg от 10 Января 2008, 14:19:25
Лично мне не очень понятно для чего нужно дополнительное ТРЕБОВАНИЕ: "Реализовать UC12", хотя прошу заметить, что это ВОВСЕ не требование (по определению требований), а чистой воды TASK,
сорри за неточность:
Название: UC12 ДОЛЖЕН быть реализован(или НЕ реализован в данном проекте).
Покрываемая бизнес-потребность: BR007
Источник требования: должностная инструкция менеджеру А отдела Х.
и т.д.
Насколько я знаю, традиционные шаблоны такие атрибуты в ЮзКейс не включают.
Название: Re: Управление требованиями
Отправлено: bas от 10 Января 2008, 19:04:52
Согласен с Юрием, это уже больше относится к планированию. Зачем загружать структуру требований не нужной информацией. Если для вас это так важно, то введите новый атрибут у ВИ - требует релизации.
Это не так принципиально, но все же ...
Название: Re: Управление требованиями
Отправлено: Юрий Булуй от 10 Января 2008, 22:13:13
сорри за неточность:
Название: UC12 ДОЛЖЕН быть реализован(или НЕ реализован в данном проекте).
Покрываемая бизнес-потребность: BR007
Источник требования: должностная инструкция менеджеру А отдела Х.
и т.д.
Насколько я знаю, традиционные шаблоны такие атрибуты в ЮзКейс не включают.

Вообще для меня это несколько не привычно (это не означает что это правильно или не правильно :-)). Юзкейсы системного уровня по определению должны быть реализованы в той или иной итерации и дополнительное утверждение о необходимости реализации того или иного юзкейса в этом случае нет. А эти атрибуты не обязательно должны существовать в "традиционном" шаблоне. Это просто ваше решение -- так вам удобно и вы об этом все договорились. Лично я описываю все типы требований и их атрибуты (в т.ч. и для юзкейсов) в плане управления требованиями (если он создается для проекта). И веду их в инструментарии требований. А источник требования -- такой атрибут например описан кажись в RUP (если мне не изменяет склероз ... :-)). А вот покрытие бизнес-потребности обчно вводится не через атрибут, а через связи трассировки. Но вам удобнее так .. никто за это не осуждает :-).
Название: Re: Управление требованиями
Отправлено: Gevorg от 11 Января 2008, 13:49:28
Вообще для меня это несколько не привычно
Юзкейсы системного уровня по определению должны быть реализованы в той или иной итерации
и дополнительное утверждение о необходимости реализации того или иного юзкейса в этом случае нет.
это всё к той же теме антипрецедента
тяжело работать с требованиями в ключе "делаем только И ТОЛЬКО то, что записано в документе".
Легче в таком стиле:
- точно делаем то, что записано,
- точно НЕ делаем, что явно указано НЕ делать,
- о чём явно не договорились в документе - разбираем по ходу возникновения проблем.


А вот покрытие бизнес-потребности обчно вводится не через атрибут, а через связи трассировки.
Но вам удобнее так .. никто за это не осуждает :-).
да нет, я тоже делаю это трассировкой с соответствующим стереотипом, но это же в диаграмме.
согласен, в текстовом описании нужно было  добавить явно, что не атрибут, а трассировочная ссылка.
Но опять же, от какого источника? от ЮзКейса или от отдельно выделенного требования по данному ЮзКейсу?

Ещё пример-аргумент в защиту такого разделения (Требования и ЮзКейса):
- система давно написана, досталась в наследство на сопровождение,
- разрабатывалась не то чтобы просто партизанами, а целым партизанским движением,
- соответственно, отсутствует как документация так и какая-либо структуризация в продукте,
- Кровавым пОтом аналитики реинжирят функциональность в виде ЮзКейсов.

Приходит очередная хотелка.
По-сути - это дополнительный альтернативный сценарий для одного из отреинжиреных ВИ.
Как такую хотелку оформлять?
Я завожу отдельный объект "требование",
- даю название,
- вставляю в текст описания соответствующий бред из письма Кастомера, как есть.
- "тычу пальцем" в соответствующее место ДОРАБОТАННОЙ модели ВИ:
если это текстовый документ - кликабельную ссылочку,
если есть диаграммы - то рисую трассировочную ссылочку на ВИ, а ещё лучше - на соответствующий новый сценарий.
Теперь, если добавится ещё и соответствующая активити-диаграмма, то нарисуем и трассировку от нашего требования
к соответствующей ветке на диаграмме.
Но не так всё просто, если пытаться задействовать средства автоматизации:
с ними особо не договоришься про атрибуты, тут они либо есть - либо их нет.
Остаётся, правда, возможность пользовательских полей, но с ними тоже не особо развернёшься.
Кстати, именно здесь мне пришлось использовать связку StarTeam+Caliber+MSProject.
Название: Re: Управление требованиями
Отправлено: Irr от 14 Января 2008, 22:09:01
1. Странно, создаю в ЭА требование и класс, который его реализует, создаю связь.
Открываю свойства класса,  в закладке Links вижу связь с требованием.
Открываю свойства требования - закладки Links нет вААще.
Меня это тоже удивляло, моя гипотеза: ЕА заморозил виз.интерфейс для требований, чтоб не пересечься по разработке с RaQuest'ом, который делает японская дочка австралийской фирмы спаркс. другой причины для извращений не вижу.
3. Странно, а какое назначение закладки "Сценарии" у многих элементов, не имеющих ничего общего с ВИ?
Например - свим-лайны, артефакты, актёры, бизнес-ентити.
Прямого ответа у меня нет, подозреваю, что с т.з. архитектуры ЕА все элементы репозитария имеют одинаковый набор параметров, отражаемый в интерфейсе (кроме требований, но по ним см. ответ выше)
Предложение купить Галогену ЕА - поддерживаю, выступлю спонсором, но скорее всего в феврале.
С остальными ответами уважаемого аксакала согласна, добавить пока нечего.
Название: Re: Управление требованиями
Отправлено: Galogen от 15 Января 2008, 00:40:18
Меня это тоже удивляло, моя гипотеза: ЕА заморозил виз.интерфейс для требований, чтоб не пересечься по разработке с RaQuest'ом, который делает японская дочка австралийской фирмы спаркс. другой причины для извращений не вижу.
С чего это такой реверанс в сторону дочернего предприятия? Может просто таково политика? Или денег не хватило?
А не связано ли это вообще с проблемой команды или менеджеров ЕА? Нет же у них нормального объяснения тому, что ДП не конвертируется в ДС.
Если это их игра особая - то очень странная, а как кодогенерация у них выстроена примитивно. Мне кажется оне зазнались, либо такая политика как у 1С - выпускают полуублюдочную версию, чтобы дочки тоже могли зарабатывать.
Меня прикололо что раквест академический стоит 75 тугриков, а ЕА всего 65.
Цитировать
Предложение купить Галогену ЕА - поддерживаю, выступлю спонсором, но скорее всего в феврале.
С остальными ответами уважаемого аксакала согласна, добавить пока нечего.
Как поешь акын :)
Название: Re: Управление требованиями
Отправлено: Irr от 15 Января 2008, 10:45:35
Ну, на самом деле нормальная политика. Когда 2 медведя живут в одной берлоге, надо делить территорию. А они действительно живут в одной берлоге-репозитарии. И весь функционал логично разбить на 2 отдельных продукта-проекта. Похоже, ресурсов на оба продукта у австралийцев не хватило, вот они и поделили. Поделили, на мой взгляд, нормально, в том месте, где пересечений всего меньше. Даже если бы они были в одной стране, это имело бы смысл. Иначе не справиться с контролем изменений на стыках.