- PVSM.RU - https://www.pvsm.ru -
Недавно ко мне обратились, чтобы я посоветовал стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс [1], найду подходящую статейку и отправлю её. Но не тут-то было! Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел. Придется сделать такую статейку самому…
И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):
• ГОСТ 34
• ГОСТ 19
• IEEE STD 830-1998
• ISO/IEC/ IEEE 29148-2011
• RUP
• SWEBOK, BABOK и пр.
ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы [2] регламентирует структуру ТЗ на создание именно СИСТЕМЫ, в которую входят ПО, аппаратное обеспечение, люди, которые работают с ПО, и автоматизируемые процессы.
Согласно ГОСТ 34 техническое задание должно включать следующие разделы:
1. Общие сведения
2. Назначение и цели создания (развития) системы
3. Характеристика объектов автоматизации
4. Требования к системе
5. Состав и содержание работ по созданию системы
6. Порядок контроля и приемки системы
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
8. Требования к документированию
9. Источники разработки
При разработке ТЗ для государственных проектов Заказчики, как правило, требуют соблюдение именно этого стандарта.
“ГОСТ 19.ххх Единая система программной документации (ЕСПД)” — это комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ (или ПО) и программной документации. Т.е. этот стандарт относится к разработке именно ПО.
Согласно ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению [3] техническое задание должно включать следующие разделы:
1. Введение;
2. Основания для разработки;
3. Назначение разработки;
4. Требования к программе или программному изделию;
5. Требования к программной документации;
6. Технико-экономические показатели;
7. Стадии и этапы разработки;
8. Порядок контроля и приемки;
9. Приложения.
Естественно ГОСТ 34 (и 19) уже устарели, и я не люблю их использовать, но при правильном интерпретации стандартов, можно получить хорошее ТЗ, см. Заключение.
Достаточно хорошее определение стандарта 830-1998 — IEEE Recommended Practice for Software Requirements Specifications [4] дано в самом его описании:
Описывается содержание и качественные характеристики правильно составленной спецификации требований к программному обеспечению (SRS) и приводится несколько шаблонов SRS. Данная рекомендуемая методика имеет своей целью установление требований к разрабатываемому программному обеспечению, но также может применяться, чтобы помочь в выборе собственных и коммерческих программных изделий.
Согласно стандарту техническое задание должно включать следующие разделы:
1. Введение
2. Общее описание
3. Детальные требования (могут быть организованы по разному, н-р, так)
4. Приложения
5. Алфавитный указатель
На самом деле новичку достаточно трудно понять, что должно содержаться в данных разделах по вышеприведенной структуре (как и в случае с ГОСТом), поэтому нужно читать сам стандарт, который легко найти в Интернете [5]. Как и примеры [6], правда, на англ. языке.
Мне же больше нравится адаптированный шаблон Карла Вигерса [7], который я использую при разработки ТЗ для коммерческих компаний. И вообще дедушка Вигерс предоставляет множество полезных рекомендаций по работе с требованиями [8] (куда идут деньги при покупке этих рекомендаций, читайте в начале красным). Ну а его книжку [9] вы уже несколько раз, надеюсь, перечитали.
Стандарт IEEE 29148-2011 [10] обеспечивает единую трактовку процессов и продуктов, используемых при разработке требований на протяжении всего жизненного цикла систем и программного обеспечения. Он приходит на смену стандартов IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998.
Данный стандарт содержит два шаблона спецификации требований:
• System requirements specification (SyRS)
• Software requirements specification (SRS)
System Requirements Specification (SyRS) определяет технические требования для выбранной системы и удобства взаимодействия предполагаемой системы и человека. Она определяет высокоуровневые требования к системе с точки зрения предметной области, а также информацию об общей цели системы, ее целевой среде и ограничениях, допущениях и нефункциональных требованиях. Она может включать в себя концептуальные модели, спроектированные для иллюстрации содержания системы, сценариев использования, основных сущностей предметной области, данных, информаций и рабочих процессов. Из определения следует, что это аналог ТЗ, описанного в ГОСТ 34.
SyRS может содержать следующие разделы:
1. Введение
2. Ссылки
3. Системные требования
4. Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3)
5. Приложения
SRS это спецификация требований для определенного программного изделия, программы или набора программ (продукт), которые выполняют определенные функции в конкретном окружении. Из определения следует, что это аналог ТЗ, описанного в ГОСТ 19, а по структуре очень напоминает SRS из стандарта IEEE 830.
SRS может содержать следующие разделы:
1. Введение
2. Ссылки
3. Детальные требования
4. Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3)
5. Приложения
Данный стандарт достаточно сложно найти в открытом виде в Интернете, но постараться можно, и опять же только на англ.
Структура SRS в RUP(Rational Unified Process) [11] представляет собой документ, в котором необходимо описать артефакты, полученные в процессе специфицирования требований.
Шаблон SRS в RUP [12] адаптирован из стандарта IEEE STD 830 и содержит два варианта:
• Традиционный шаблон SRS со структурированными функциональными требованиями по функциям Системы, максимально похож на 830 стандарт.
• Упрощенный шаблон SRS со структурированными функциональными требованиями в виде вариантов использования (use cases):
1. Введение.
2. Обзор системы
3. Детальные требований
4. Вспомогательная информация.
Естественно, что в Интернете можно найти шаблон и примеры SRS от RUP [13].
SWEBOK [14], BABOK [15], а также множество других методологий разработки ПО и сводов знаний при упоминании SRS ссылаются на вышеупомянутые зарубежные стандарты.
Также стоит сказать, что для описания требований к АС и ПО используются и другие виды документов, кот каждый называет по разному: FRD (Functional Requirements Document), RD (Requirements Document), ПЗ (Постановка задачи или Пояснительная записка) и пр. Но это все производные документы от вышеупомянутых стандартов, не имеющих отраслевой стандартизации, хотя, в некоторых случаях, уже и с устоявшейся терминологией.
Я скажу одной фразой из Манифеста Agile [16]: “Working software over comprehensive documentation”. Поэтому в Agile документации отводится совсем мало места.
Мое же убеждение, что разработать АС без ТЗ можно (используя техники/рекомендации Agile), но вот в дальнейшем сопровождать — невозможно. Поэтому сразу задумайтесь, как вы будете писать ТЗ и другую документацию, при разработке ПО по Agile.
Как говорится, каждому проекту свое техническое задание. При правильном использовании любого из вышеперечисленных стандартов можно брать эти шаблоны для написания ТЗ, естественно адаптируя их под себя.
Но главное, чтобы ТЗ не превращалось в ХЗ, а, именно, содержание (наполнение) в ТЗ — самое главное! Но это уже совсем другая история… Если есть интерес, то можно пройти он-лайн курс Разработка и управление требованиями к ПО [17].
Ну а кто дочитал до конца — тому бонус: пример ТЗ, который я писал много лет назад [18] (сейчас уже просто аналитиком давно не работаю, да и другие более удачные примеры запрещает открывать на всеобщее обозрение NDA).
Также рекомендую ознакомиться со следующими материалами:
• Презентацией Юрия Булуя Классификация требований к программному обеспечению и ее представление в стандартах и методологиях [19].
• Анализ требований к автоматизированным информационным системам. Лекция 11: Документирование требований [20].
• Правила составления Software requirements specification [21] (читать вместе с комментариями)
• Примеры ТЗ и другой документации по разработке АС [22] для МЭР
• Шаблоны документов для бизнес-аналитиков из группы ВК «Business Analysis Magazine» [23]
Автор: bas
Источник [24]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/analiz-i-proektirovanie-sistem/255439
Ссылки в тексте:
[1] Яндекс: https://yandex.ru/search/?lr=213&msid=1488318331.00207.22871.2603&text=%D1%88%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD%D1%8B%20%D1%82%D0%B5%D1%85%D0%BD%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D1%85%20%D0%B7%D0%B0%D0%B4%D0%B0%D0%BD%D0%B8%D0%B9
[2] ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы: http://www.rugost.com/index.php?option=com_content&view=article&id=96:gost-34602-89&catid=22&Itemid=53
[3] ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению: http://www.rugost.com/index.php?option=com_content&view=article&id=46:19001-77&catid=19&Itemid=50
[4] 830-1998 — IEEE Recommended Practice for Software Requirements Specifications: https://ru.wikipedia.org/wiki/%D0%A1%D0%BF%D0%B5%D1%86%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F_%D1%82%D1%80%D0%B5%D0%B1%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B9_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%B3%D0%BE_%D0%BE%D0%B1%D0%B5%D1%81%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%B8%D1%8F#.D0.A0.D0.B5.D0.BA.D0.BE.D0.BC.D0.B5.D0.BD.D0.B4.D1.83.D0.B5.D0.BC.D0.B0.D1.8F_.D1.81.D1.82.D0.B0.D0.BD.D0.B4.D0.B0.D1.80.D1.82.D0.BE.D0.BC_IEEE_830.5B1.5D_.D1.81.D1.82.D1.80.D1.83.D0.BA.D1.82.D1.83.D1.80.D0.B0_SRS
[5] легко найти в Интернете: https://www.google.ru/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=830-1998+-+IEEE+Recommended+Practice+for+Software+Requirements+Specifications+pdf&*
[6] Как и примеры: https://www.google.ru/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#newwindow=1&q=srs+example&*
[7] адаптированный шаблон Карла Вигерса: http://www.processimpact.com/process_assets/srs_preview.pdf
[8] множество полезных рекомендаций по работе с требованиями: http://www.processimpact.com/goodies.shtml
[9] его книжку: http://www.processimpact.com/pubs.shtml#SR3E
[10] Стандарт IEEE 29148-2011: https://www.iso.org/standard/45171.html
[11] RUP(Rational Unified Process): https://ru.wikipedia.org/wiki/Rational_Unified_Process
[12] Шаблон SRS в RUP: http://dit.isuct.ru/Publish_RUP/index.htm#core.base_rup/workproducts/rup_software_requirements_specification_934E66F.html
[13] Интернете можно найти шаблон и примеры SRS от RUP: https://www.google.ru/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=rup+srs+template&*
[14] SWEBOK: https://www.computer.org/web/swebok
[15] BABOK: http://iiba.ru/babok/chapters-of-babok-version-3/
[16] Манифеста Agile: http://agilemanifesto.org/
[17] Разработка и управление требованиями к ПО: https://www.webursitet.ru/product/kratkiy-kurs-sistemnogo-analiza.html
[18] пример ТЗ, который я писал много лет назад: https://drive.google.com/file/d/0B5xz4Vc-CUY1NjVoT0pFcnlEQU0/view?usp=sharing
[19] Классификация требований к программному обеспечению и ее представление в стандартах и методологиях: http://2006.secr.ru/upload/files/63.pdf
[20] Лекция 11: Документирование требований: http://www.intuit.ru/studies/courses/2188/174/lecture/4732
[21] Правила составления Software requirements specification: https://habrahabr.ru/post/52681/
[22] Примеры ТЗ и другой документации по разработке АС: http://aisup.economy.gov.ru/pubportal/
[23] группы ВК «Business Analysis Magazine»: https://vk.com/topic-51760813_32631714
[24] Источник: https://habrahabr.ru/post/328822/
Нажмите здесь для печати.