Чат поддержки
Практикум
Привет! Это поддержка Практикума 👋 Если что-то не получается — постараемся помочь. Пишите в чат или выберите другой способ связи
Выбрать способ связи
Виктория Казмина
kazminaviktoriya1
Пригласите друга
В профиль
Выход
ViktoriyaPolyakova81
natalyaefremova78
tatyana1988tatiana
MiloMilo83
SvetlanaKuznezova1987
milomilo79.maria
Добавить аккаунт

Документирование требований

В этом уроке вы узнаете, как документировать требования к ПО так, чтобы они были понятны и полезны всем заинтересованным лицам.
Артём
Ну что, приступаем к спецификации требований к ПО. Готов?
Даня
Эээ, то есть все эти требования, которые мы собирали и анализировали, это — ещё не спецификация?!
Артём
Нет😅 Но мы уже почти на финишной прямой.
Даня
Где-то я уже это слышал…
Когда требования к продукту выявлены и проанализированы, а варианты использования определены, самое время приступать к проектированию ПО. Но прежде чем переходить к этому этапу, системный аналитик должен описать все требования к ПО в едином документе с чёткой структурой. Другими словами, нужно задокументировать требования или подготовить спецификацию требований к ПО.
Спецификация требований к ПО, или SRS (от англ. Software Requirements Specification) — документ, где описаны все функции и возможности, которыми должно обладать ПО, включая требования к внешним интерфейсам и ограничения. На основе спецификации требований проектируют, разрабатывают и тестируют ПО. После запуска продукта этот документ помогает команде поддержки находить ошибки в работе ПО, в которое она внесёт изменения.
Спецификация требований — это своего рода договор между заказчиком и командой разработки, который описывает, каким должен быть готовый и правильно работающий продукт.

Шаблоны спецификации требований

Спецификация требований — объёмный документ, поэтому его нужно организовать так, чтобы в спецификации могли разобраться все заинтересованные лица.
В рамках этой темы мы рассмотрим стандартный шаблон спецификации, который содержит все основные разделы и чаще всего используется в организациях. В качестве примера для такой спецификации рассмотрим ПО, которое позволяет оплатить проезд с помощью транспортной карты.
Стандартная спецификация требований к ПО включает в себя:
  1. Введение
    В этой части содержится описание спецификации и инструкция, как её использовать. Раздел в основном посвящён спецификации, а не продукту, к которому он относится.
    1.1 Цель
    Здесь записывают название разрабатываемого продукта (ПО или его части) и указывают лица, которым будет полезен этот документ.
    1.2 Соглашения, принятые в документе
    В этом подразделе содержится информация об используемых стандартах, нотациях, принципах нумерации требований и прочее. Сюда записывают всё, что поможет корректно внести изменения или дополнить спецификацию.
    1.3 Границы проекта
    Во время разработки важно определять границы проекта, иными словами, описывать, что продукт может делать, а что — нет. Здесь также содержится краткая информация о разрабатываемом продукте и его назначении.
    1.4 Ссылки
    В этом подразделе указывают ссылки на внешние ресурсы (например, регламенты, стандарты, спецификации требований связанных продуктов, руководства по пользовательским интерфейсам). Если доступ к этим документам ограничен, стоит дополнительно указать, как его получить.
Пример:
  1. Введение
    1.1 Цель
    Эта спецификация требований описывает функциональные и нефункциональные требования к ПО для оплаты проезда с помощью транспортной карты. Спецификация создана для команды разработки данного ПО.
    1.2 Соглашения, принятые в документе
    Все требования, указанные в данной спецификации, имеют одинаковый приоритет.
    1.3 Границы проекта
    ПО для оплаты проезда с помощью транспортной карты предназначено для использования на станциях метро, оснащённых электронными турникетами с доступом к интернету.
    1.4 Ссылки
    …
  1. Общее описание
    Этот раздел содержит общее описание продукта: для чего он нужен, кто им будет пользоваться и от чего зависит его работа.
    2.1 Общий взгляд на продукт
    В этом подразделе описывается общее впечатление о продукте и информация о контексте его использования: это новый продукт или обновлённая версия уже существующего ПО? Связан ли он с другими продуктами или может работать автономно? Контекст использования продукта определяет и то, с какой целью будут использовать продукт.
    2.2 Классы пользователей и их характеристики
    Продукт, описываемый в спецификации к ПО, создаётся для разных классов пользователей. Некоторые требования распространяются только на часть из них. Например, у одних классов пользователей может быть больше привилегий, чем других, а значит, и требования для них будут отличаться. Поэтому для удобства чтения функциональных требований, которые выделяют из пользовательских, все классы и их характеристики указывают в отдельном подразделе спецификации.
    2.3 Операционная среда
    В этом подразделе содержится описание среды, в которой должен работать продукт: тип аппаратной платформы, требования к операционной системе, совместимость с другим ПО или его компонентами, требования к местоположению ПО и его компонентов.
    2.4 Ограничения проектирования и реализации
    При проектировании и реализации будущего продукта появляются самые разные ограничения. Например, нужно использовать определённые языки программирования, типы API, базы данных или библиотеки. Такие ограничения подробно описывают в этом подразделе.
    2.5 Предположения и зависимости
    Когда вы создаёте спецификацию, нужно стремиться к тому, чтобы каждое функциональное требование считывалось однозначно. Но всегда есть внешние факторы, которые могут повлиять на функциональность системы, а значит, и на точность требования к ней. Поэтому в спецификации отдельно описывают предположения, которые приняты при разработке проекта. Ещё в этом подразделе указывают, какие факторы, а также виды и версии ПО влияют на работу описываемого продукта.
Пример:
  1. Общее описание
    ….
    2.5 Предположения и зависимости
    Предполагается, что все турникеты, на которых установлено ПО, подключены к централизованной системе автоматической блокировки при перебоях в электроснабжении.
  1. Функции системы
Описание функций системы — самый объёмный раздел спецификации требований. Поскольку каждая функция требует детального описания, её выделяют в отдельный подраздел.
Функции можно сгруппировать по-разному: в зависимости от классов пользователей, вариантов использования, функциональных областей или иначе.
Важное правило: если какая-то функция не описана в спецификации требований, то и в конечном продукте её быть не должно.
3.1 Описание
Здесь записывают название функции, о которой пойдёт речь, добавляют её краткое описание.
3.1.1 Use Case
Use Case (варианты использования) в этом подразделе описываются по тому шаблону, который принят в организации.
Вспомните шаблон Use Case, с которым вы познакомились в прошлых уроках.
3.1.2 Функциональные требования
После того как вы описали Use Case и задали общие условия для выполнения функции, нужно определить, что должна делать система, чтобы пользователь достиг цели в заданных условиях.
Этот подраздел содержит подробные требования к системе — отвечает на вопросы:
  • Что система должна сделать для того, чтобы пользователь достиг желаемого результата?
  • Как система должна реагировать в альтернативных ситуациях?
  • Какие ошибки могут возникнуть в ходе выполнения сценария и как система должна на них реагировать?
Пример:
  1. Функции системы
    1. Оплата проезда пассажира транспортной картой
      3.1.1 Описание. Пользователь может оплатить проезд одного пассажира, используя стандартный турникет. Пользователь может иметь любую сумму на счету.
      3.1.2 Use Case
      ...
      1. 3 Функциональные требования
        3.1.3.1 Если пользователь прикладывает транспортную карту более одной секунды, система должна выполнить проверку баланса транспортной карты.
        3.1.3.2 При положительном балансе транспортной карты система должна выполнить списание суммы поездки с баланса карты.
    2. Оплата провоза багажа транспортной картой
      3.2.1 Описание
      Пользователь может оплатить провоз багажа, используя специальный турникет для багажа. Пользователь может иметь любую сумму на счету.
      3.2.2 Use Case
      …
      3.2.3 Функциональные требования
      …
  1. Требования к данным
    Сложно представить себе систему, которая бы работала без данных. Пользователи могут вводить и получать их, система может хранить и обрабатывать данные. Поэтому эта важная часть продукта описывается в отдельном разделе. В нём может содержаться:
    4.1 Логическая модель данных — визуальное представление объектов и наборов обрабатываемых системой данных, а также отношений между ними (Карл Вигерс).
    4.2 Словарь данных — информацию о типе данных, их формате, допустимых значениях и прочее.
    4.3 Отчёты, если их предусматривают опции продукта.
    4.4 Получение, целостность, хранение и утилизация данных
    Здесь содержится максимально полная информация о том, как система получает данные, как она их хранит и как удаляет.
  2. Требования к внешним интерфейсам
    Система, которая описана в предыдущих разделах, взаимодействует с пользователем, другими системами и оборудованием при помощи интерфейса. Требования ко всем видам интерфейсов относятся к нефункциональным и также учитываются в спецификации.
  3. Атрибуты качества
    В этом разделе описываются нефункциональные требования к продукту — атрибуты качества, которые система должна демонстрировать. К ним относятся удобство использования, производительность системы, её безопасность и многое другое.
Это основные разделы и подразделы спецификации. Обычно их достаточно для описания практически любого продукта. Но если какой-то из этих разделов и подразделов неактуален для разрабатываемого ПО, лучше не удалять его из спецификации, а указать, что данный пункт не применим. Зачем? Чтобы не потерять необходимые разделы, если спецификация будет меняться, или если нужно проверить её на полноту.
Как оформлять:
  1. Требования к внешним интерфейсам
     5.1 Пользовательские интерфейсы
     Не применимо.

Уникальный код требования

Стандартную спецификацию требований следует регулярно пересматривать, редактировать и отслеживать сделанные изменения в продукте. Чтобы упростить эти процессы и не превратить спецификацию в бесконечный, запутанный документ, нужно следовать правилам наименования и нумерации требований, а также использовать различные текстовые метки.
Наименование
Название каждого требования должно содержать уникальный код. Это позволяет точно идентифицировать каждое требование и при необходимости сослаться на конкретный номер, а не описание требования или страницу документа.
Нумерация
Присваивать уникальные коды требованиям можно по-разному.
  • Порядковая нумерация
Каждой группе требований присваивается своё уникальное обозначение (например, бизнес-требования обозначаются как BR (business requirements) или БТ, а функциональные — FR (functional requirements) или ФТ). Каждое требование из этой группы также получает свой порядковый номер (например, ФТ-1, ФТ-2).
Так как требований может быть много, и они относятся к разным типам, уникальное обозначение позволит легко определить, в какую группу входит какое-либо из требований.
Пример порядковой нумерации:
image
  • Иерархическая нумерация
Этот вид нумерации связан с порядком разделов самой спецификации. На примере шаблона спецификации, который мы рассматривали выше, все функциональные требования будут иметь нумерацию 3.1, 3.2 и так далее, а все требования к качеству продукта пойдут по номерами 6.1, 6.2. Такой подход позволяет группировать требования и создавать древовидную структуру.
Пример иерархической нумерации функциональных требований:
  1. Функции системы
    1. Пополнение баланса транспортной карты
      1. 1 Пополнение баланса транспортной карты наличными
        3.1.1.2 Описание
        3.1.1.2 Функциональные требования
      2. 2 Пополнение баланса транспортной карты безналичными способами
        3.2.1.1 Описание
        3.2.1.2 Функциональные требования
  • Текстовые метки
Уникальный код требования может быть не только числовым, но и текстовым. В этом случае потребуется создать единый подход к формированию таких меток для того, чтобы все участники команды разработки могли идентифицировать по ним требования.
Пример использования текстовых меток при формировании функциональных требований:
image
Все варианты присвоения уникальных кодов можно сочетать при условии, что подход к присваиванию этих номеров понятен и согласован со всеми заинтересованными лицами.
Уникальные коды также позволяют ссылаться на них в разных частях спецификации и не переживать, что потерялись какие-то изменения. Перекрёстные ссылки на разные коды требований также позволяют синхронизировать обновление документации.
Прочитайте выдержки из спецификации требований к ПО для управления кофемашиной. Они могут содержать некоторые ошибки. Определите, какие ошибки допущены там, где они есть.
image
image
image

Стиль описания требований

Прежде чем говорить о стиле описания требований, важно отметить, что любой, кто читает требования, должен трактовать их так, как автор это планировал. Однозначность в понимании требований превыше стиля.
Как донести до читателя именно то, что хотел сказать автор:
  1. Ясно, понятно
    Требования стоит писать простым языком, используя простые предложения с минимальным количеством причастных и деепричастных оборотов. Ещё стоит избегать сленга и внутренних терминов, которые понятны только узкому кругу лиц (например, «краш» вместо «прекращение работы программы»).
    Чем проще формулировки, тем лучше. Поэтому, если слова в предложении можно опустить без потери важной информации, стоит это сделать.
  2. Вам все должны
    Не стоит стесняться выдвигать требования к системе. Фраза «Система должна сообщить…» чётко указывает на требование. А вот фраза «Система может сообщить…» даёт разработчику и системе свободу интерпретации.
    Запомните стоп-фразы:
    • «Система может…»
    • «По возможности система должна сделать…»
    • «В зависимости от [каких-то условий] система должна сделать…» (нужно чётко определить, при каких условиях система должна вести себя определённым образом).
  3. Залог успеха
При описании требований нужно использовать активный залог. Это позволяет однозначно определить, какая сущность выполняет действие, и избавляет от разных интерпретаций написанного.
Пример
Пассивный залог: «Баланс транспортной карты будет изменён после выполнения списания стоимости проезда».
Активный залог: «После списания стоимости проезда система должна изменить баланс транспортной карты».
  1. Лучше один раз увидеть
Если что-то можно представить графически, обязательно воспользуйтесь этим. Так вы сильно облегчите понимание требований. Но нужно помнить, что каждой схеме, как и требованию, необходимо присваивать своё название и номер.

Уровень детализации требований

Задача системного аналитика — так описать требования, чтобы их было достаточно для создания продукта при приемлемом уровне риска. Чтобы снизить уровень риска до приемлемого, нужно подробно сформулировать требования. Это значит, что не стоит разъяснять самые простые понятия или, наоборот, гнаться за краткостью. Важно сохранить золотую середину.
Хорошая практика — сохранять единый уровень детализации для всех типов требований. Если одни требования описаны максимально подробно, а другие поверхностно, у того, кто читает спецификацию, будет впечатление, что более подробные требования важнее, чем те, что описаны кратко.
Пример одного и того же требования с разным уровнем детализации.
image
Качественно написанная спецификация требований — один из элементов успешной разработки продукта. Низкое качество спецификации может привести к:
  • Созданию продукта, который не отвечает желаниям заинтересованных сторон, включая пользователей.
  • Разному пониманию требований участниками команды разработки.
  • Неправильной оценке труда разработчика, тестировщика, и, следовательно, к срывам сроков проекта.
Выберите требования, которые не соответствуют стилистическим правилам описания требований.

Подведём итоги

  • Не существует единственно верного подхода для описания требований. Наиболее эффективен — тот, при котором все заинтересованные лица могут легко понять, какой продукт получится по итогам разработки.
  • При создании спецификации стоит использовать шаблоны. Не все разделы из них могут понадобиться при разработке, но их всегда можно адаптировать под потребности вашего продукта.
  • Каждое требование в спецификации должно иметь свой уникальный код (один или несколько вариантов):
    • Порядковый номер
    • Иерархический номер
    • Текстовую метку
  • При создании спецификации стоит придерживаться нескольких стилистических правил:
    • Писать ясно и умеренно детализировать
    • Использовать слово «должна» или «должен»
    • Использовать активный залог
    • Использовать схемы там, где информацию можно представить графически