Как стать автором
Обновить

Правила составления 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-ми классное образование по русскому языку накладывает свой отпечаток.)
Теги:
Хабы:
Всего голосов 58: ↑56 и ↓2 +54
Просмотры 133K
Комментарии Комментарии 30