Пример требований к системе. Часть 1.

В связи с огромным количеством вопросов: «А где можно найти образец написания требований к системе?» - и стандартным ответом: «В рунете - маловероятно», - выкладываю вариант описания требований к системе.

В целом эта документация базируется на руповском шаблоне SRS. Это не плохо и не хорошо. Для некоторых команд было бы удобней видеть не варианты использования, а пользовательские истории. И совсем не видеть функциональных требований в виде «Система должна» ;-) . А описание объектов можно делать и более удобным способом. Но так писать тоже можно. В конце концов, если бы на проектах была такая документация, жить как программисту, так и тестировщику было бы значительно проще.

Документация «рабочая», т.е. перед выкладкой не прилизывалась. Часть информации не заполнена. Сделано это умышленно, чтобы показать работу с документом. Набор частей также не полон.

Дисклаймер. Авторские права да данный материал полностью принадлежат мне. При публикации не пострадали интересы ни одной фирмы.

1 Введение

1.1 Цель
Цель документа «Спецификации требований к программному обеспечению» - определение требований к продукту и согласование их с заказчиком.
Документ является основанием для заключения контракта с заказчиком.

1.2 Область действия документа
Документ включает общее видение продукта, формализованные требования, описание объектов системы и прототипы пользовательского интерфейса. Таким образом, данный документ является достаточным для разработки продукта.

1.3 Определения
Прецеденты (юзкейсы) – варианты использования ПО пользователями.

1.4 Аббревиатуры
CRUD (Create, Read, Update, Delete) – группа стандартных прецедентов (юзкейсов) объекта, касающиеся создания, просмотра, редактирования и удаления.
ОДЛ – Основное действующее лицо

2 Общее описание
2.1 Предназначение и перспективы продукта
Продукт разрабатывается как законченное решение для конкретной фирмы заказчика (в дальнейшем просто заказчик) для управления территориально распределенной группой медпредставителей.

Основное предназначение продукта – возможность контроля действий медпредставителей и получение данных для дальнейшего анализа и планирования действий вне рамок разрабатываемой системы.
Для успеха продукта необходимо обеспечить:

  • Легкость ввода первичной информации
  • Достаточность отчетов

2.2 Роли
1. Администратор – осуществляет настройку и контроль над системой.
2. Медпредставитель – вводит исходную информацию, отслеживает информацию и получает сводные отчеты по своим партнерам.
3. Аналитик – получает сводные отчеты в целом по фирме

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

2.3 Обзор модели вариантов использования
Будет доработано позднее.

2.3.1 Введение
Функции системы объединяются в следующие группы:

  • Работа с партнерами
  • Управление партнерами и медпредставителями
  • Отчеты
  • Администрирование
  • Работа со справочниками

2.3.2 Обзор описания
Будет доработано позднее.

2.3.3 Иерархия модели вариантов использования
Будет доработано позднее.

2.3.4 Диаграмма модели вариантов использования
Будет доработано позднее.

2.4 Допущения и зависимости
В настоящий момент отсутствуют.

Оставьте комментарий

Вы должны войти, чтобы оставить свой комментарий.