Уроки 50 Лет Разработки ПО
Урок 57. Адаптируйте готовые шаблоны документов. Начало
Простые списки функций, запрашиваемых клиентами – хорошее начало для упорядочивания спецификации. Однако, есть шаблон спецификации требований к ПО (Software Requirements Specification, SRS), описанный в уже устаревшем стандарте IEEE 830. Шаблон содержит множество разделов, которые помогут систематизировать разнообразную информацию о требованиях. Однако, это не догма. Его можно и нужно менять, чтобы он лучше подходил для разрабатываемых вами систем.
РАСШИРЕННЫЙ ШАБЛОН СПЕЦИФИКАЦИИ ТРЕБОВАНИЙ К ПО
1. Введение.
1.1. Цель.
1.2. Условные обозначения.
1.3. Сфера применения проекта.
1.4. Ссылки.
2. Общее описание.
2.1. Перспектива продукта.
2.2. Классы и характеристики пользователей.
2.3. Операционная среда.
2.4. Ограничения и реализация.
2.5. Допущения и зависимости.
3. Системные функции.
3.x. Системная функция X.
3.x.1. Описание.
3.x.2. Функциональные требования.
4. Требования к данным.
4.1. Логическая модель данных.
4.2. Словарь данных.
4.3. Отчеты.
4.4. Целостность, хранение и удаление данных.
5. Требования к внешнему интерфейсу.
5.1. Пользовательские интерфейсы.
5.2. Программные интерфейсы.
5.3. Аппаратные интерфейсы.
5.4. Коммуникационные интерфейсы.
6. Атрибуты качества.
6.1. Удобство использования.
6.2. Производительность.
6.3. Безопасность.
6.4. Защищенность.
6.x. [другие].
7. Требования к интернационализации и локализации.
8. Другие требования.
Приложение A. Глоссарий.
Приложение Б. Модели анализа.
Шаблоны документов предлагают несколько преимуществ:
- определяют согласованные способы организации проектной информации, что облегчает людям, работающим с этими документами, поиск нужной информации.
- могут выявить потенциальные пробелы в знаниях автора документа о проекте, напомнить об информации, которую, возможно, следует добавить.
Предположим, вы решили использовать шаблон, приведённый выше, для структурирования информации о требованиях к новой системе. Не заполняйте его сверху вниз. Пишите определённые разделы по мере накопления соответствующей информации. Возможно, через какое-то время вы заметите, что раздел 2.5 «Допущения и зависимости» не заполнен. Это побудит задаться вопросом, есть ли какая-то недостающая информация о предположениях и зависимостях, которую нужно выяснить. Возможно, нужно побеседовать с определёнными заинтересованными сторонами. Может быть, никто ещё не указал на какие-либо вероятные предположения или зависимости и следует их определить. Некоторые допущения или зависимости могли быть записаны где-то еще; тогда, возможно, их следует переместить в этот раздел или добавить ссылки на них. Или, может быть, действительно нет никаких известных предположений или зависимостей. Пустой раздел напоминает, что вам ещё есть над чем поработать.
Кроме того, нужно подумать, что делать, если определённый раздел неактуален для вашего проекта. Один из вариантов — просто удалить его из документа с требованиями по завершении работы. Но отсутствие раздела может вызвать у читателя вопрос: «Я не увидел ничего о допущениях и зависимостях. Есть ли такие? Спрошу-ка я у кого-нибудь». Конечно, можно сохранить заголовок раздела и оставить сам раздел пустым, но это заставит читателя задаться вопросом, завершён ли документ. Лучше оставить заголовок и добавить пояснение: «Для этого проекта не было выявлено никаких допущений или зависимостей». Явное сообщение вызывает меньше путаницы, чем неявное.
Окончание следует…
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 7.