requirements-specification.md

1. Введение

Введение представляет собой обзор, помогающий читателям разобраться
в структуре и принципе использования спецификации требований к ПО.

1.1 Назначение

Определите продукт или приложение, требования для которого указаны
в этом документе, в том числе редакцию или номер выпуска. Если эта специ-
фикация требований к ПО относится только к части системы, идентифици-
руйте эту часть или подсистему. Опишите типы читателей, которым адресо-
ван этот документ, например разработчикам, менеджерам проектов, маркето-
логам, пользователям, тестировщикам или составителям документации.

1.2 Соглашения, принятые в документах

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

1.3 Границы проекта

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

1.4 Ссылки

Перечислите все документы или другие ресурсы, на которые вы ссылаетесь
в этой спецификации, в том числе гиперссылки на них, если их местополо-
жение меняться не будет. Это могут быть руководства по стилям пользова-
тельского интерфейса, контракты, стандарты, спецификации к системным
требованиям, спецификации интерфейса и спецификации требований к ПО
связанных продуктов. Объем информации должен быть достаточным для
того, чтобы пользователь сумел при необходимости получить доступ к каж-
дому указанному материалу, а именно: название, имя автора, номер версии,
дата, источник, место хранения или URL-адрес.

2 Общее описание

В этом разделе представлен общий обзор продукта и среды, в которой он бу-
дет применяться, предполагаемая пользовательская аудитория, а также из-
вестные ограничения, предположения и зависимости. Этот раздел не определяет
специфические требования. Он предоставляет бэкграунд для требований, опре-
деленных в пункте 3 и помогает их понять. В каком-то смысле, этот раздел
рассказывает о требованиях на естественном языке для конечного потребителя.
Раздел 3 будет содержать специфические требования, которые написаны для
разработчиков.

2.1 Общий взгляд на продукт

Опишите контекст и происхождение продукта. Поясните, является он новым
членом растущего семейства продуктов, новой версией существующей систе-
мы, заменой существующего приложения или совершенно новым продуктом.
Если спецификация требований определяет компонент более крупной систе-
мы, укажите, как это ПО соотносится со всей системой и определите основ-
ные интерфейсы между ними. Неплохо также включить визуальные модели,
такие как контекстную диаграмму или карту экосистемы,
чтобы показать взаимосвязь продукта с другими системами.

2.2 Классы и характеристики пользователя

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

2.3 Операционная среда

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

2.4 Ограничения дизайна и реализации

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

2.5 Предположения и зависимости

Предположение (assumption) — это утверждение, которое предполагается
верным в отсутствие знаний или доказательств иного. Проблемы возможны
в том случае, если предположение неверны, устарели, не находятся в совмест-
ном использовании или изменяются, поэтому определенные предположения
можно отнести к группе рисков проекта. Один читатель спецификации тре-
бований к ПО может считать, что продукт будут соответствовать особому
стандарту пользовательского интерфейса, тогда как другой предположит не-
что совершенно иное. Разработчик может думать, что определенный набор
функций написан специально для этого приложения, бизнес-аналитик — что
он будет взят из предыдущего проекта, а менеджер проекта — что предпола-
гается приобрести коммерческую библиотеку функций. Включаемые здесь
предположения относятся к системной функциональности; предположения
относящиеся к бизнесу представлены в документе концепции и границ про-
екта, как описано в главе 5.
Определите все зависимости проекта или создаваемой системы от внеш-
них факторов или компонентов вне ее контроля. Например, до установки
продукта может требоваться установить Microsoft .NET Framework 4.5 или
более позднюю версию — это зависимость.

3. Функции системы

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

В этом разделе описывается:

* Как проверяются входные данные
* Точная последовательность действий
* Реакция на аномальные ситуации, включая
    
    - утечки
    - ошибки коммуникации
    - обработку ошибок и восстановление

* На что влияют входные параметры
* Связь входных и выходных данных, включая
    
    - Последовательность входных/выходных данных
    - Формулы преобразования входных данных в выходные данные

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

3.X Функция системы X

Опишите название особенности несколькими словами, например «3.1 Про-
верка правописания». Так же назовите подразделы с 3.x.1 по 3.x.3 для каждой
функции системы.

3.X.1 Описание

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

3.X.2 Функциональные требования

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

4. Требования к данным

Ценность информационных систем заключается в том, что они предостав-
ляют возможность манипулировать данными. Используйте этот раздел ша-
блона для описания различных аспектов данных, которые будет потреблять
система в качестве входной информации, как-то обрабатывать и возвращать
в виде выходной информации.

4.1 Логическая модель данных

Модель данных это визуальное представление объ-
ектов и наборов данных, которые будет обрабатывать система, а также от-
ношений между ними. Существует много видов нотации для моделирования
данных, в том числе диаграммы отношений «сущность–связь» и диаграммы
классов UML. Можно включить модель данных для бизнес-операций, вы-
полняемых системой или логическое представление данных, с которыми
будет работать система. Это не то же самое, что модель данных реализации,
которая реализуется в виде дизайна базы данных.

4.2 Словарь данных

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

4.3 Отчеты

Если приложение будет генерировать отчеты, перечислите их здесь и опи-
шите их характеристики. Если отчет должен соответствовать определенному
готовому макету, можно указать это как ограничение, возможно с примером.
В противном случае сосредоточьтесь на логических описаниях, порядке со-
ртировки, уровнях суммирования и т. п., отложив подробный макет до этапа
дизайна.

4.4 Получение, целостность, хранение и утилизация данных

Если это важно, опишите, как получают и обслуживают данные. Например,
при открытии канала номенклатуры данных может требоваться первым де-
лом выполнить начальный дамп всей номенклатуры данных в принимающую
систему, а после этого использовать каналы для передачи только изменений.
Укажите все требования, относящиеся к защите целостности данных систе-
мы. Укажите все процедуры, которые могут потребоваться, например резерв-
ное копирование, создание контрольных точек, зеркальное отображение или
проверка корректности данных. Укажите политики, которые должна приме-
нять система для хранения или утилизации данных, в том числе временных
данных, метаданных, остаточных данных (таких как удаленные записи), дан-
ных в кеше, локальных копий, архивов и промежуточных архивов.

5. Требования к внешним интерфейсам

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

5.1 Пользовательские интерфейсы

Опишите логические характеристики каждого пользовательского интер-
фейса, который необходим системе. Некоторые особенные характеристики
пользовательских интерфейсов могут упоминаться в разделе «6.1 Удобство
использования». Некоторые из них перечислены здесь:

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

5.2 Интерфейсы ПО

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

5.3 Интерфейсы оборудования

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

5.4 Коммуникационные интерфейсы

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

6 Атрибуты качества

В этом разделе описываются нефункциональные требования помимо огра-
ничений и требований к внешним интерфейсам.
Эти характеристики должны быть точно определе-
ны и поддаваться проверке и измерению. Укажите относительные приори-
теты различных атрибутов, например приоритет простоты использования
над легкостью изучения или приоритет безопасности над производительно-
стью. Необходимые степени качества удается гораздо эффективнее описать
с помощью подробных нотаций спецификации, таких, как Planguage, чем с
помощью простых описательных утверждений.

6.1 Удобство использования

Требования к удобству использования подразумевают легкость изучения,
простоту использования, предотвращение ошибок и восстановление, эффек-
тивности взаимодействия и специальные возможности. Указанные в этом
разделе требования к удобству использования помогут дизайнеру интерфей-
сов создать максимально удобную для пользователя рабочую среду.

6.2 Производительность

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

6.3 Безопасность

Укажите все требования, касающиеся безопасности или конфиденциально-
сти, которые ограничивают доступ или возможности использования про-
дукта. Это может быть физическая безопасность, а также защита данных или
ПО. Источником требований к безопасности, как правило, являются бизнес-
правила, поэтому определите политики или положения, касающиеся защиты
или конфиденциальности, которым продукт должен соответствовать. Если
они задокументированы и хранилище бизнес-правил, просто сошлитесь на
них.

6.4 Техника безопасности

В этом разделе укажите требования, связанные с возможными потерями,
повреждениями или ущербом, которые могут быть результатом использова-
ния продукта. Определите меры безопасности или упреждающие действия,
которые можно предпринять, так же как и потенциально опасные действия,
которые можно предотвратить. Определите сертификаты по безопасности,
политики или положения, которым продукт должен соответствовать.

6.X Другие

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

7. Требования по интернационализации и локализации

Требования по интернационализации и локализации обеспечивают возмож-
ность использовать продукт в других странах, региональных стандартах и
географических районах, отличающихся от тех, в которых он был создан.
Такие требования могут быть направлены на разрешение различий в валю-
тах, форматировании дат, чисел, адресов и телефонных номеров, языках, в
том числе различных вариантах одного языка (например, американского
и британского вариантов английского), используемых символах и наборах
символов, личных именах и фамилиях, часовых поясах, международных нор-
мативных актах и законах, культурных и политических традициях, размере
используемой бумаги, единицах веса и меры, электрическом напряжении и
конфигурации электрических разъемов и во многом другом. Требования по
интернационализации и локализации вполне могут повторно использовать-
ся во многих проектах.

8. Остальные требования

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

Приложение А. Словарь терминов

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

Приложение Б. Модели анализа

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