Некоторые из нефункциональных требований для «высокой доступности» сопоставлены с вариантом использования, называемым «Обеспечение высокой доступности», отмеченным как ‹>.
Как говорится, «если у вас есть единственный инструмент, это молоток, каждая проблема выглядит как гвоздь». Существуют варианты использования для определения ценности, которую система предоставляет своим пользователям. Итак, они предназначены для описания функциональных вещей: того, что делает система.
Поэтому я бы не рекомендовал таким способом захватывать нефункционалы. Однако: это не значит, что они не могут быть зафиксированы в сценариях использования. Может быть очень полезно внутри функциональных вариантов использования указать их нефункциональные требования. Например:
Use Case: Submit Order
{...functional description...}
Availability: 9-5 mon-fri
Volumes: 5000 peak per day
...
Это напрямую связывает нефункциональное требование с функцией, которую оно поддерживает. Что имеет смысл - поскольку нефункционалы не имеют цели или контекста без функции.
Конечно, вы обнаружите, что многие варианты использования имеют одни и те же нефункционалы. Вы не хотите дублировать, поэтому вам нужно найти способ исключить их. Я предпочитаю сделать это в отдельном документе.
Но нет закона против захвата в «сценариях использования». Хотя это и противоречит теории, есть причины делать это на практике: например, ограничения инструмента моделирования (невозможно связать UC с документом) и / или желание хранить все в одном месте.
По сути, все сводится к теории и практике. Теоретически нефункционального варианта использования не существует. На практике может иметь смысл создание объединенных коммуникаций для хранения нефункционалов. Пока все понимают, что это всего лишь удобный контейнер, а не настоящая функциональность, я бы не стал волноваться по этому поводу.
hth.
person
sfinnie
schedule
17.09.2013
