Следует различать три вида спецификаций:

• контекстная спецификация требования - отвечает на вопросы типа "зачем и почему" существует требование, в каком контексте оно возникло.
• внутренняя спецификация - разъясняет и детализирует само требование, дает ответ на вопрос типа "что надо делать" и "как ПО должно исполнять свою функцию"
• внутренняя спецификации фичи, отвечающая на вопрос "как конструировать фичу, группу фич или систему в целом".  

Здесь я расскажу о контексной спецификации. Начало темы о проектировании на основе требований см здесь >>>

Многие понимают КОНТЕКСТ интегрально и интуитивно, поэтому и не занимаются им вовсе. Контекст - дело архитекторов и на его структурирование нужно много ума и времени. Но благо у нас есть Архимейт хотя бы в виде методической подсказки. Контекстом для системных требований являются строительные блоки Архимейта из доменов мотивации и бизнеса.

Что мы берем из домена мотивации для спецификации контекста требования:

Что мы берем из домена бизнеса для спецификации контекста требования:

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

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