🤖 Инсайт по разработке требований (в частности — к ПО) При разработке требований к ПО широко применяются неформальные нотации на основе естественного языка. На практике при таком подходе часто наблюдается следующий паттерн: в разных требованиях регулярно встречаются фрагменты с одинаковым смыслом. Они могут относиться, например, к выполнению одного и того же действия, но при возникновении различных условий в разных требованиях. Типичный пример – установка одного и того же флага при обнаружении разных ошибок. 🔲 Принцип LEGO-конструктора для требований Для неформальных нотаций часто используется подход EARS (Easy Approach to Requirements Syntax). Но его можно немного усилить, применив принцип LEGO-конструктора. Идея простая: заранее определить набор «многоразовых кубиков», из которых потом собираются полноценные требования. Такие кубики — это типовые элементы: ▪️условия требования; ▪️обязательное выполняемое действие; ▪️временные и иные ограничения; ▪️состояния программного обеспечения; ▪️объект или субъект требования; ▪️а также другие типовые элементы требований. Использование подобных кубиков позволяет формировать требования с единообразной и предсказуемой структурой и упрощает их восприятие и анализ. Например, требования могут быть сформулированы так: →  «В состоянии S1, при возникновении условия C1, субъект K должен выполнить действие A1 за время t1»; →  «В состоянии S1, при возникновении условия C2, субъект K должен выполнить действие A2 за время t2». Что это дает на практике? 1️⃣Проще писать требования: инженер сосредотачивается на формировании базовых элементов, а затем собирает из них законченные смысловые требования. 2️⃣Легко вносить изменения: если нужно скорректировать одинаковое условие для группы требований — меняем один «кубик», и изменения распространяются на все связанные требования. 3️⃣Больше однозначности:  За счет заданных правил построения и единообразия структуры естественный язык становится ближе к полуформальным нотациям, что снижает риск неоднозначной интерпретации. 🔩Про инструменты Концепция модульного построения требований уже поддерживается специализированными инструментами.  Например, ANSYS Medini Analyze удобен тем, что позволяет выстраивать трассируемые связи между требованиями разных уровней, результатами анализов безопасности и архитектурными элементами системы, описанными в нотации SysML. Дополнительное преимущество — возможность адаптации инструмента под конкретные задачи проекта за счет встроенного API, пользовательских скриптов на JavaScript, а также расширения функциональности через разработку собственных плагинов на Java в рамках платформы Eclipse. Например, такие скрипты могут использоваться для автоматического формирования типовых шаблонов требований, проверки их структуры или массового обновления повторно используемых элементов. Это позволяет сократить объем ручной работы и обеспечить единообразие и воспроизводимость требований в рамках проекта. Примечание: приведенные примеры требований носят иллюстративный характер и не претендуют на роль эталонных формулировок. 😃 [FTS] Экварта | Лицом к безопасности