План доклада на семинар:
1. Классификация требований
2. Документирование требований
3. Аспекты классификации унифицированного процесса
4. Методы выявления

Прошу ответить во время семинара на ряд вопросов, если возможно.

1. Зачем нужно классифицировать требования?
2. Почему требуется семинар по классификации требований, если в мире существуют уже устойчивые классификации, а при этом в некоторых организация особо не паряться по поводу классификации требований. Требование есть требования.
3. Как докментируются требования в реальной практике, не как документ для заказчика, тут все ясно, а как документ внутреннего использования. Как вообще организовать документирование и документооборот требований?
4. Как рекомендуется структурировать требования, стоит ли их структурировать? Каковы критерии качественного структурирования требований
5. как выявлятьь требования на тестировние, особенно если они отсутствуют в документальной форме или форма их представления далека от классических норм?

З.Ы. Тема родилась из Re: [Семинар] Классификация требований, 29 ноября, СПб

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

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

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

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

4. Как рекомендуется структурировать требования, стоит ли их структурировать? Каковы критерии качественного структурирования требований

Постараемся ответить

5. как выявлятьь требования на тестировние, особенно если они отсутствуют в документальной форме или форма их представления далека от классических норм?

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

Не понял ответа на 2 вопрос. Можно пояснить?

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

Виталя, ну куда уж четче Есть требования к продукту, но есть требования к тестированию этого продукта. Часто требования к продукту нужно изменить так, чтобы они были годны при использовании в тестировании. Поскольку семинар про требования, я заострил внимание на ту часть которая частенько выпадает из рассмотрения, т.е. требование как инструмент проверки качества и соответствия ПО

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

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

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

И не говори, совсем меня запутали

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

Не понял ответа на 2 вопрос. Можно пояснить?

Ну во-первых, мне совсем понятно что такое документооборот требований. Во-вторых, документирование требований (шаблоны документов) всегда зависят от заказчика или процесса работы с требованиями. Если есть желание узнать про то как требования по классификации К. Вигерса ложаться на спеки можно посмотреть его книжки, в презентации Алексей тоже попытался это показать. В РУПе та же ситуация. Спецификация, которая готовится для заказчика не создается отдельно от внутреннего процесса разработки - это часть процесса. Если процесс водопадный, то можно сделать спеку, подписать ее у заказчика, а дальше детализировать, создавать постановки задач и тп. Я же считаю что детализация требований, это их анализ и уточнение. Существует много способов анализа требований, и эта тема не относится к классификации (или по крайней мере они не жестко связаны).
Поэтому, я и написал, что документооборот требований относится не к классификации, а к процессу разработки ПО (SDLC). Сначала концепция, потом ТЗ, потом ЧТЗ, постановка и тп... На всех этих этапах идет разработка требований. Если на этапе проектирования возникают проблемы, то должна быть обратная связь с требованиями, чтобы их откорректировать и тд..
Если я опять, что то не то написал или не на то ответил, то поправьте меня. 

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

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

ЗЫ Если есть желание поговорить о какой-то теме, то можно начать новую.

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

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

+ к Алексею можно попробовать следующее:
При внесении изменении в функционал пишутся не просто кусок требований на доработку, но также восстанавливаются утерянные требования к данной части ф-ла