Обсуждение

"Некоторые употребляют термин «моделирование требований». Это термин является неверным по сути. Моделируется реализация системы, а не требования к ней". У классиков СУТ старого поколения модели отдельно, а требования -- тоже отдельно. Если требования формализованы (тем более, если исполнимы) - то говорить о моделировании требований вполне корректно. Потому как формальный язык отличается от обычного человеческого, который весьма многозначен. А формальный как раз упрощенный, зато строгий. Т.е. по факту имеем моделирование (реального языка на неком искусственном). Ну и процесс записи явно является моделированием. К примеру, даже такой базовый объект как множество, можно представить на формальном языке, т.е. отмоделировать, разными способами: конструируемым типом, предикатом, функцией возвращающей bool, списком, другой структурой данных, типа разнообразных деревьев.

Когда мы меняем природу "требования", меняем природу "трассировки", переходим на управление конфигурацией в контексте всего жизненного цикла, а базис требований становится всего лишь частью общей информации модели, а не отдельной "базой данных требований", мы должны ожидать, что меняются и все остальные практики, связанные с требованиями. Так, сбор требований сразу может проходить в форме моделей, без предварительного текстового описания в виде полотен бумаги. Анализ требований -- тоже связан с моделированием. Хуже того, если рассматривать исполнимые спецификации, то спецификация часто может являться реализацией, по крайней мере, прототипом. Особенно, это касается библиотечных спецификаций. К примеру, рассмотрим (софтверное) требование, что функция должна выдавать в качестве результата масимальный элемент из списка переданного в параметре. Пример конечно примитивнй, но тем не менее, если записать требование в виде forall params, In (func params) params /\ forall a, In a params -> (func params) >= a, то нетрудно представить себе алгоритм, который такие спеки при некоторых условиях преобразует в исполнимый код (логическое программирование, программирование в ограничениях).

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

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

Тут много спекуляций по поводу "моделирования" и "описания" как терминов. У меня вот статья на английском в верстку уже пошла -- так там начинается с того, что "слово моделирование уже имеет примерно такое же значение, как просто слово описание, и значение это так же туманно". Мне очень понравилось: "формальный язык упрощенный, зато строгий". По пять, но большие ;) В этом-то и фишка.

Где бы парочку таких томов заполучить, о квалификации допрашивающего? Был бы весьма признателен за на водку...

Я беру оттуда же, откуда и все: http://ebdb.ru/Search.aspx?p=1&s=requirements+engineering&x=0&y=0. Ну и другие запросы тоже можно попробовать (requirements management, например).

Спасибо, ушел изучать :)

Как-то смотрел я на языки формальных спецификаций, а именно на Z. Это тихий ужас. Для систем со сколько-нибудь размытыми границами такого не создать. Это я к тому, что часть требований всегда будет находиться в некой субстанции, называемой "культура фирмы". Можно накопать много, но по мере углубления цена добывания информации растёт, а ценность падает. Чёткие релизы (в том числе и в виде бумажек) нужны для передачи работы от отдела к отделу. Если не фиксировать, то последнее звено в цепи всегда будет виновато. Так что менеджер откажется брать работу, состояние которой не зафиксировано. И по цепочке череда замороженных View поднимится вверх.

Тут я пишу о совсем разных механизмах, каждый из которых почти независим: -- формальные спецификации, только совсем не на языке Z или каком-то особом языке управления требованиями. Формальные спецификации делаются в том же языке, с которым работают разные workbenches/editors/workstations САПР, только ставится пометка "требования" -- передача требований между работниками (необязательно между "отделами"). Это делается внутри САПР, а не внутри отдельной системы. Можно еще предположить, что внутри отдельных окошек одной системы, но не в виде отдельной специализированной системы, предназначенной только для этого. Конечно, это все про будущее, а не настоящее. Но это будущее готовится прямо сейчас, и мимо этого поворота не нужно промахивать. Кое-какой софт есть уже сейчас, и нужно сделать поворот в мозгах.