Не совсем понимаю, что именно обозначилось раньше?

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

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

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

Но наверное это неизбежный процесс притирки, а может gevorg нас проверял.

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

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

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

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

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

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

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

В каком смысле “проверял”?

Я говорю может. Не принимайте все так всерьез. И извините, если ненароком обидел.

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

Уважаемый Gevorg, мы все Вас с нетерпением ждем. Будет ли продолжение урока? все-таки интерес к теме 1615 просмотров

Уважаемый Gevorg, мы все Вас с нетерпением ждем. Будет ли продолжение урока? все-таки интерес к теме 1615 просмотров

thnx всем писателям и читателям темы за интерес,
продолжение обязательно, уже есть части.

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

В первую очередь нужно описать свою концептуальную наработку:
Разнесение понятий элемента модели и требования на каждом из уровней.
Меня этот принцип особенно выручал на 2-х верхних уровнях: бизнес и пользовательском.

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

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

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

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

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

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

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

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

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

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

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

Спасибо, Gevorg. Очень познавательно

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

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

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

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

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

В первую очередь нужно описать свою концептуальную наработку:
Разнесение понятий элемента модели и требования на каждом из уровней.
Меня этот принцип особенно выручал на 2-х верхних уровнях: бизнес и пользовательском.

Для меня ВИ - это не совсем требования, это элементы модели уровня пользовательского взаимодействия с системой.
А требования - это:
RQ№ххх,
Уровень: пользовательский,
Автор: Analyst1,
Источник: должностная инструкция Менеджеру отдела Х,
Необходимость:....
Описание: должен быть реализован ВИ000ХХ.
и т.д.

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

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

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

Описание: должен быть реализован ВИ000ХХ.
и т.д.
т.е. обеспечиваем себе возможность нарисовать стройную картину взаимодействия пользователя с системой, а затем по ней указать только те ВИ, которые требуется реализовать в текущей разработке.

А Вы не путаете планирование с требованием? Это уже больше похоже на планирование, что Вы сказали. Я просто не пойму зачем 100 раз одно и тоже дублировать, а потом еще и поддерживать целостность?
В каких Вы книжках это прочитали?? И как это вас спасало?

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

Поясните свой ответ. И вообще дайте плиз определение антипрецеденту, или ткните где почитать.

И вообще дайте плиз определение антипрецеденту, или ткните где почитать.

http://www.osp.ru/os/2005/04/185537/
не гуру, конечно, но идея мне понравилась

В каких Вы книжках это прочитали?? И как это вас спасало?
Поясните свой ответ.

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

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

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

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

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

некоторые итоги

некоторые итоги

Galogen, очень уместная инициатива, искренне благодарен.

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

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

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

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

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

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