Диаграммы прецедентов - для двух приложений (документ спецификации требований к программному обеспечению)

Question

Я пишу документ СГД для двух приложений, которые обслуживают два пользователя ресторана "Система бронирования". Один для менеджера, а другой для клиента. Мне интересно, если я должен разделить их на разные системы, когда я рисую диаграмму варианта использования?

или поскольку они обслуживают одну и ту же систему, я должен поместить их в один и тот же системный блок?

-

+ Если вы, ребята, знаете какие-либо субтитры, которые я должен охватить в документе SRS, пожалуйста, опубликуйте их. Я рассмотрел только требования и варианты использования.

Answer 1

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

Вы, вероятно, будете членом команды SRS (если нет, попросите об этом), что означает, что разработка SRS будет совместным усилием для конкретного проекта. Несколько организаций по стандартизации (включая IEEE) определили девять тем, которые необходимо учитывать при разработке и написании SRS:

1. Интерфейсы
2. Функциональные возможности
3. Уровни производительности
4. Структуры данных / Элементы
5. безопасности
6. надежность
7. Безопасность / Безопасность
8. Качественный
9. Ограничения и ограничения

Образец базовой схемы SRS

1. Введение 1.1 Цель 1.2 Условные обозначения в документе 1.3 Предполагаемая аудитория 1.4 Дополнительная информация 1.5 Контактная информация / члены команды SRS 1.6 Ссылки
2. Общее описание 2.1 Перспектива продукта 2.2 Функции продукта 2.3 Классы и характеристики пользователя 2.4 Рабочая среда 2.5 Пользовательская среда 2.6 Ограничения проектирования / реализации 2.7 Допущения и зависимости
3. Требования к внешнему интерфейсу 3.1 Пользовательские интерфейсы 3.2 Аппаратные интерфейсы 3.3 Программные интерфейсы 3.4 Протоколы и интерфейсы связи
4. Системные функции 4.1 Системная функция A 4.1.1 Описание и приоритет 4.1.2 Действие / результат 4.1.3 Функциональные требования 4.2 Системная функция B
5. Другие нефункциональные требования 5.1 Требования к производительности 5.2 Требования безопасности 5.3 Требования безопасности 5.4 Атрибуты качества программного обеспечения 5.5 Проектная документация 5.6 Пользовательская документация
6. Другие требования Приложение A: Терминология / Глоссарий / Список определений Приложение B: подлежит определению

о вопросе, менеджер и клиент являются субъектами одной системы. Таким образом, вы должны использовать одну систему для вашего проекта.