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