[
Комментарий: Для сравнительного анализа важен подбор критериев сравнения. Критерии анализа должны полностью отражать ключевые бизнес-требования, описанные в разделе 1, а также наиболее приоритетные детализированные требования и ограничения, которые описываются в разделе 3.
В начале данного раздела необходимо дать пояснения по выбору критериев сравнения.
Результаты сравнения желательно представлять в виде таблицы. Пример таблицы сравнения:
| Критерии сравнения | Название решения 1 | Название решения 2 | Название решения 3 | … |
| Критерий 1 | ||||
| Критерий 2 | ||||
| Критерий 3 | ||||
| … |
Замечание: Если при проведении сравнения использовались статьи и иные источники со сравнительным обзором решений, статистические данные либо иные дополнительные сведения то необходимо указывать ссылки на использованные источники.
]
Выводы по анализу
[
Комментарий: Данный пункт подводит итоги сравнения аналогов и должен содержать вывод с принятием определенного решения в рамках проекта, которое может сводиться, к примеру:
− к выбору какого-либо из рассмотренных существующих решений (части решения или комбинации нескольких решений) в качестве основы для построения собственного решения;
− к определению ключевых достоинств и недостатков наиболее подходящих решений и переходу к разработке собственного решения «с нуля», которое устранит недостатки существующих решений и будет полностью удовлетворять требованиям заказчика.
]
Концепция решения
[
Комментарий: Этот раздел содержит общее описания подхода проектной команды к удовлетворению потребностей пользователя. Он включает в себя понимание потребностей пользователя, круга пользователей и заинтересованных лиц, описание возможностей и функций будущей системы.
|
|
Концепцию решения предлагается описывать одним из следующих трех способов (на ваш выбор):
- Техническое задание
- Модель прецедентов
- Customer Journey Mapping + User Story Mapping
Раздел «Концепция решения» завершается анализом рисков проекта.
Замечание: Концепция решения обеспечивает команду ограниченными, но достаточными деталями для выработки в дальнейшем законченного решения, при этом она должна включать в себя анализ рисков проекта, анализ осуществимости проекта, удобство использования готового продукта, а также анализ будущих эксплуатационных характеристик.
]
Техническое задание
[
Комментарий: Техническое задание на разработку автоматизированной системы (далее - АС) является основным документом, определяющим требования и порядок создания (развития или модернизации - далее создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие.
Литература по разделу:
- Карл Вигерс
Разработка требований к программному обеспечению
− Глава 5. Определение образа и границ проекта
− Глава 10. Документирование требований
− Глава 14. Назначение приоритетов требованиям
- Дин Лэффингуэлл, Дон Уидриг
Принципы работы с требованиями к программному обеспечению. Унифицированный подход
− Часть 5. Уточнение определения системы
- ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы
https://www.rugost.com/index.php?option=com_content&view=article&id=96:gost-34602-89&catid=22:34&Itemid=53 - Техническое задание на сайт
https://habrahabr.ru/post/138749/
|
|
https://habrahabr.ru/post/140574/
]
Общие сведения
[
Комментарий: В разделе «Общие сведения» указывают:
1) полное наименование системы и ее условное обозначение;
2) наименование предприятий (объединений) разработчика и заказчика (пользователя) системы;
3) плановые сроки начала и окончания работы по созданию системы;
4) сведения об источниках и порядке финансирования работ;
]
<<НАЧНИТЕ ТЕКСТ ЗДЕСЬ>>
Назначение и цели создания системы
[
Комментарий: В подразделе «Назначение системы» указывают вид автоматизируемой деятельности (управление, проектирование и т. п.) и перечень объектов автоматизации (объектов), на которых предполагается ее использовать. Для АСУ дополнительно указывают перечень автоматизируемых органов (пунктов) управления и управляемых объектов.
В подразделе «Цели создания системы» приводят наименования и требуемые значения технических, технологических, производственно-экономических или других показателей объекта автоматизации, которые должны быть достигнуты в результате создания АС, и указывают критерии оценки достижения целей создания системы.
]
<<НАЧНИТЕ ТЕКСТ ЗДЕСЬ>>
Требования к системе
[
Комментарий: Требования идентифицируют что программный продукт должен делать. Эти требования выражаются в функциональных терминах (например, система регистрации пользователей на Web-сайте должна протоколировать все события, связанные с попытками регистрации пользователей на сайте), правилах или параметрах, обеспечивающих выполнение заложенной в систему функциональности (пользователь, зарегистрировавшись раз, получает доступ откуда угодно в пределах сети организации).
|
|
Требования существуют как на пользовательском уровне, так и на уровне организации (архитектуры) программного продукта.
Замечание: Требования пользовательского уровня и уровня организации являются ключевыми для определения границ проекта и архитектурной стратегии. Требования являются мостом между анализом использования и описанием решения. Хорошо описанные требования демонстрируют понимание командой разработчиков потребностей пользователя. Требования являются основой для создания более детальной проектной документации на следующей фазе проекта. Анализ требований снижает риск неудачи проекта.
В данном разделе обязательным является описание функциональных требований, описание иных видов требований (наиболее подробно виды требований описаны в ГОСТ 34.602-89) зависит от специфики проектного решения.
Важно! В подпунктах перечислены некоторые возможные виды требований. Заполнение всех видов требований необязательно и полностью зависит от специфики проекта. Вы можете добавить собственные виды требований в качестве подпунктов при необходимости.
Важно: при описании требований (особенно функциональных требований) указывайте приоритет реализации требования (низкий, средний, высокий)
]
<<НАЧНИТЕ ТЕКСТ ЗДЕСЬ>>