Стандарти и шаблони за TOR за разработка на софтуер

Наскоро се обърнах към мен, за да посъветвам стандарти за написване на техническо задание (TOR) за разработване на автоматизирани системи (AS) и софтуер (SW). Затова мисля, че сега ще отида в Yandex, ще намеря подходяща статия и ще я изпратя. Но го нямаше! Не намерих нито една статия, изброяваща стандартите за TK, включително шаблони и примери за готови документи. Ще трябва да напиша собствена статия...

И така, основните стандарти, методологии и кодове на знания, където се споменава TK или SRS (спецификация на софтуерните (или системните) изисквания):

• GOST 34 • GOST 19 • IEEE STD 830-1998 • ISO/IEC/IEEE 29148-2011 • RUP • SWEBOK, BABOK и др.

ГОСТ 34.602-89 Техническо задание за създаване на автоматизирана система регламентира структурата на ТЗ за създаване на СИСТЕМА, която включва софтуер, хардуер, хора, които работят със софтуера, и автоматизирани процеси.

Съгласно GOST 34 техническото задание трябва да включва следните раздели:

При разработването на технически спецификации за държавни проекти, Клиентите, като правило, изискват съответствие с този конкретен стандарт.

„GOST 19.xxx Единна система за програмна документация (ESPD)“ е набор от държавни стандарти, които установяват взаимосвързани правила за разработване, проектиране и разпространение на програми (или софтуер) и програмна документация. Тези. Този стандарт се прилага специално за разработката на софтуер. Съгласно GOST 19.201-78 Техническо задание, изискванията за съдържанието и дизайна на заданието трябва да включват следните раздели:

1. Въведение; 2. Основания за развитие; 3. Цел на разработката; 4. Изисквания към програмата или софтуерния продукт; 5. Изисквания към софтуерната документация; 6. Технико-икономически показатели; 7. Етапи и етапиразработки; 8. Ред за контрол и приемане; 9. Приложения.

Естествено, GOST 34 (и 19) вече са остарели и не обичам да ги използвам, но с правилното тълкуване на стандартите можете да получите добър TK, вижте Заключение.

IEEE STD 830-1998

Съгласно стандарта техническото задание трябва да включва следните раздели:

1. Въведение

  • 1. Назначаване
  • 2. Обхват
  • 3. Дефиниции, акроними и съкращения
  • 4. Връзки
  • 5. Преглед
2. Общо описание
  • 1. Взаимодействие на продукта (с други продукти и компоненти)
  • 2. Характеристики на продукта (кратко описание)
  • 3. Потребителски характеристики
  • 4. Ограничения
  • 5. Предположения и зависимости
3. Подробни изисквания (могат да бъдат организирани по различни начини, напр. така)
  • 1. Изисквания за външни интерфейси
  • 1. Потребителски интерфейси
  • 2. Хардуерни интерфейси
  • 3. Софтуерни интерфейси
  • 4. Интерфейси за взаимодействие
  • 2. Функционални изисквания
  • 3. Изисквания за изпълнение
  • 4. Ограничения на дизайна (и препратки към стандарти)
  • 5. Нефункционални изисквания (надеждност, достъпност, сигурност и др.)
  • 6. Други изисквания
    • 4. Приложения 5. Азбучен указател

    ISO/IEC/IEEE 29148-2011

    Стандартът IEEE 29148-2011 осигурява общо разбиране на процесите и продуктите, използвани при разработването на изисквания през целия жизнен цикъл на системите и софтуера. Заменя стандартите IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998.

    Този стандарт съдържа два шаблона за спецификация на изискванията:

    • Спецификация на системните изисквания (SyRS) • Софтуерспецификация на изискванията (SRS)

    Спецификацията на системните изисквания (SyRS) определя техническите изисквания за избраната система и лекотата на взаимодействие между предвидената система и лицето. Той определя изискванията на високо ниво за системата от гледна точка на домейна, както и информация за цялостната цел на системата, нейната целева среда и ограничения, допускания и нефункционални изисквания. Може да включва концептуални модели, предназначени да илюстрират системно съдържание, случаи на употреба, основни обекти на домейн, данни, информация и работни потоци. От определението следва, че това е аналог на TK, описан в GOST 34.

    SyRS може да съдържа следните раздели:

    • 1. Предназначение на системата
    • 2. Съдържание на системата (граници на системата)
    • 3. Преглед на системата
    • 1. Системно съдържание
    • 2. Системни функции
    • 3. Характеристики на потребителите
  • 4. Термини и определения
    • 2. Връзки

    3. Системни изисквания

    • 1. Функционални изисквания
    • 2. Изисквания за използваемост
    • 3. Изисквания за изпълнение
    • 4. Интерфейс (взаимодействие) на системата
    • 5. Работа на системата
    • 6. Състояния на системата
    • 7. Физически характеристики
    • 8. Условия на околната среда
    • 9. Изисквания за сигурност
    • 10. Управление на информацията
    • 11. Политики и правила
    • 12. Изисквания за поддръжка на системата през целия й жизнен цикъл
    • 13. Изисквания за опаковане, обработка, доставка и транспорт
    4. Тестване и валидиране (списък на необходимите тестове за приемане, които отразяват раздел 3)

    • 1. Предположения и зависимости
    • 2. Съкращения и съкращения
    SRS еспецификация на изискванията за определен софтуерен продукт, програма или набор от програми (продукт), които изпълняват определени функции в определена среда. От определението следва, че това е аналог на TK, описан в GOST 19, и по структура е много подобен на SRS от стандарта IEEE 830.

    СРС може да съдържа следните раздели:

    • 1. Назначаване
    • 2. Съдържание (граници)
    • 3. Преглед на продукта
    • 1. Взаимодействие на продукта (с други продукти и компоненти)
    • 2. Характеристики на продукта (кратко описание)
    • 3. Характеристики на потребителите
    • 4. Ограничения
  • 4. Термини и определения
    • 2. Връзки

    3. Подробни изисквания

    • 1. Изисквания за външни интерфейси
    • 2. Характеристики на продукта
    • 3. Изисквания за използваемост
    • 4. Изисквания за изпълнение
    • 5. Изисквания към логическата структура на базата данни
    • 6. Ограничения на дизайна
    • 7. Свойства на софтуерната система
    • 8. Допълнителни изисквания
    4. Тестване и валидиране (списък на необходимите тестове за приемане, които отразяват раздел 3)

    • 1. Предположения и зависимости
    • 2. Съкращения и съкращения
    Този стандарт е доста труден за намиране в обикновен текст в Интернет, но можете да опитате и отново само на английски.

    Структурата на SRS в RUP (Rational Unified Process) е документ, в който е необходимо да се опишат артефактите, получени по време на процеса на спецификация на изискванията.

    SRS шаблонът в RUP е адаптиран от стандарта IEEE STD 830 и съдържа два варианта:

    • Традиционният SRS шаблон със структурирани функционални изисквания за системни функции, максимално близки до стандарта 830. • Опростен SRS шаблон със структуриранфункционални изисквания под формата на случаи на употреба:

    • 1. Преглед на случаите на употреба.
    • 2. Предположения и зависимости.
    3. Подробни изисквания

    • 1. Описание на случаите на използване.
    • 2. Допълнителни изисквания.
    • 3. Други функционални изисквания.
    • 4. Нефункционални изисквания.
    4. Помощна информация.

    SWEBOK, BABOK и др.

    SWEBOK, BABOK, както и много други методологии и сборове от знания за разработка на софтуер, когато споменават SRS, се позовават на гореспоменатите чуждестранни стандарти.

    Също така си струва да се спомене, че за описание на изискванията за AS и софтуер се използват други типове документи, които всеки нарича по различен начин: FRD (Документ с функционални изисквания), RD (Документ с изисквания), PZ (Изложение на проблема или Обяснителна бележка) и т.н. Но това са всички производни документи от гореспоменатите стандарти, които нямат индустриална стандартизация, въпреки че в някои случаи вече са с установена терминология.

    Но какво да кажем за Agile?

    Ще кажа с една фраза от Agile Manifesto: „Работещ софтуер над изчерпателна документация“. Следователно в Agile документацията се отделя много малко място.

    Заключение

    Както се казва, всеки проект има свое задание. С правилното използване на някой от горните стандарти можете да вземете тези шаблони за писане на технически спецификации, като естествено ги адаптирате за себе си.

    Е, за тези, които го прочетат до края, има бонус: пример за TK, който написах преди много години (сега просто не съм работил като анализатор от дълго време, а други по-успешни примери са забранени за обществено отваряне от NDA).

    Също така препоръчвам да прочетете следните материали:

    Hardcore conf в C++. Каним само професионалисти.