Правила составления Software requirements specification

    Все мы прекрасно знаем о том, как разрабатывается ПО. Подумали 10 минут и сразу пошли кодить. Цикл создания программного обеспечения состоит из многих ключевых моментов. Это такие моменты как планирование, создания архитектуры, создание SRS, создание дизайна и тд и тп.



    Что такое SRS ?


    SRS — Software Requirement Specification — специальная документация для ПО которая содержит в себе информацию о том, как должна себя вести система, какие функции должна выполнять, какую нагрузку должна выдерживать и тд.

    Зачем оно надо ?


    Все предельно просто. Вы используете ТЗ (велосипед), я использую SRS (машину). Надеюсь аналогия получилась ясная? :)

    Структура SRS


    Ниже приведена структура на англ языке в raw виде. Чуть ниже в статье мы рассмотрим каждый пункт более подробно

    • Introduction
      • Purpose
      • Document conventions
      • Intended Audience and Reading Suggestions
      • Project scope
      • References
    • Overall Description
      • Product perspective
      • Product features
      • User classes and characteristics
      • Operating environment
      • Design and implementation constraints
      • User documentation
      • Assumptions and dependencies
    • System features
      • System feature X (таких блоков может быть несколько)
        • Description and priority
        • Stimulus/Response sequences
        • Functional requirements
    • External interface requirements
      • User interfaces
      • Software interfaces
      • Hardware interfaces
      • Communication interfaces
    • Non functional requirements
      • Performance requirements
      • Safety requirements
      • Software quality attributes
      • Security requirements
    • Other requirements
    • Appendix A: Glossary
    • Appendix B: Analysis Models
    • Appendix C: Issues list


    И так со структурой разобрались, теперь перейдем к разделам и тому, что в них надо писать.

    Базовые требования ко всем разделам SRS


    • Кратко, четко. Описывает все предельно кратко и четко. Насколько это возможно.
    • Без двусмысленных описаний. Человек читающий SRS должен понимать именно то, что написано, а не что-то другое. Закон Мерфи: Если Вас могут понять неправильно, Вас поймут неправильно. Избегайте этого
    • Простота и «читабельность». Не используйте каких либо слишком заумных оборотов. Красота в простоте :)
    • DFD-диаграммы. Спецификация не может быть полной если мы не знаем что на входе в описываемый софт, а что на выходе. Все должно быть четко нарисовано.
    • Степень детализации. Это эвристический параметр. Его можно определить так: если я могу свободно изложить информацию о функционале и написанное не вызывает у меня смущения, если требования однозначны и не подлежат никакому двоякому пониманию, если требования в достаточной для меня мере описывают поведение функционала, то проработку SRS можно считать завершенной


    Пояснение каждого пункта структуры SRS



    Introduction \ Purpose
    В данной секции описываем приложение или продукт, функционал которого будет описываться в SRS.

    Introduction \ Document conventions
    Здесь мы описываем все непонятные технические слова или термины которые встречаются в SRS. Заметьте, что описание непонятного слова не может содержать другое непонятное слово. Старайтесь расписать как можно подробнее термин который Вы используете простым и понятным всем языком. Не экономьте на этой секции потому, что чем больше вы распишете непонятных вещей, тем проще будет потом проектировать.

    Introduction \ References
    В данной секции мы пишем ссылки на литературу в которой можно найти основания использованных технологий и фактов. Допустим можно вставлять RFC если вы пишете приложение работающее с TCP/IP, вставлять ссылки на документы на которые вы ссылаетесь и тд. Ссылки и их описание должны быть максимально полными, чтобы в случае чего (линк умер просто) можно было нагуглить этот материал.

    Overall Description \ Product features
    В данном разделе мы описываем части функционала на высоком уровне. Более детально каждая часть функционала будет описана в своем разделе ниже. Тут желательно разместить DFD-диаграмму которая покажет общее взаимодействие системы.

    Overall Description \ Operating environment
    Как понятно из названия раздела тут мы описываем окружение в котором будет работать продукт. ОС, версии компиляторов, базы данных, сервера, софт, железо и другие вещи которые необходимы для работы вашего продукта.

    Overall Description \ Design and implementation constraints
    Данный раздел гнусный :). Он ограничивает полет мысли разработчика налагая стандарты разработки. Такими ограничениями могут быть, например, такие вещи:
    • Язык программирования, база данных
    • Стандарты кодирования
    • Стандарты обмена данными
    • Ограничения накладываемые Operational Enviroment, допустим совместимость только с ФФ
    • Ограничения которые могут быть наложены бизнес-логикой проекта


    Overall Description \ User documentation
    Описываем какая документация нужна для пользователей данного продукта. Возможно это книга по HTML если это HTML редактор.

    System features \ System feature X
    Называем фичу проекту и даем ей уникальный идентификатор. Например, server.html.editor. Уникальный идентификатор дается для того, чтобы потом где то в тикетах ваших не писать — «а вот та хреновина, которая позволяет редактировать хтмл»

    System features \ System feature X \ Description and priority
    Описываем детально фичу продукта. Для чего она? Что должна делать? Какой у нее приоритет выполнения?.. Из этого раздела читающему срс человеку должно сразу стать понятно зачем этот функционал присутствует в системе.

    System features \ System feature X \ Stimulus/Response sequences
    Триггер запуска фичи. Когда она запускается и как себя ведет при запуске? Например, HTML редактор показывается при нажатии пользователя на ссылку меню Открыть HTML редактор

    System features \ System feature X \ Functional requirements
    Подробное и детальное описание фичи. Описываем все: как работает, как реагирует на ошибки, что должно проверять, как отображать данные, как и куда что сохраняет и тд

    External interface requirements
    Описание того как система будет взаимодействовать с внешним миров. Если будет конечно. Какие API, как получить те или иные данные и тп. Подразделы служат для детализации требований. Какие софт интерфейсы, «железячные» интерфейсы, комуникационные интерфейсы и прочее.

    Non functional requirements
    Не функциональные требования. Есть требования которые невозможно описать как какую то фичу, например, требования к безопасности.

    Non functional requirements \ Performance requirements
    Требования к производительности. Это не фича, однако налагает определенные ограничения. Допустим база данных проекта должна выдерживать 1000 запросов в секунду и тп. Эти требования приводят к колоссальной работе по оптимизации проекта.

    Non functional requirements \ Software quality attributes
    Тут мы описываем требования к качеству кода. Какие тесты использовать? Какие метрики использовать для определения качества кода? Сколько кода должно быть покрыто тестами?

    Non functional requirements \ Security requirements
    Требования по безопасности. Если это HTML редактор, через которые можно изменять что-то на сайте, то это может быть нечто вроде: через HTML редактор не должно быть возможности поставить shell на сервер и тп

    Appendix A: Glossary
    Приложение. Иногда в SRS пытаются вставлять описание протоколов и тд и тп. Этого делать не нужно. Однако иногда нужно таки прояснить какую то концепцию. Для этого существует этот раздел. Вставляем ссылочки на такие пояснения. Такой себе словарик.

    Appendix B: Analysis Models
    Раздел определяет какие диаграммы нужно использовать при написании SRS. Например, DFD, какие то общие диаграммы взаимодействия и работы

    Appendix C: Issues list
    Данный раздел используется для очень формальных SRS. Описывает пункты TBD(To Be Done) — что в будущем надо еще сделать, но тут не описано.

    Заключение


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

    P.S. прошу сильно не винить — первая статья более или менее среднего масштаба на хабре. Исправления в синтаксисе приветствуются (стараюсь писать грамотно, однако 7-ми классное образование по русскому языку накладывает свой отпечаток.)
    Поделиться публикацией
    Комментарии 30
      +1
      Хорошая статья. Думаю только ссылку на IEEE нужно привести.
      +4
      Спасибо, мне было бы интересно посмотреть на примеры готовых SRS (FDS), шаблоны оформления, а также ту спецификацию, которую можно считать идеальной. Причем будь-то CMS, Ecommerce или Social Network, в этих проектах, я уверен, есть свои шаблоны и идеалы ;-) Если автор найдет такое и добавит в статью, будет просто замечательно
        0
        Поддерживаю, статья сыровата без примера. Можно даже шуточного, но излагающего основную суть каждого раздела.
          0
          пример планирую сделать, на это сейчас немножко нет времени
        0
        Всё понятно, однако не хватает примера.
          +1
          >> Вы используете ТЗ (велосипед), я использую SRS (машину)

          Вот здесь не понял :) На работе пользуемся SRS («specs», «спеки» на жаргоне), но ваша аналогия «велосипед» — «автомобиль» как-то неочевидна :/ Слово «велосипед» заставляет думать о ТЗ как о чем-то ненужном, лишнем, бесполезной трате ресурсов на поиск уже известного решения. Давайте назовем его «самокат»

          Статья полезная, спасибо.
            0
            а пример? ;-)
              +1
              надо написать не один srs чтобы рассказывать остальным что это такое. беглое чтение дефолтных описаний из шаблона не поможет. судя по описанию functional/nonfunctional reqs автор так и сделал.
                0
                Поддерживаю. В реальности получается так, что какие-то разделы можно опустить, каким-то, напротив, уделить больше внимания, какие-то просто не стоят того, чтобы быть в SRS, так как у компании в проектном документообороте уже есть аналоги и внесение тех или иных пунктов будет дублированием, стоящим компании (а в итоге — заказчикам) дополнительных денег.

                Однако, с другой стороны, шаблон — он и есть шаблон.
              • НЛО прилетело и опубликовало эту надпись здесь
                  0
                  Полезный материал. А если перевести названия разделов для русских заказчиков прокатит? Или в России свои автомобили?
                    +6
                    Если что, то вот русский перевод самих пунктов:

                    Введение
                    • — Цели
                    • — Соглашения о терминах
                    • — Предполагаемая аудитория и «Reading Suggestions» (не знаю как перевести)
                    • — Масштаб проекта
                    • — Ссылки на источники


                    Общее описание
                    • — Видение продукта
                    • — Функциональность продукта
                    • — Классы и характеристики пользователей
                    • — Среда функционирования продукта (операционная среда)
                    • — Рамки, ограничения, правила и стандарты
                    • — Документация для пользователей
                    • — Допущения и зависимости


                    Функциональность системы
                    Функциональный блок X (таких блоков может быть несколько)
                    • — Описание и приоритет
                    • — Причинно-следственные связи, алгоритмы (движение процессов, workflows)
                    • — Функциональные требования


                    Требования к внешним интерфейсам
                    • — Интерфейсы пользователя (UX)
                    • — Программные интерфейсы
                    • — Интерфейсы оборудования
                    • — Интерфейсы связи и коммуникации


                    Нефункциональные требования
                    • — Требования к производительности
                    • — Требования к сохранности (данных)
                    • — Критерии качества программного обеспечения
                    • — Требования к безопасности системы


                    Прочие требования
                    Приложение А: Глоссарий
                    Приложение Б: Модели процессов и предметной области и другие диаграммы
                    Приложение В: Список ключевых задач
                      +1
                      «Reading Suggestions» — тут либо порядок прочтения, либо «рекомендуемая литература». Наверное так.
                        0
                        «Reading Suggestions» — использующиеся соглашения?
                        0
                        А смысл? В России используется своя система гостов, на программное обеспечение и автоматизированные системы, в частности, ГОСТ 19 и 34. Они не такие плохие, как принято считать. А если вы планируете участвовать в серьезных тендерах на автоматизацию задач для государства и бизнеса (того, что покрупнее), SRS там в комиссии никто не примет. Это я так, к слову — приходилось иметь дело с написанием ТЗ по массе спецификаций, включая и SRS и наши ГОСТы…
                          0
                          «Закон Мерфи: Если Вас могут понять неправильно, Вас поймут неправильно.»

                          Практика показывает, что зачастую творение одного лица очень понятно самому этому лицу, но вот остальным… что делать ???
                            0
                            Почитайте ГОСТы — разницы ноль целых ноль десятых.

                            Ибо они тупо… зжены с буржуинских :)
                              0
                              про идентификаторы фич отдельно сказать хочется, лучше избегать осмысленных слов, а использовать номера, ибо на практике фичи имеют свойство трансформироваться, что приводит к обрастанию названия всякими суффиксами и префиксами, поэтому остановились на нумерации фич (и других компонентов, требующих идентификаторов) в виде F0001, F0045 и т.п. Самому документу тоже можно назначить идентификатор, который будет выполнять роль неймспейса: SRS0067.F0065
                                0
                                Тогда теряется упомянутая в статье возможность использовать названия фич в тикетах. Понятно, что можно использовать и номера, но тогда постоянно придётся копаться в списке фич, чтобы вспомнить, какому номеру какая фича соответствует.
                                  0
                                  Копаться придётся в любом случае, проверено на практике.
                                    0
                                    Но в случае со значащими именами можно хоть пробежаться глазами по списку тикетов и примерно понять, о чём речь. А с номерами этого не получится. Впрочем, каждый оптимизирует свою работу по своему :-)
                                0
                                www.processimpact.com/goodies.shtml — есть отличные шаблоны и примеры (Karl Wiegers — один из из авторитетов данной области).
                                  0
                                  Не вполне понял, в чем коренное отличие от ТЗ. Разъясните, ежли не трудно
                                    0
                                    Определиться бы с терминами…
                                    А то так:
                                    Сравниваем «SRS» и «ТЗ»

                                    «ТЗ»
                                    ТЗ — Техническое задание

                                    «SRS»
                                    SRS — Software requirements specification
                                    Software — (англ.) Программное обеспечение
                                    Requirements specification — (англ.) Техническое задание (перев. Lingvo Online:
                                    www.abbyyonline.com/translate.aspx?CardId=72;65;71;75;69;72;65;6d;65;6e;74;73;20;73;70;65;63;69;66;69;63;61;74;69;6f;6e;0;4c;69;6e;67;76;6f;45;63;6f;6e;6f;6d;69;63;73;20;28;45;6e;2d;52;75;29)
                                    Итого: SRS — ТЗ на ПО

                                    Вот и получается, что сравниваем бегемота с гиппопотамом
                                      0
                                      так это шаблон Вигерса :)

                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                      Самое читаемое