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

×


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

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

Или о том, что участники форума уже сами пришли к тому же представлению, а я только повторил?
Нет, Gevorg, не повторили, а как раз обозначили то, что, вероятно, нужно было сделать с самого начала. Вы молодец. Мы Вас не критикуем.



Re: Управление требованиями Ответ #151 : 27 Ноября 2007, 18:57:38
Но наверное это неизбежный процесс притирки, а может gevorg нас проверял.

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

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

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



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

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

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

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

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



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

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



Re: Управление требованиями Ответ #154 : 04 Декабря 2007, 17:44:32
Уважаемый Gevorg, мы все Вас с нетерпением ждем. Будет ли продолжение урока? все-таки интерес к теме 1615 просмотров



Re: Управление требованиями Ответ #155 : 05 Декабря 2007, 13:15:54
Уважаемый Gevorg, мы все Вас с нетерпением ждем. Будет ли продолжение урока? все-таки интерес к теме 1615 просмотров
thnx всем писателям и читателям темы за интерес,
продолжение обязательно, уже есть части.

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



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

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

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

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

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

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

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

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

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

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

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

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



Re: Управление требованиями Ответ #157 : 05 Декабря 2007, 20:30:18
Спасибо, Gevorg. Очень познавательно

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

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

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

Таким образом на первом этапе следует выделить наиболее значимые прецеденты, функциональные и не функциональные требования и  их обработать, далее по нарастающей в итерационной манере идет выполенение 90% требований к первому устойчивому выпуску, на каждой итерации набор требований стабилизируется после анализа и формируется как я понимаю baseline



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

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

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



Re: Управление требованиями Ответ #159 : 13 Декабря 2007, 13:16:28
Можно просто сделать ссылку на соответствующее сообщение форума.
Или вернуться в ту тему, выбрать цитировать - скопировать полученный текст
возвратится в другую тему и начать писать ответ.



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

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



Re: Управление требованиями Ответ #161 : 13 Декабря 2007, 18:03:12
И вообще дайте плиз определение антипрецеденту, или ткните где почитать.
http://www.osp.ru/os/2005/04/185537/
не гуру, конечно, но идея мне понравилась



Re: Управление требованиями Ответ #162 : 13 Декабря 2007, 18:41:50
В каких Вы книжках это прочитали?? И как это вас спасало?
Поясните свой ответ.
дак речь у нас не о книжках, а о "поделиться опытом" и получить критику от форумчан, в том числе и в плане есть\нет в книжках, может я велосипед изобрёл :-)

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

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

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

вот и родилась описанная конструкция.



Re: Управление требованиями Ответ #163 : 13 Декабря 2007, 20:31:56
некоторые итоги



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

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

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

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

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

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

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





 

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