Бизнес требования к программному обеспечению шаблон

Шаблон и описание документа требований к программному обеспечению

Шаблон один шаблон один

оглавление
1. Введение 1
1.1. Фон 1
1.2. Ссылка 1
1.3. Допущения и ограничения 1
1.4. Характеристики пользователя 1
2. Функциональные требования 1
2.1. Область действия системы 1
2.2. Архитектура системы (в этом разделе можно настроить двухуровневую систему) 1
2.3. Общий поток системы 2
2.4. Анализ спроса 2
2.4.1. XXXXXXX (название требования к функции) 2
2.4.1.1. Описание функции 2
2.4.1.2. Бизнес-моделирование 2
2.4.1.3. Описание сценария использования 3
2.4.1.4. Пользователь интерфейс 5
2.4.2. XXXXXXX (название требования к функции) 5
3. Нефункциональные требования 5
3.1. Требования к производительности 5
3.1.1. Точность 5
3.1.2. Требования к временным характеристикам 6
3.1.3. Требования к вводу и выводу 6
3.2. Требования к возможностям управления данными 6

Бизнес-требования, шаблон, наполнение

3.3. Требования безопасности и конфиденциальности 6
3.4. Требования к гибкости 6
3.5. Другие особые требования 6
4. Требования к операционной среде 6
4.1. Оборудование 6
4.2. Программное обеспечение поддержки 7
4.3. Интерфейс 7
4.4. Элемент управления 7
5. Отслеживание спроса 7
6. Подпишите пакет 7
1. Введение
1.1. Фон
Пояснение:
а. Название разрабатываемой программной системы;
б. Составитель задачи, разработчик, пользователь этого проекта и вычислительный центр или компьютерная сеть, реализующая программное обеспечение;
В. Базовое взаимодействие между программной системой и другими системами или другими учреждениями. к
1.2. Справочные материалы
Перечислите цитируемые и упоминаемые материалы в этом руководстве, например:
а. Утвержденный план и заявление о миссии или контракт этого проекта и одобрение вышестоящего органа;
б. Другие опубликованные документы, относящиеся к этому проекту;
c. Документы и материалы, цитируемые в этом документе, включая используемые стандарты разработки программного обеспечения. Перечислите названия, номера документов, даты публикации и единицы публикации этих документов и материалов, а также объясните источники, из которых можно получить эти документы и материалы.
1.3. Допущения и ограничения [необязательно]
Перечислите допущения и ограничения для разработки этого программного обеспечения, такие как ограничения финансирования, сроки разработки, состояние оборудования, вопросы подготовки пользовательских данных и связи и т. д.
1.4. Характеристики пользователя [необязательно]
Перечислите характеристики конечного пользователя программного обеспечения, полностью объясните уровень образования и технический опыт операторов и обслуживающего персонала, а также ожидаемую частоту использования программного обеспечения. Это важные ограничения при разработке программного обеспечения.

Основы разработки требований к ПО. Разбор книги Карла Вигерса. Главы 1 и 2

2. Функциональные требования
2.1. Область действия системы
Четко и кратко объясните высокоуровневые целевые требования пользователя к системе и продукту, такие как намерения разработки системы, цели приложений, объем действий и другие соответствующие справочные материалы.
Если определенный продукт является компонентом более крупной системы, необходимо объяснить взаимосвязь между этим продуктом и другими компонентами системы, и для этого можно использовать блок-схему. Объяснять состав системы, а также связь и интерфейс между этим продуктом и другими частями.
2.2. Архитектура системы (в этом разделе можно настроить двухуровневую систему) [необязательно]
описывает общую архитектуру системы в сочетании изображений и текста.
Ниже должна быть представлена ​​общая схема архитектуры системы:
Ниже описана общая архитектура системы:
2.3. Общий поток системы
Иллюстрирует общий процесс системы с комбинацией изображений и текста.
На рисунке 1 представлена ​​общая блок-схема системы управления контрактами на планирование.
Рис. 1
2.4. Анализ спроса
Цель анализа требований — получить или описать каждое функциональное требование в системных требованиях и определить, что система может делать с помощью анализа? Кто будет пользоваться этой системой?
· Создание модели варианта использования: обнаружение ролей и вариантов использования и определение взаимосвязи между ролями, взаимосвязи между вариантами использования и взаимосвязи между ролями и вариантами использования.
· Опишите вариант использования: описание того, как роль взаимодействует с системой.
2.4.1. XXXXXXX (название требования к функции)
2.4.1.1. Описание функции
Номер функции:
Функциональные требования: описание функциональных требований с точки зрения бизнеса пользователей.
2.4.1.2. Бизнес-моделирование
С визуальной точки зрения — диаграмма вариантов использования — описание функциональных требований.
Рисунок 2 Комплексный план Схема вариантов использования функциональных требований для системы управления редактированием договоров.
Рис. 2
2.4.1.3. Описание сценария использования
описывает взаимодействие между ролями и системой в каждом варианте использования в текстовом формате.
1, XXXXXX (название варианта использования)
Описание объекта Описание содержимого
Идентификатор Уникальный идентификатор варианта использования.
Описание Краткое описание варианта использования.
Участники. Список участников, связанных с вариантом использования, и их характеристики.
Частота Как часто участники посещают этот вариант использования
Статус обычно делится на: в процессе, ожидает проверки, прошел проверку или не прошел проверку.
Предварительные условия Список условий, если он содержит условия, эти условия должны быть выполнены перед доступом к варианту использования.
Постусловия Список условий, если он содержит условия, эти условия будут выполнены после успешного завершения варианта использования.
Расширенный вариант использования Расширенный вариант использования (если есть)
Включенные варианты использования Варианты использования, включенные в этот вариант использования (если есть)
Базовый рабочий процесс. Основной логический путь, по которому участники следуют в варианте использования, то есть рабочий метод варианта использования, когда все задачи выполняются нормально.
Необязательный рабочий процесс. Путь, по которому следует следовать в случае изменений в методах работы, отклонений или ошибок.
История изменений Изменено: Дата изменения: Причина изменения:
Если есть проблема, это список проблем, связанных с разработкой этого варианта использования или операции.
Ниже приводится описание варианта использования добавления контракта в требованиях функции редактирования контракта интегрированной системы управления планированием:
Описание объекта Описание содержимого
Идентификатор IPMS0101
Описание Добавить запись контракта
Участники Редакторы контрактов — знакомы с бизнесом по управлению контрактами
Частота
Статус прошел проверку
Предпосылки 1. Участник имеет право увеличить контракт 2. Участник выбрал соответствующую запись плана 3. Общая сумма инвестиций текущего плана ≥ SUM (цена подписанного контракта по плану)
Постусловие 1. Больше дисциплины контракта в базе данных 2. Вариант использования сканирования оригинала исполняемого контракта 3. Вариант использования увеличения платежа исполняемого контракта 4. Вариант использования модификации исполняемого контракта и удаления контракта
Расширенные варианты использования Нет
Включенные варианты использования Нет
Базовый рабочий процесс См. процесс увеличения контракта на рисунке 3.
Необязательный процесс операции Когда обнаруживается исключение, когда пользователь подтверждает увеличение контракта, система сообщает, что увеличение контракта недействительно.
История изменений Изменено: Дата изменения: Причина изменения:
Вопрос 1. Конкретное соглашение кода контракта 2. Конкретный дизайн словарной таблицы типа контракта, источника средств и агента контракта.

Рисунок 3 Процесс увеличения количества контрактов
2, XXXXX (название варианта использования)
……
2.4.1.4. Пользовательский интерфейс
описывает стиль пользовательского интерфейса, соответствующий функции. Проекты, которые принимают жизненный цикл прототипа, также могут предоставлять копию интерфейса прототипа.
2.4.2. XXXXXXX (название требования к функции)
……
3. Нефункциональные требования
3.1. Требования к производительности
3.1.1. Точность [необязательно]
Объясняет требования к точности входных и выходных данных программного обеспечения, которые могут включать точность во время передачи.
3.1.2. Требования к характеристикам времени
Объясняет требования к характеристикам времени программного обеспечения, такие как: время отклика; время обработки обновления; время преобразования данных и время передачи обновления интерфейса.
3.1.3. Требования к вводу и выводу
Объясните каждый тип входных и выходных данных и объясните их носитель, формат, числовой диапазон, точность и т. д., элемент за элементом. Объясните и приведите примеры вывода данных программного обеспечения и контрольного вывода, которые необходимо пометить, включая описание отчетов на бумажном носителе (нормальный вывод результатов, вывод состояния и ненормальный вывод) и графических или отображаемых отчетов.
3.2. Требования к возможностям управления данными [необязательно]
Объясняет количество файлов и записей, которыми нужно управлять, размер таблиц и файлов, а также требования к хранилищу данных и их компонентов, которые следует оценивать с учетом прогнозируемого роста.
3.3. Требования безопасности и конфиденциальности
У пользователя есть требования к возможностям системы по обработке ошибок, методам обработки, восстановлению системы после сбоя, восстановлению данных и т. д., а также требования к системе по предотвращению незаконного вторжения, модификации и потери конфиденциальных данных.
3.4. Требования к гибкости [необязательно]
описывает требования к гибкости программного обеспечения, то есть, при изменении требований, способность программного обеспечения адаптироваться к этим изменениям, например:
а. Изменения в методах работы;
б. Изменения в операционной среде;
c. Изменения в интерфейсе с другим ПО;
d. Изменения в точности и сроке действия;
e. Планируйте изменения или улучшения.
Следует отметить , специально предназначенный для обеспечения такой гибкости.
3.5. Другие особые требования [необязательно]
Например, требования к пользовательскому модулю по простоте использования, особые требования к удобству обслуживания, дополняемости, удобочитаемости, надежности, требованиям обработки исключений и конвертируемости операционной среды.
4. Нормативы операционной среды
4.1. Оборудование
Список аппаратных устройств, необходимых для запуска программного обеспечения. Объясните новое оборудование и его специализированные функции, в том числе:
а. Модель процессора и объем памяти;
б. Емкость внешнего хранилища, онлайн или офлайн, носитель и его формат хранения, модель и количество оборудования;
c. Модель и количество устройств ввода и вывода, онлайн или офлайн;
d. Тип и количество оборудования передачи данных;
e. Функциональные клавиши и другое специализированное оборудование
4.2. Вспомогательное программное обеспечение
перечисляет поддерживающее программное обеспечение, включая платформы сетевого и аппаратного оборудования, платформы операционных систем, платформы систем баз данных, а также программы компиляции (или сборки), программное обеспечение для поддержки тестирования и т. д.
4.3. Интерфейс [необязательно]
Объясняет интерфейс, протокол передачи данных и т. д. между программным обеспечением и другим программным обеспечением.
4.4. Элемент управления [необязательно]
Объясните методы и сигналы управления для управления работой программного обеспечения и объясните источник этих сигналов управления.
5. Отслеживание спроса
Основная цель отслеживания требований — гарантировать, что все требования проанализированы, а охват проанализированных требований подтвержденными требованиями описан в таблице соответствия обещанного спроса и анализа спроса (таблица PRS_SRS). Формат таблицы PRS_SRS см. В Спецификации процесса управления требованиями к программному обеспечению (SUPL-MANU-SRS-001).

6. Подпишите одобрение.
Я прочитал приведенную выше спецификацию требований к программному обеспечению, я буду строго соблюдать условия спецификации и обещаю полностью поддерживать реализацию спецификации.
Исполнительный руководитель:
дата
Технический руководитель:
дата
Руководитель проекта:
дата
Представитель пользователя:
дата
Представитель разработчика:
дата
Участники группы:
Дата
Участники группы:
Дата

Шаблон 2 шаблон 2

Напиши вот так, хорошо

Цзянь Шу, по-моему, так выглядит

Возьмите мобильный терминал «Цзяньшу» в этой статье в качестве примера, напишите копию в соответствии с приведенным выше резюме.Простая структура документов PRD, Я надеюсь помочь всем, кто также является пользователем «Цзяньшу», лучше понять. (Новичок в личном кабинете, новый пользователь Jianshu, специализирующийся на документации и анализе).

1. Информация о версии

Принципиальная схема информационной таблицы версии приложения Jianshu

2. Описание документа

2.1 Введение в документ

Этот документ в основном описывает функциональные требования приложения Jianshu APP и его дизайн с целью четкого определения деталей требований и логической последовательности каждого модуля.

2.2 Читатели документов

Этот документ в основном предназначен для следующих читателей: сотрудников отдела НИОКР, тестировщиков, менеджеров по продукции, персонала рыночных операций, управленческого персонала и т. Д. Проекта Jianshu APP.

2.3 Профессиональные условия

Некоторые профессиональные термины могут быть объяснены здесь заранее, чтобы облегчить понимание в дальнейшем (обычно в табличной форме), см. Также Приложение 8.4.

Каталог (опущен)

3. Введение в продукт

3.1 Позиционирование продукта

Цзяньшу стремится обеспечить лучший обмен опытом, создание лучшего программного обеспечения для писателей и создание самого элегантного читательского сообщества для читателей. «Обменивайтесь историями, делитесь идеями» — это слоган Jianshu.

3.2 Характеристики продукта

Простой и элегантный дизайн, хорошая коммуникационная атмосфера, богатая тематика статей, форматированный текст Mardown и другие функции.

3.3 Пользовательский анализ

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

4. Архитектура продукта

4.1 Схема структуры продукта

Эта статья охватывает только основные модули и должна быть расширена до наименьшего видимого пользователю модуля.

Схема структуры продукта приложения Jianshu APP

4.2 Схема информационной структуры

Информационная структура принимает информацию в качестве измерения, такую ​​как информация о пользователе, информация о пользовательской статье, информация о поведении пользователя и т. Д., Которая может быть проанализирована в соответствии со структурой продукта и не будет указана.

4.3 Общая блок-схема

Общий процесс может объяснить базовое поведение пользователя продукта и помочь понять продукт.

Общая блок-схема приложения Jianshu APP

5. Подробное описание функций

5.1 Список функций

Список функций служит обзором описания требований к функциям, которое можно разделить на модули.

Принципиальная схема списка функций приложения Jianshu

5.2 Интерфейс прототипа

Описание требований для каждой функции модуля должно включать подробную прототипную схему интерфейса и блок-схему, которая представляет собой простую схему (сброс пароля).

Схема прототипа сброса пароля приложения Jianshu

5.3 Поток сценариев использования

Блок-схема сброса пароля приложения Jianshu APP

6. Нефункциональные требования

6.1 Требования к характеристикам

1. Интерфейсное отображение содержимого должно обеспечивать беспрепятственное чтение пользователями через WIFI и мобильные сети;

2. Обработка фоновой информации стабильная и быстрая, когда 10 000 пользователей находятся в сети.

6.2 Системные требования

Совместимость с Andriod, версиями системы IOS (включая последнюю версию)

6.3 Эксплуатационные требования

Разработка системы управления пользователями / контентом, разработка системы анализа пользовательских данных и др.

7. Планирование проекта

Некоторые проекты или продукты не включают эту часть, но обычно необходимо объяснить анализ рисков и стратегии преодоления, связанные с продуктом.

8. Приложение

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

Источник: russianblogs.com

Шаблон спецификации

1.1 Назначение 1.2 Соглашения, принятые документах 1.3 Границы проекта 1.4 Ссылки 2. Общее описание 2.1 Общий взгляд на продукт 2.2 Классы и характеристики пользователей 2.3 Операционная среда 2.4 Ограничения дизайна и реализации 2.5 Предположения и зависимости 3. Функции системы 3.x Функция системы X 3.x.1 Описание и приоритеты З.х.2 Функциональные требования

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

4.1 Логическая модель данных 4.2 Словарь данных 4.3 Отчеты 4.4 Получение, целостность, хранение и утилизация данных 5. Требования к внешним интерфейсам 5.1 Интерфейсы пользователя 5.2 Интерфейсы ПО 5.3 Интерфейсы оборудования 5.4 Коммуникационные интерфейсы (интерфейсы передачи информации) 6. Атрибуты качества 6.1 Удобство использования 6.2 Производительность 6.3 Безопасность 6.4 Техника безопасности (охрана труда) 6.х Прочие требования 7. Требования по интернационализации и локализации

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

Пример спецификации

1. Введение

1.1. Назначение

Эта спецификация требований к ПО описывает функциональные и нефункциональные требования к выпуску 1.0 Cafeteria Ordering System (COS). Этот документ предназначен для команды, которая будет реализовывать и проверять корректность работы системы. Кроме специально обозначенных случаев, все указанные здесь требования имеют высокий приоритете и приписаны к выпуску 1.0. 1.2. Соглашения, принятые в документах В этой спецификации нет никаких типографских условных обозначений.

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

Cafeteria Ordering System позволит сотрудникам Process Impact заказывать блюда в кафетерии компании через Интернет для доставки в указанные пункты на территории компании. Детальное описание продукта приведено в документе «Cafeteria Ordering System Vision and Scope Document» [1], где перечислены функции, полная или частичная реализация которых запланирована в этом выпуске.

1.4. Ссылки

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

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

Cafeteria Ordering System – это новая система, которая заменяет текущие ручные процессы заказа и получения обедов в кафетерии Process Impact. Контекстная диаграмма на рис. 1 показывает внешние объекты и системные интерфейсы для версии 1.0. Предполагается выпустить несколько версий системы, чтобы в конечном итоге удалось встроить ее в службу заказов нескольких близлежащих ресторанов, работающую через Интернет, а также службы авторизации кредитных и дебетовых карт. Р ис. 1. Контекстная диаграмма для выпуска 1.0 системы Cafeteria Ordering System

Источник: studfile.net

Как написать ТЗ, часть 1: ГОСТЫ и спецификации требований

Близнецы или тройняшки: ПО, информационная и автоматизированная системы – отличия и разные ГОСТ’ы

• программа (программное изделие). Российский ГОСТ 19781-90 «Обеспечение систем обработки информации программное» описывает это как данные, предназначенные для управления кон­кретными компонентами системы обработки ин­формации в целях реализации определенного ал­горитма.
• автоматизированная система (АС), которая согласно ГОСТ 34.003-90, состоит из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций. АС включает различные виды обеспечения: организационное, методическое, техническое, программное (ПО), информационное, лингвистическое, математическое, правовое, эргономическое.

Таким образом, программа или программное изделие – это часть АС. А термин «информационная система» трактуется согласно следующим определениям:

• совокупность информации, содержащейся в базах данных, информационных технологий и технических средств, которые обеспечивают её обработку [ФЗ РФ от 27.06.2006 г. № 149-ФЗ «Об информации, информационных технологиях и о защите информации», ГОСТ Р 50922-2006];
• автоматизированная система, результатом функционирования которой является представление выходной информации для последующего использования [ГОСТ РВ 51987].

Поэтому информационная система (ИС), которая помимо программного обеспечения, также включает техническую часть, например, носимые устройства так называемого интернета вещей (IoT) – «умные часы», компоненты комплекса «умный дом» и пр. – является АС. В России ТЗ на создание АС регламентирует ГОСТ 34.602-89, впервые введенный в 1990 году и переизданный в 2009 г.

С 1 января 2022 года ГОСТ 34.602-89 признан недействующим и заменен на ГОСТ 34.602-2020, что мы рассматриваем в новой статье.

А порядок построения и оформления ТЗ на разработку программы или программного изделия, которые не включает технического и других видов обеспечения, описывает ГОСТ 19.201-78, введенный в 1980 году и переизданный в 2010.

Рассмотрим, чем отличаются эти стандарты. ГОСТ 34.602-89 выделяет следующие разделы в ТЗ на создание АС:

По ГОСТ 19.201-78 в ТЗ на разработку программы должны быть следующие разделы:

1. Введение
2. Основания для разработки
3. Назначение разработки
4. Требования к программе или программному изделию
5. Требования к программной документации
6. Технико-экономические показатели (можно взять из ТЭО)
7. Стадии и этапы разработки
8. Порядок контроля и приемки
9. Приложения

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

Однако, сегодня большинство разработчиков и аналитиков считают эти отечественные ГОСТ’ы морально устаревшими и все чаще вместо них для оформления требований к ИС используют шаблоны зарубежных стандартов: ISO IEEE 29148-2011 и IEEE 830-1998, которые регламентируют составление спецификаций требований к ПО. Преимущества этих шаблонов над российскими регламентами и практику их совместного использования рассмотрим далее.

Разработка ТЗ на информационную систему по ГОСТ и SRS

Код курса

TTIS

Ближайшая дата курса

24 июля, 2023

Длительность обучения

12 ак.часов

Стоимость обучения

20 000 руб.

Стандарты ISO IEEE 29148-2011 и IEEE 830-1998: в чем разница и как их использовать для разработки ТЗ

SRS по IEEE 830-1998

IEEE 830-1998 – это рекомендуемая методика составления спецификаций требований к ПО (Software Requirements Specification). Она описывает критерии проверки качественно составленной SRS, ее части и шаблоны. Основными рекомендуемыми разделами SRS по IEEE 830-1998 являются следующие:

1. Введение
2. Назначение
3. Область действия
4. Определения, акронимы и сокращения
5. Ссылки
6. Краткий обзор
7. Общее описание
8. Взаимодействие продукта с другими продуктами и компонентами
9. Функции продукта (краткое описание)
10. Характеристики пользователя
11. Ограничения
12. Допущения и зависимости
13. Детальные требования
14. Требования к внешним интерфейсам
15. Интерфейсы пользователя
16. Интерфейсы аппаратного обеспечения
17. Интерфейсы программного обеспечения
18. Интерфейсы взаимодействия
19. Функциональные требования
20. Требования к производительности
21. Проектные ограничения (и ссылки на стандарты)
22. Нефункциональные требования (надежность, доступность, безопасность и пр.)
23. Другие требования
24. Приложения
25. Алфавитный указатель

ТЗ по ГОСТ vs SRS по ISO IEEE 29148-2011

IEEE 830-1998 носит рекомендательный характер – не случайно в оригинале он называется Recommended Practice for Software Requirements Specifications и сегодня не так часто используется на практике, как международный стандарт по инженерии требований ISO IEEE 29148-2011, который обеспечивает единую трактовку процессов и продуктов для всей системы и ПО. По сути, этот стандарт заменяет IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998 и объединяет российские ГОСТ’ы 34.602-89 и ГОСТ 19.201-78. Он содержит два шаблона спецификации требований:

• System requirements specification (SyRS)– технические требования к системе и удобству взаимодействия человека с ней;
• Software requirements specification (SRS)– спецификация требований к ПО, включая программное изделие, программу или набору программ (продукт), которые выполняют определенные функции в конкретном окружении.

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

1. Введение
2. Цели
3. Соглашения о терминах
4. Предполагаемая аудитория и последовательность восприятия
5. Масштаб проекта
6. Ссылки на источники
7. Общее описание
8. Видение продукта
9. Функциональность продукта
10. Классы и характеристики пользователей
11. Среда функционирования продукта (операционная среда)
12. Рамки, ограничения, правила и стандарты
13. Документация для пользователей
14. Допущения и зависимости
15. Функциональность системы
16. Функциональный блок X (таких блоков может быть несколько)
17. Описание и приоритет
18. Причинно-следственные связи, алгоритмы (движение процессов, workflows)
19. Функциональные требования
20. Требования к внешним интерфейсам
21. Интерфейсы пользователя (UX)
22. Программные интерфейсы
23. Интерфейсы оборудования
24. Интерфейсы связи и коммуникации
25. Нефункциональные требования
26. Требования к производительности
27. Требования к сохранности (данных)
28. Требования к качеству программного обеспечения
29. Требования к безопасности системы
30. Требования на интеллектуальную собственность
31. Прочее
32. Приложение А: Глоссарий
33. Приложение Б: Модели процессов и предметной области и другие диаграммы
34. Приложение В: Список ключевых задач

Можно сказать, что все эти разделы дополняют и уточняют пункты, предусмотренные отечественными ГОСТ’ами. С практической точки зрения структура SRS по ISO IEEE 29148-2011 дает следующие преимущества по сравнению с ГОСТ 34.602-89 и ГОСТ 19.201-78:

• глубокий уровень детализации, в частности, подробное описание различных категорий пользователей, интерфейсов, разделение допущений и ограничений;
• разделение требований на функциональные и нефункциональные;
• рекомендации представлять функциональные требования в форме сценариев (вариантов) использования, т.н. use case, которые мы разбирали здесь;
• структурированный и детальный набор разных требований легко разделяется по итерациям гибкой разработки (Agile) через определение их приоритета и очередности реализации по релизам;
• тесная связь с бизнесом благодаря детальному описанию контекста, правил, процессов, организационной среды и других аспектов, описываемых в спецификации требований стейкхолдеров (StRS, Stakeholder requirements specification) в разделах «Видение» и «Общее описание»;
• наглядность трассировки требований разных уровней друг к другу, а также к бизнес-правилам и регламентирующим документам.

Недостатком SRS по ISO IEEE 29148-2011 можно назвать большой объем этого документа, что отражается в длительности и трудоемкости его разработки. Впрочем, несмотря на это и вышеотмеченные достоинства, хочется подчеркнуть, по сути SRS по ISO IEEE 29148-2011 не лучше и не хуже отечественных ГОСТ’ов. В любом случае, не зависимо от выбранного шаблона ТЗ на создание ИС, АС или ПО, этот документ должен отражать функциональные и нефункциональные требования к объекту разработки так, чтобы их можно было реализовать и проверить, что решение соответствует целям бизнеса и приносит стейкхолдерам пользу. Про ограничения, допущения и зависимости читайте здесь. В следующей статье мы продолжим разговор про разработку ТЗ, а пока предлагаем вам пройти открытый интерактивный тест на проверку знаний о стандартах и требованиях из этого материала.

Источник: babok-school.ru