И ментальные модели, сформировавшиеся у людей, привыкших или обученных разрабатывать "автоматизированные системы", приводят к их осознанному или неосознанному сопротивлению
Во-во, мой мозг сейчас активно сопротивляется
![Улыбающийся :)](http://www.uml2.ru/forum/Smileys/classic/smiley.gif)
Давайте заново, а то я запутался... Итак, говорим о классификации требований. Есть модель Вигерса, есть ГОСТ 34.602. Вигерс хорошо рассказывает, какие требования бывают и как их добыть, ГОСТ говорит, как должно быть оформлено ТЗ. Очевидно, что Вигерс на ГОСТ просто так не ложится, но иногда надо (например, госконтракт). Выше я предложил одну из схем, по всей видимости неудачно, но все же. Далее две точки зрения: 1. ГОСТ умер, 2. ГОСТ жив. Основные тезисы первой точки зрения (поправьте, если неправильно понял):
1. ГОСТ не определяет порядок разработки требований.
2. ГОСТ не определяет модель требований.
3. ГОСТ ничего не знает про требования пользователей, юзкейсы, ДВИ и т.д.
4. ГОСТ не предлагает широкий выбор моделей жизненного цикла АС.
5. ГОСТ говорит только о функциональных требованиях.
Тезисы второй точки зрения (ГОСТ жив):
1. ГОСТ предусматривает отдельную стадию для формирования требований к разрабатываемой АС. Как именно это будет происходить дается на откуп специалистам.
2. Какая-то модель требований в ГОСТ все же заложена, структура ТЗ об этом недвусмысленно намекает. Отдельно про модель нигде не говорится, потому как в то время отсутствовала необходимость (или осознание необходимости) управлять этими требованиями. Написали ТЗ и все, вперед делать. И стоит отметить, делали-то на совесть, до сих пор все работает! Еще один момент: ГОСТ предусматривает изменение/дополнение ТЗ (путем разработки доп.ТЗ, ЧТЗ), чем вам не итерационный подход? при этом нигде не говорится, сколько должна длиться одна итерация, может 10 лет, а может месяц. На этапе разработки доп.ТЗ проводится анализ требований (а как без этого), но каким способом - на усмотрение специалиста.
3. Есть три уровня требований: бизнес, пользовательские и функциональные + нефункциональные требования. Система строится по требованиям низкого уровня (функциональным требованиям) + нефункциональным требованиям, остальные 2 уровня требований нужны чтобы получить (и обосновать) этот 3-й уровень. Да, в ГОСТе нет такого деления, но что мешает его использовать? Функциональные требования в ТЗ по ГОСТ нужно как-то обосновывать, почему бы это не сделать при помощи ВИ? я не встретил явного запрета.
4. ГОСТ предлагает перечень стадий и этапов разработки АС, при этом ГОСТ 34.601 гласит: "Допускается исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая документация» в одну стадию «Технорабочий проект». В зависимости от специфики создаваемых АС и условий их создания допускается выполнять отдельные этапы работ до завершения предшествующих стадий, параллельное во времени выполнение этапов работ, включение новых этапов работ". Таким образом, путем варьирования предложенных стадий и этапов можно реализовать практически любую модель жизненного цикла и ГОСТ это разрешает. Главное с заказчиком потом все это согласовать
![Усмешка ;D](http://www.uml2.ru/forum/Smileys/classic/grin.gif)
5. ГОСТ явно не проводит деление требований на группы (классификацию), но нефункциональные требования он не обходит стороной. Так в ТЗ есть такие разделы, как Показатели назначения, Требования надежности, безопасности и т.д. Как их родить он не говорит, но его ли это задача?
Они есть, конечно, и в первую очередь их прорабатывают в новой отрасли, которую сейчас называют "юзабилити" или "проектирование пользовательского взаимодействия"
В ТЗ есть раздел "требования эргономики и технической эстетики", звучит старомодно, но это тоже самое. "2.6.1.6. В требования по эргономике и технической эстетике включают показатели АС, задающие необходимое качество взаимодействия человека с машиной и комфортность условий работы персонала". Запишите туда свои требования к интерфейсу, что вам мешает?
и которая уже тесно связана с психологией (поэтому я и говорю, что современные подходы выявления и разработки требований переползают в гуманитарную область). Но тут на первый план выходит нефункциональная сторона системы. Нефункциональные требования (юзабилити) оказываются важнее, их проработка обходится дорого, и они порождают в конечном итоге очень большую долю программного кода при разработке.
психологией занимается не система, а оператор системы. Для системы это всего лишь дополнительный функционал (или ограничение). Пригласите на этапе разработки требований психолога, получите ТЗ, учитывающее данные аспекты. Но для разработчиков это не имеет никакого значения! они получат ТЗ, в котором советы психолога будут интерпретированы аналитиком в обычные требования к системе и они будут писать такие же процедуры и функции. После реализации интернет-магазина посадите вместо обычного менеджера толкового маркетолога и вы увидите, как ваш магазин с "бесчеловечным" интерфейсом будет бить рекорды продаж!
Вобщем, не убедили вы меня
![Улыбающийся :)](http://www.uml2.ru/forum/Smileys/classic/smiley.gif)