Функциональные и нефункциональные инженерные требования

Требования к домену
Требования домена связаны с доменом приложения системы, а не с конкретными потребностями пользователей системы. Они могут быть новыми функциональными требованиями, ограничивать существующие функциональные требования или указывать, как должны выполняться конкретные расчеты.
Проблема с требованиями к домену заключается в том, что инженеры-программисты могут не понимать характеристик домена, в котором работает система. Это означает, что эти инженеры могут не знать, было ли пропущено требование домена или оно не соответствует другим требованиям.
http://software-engineering-bo ok.com/web/domain-requirements/
Требования к системе Mentcare, используемой для хранения информации о пациентах, проходящих лечение от психических расстройств:
1. Пользователь может искать список назначений для всех клиник.
2. Система формирует список пациентов, которые должны быть госпитализированы в один день для каждой клиники.
3. Каждый сотрудник, использующий систему, должен быть однозначно идентифицирован своим восьмизначным номером сотрудника.
Эти требования пользователя определяют конкретные функции, которые должны быть включены в систему. В требованиях указано, что функциональные требования могут быть написаны с разным уровнем детализации (в отличие от требований 1 и 3).
Функциональные требования, как следует из названия, традиционно фокусировались на том, что должна делать система. Однако, если организация решает, что несуществующий системный программный продукт может удовлетворить ее потребности, нет особого смысла разрабатывать подробную функциональную спецификацию. В таких случаях основное внимание следует уделять разработке требований к информации, определяющих, какая информация нужна людям для выполнения их работы. Информационные требования определяют требуемую информацию и то, как она предоставляется и регулируется. Поэтому в информационном запросе для системы Mentcare может быть указано, какая информация должна быть включена в список пациентов, которые, как ожидается, будут назначены в этот день.
Неопределенность в спецификации требований может привести к разногласиям между заказчиками и разработчиками программного обеспечения. Для разработчика системы естественно интерпретировать неоднозначное требование таким образом, чтобы упростить его реализацию . Но часто это не то, чего хочет клиент. Необходимо установить новые требования и внести изменения в систему. Конечно, эта система задерживает доставку и увеличивает затраты.
Например, первый запрос системы Mentcare в приведенном выше списке означает, что пользователь может искать в списке приемов все клиники. Логическая причина этого требования заключается в том, что пациенты с проблемами психического здоровья иногда находятся в замешательстве. Они могут встретиться в одной клинике, а на самом деле пойти в другую клинику. Если они записаны на прием, они будут записаны как посетившие, независимо от клиники.
Зная имя «искомого» пациента, поставщик медицинских услуг, задавший поисковый запрос, может ожидать, что система будет искать это имя на всех встречах во всех клиниках. Однако это требование четко не сформулировано. Разработчики системы могут комментировать, чтобы упростить выполнение запроса. Их функция поиска может потребовать от пользователя выбрать клинику, а затем найти пациентов, которые посетили эту клинику. Это требует большего количества действий пользователя и, следовательно, занимает больше времени для завершения поиска.
В идеале спецификация функциональных требований к системе должна быть полной и последовательной. Полнота означает, что все услуги и информация, требуемые пользователем, должны быть идентифицированы. Соответствие означает, что требования не должны противоречить друг другу.
На практике непротиворечивость и полнота требований могут быть достигнуты только для очень небольших программных систем. Одна из причин этого заключается в том, что при написании спецификаций для больших и сложных систем легко допустить ошибки и упущения. Другая причина заключается в том, что в больших системах много заинтересованных сторон с разным опытом и ожиданиями. Заинтересованные стороны могут иметь разные и часто противоречивые потребности. Эти несоответствия могут быть неочевидными при первоначальном изложении требований, а несоответствия могут быть выявлены только после углубленного анализа или во время разработки системы.