Рассмотрим примерное содержание Requirements (Запрос на разработку)- документа, подготавливаемого заказчиком.
Титульный лист

<Project>

Requirements

Версия 1.0

Дата создания


Подготовлен:
Фамилия И. О.
E-mail:

Контактная информация:
Фамилия И. О.
E-mail:


Полное название организации
Адрес:
Телефон:

1. Введение

1.1 Назначение
Документ Requirements описывает поведение <Project> с пользовательской точки зрения, включая подробное описание требований к продукту. Наряду с функциональными требованиями, он также описывает и нефункциональные, а также проектные требования и ограничения и другие факторы, необходимые для предоставления полного и ясного описания требований к продукту.

1.2 Предмет
Предметом данного документа является продукт <Project>, а также его особенности и требования к нему.

1.3 Термины, определения и соглашения
1.3.1 Аббревиатуры
<INSERT>

1.3.2 Соглашения
<INSERT>

1.4 Ссылки
[Данный подраздел предоставляет полный список всех документов, на которые имеется ссылка где-либо в Requirements.]

Номер	Название	Дата и Издательство	Автор	Комментарий
-	-	-	-	-

1.5 Влияние на бизнес-процессы
<INSERT>
[В этом разделе указывается на какие процессы и как влияет данный проект. По одному подразделу на каждый процесс.]

2. Бизнес-требования

2.1 Поток бизнес-процесса
<INSERT>
[Поместите здесь диаграмму бизнес-процесса.]

2.2 Описание бизнес-процесса
<INSERT>
[Предоставьте подробное описание бизнес-процесса, представленного на диаграмме 2.1]

2.3 Функциональные требования
<INSERT>
[Опишите с точки зрения бизнеса (т.е. что должно быть разработано) что есть требование. Здесь необходимо кратко описать желаемые возможности продукта.]

2.4 Бизнес-правила
<INSERT>
[Опишите все необходимые бизнес-правила и расчеты.]

2.5 Безопасность
<INSERT>
[Определите все вопросы безопасности: безопасность данных, системы, сети, физической и проч. безопасности]

2.6 Требования к данным
<INSERT>
[Определите все данные, их описания, режимы редактирования, источники, маппирование данных на другие базы и т.д.]

2.7 Требования к преобразованию данных
<INSERT>
[Определите все данные, преобразование которых может потребоваться и их источники, включая маппирование и редактирование]

2.8 Требования к пользовательской документации
<INSERT>
[Описывает реализацию он-лайновой пользовательской документации (при ее наличии), помощи, заметок "help about" и т.д.]

2.9 Требования, которые, возможно, появятся в будущем
<INSERT>
[Опишите то, что не было включено к этому моменту.]

2.10 Зависимости
<INSERT>
[Укажите от чего зависит данная система, ее данные, проект и прочие объекты проекта.]

3. Технические требования

<INSERT>
[Этот раздел описывает главные элементы процесса разработки продукта. Уровень детализации должен быть выбран таким образом, чтобы заказчик понимал, что он получает. У разработчиков же, должно быть достаточно информации для того, чтобы начать детальную разработку проекта системы.]

3.1 Обзор используемого программного обеспечения и обоснование причин выбора
<INSERT>
[Этот раздел описывает программные пакеты и приложения, которые необходимо использовать при разработке, а также еще раз описывает причины выбора данных продуктов.
Нижеследующий процесс может быть использован для оценки программного обеспечения.
- Определите всех потенциальных производителей.
- Создайте список функциональности пакета и оцените каждую функцию.
- Создайте матрицу функциональностей по производителю и проставьте значение каждой функции..
- Сравните цены производителей, цены реализации, приобретения права собственности на пакет, стоимость адаптации.
- Определите финансовое состояние производителя.
- Проверьте ссылки на производителей.
- Определите отношения <Купить> (все решение пакетное, часть решения пакетная, пакет является ядром системы).
Подробнее производители рассматриваются ниже:]

Наименование производителя	Название продукта	Web Address	Контакт	Телефон
-	-	-	-	-

3.2 Экранные виды
<INSERT>
[Здесь нужно привести видение пользовательского интерфейса с точки зрения пользователя. Включая следующие пункты для каждого экрана:
- Расположение.
- Экранные области.
- Меню.
- Проверки.
- Опции.
- Эффекты нажатия кнопок.
- Кнопки.
- Навигация.
- Buttons.]

3.3 Применимость
<INSERT>
[This section includes all those requirements that affect usability. For example,
- specify the required training time for a normal users and a power user to become productive at particular operations;
- specify measurable task times for typical tasks or base the new system's usability requirements on other systems that the users know and like;
- specify requirement to conform to common usability standards, such as IBM's CUA standards, Microsoft's GUI standards etc.]

3.4 Надежность
<INSERT>
[Requirements for reliability of the system should be specified here. Some suggestions follow:
- Availability-specify the percentage of time available ( xx.xx%), hours of use, maintenance access, degraded mode operations, and so on.
- Mean Time Between Failures (MTBF) - this is usually specified in hours, but it could also be specified in terms of days, months or years.
- Mean Time To Repair (MTTR)-how long is the system allowed to be out of operation after it has failed?
- Accuracy-specifies precision (resolution) and accuracy (by some known standard) that is required in the system's output.
- Maximum Bugs or Defect Rate-usually expressed in terms of bugs per thousand lines of code (bugs/KLOC) or bugs per function-point( bugs/function-point).
- Bugs or Defect Rate-categorized in terms of minor, significant, and critical bugs: the requirement(s) must define what is meant by a "critical" bug; for example, complete loss of data or a complete inability to use certain parts of the system's functionality.]

3.5 Производительность
<INSERT>
[The system's performance characteristics are outlined in this section. Include specific response times. Where applicable, reference related Use Cases by name.
- Response time for a transaction (average, maximum).
- Throughput, for example, transactions per second.
- Capacity, for example, the number of customers or transactions the system can accommodate.
- Degradation modes (what is the acceptable mode of operation when the system has been degraded in some manner).
- Resource utilization, such as memory, disk, communications, and so forth.]

3.6 Масштабируемость
<INSERT>
[Describe any transaction volumes, expected growth and what considerations are needed for scalability of the system.]

3.7 Удобство поддержки
<INSERT>
[This section indicates any requirements that will enhance the supportability or maintainability of the system being built, including coding standards, naming conventions, class libraries, maintenance access, and maintenance utilities.]

3.8 Требования к средствам разработки и производства
<INSERT>
[Identify all development and production hardware, operating systems, software and related information in detail.]

3.8.1 Среда разработки
<INSERT>

3.8.2 Среда производства
<INSERT>

3.8.3 Программное обеспечение для разработки
<INSERT>

4. Требования к персоналу

<INSERT>
[The following table contains a list of everyone who will play a role in the development of the system.]

Имя	Организация	Роль
-	-	-

5. Требования к поддержке

5.1 Бизнес-подготовка
<INSERT>
[What support business changes will be made as a result of implementation of the project.]

5.2 Системная подготовка
<INSERT>
[Hardware, OS, network, environment issues that need to be addressed.]

5.3 Обучние
<INSERT>
[What training will be done for business, IT, support, etc. and who will conduct training and who will create training materials.]

5.4 Поддержка
<INSERT>
[The following table contains a list of everyone who will play a role in the ongoing maintenance of the system following implementation.]

Имя	Организация	Роль
-	-	-

6. Планирование контрольных сроков

<INSERT>
[A high-level bullet list of major milestones. The file location of the detailed schedule if appropriate.]

7. Критерии удовлетворения бизнес-требований

<INSERT>
[Identify the criteria by which the business, project office, and support will deem the project a success and complete.]

8. Основные технические и бизнес-допущения

8.1 Основные бизнес-допущения
<INSERT>
[A bullet list of all assumptions made.]

8.2 Основные технические допущения
<INSERT>
[A bullet list of all assumptions made.]

9. Открытые вопросы
Список вопросов, которые все еще не разрешены..

Вопрос	Разрешить в срок до	Ответственный
-	-	-

10. Утверждения

Person Name	Title	Approval Date	Signature
-	-	-	-

История изменений документа

Date	Version	Description	Author
-	-	-	-