Требования к разработке ПО. Почему вам нужно разбираться в них? Часть 2

0
375
views

Перевод второй части статьи «Why You Need to Understand Software Requirements as a Software Engineer».

Первую часть можно найти по ссылке.

Photo by You X Ventures on Unsplash

Классификация требований к ПО

Когда требования собраны, команда, которая будет заниматься проектом, может приступить к их классификации и разбивке на категории.

Благодаря классификации требований можно точнее оценить сроки и определить компоненты решения. В процессе работы у вас также могут появиться идеи, касающиеся реализации проекта.

Требования к ПО могут быть:

1. Функциональными и нефункциональными.

  • Функциональные требования описывают функции, которые должно выполнять ПО. Например, предоставлять канал коммуникации для пользователя или переводить данные из одного формата в другой. То есть, речь идет о функционале продукта.
  • Нефункциональные требования касаются таких вещей, как доступность, надежность, способность к восстановлению, поддерживаемость, масштабируемость, производительность, безопасность и прочие «…ость».

2. Производными и навязанными.

  • Вытекает ли это требование из других требований?
  • Это требование было явно и недвусмысленно высказано стейкхолдерами?

3. Ориентированными на продукт или на процесс его разработки.

  • «Программа должна проверять права пользователя» — это требование к продукту.
  • «Программа должна разрабатываться инкрементально. В ходе разработки должна использоваться непрерывная интеграция» — это требование к процессу.

4. Разной приоритетности. Для назначения приоритета может использоваться шкала с фиксированными значениями «обязательно», «крайне желательно», «желательно» и «необязательно».

5. Разного масштаба. Одни требования касаются проектирования отдельных компонентов, другие — архитектуры всего ПО. Нефункциональные требования чаще всего касаются всей программы в целом.

6. Изменчивыми или стабильными. Например, изначально может быть ясно, что требования будут меняться в ходе жизненного цикла продукта. В таком случае реализация программы должна быть толерантной к внесению изменений.

Валидация требований

Когда требования выяснены и классифицированы, нужно проверить их, обсудив со стейкхолдерами. Вы должны быть уверены, что поняли и записали все точно и что требования в целом действительно удовлетворяют нужды стейкхолдеров. Требования, которые не прошли валидацию, являются всего лишь «хотелками» тех, кто их высказал.

Если вы практикуете итеративную разработку, валидация требований будет осуществляться регулярно, при этом будут обсуждаться требования, касающиеся отдельных частей решения, т. е., они будут разбиты на логичные группы.

Обычно для проверки требований команда, реализующая решение, воспроизводит свое понимание требований стейкхолдерам. При этом может применяться начальный проект (бизнес-проект или технический, или даже оба), на котором показывается, как будут реализованы нужды стейкхолдеров.

Такие обсуждения для выяснения, все ли правильно всё поняли, устраиваются итеративно на этапах планирования. Обычно в них участвуют кросс-функциональные команды (дизайнеры, бизнес-аналитики, технические эксперты).

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

В ходе валидации может выясниться, что команда не может полностью удовлетворить все требования каждого стейкхолдера. Ваша задача (как технического эксперта) — продемонстрировать, что можно сделать, и обсудить уступки, на которые можно пойти при существующих ограничениях. Эти компромиссы должны быть приемлемыми для главных стейкхолдеров, а также укладываться в рамки бюджета, технических возможностей и прочих ограничений.

Использование функциональных прототипов

Функциональные прототипы помогают нам:

  • проверить, что требования поняты правильно;
  • проверить допущения разработчика;
  • получить фидбэк, в котором могут содержаться новые требования.

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

То, как создается прототип, определяется командой, которая занимается проектом. Кто-то предпочитает прототипы, в которых вообще не задействовано ПО (аналогичные тем, которые создаются при сборе требований). Другие отдают предпочтение специальным инструментам, с помощью которых можно быстро создать «черновик» будущей программы.

Какой бы вариант вы ни выбрали, следует учитывать, сколько времени уйдет на создание прототипа, и насколько эффективно он продемонстрирует основной функционал.

Photo by Allen Ng on Unsplash

Разработка и реализация требований

Когда требования прошли валидацию у стейкхолдеров, можно приступать к разработке ПО (т. е., к реализации этих требований).

Основной интерес вашей организации — получить прибыль от программного решения. Ваша задача и ответственность — попытаться использовать методы, снижающие стоимость разработки и поддержки.

Сделать это можно, например, путем повторного использования компонентов (внутри одной программы или из других продуктов), применения выверенных шаблонов и работы с проверенными инструментами (фреймворками) с хорошей документацией.

Специфические требования, в частности, ограничительные, могут очень сильно влиять на стоимость программ. Например, если ваш набор навыков не соответствует проекту или требования противоречат существующей архитектуре (или даже просто недостаточно хорошо в нее вписываются). Команда, занимающаяся проектом, должна найти возможные компромиссы, касающиеся таких требований.

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

User Story

Разработчик часто работает в контексте данной ему пользовательской истории (user story).

User story — это изложенное простыми словами представление о взаимодействии пользователя определенного типа с программным обеспечением и его функционалом. Обычно user story излагается в следующем формате:

Как <роль> я хочу <цель, желание>, чтобы <выгода>.

Пример:

Как администратор курса я хочу видеть число записавшихся людей, чтобы оценивать наполненность курса.

В некоторых случаях user story поступает вместе с дизайном или прототипом — если это требовалось на стадии валидации.

User story не обязательно ориентирована на пользователя. Она может происходить из какой-то необходимости или нефункционального требования. В этих случаях вы можете получить требование в спецификации или наборе сценариев.

Каждая отдельная пользовательская история должна содержать минимально необходимое количество информации, позволяющее оценить, сколько усилий потребуется для ее реализации. Если команда не может сделать разумных прикидок, это может быть признаком того, что знания и навыки членов команды не подходят для проекта, у людей нет достаточной уверенности в своем уровне, существуют какие-то ограничения или, наконец, что сама user story низкого качества.

Разработчиков ограничивают (вынужденно) планы менеджмента проекта, но нужно стремиться обеспечивать качество на максимально высоком уровне с учетом доступных ресурсов.

Прежде, чем браться за реализацию user story, проверьте:

  • что у вас есть подходящие критерии приемки, написанные стейкхолдерами или согласованные с ними. Эти критерии определяют, каким образом реализация в коде должна помочь пользователю достигнуть цели, заявленной в истории. Критерии приемки будут составлять основу приемочного тестирования (другими словами, тесты будут проверять, соответствует для функционал требованиям). Кроме того, с помощью этих критериев сама команда сможет определять, когда работа над функцией завершена.
  • что дизайн прототипа (если вы его делали) в принципе можно реализовать, что это будет вписываться в существующую архитектуру, а также — что навыки разработчиков и имеющиеся у них инструменты позволяют выполнить эту работу.
  • любые предположения относительно того, что стоит за требованиями. Таким образом вы сможете заполнить пробелы в знаниях, узнать о потенциальных проблемах, а также о неучтенных сценариях (edge cases), которые придется обсудить со стейкхолдерами.
Photo by John Hult on Unsplash

«Торги» по требованиям к ПО

При реализации требований может оказаться, что вы не способны полностью удовлетворить интересы каждого стейкхолдера. Например, могут возникнуть разногласия между функциональными и нефункциональными требованиями или реализация одного требования может задевать какие-то другие интересы стейкхолдеров.

В таких случаях будет неразумно принимать решения в одностороннем порядке.

Вы должны донести информацию о возникших затруднениях до заинтересованных сторон. При этом надо простым языком рассказать о возможных компромиссах и согласовать их со стейкхолдерами (не выходя при этом за рамки бюджетных, технических, нормативных и прочих ограничений).

Верификация требований к ПО

Реализация любых требований должна проверяться. Это должно делаться как на уровне отдельных функций, так и на глобальном уровне (когда дело касается, например, нефункциональных требований). В общем, мы проверяем, насколько созданное ПО соответствует заявленным требованиям.

Спланировать, как будет верифицироваться каждое требование, это одна из важных задач.

Разработчики верифицируют требования при помощи приемочного тестирования. Эти тесты демонстрируют, насколько полно были выполнены требования. Делается это путем показа, что конечный пользователь может использовать созданное ПО в предусмотренных сценариях.

В случаях, когда продемонстрировать верификацию сложнее, например, когда речь идет о нефункциональных требованиях, может понадобиться некое моделирование. Скажем, чтобы протестировать производительность, может создаваться специальное ПО, симулирующее сотни или тысячи запросов к системе.

По мере развития программного обеспечения реализация каждого нового требования может непреднамеренно влиять на ранее реализованные требования. Это можно обойти, автоматизировав приемочные тесты. Для этой цели существует множество инструментов и библиотек.

Не следует считать приемочное тестирование единственно важным. Не забывайте покрывать свой код и другими тестами (например, модульные и интеграционными).

Приемочные тесты различаются по уровню сложности, который зависит от критериев приемки. Также в разных компаниях могут использовать разную терминологию и разные методы, из-за чего приемочное тестирование можно спутать со сквозным, функциональным или тестированием сценариев.

Помните, что суть каждого приемочного теста — просто формальная проверка того, что реализованное решение удовлетворяет требованиям, которые выдвигались к программному обеспечению. Делается это путем копирования поведения пользователей при запуске приложения.

ОСТАВЬТЕ ОТВЕТ

Please enter your comment!
Please enter your name here