Рассмотрим примерное содержание 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 |
| - | - | - | - |