Выложены материалы со встречи про инструменты в Лаборатории Касперского https://www.facebook.com/kaspercareer/posts/1288178701196559

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

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

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

Я считаю, что можно и нужно разрабатывать требования, не ставя в качестве конечной цели получение документа. То, что документы для нас так важны - это наша специфика и вопрос привычки, а так же отсутствие удобных средств для всех нужных нам действий, с которыми справляется Word.
И не согласна с утверждением, что документ - структура хранения требований, для нас это структура визуализации, представления требований. Инструментом хранения для нас там, где используется, всегда является ЕА.

Я считаю...

Редкий случай, когда хочется полностью подписаться под сказанным.

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

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

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

Выложены материалы со встречи про инструменты в Лаборатории Касперского https://www.facebook.com/kaspercareer/posts/1288178701196559

Испытывал очень сильные душевные волнения во время просмотра. Три года назад пытался реализовать схожие подходы на ЕА. Тогда не хватило опыта, сил, ума и я думал, что это всё плод моих перфекционистских фантазий и на практике мало осуществимо, дорого и никому не нужно. Эти видео подтверждают, что я шел в правильном направлении. Спасибо команде касперского. Это очень ценно!

Я считаю, что можно и нужно разрабатывать требования, не ставя в качестве конечной цели получение документа. То, что документы для нас так важны - это наша специфика и вопрос привычки, а так же отсутствие удобных средств для всех нужных нам действий, с которыми справляется Word.
И не согласна с утверждением, что документ - структура хранения требований, для нас это структура визуализации, представления требований. Инструментом хранения для нас там, где используется, всегда является ЕА.

+1

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

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

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

+1

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

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

Возможно не так долго, как кажется.

У Юлии Мадорской есть отличное сравнение процесса перехода разработки требований в виде бумажки (пусть даже электронной) с ведением БАЗЫ требований в инструментарии с переходом от бумажного проектирования к autocad.

http://edu.reqcenter.pro/?p=4500

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

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

Появление CAD-систем действительно сопровождалось значительной скоростью перехода на них проектных организаций.
Я вижу причины в том, что 3-хмерные модели физических объектов действительно удобны в работе, т.к. в своих проекциях на экране дают наглядное представление о себе.

С другой стороны, у софта и ИС нет никакой истинной 3D-формы, которая была бы легко постижима человеком. Поэтому модель софта и ИС остаётся ментальной конструкцией, которую каждый участник строит в своей голове по проекциям — будь-то диаграммы процессов, структуры.

Документ (бумажный или электронный) по сути даёт 2,5D-модель, т.к. показывает, в каком порядке эту модель собирать в голове.

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

"Я так вообще не фанат никакого ПО (а скорее открытых систем как класса)"
Денис, а можете поподробнее рассказать, почему?

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

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

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

Это задачи старшего (ведущего) аналитика, методолога, а вовсе не начинающего. И помочь решать эти вопросы ничего, кроме человека с опытом не поможет. А опыт этот в свою очередь  - кладбище загубленных проектов или наоборот успешных.

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

Почему от этих ошибок должен уберечь опыт технического писательства?

Это задачи старшего (ведущего) аналитика, методолога, а вовсе не начинающего.

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

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

Т.е. вы считаете, что этот опыт не может быть формализован ни в какие чеклисты, шаблоны, технологию? Я считаю — может.

К вопросу - инструментарий или word имеет самое косвенное отношение.

ничего не понял. word – тоже инструмент.

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

мне тоже непонятно, о чём вы тут пишете. Кем вводится? Куда вводится? Когда вводится? Где вводится?

Умение выражать знания с чётким выделением действующего лица — важнейший навык аналитика.

Почему от этих ошибок должен уберечь опыт технического писательства?

При чём тут техническое писательство?

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

Ещё раз — меня не интересует выбор 1) Word или 2) CASE-средства.

Я говорю о выборе аналитика, во что инвестировать своё время — А) в освоение новых инструментов или Б) в освоение технологий выполнения аналитических и проектных работ. Я считаю, что окупаемость от Б-варианта гораздо выше, чем А.

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

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

Т.е. вы считаете, что этот опыт не может быть формализован ни в какие чеклисты, шаблоны, технологию? Я считаю — может.

На 100% нет. Есть вещи, которые в технологию не транслируются. Чуйка, интуиция.

ничего не понял. word – тоже инструмент.

С некоторым допущением что-угодно можно считать чем угодно. И карандаш инструмент. И долото для наскальных рисунков тоже.

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

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

уууу, это порождает другие проблемы. является ли XML базой данных? но не будем.

Я говорю о выборе аналитика, во что инвестировать своё время — А) в освоение новых инструментов или Б) в освоение технологий выполнения аналитических и проектных работ. Я считаю, что окупаемость от Б-варианта гораздо выше, чем А.

Вы уверены, что A и Б никак не взаимосвязаны? Что инструменты не создают предпосылки для новых технологий, а технологии не определяют необходимость в тех или иных инструментах?