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

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

Требования

Два смысла слова “требования”.

Термин “требования” имеет два разных смысла:

●Определение системы как “чёрного ящика” — что требуется от целевой системы с точки зрения её стейкхолдеров (stakeholder requirements) и использующей надсистемы (system requirements). Обычно это спецификация (т.е. точное формулирование) способности (capability) или условия (condition), которое должно или может быть удовлетворено (функция, которую нужно будет выполнить, или характеристика, которую нужно достигнуть и т.д.).

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

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

“Требования” обычно означают совокупность отдельных “требований” (отдельных высказываний о системе).

Модальности в требованиях

Чтобы понять природу требований, нужно разобраться с логическими модальностями высказываний о системе (http://en.wikipedia.org/wiki/Modal_logic):

●нейтральные высказывания о мире, суть которых непонятна без указания модальности. Например, "длина дана как 16".

●алетическая (alethic) модальность, относящаяся к возможности существования. Обычно с алетической модальностью в связи 4D extensionalism связаны рассуждения про возможные миры (possible worlds): пока воплощения системы ещё нет, возможны варианты определений системы для разных возможных вариантов будущего воплощения системы — но только один из них будет реализован “в железе”. Например, "длина пусть будет 16" ("положим длину равную 16").

●деонтическая (deontic) модальность, относящаяся к обязыванию и дозволению. Например, "длина должна быть 16". Собственно, это и есть главная модальность “требований”, требования — это то, что должно быть, рекомендуется быть, разрешается быть, обязательно или необязательно и т.д.

●темпоральная (temporal) модальность, связанная со временем. Например, "длина была 16 три года назад".

●Доксическая (doxastic) модальность, связанная с верой. "Я верю, что длина дана как 16". Доксическая модальность важна для квалификации (удостоверения того, что требования выполнены — вера в то, что система соответствует её определению).

Требования довольно трудно формализовать именно потому, что нужно разбираться с их модальностями. Сложность вопроса можно оценить по базовой статье, только не в попсовой википедии, а в серьезной философской энциклопедии: http://plato.stanford.edu/entries/logic-modal/

Инженерные обоснования

Требования связаны с инженерными обоснованиями: они переформулируются как "декларации" (claim) разработчиков о соответствии — т.е. "я верю, что длина равна 16", а затем это высказывание доказывается по логическим правилам рациональной аргументации (помним, что логика — это дисциплина, занимающаяся правильностью рассуждений). Эти доказательства проводятся “как в суде” — и для этого даже заводится “дело” (assurance case, как раз от “судебного дела” — с

вариантами dependability case, safety case, security case, requirement case, architectural quality case).

Обзор по инженерным обоснованиям приведён тут: http://ailev.livejournal.com/811715.html

Рабочие продукты требований

Рабочие продукты требований могут быть самые разные — и чаще всего они не называются “требования”. Так, требования можно обнаружить в:

●Разделе “технические требования” технических заданий (хотя “техническое задание” чаще всего подробно перечисляет работы — “задание на работы”, а не требования, но всё-таки какое-то описание целевой системы как “чёрного ящика” это описание содержит)

●Документе “Опросный лист” (который посылается, чтобы опросить потенциальных поставщиков инженерных решений и содержит как раз основные требования к поставляемой системе) и посылаемом в ответ на “Опросный лист” документе “Технико-коммерческие предложения”

●Различных стандартах (некоторые из которых называются “технические

условия”, т.е. даже в названиях они не содержат слова “стандарт” или “требования”)

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

— приказе, который делает какой-то документ с описанием системы дОлжным к соблюдению).

Требования совсем необязательно являются бумажными документами-текстами. Они вполне могут храниться в какой-то базе данных (часто эта база данных ведётся в рамках какой-то “информационной системы управления требованиями” — DOORS, IRqA и т.д.) в виде отдельных пронумерованных текстовых описаний. Или требования могут быть представлены в виде какой-то компьютерной модели, численной или логической.

Требования стейкхолдеров

Требования стейкхолдеров — это требования (описания “черного ящика”), которые создаются для отдельных стейкхолдеров. Конечно, требования разных стейкхолдеров будут противоречить друг другу. Обычно от инженера по требованиям требуется документировать (в тексте или какой-то модели) требования стейкхолдеров, а затем завизировать эти требования у них — чтобы подтвердить правильность понимания. К требованиям стейкхолдерам главное — их понятность самим стейкхолдерам.

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

Требования и ограничения

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

Неплохо бы понимать в каждом проекте, что является требованиями, а что является ограничениями. Прежде всего вы должны удовлетворить требования. И если придуманное вами инженерное решение для “прозрачного ящика” лучше того, которое требует клиент в своих ограничениях, нужно попытаться убедить клиента снять эти ограничения.

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

Требования к системе

Требования стейкхолдеров могут быть противоречивы, разрознены и неполны. Требования, достаточные для разработки системы, называются системными требованиями (требованиями к системе, system requirements). Их разрабатывает инженер по требованиям в ходе так называемой “аналитической” работы (хотя в этой работе кроме анализа требований стейкхолдер и присутствует синтез системных требований).

К требованиям к системе предъявляют множество самых разных требований: непротиворечивости, полноты, проверяемости и т.д. Разработать хорошие требования к системе очень и очень непросто.

Главная ошибка, из-за которой терпят провал многие проекты — это необнаружение какого-то важного требования какого-то из стейкхолдеров.

Инженерия требований

Разработкой требований занимается поддисциплина системной инженерии “инженерия требований”. Главная часть инженерии требований — это реверсинжиниринг использующей (над)системы (using system) для того, чтобы получить описания “чёрного ящика”. Инженеры по требованиям (это вид системных инженеров) выявляют стейкхолдеров, узнают их потребности (нужды, needs), разрабатывают требования стейкхолдеров, проводят переговоры между стейкхолдерами в тех случаях, когда их требования противоречивы, или когда команда проекта оказывается не в состоянии их выполнить и требования нуждаются в коррекции, согласуют требования стейкхолдеров между собой, готовят требования к системе.

Неправильно называть инженерию требований “управлением требованиями”. Управление требованиями — это дисциплина инженерного менеджмента (логистическая, “инженерного документооборота”), она заключается в том, чтобы предоставить средства хранения требований и сообщения о них всем тем, кто в них нуждается. Для того, чтобы управлять требованиями, нужно их сначала иметь: а для этого нужно проводить инженерную работу (прежде всего делать реверсинжиниринг использующей системы, чтобы понять, что в ней должна делать целевая система). Обычно управление требованиями включают в состав инженерии требований как поддисциплину, но только одну из многих. Обзор стандартов представления требований в целях управления требованиями (хранения и пересылки) можно найти тут: http://ailev.livejournal.com/900086.html — обратите внимание, что во всех этих стандартах нет никаких следов того, откуда эти требования берутся и как потом используются.

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