Что считается функциональным требованием, а что нет в следующем примере?

Question

Для домашней работы я должен написать функциональное требование игры под названием downfall ( см. Википедию ). Мы должны сделать эту игру, но не с двумя сторонами, а с n (любым числом) сторон.

В примере решения (другая игра) учитель записывает функциональные требования, а затем пишет, к какому сценарию использования они принадлежатк.

Я создал диаграмму прецедентов, в которой игрок является актером, а ChooseDial, RotateDial и EndTurn в качестве прецедентов:

Что я не понимаю, так это следующее: Является ли количество игроков функциональным требованием? Является ли стол, имеющий две стороны, функциональным требованием? Является ли цель игры (получение монет сверху вниз) функциональным требованием? Должно ли такое правило, как монеты, достигать дна, чтобы соответствовать функциональному требованию?

Если это так, к какому варианту использования они могут принадлежать? Моя диаграмма вариантов использования неверна?

Я понятия не имею, куда поместить эти функциональные требования, потому что я чувствую, что они не являются частью какого-либо из моих вариантов использования.

Answer 1

О требованиях

Сначала рассмотрим вопрос с требованиями:

• A функциональное требование говорит о том, что должно делать программное обеспечение. Все, что связано с целью, игровым процессом или правилами игры, является функциональным требованием.
• A нефункциональное требование говорит о том, каким должно быть программное обеспечение, например, насколько точно, какПроизводительность, простота использования, простота обслуживания. Ваш рассказ не показывает таких требований.

О прецедентах

Методы разработки программного обеспечения, основанные на прецедентах, начинаются с целей пользователя высокого уровня, которые фиксируются в прецедентах. Лично я вижу только одну такую ​​цель:

Очень редкое использование : множественность на стороне актера варианта использования. Это говорит о том, что в одном случае использования участвуют 2 или более экземпляров игроков. Конечно, это имеет смысл только для игры в целом, а не для отдельных действий (как у вас на диаграмме).

На вашей диаграмме вы показали 3 варианта использования:

• является EndTurn независимой целью, которую пользователь может свободно выбирать? Нет! Это то, что всегда следует за действиями игрока. Так что это определенно не случай использования.
• Вы говорите, что RotateDials расширяется ChooseDials. Это означает, что игрок может ChooseDials, но не вращать его. Это правильный сценарий?
• с другой стороны, если вы скажете, что ChooseDials включает RotateDials, последнее всегда будет происходить. Но разве ChooseDial не будет чем-то большим, чем просто выбор циферблата? Разве это не должно тогда называться PlayTurn?

Я мог бы понять, что для целей обучения вы захотите разложить Play game в более подробных сценариях использования. Как правило, когда игроки пытаются достичь своей цели Play game, это может включать подцели Play turn. Пока это целенаправленно и не слишком подробно, это нормально. Но избегайте простой функциональной декомпозиции (это не помогает быть более управляемым пользователем, и варианты использования не являются функциями). И, прежде всего, не злоупотребляйте диаграммой прецедентов для попытки показать последовательность действий .

Отслеживаемость требований

Варианты использования не охватывают все требования. Он отражает самую важную вещь: назначение системы и цели пользователя.

Когда вы записываете требования, полезно руководствоваться сценариями использования и их описанием, а также отслеживать каждое конкретное требование варианта использования.

Но, конечно, есть и общие требования. Они не являются специфическими для конкретного варианта использования. Некоторые даже общие для всех вариантов использования. Отметьте их как общие требования (например, вариант использования *).

Answer 2

Управление требованиями (RM) действительно может быть сложным. Требование типа Плата должна иметь две стороны , кажется, больше вовлечены в проект, чем в вариант использования. В таких случаях вы можете связать это с границей, а не с одним вариантом использования. Это будет означать, что это какое-то «глобальное» требование (похожее на нефункциональное требование). Обычно в проекте вы начинаете с более или менее странного сочетания требований, смешанных в пользовательских историях. Бизнес-аналитик (BA) должен прочесать эту информацию и придумать подходящие варианты использования (синтезировать добавленную стоимость). Затем системный архитектор (вместе с БА) рассмотрит требования и варианты использования для создания модели (бизнес) класса.

Существуют тонны книг и процедур, описывающих RM. Много семинаров тоже. Я думаю, что если вы поймете сжатую идею выше, вы готовы начать. Это марафон для начала ...