Титульный лист

<Project>

Project Proposal

Версия 1.0

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


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

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


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

1. Введение

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

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

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

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

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

2. Назначение проекта

<INSERT>
[This section should describe what the project is supposed to accomplish including the business drivers and other justification as deemed appropriate. For example, why did the customer request the project and why did the GSO consider it important to go forward?
Essence
Expected results
Target Audience]

3. Предмет проекта и требования

<INSERT>
[Description of the project scope in summary and requirements in more details as you know it so far is in this section. Highlight what is requested to be included as well as what is excluded. Try to be as specific as possible. For example, list the functionality that has been agreed to so far. It can always be changed later within a document scope. The items in this section should also roll up to your objectives.]

4. Опции

<INSERT>
[In this section list and detail all options for consideration. Include all pros and cons including benefits and risks per option.]

5. Рекомендации

<INSERT>
[In this section identify which option you recommend and why. Provide as many details as possible. You can also provide an alternate recommendation, if appropriate.]

6. Timeline

<INSERT>
[This section should describe the high level timeline with milestones where known. Describe any phasing strategies here. The timeline should roll up to your objectives.]

Major Milestones	Phases	Start	Deadline	Comments
Stage	-	-	-	-
-	Phase	-	-	-
General FTE	-	-	-	-

7. Межпроектные зависимости

<INSERT>
[Describe or list in detail those projects or systems which either have an impact on this project or any project(s) this will impact.]

8. Допущения

<INSERT>
[List any assumptions used to develop this document. For example, IT will provide a DBA, sys admin, etc. Assumptions could include any data points you used in order to come up with any commitment in this document.]

9. Известные риски

<INSERT>
[Known Risks are unanswered questions which need to be monitored/addressed in the future. Known Risks will probably end up necessitating a change to this document.]

10. Ответственности

<INSERT>
[Describes the responsibilities of "parties" involved in this project]

11. Ресурсы

<INSERT>
[Resources to be allocated for this project]

11.1 Human Resources
<INSERT>
[List of roles/specialties with number of people for each of it]

11.2 Software Resources
<INSERT>
[List of software tools necessary for the development team]

11.3 Hardware Resources
<INSERT>
[List of hardware equipment necessary for the development team]

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

[Этот раздел предназначен для того, чтобы фиксировать согласие с вышеизложенным и, фактически, подписывать, визировать данный документ]

Person Name	Title	Approval Date	Status
-	-	-	-

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

Date	Version	Description	Author
-	-	-	-

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