Перевод первой части статьи «Why You Need to Understand Software Requirements as a Software Engineer».
В этой статье я расскажу вам о требованиях к программному обеспечению. Мы разберем, что это такое, каков процесс работы с требованиями и, что самое главное, — каковы ваши обязанности в этой сфере (т. е., обязанности разработчика).
Прочитав эту статью, вы лучше поймете свою роль в работе с требованиями. Даже если ничем больше это вам не поможет, у вас хоть появится «умная» тема для обсуждения с коллегами.
Прежде всего, почему это важно?
У людей, не связанных с разработкой программ, есть некоторое недопонимание профессии разработчика ПО. Они считают, что разработчик только «пишет код».
Да, код писать мы любим. Но считать, что мы только этим и занимаемся в своей работе, было бы слишком большим упрощением. Это лишь небольшая часть наших обязанностей.
На самом деле разработчик ПО создает решения для бизнеса. Мы работаем над самыми разными задачами, не связанными напрямую с написанием кода.
В частности, разработчик работает с требованиями к программному обеспечению.
Что такое требования к ПО?
Словосочетание «требования к программному обеспечению» на первый взгляд кажется простым и понятным. Программа должна делать А для Б, чтобы В. Если вы возьмете любую проблему, которую способно решить программное обеспечение, и будете обдумывать ее достаточно долго, вы, вероятно, придумаете довольно много требований к этому ПО. Поэкспериментировать можно и с уже существующими программами. Вроде как все просто, верно?
Не верно. По крайней мере, не для программ корпоративного уровня.
Как вы собираете требования? Учитываете нужды и приоритеты стейкхолдеров? Или это требования с точки зрения пользователей ПО? Есть ли какие-то технические ограничения относительно требований? Как вы определяете, что работа завершена? Должна ли реализация требований отвечать какому-то набору критериев? И так далее…
Когда вы начинаете углубляться в идею требований к ПО, вы обнаруживаете, что это довольно обширная и глубокая сфера знаний.
Насколько она широка и глубока? Она включает в себя процесс определения требований, их анализ, спецификацию и валидацию, а также управление требованиями в ходе всего жизненного цикла ПО.
Задач, связанных с требованиями, так много, что в сфере разработки возникло отдельное направление — разработка требований ПО.
В некоторых организациях могут даже нанимать людей на отдельную позицию разработчика требований. Конечно, такое чаще встречается в крупных компаниях, занимающихся решениями системного уровня. Например, в компаниях, предлагающих комплексные решения проблем клиентов, где программное обеспечение — всего лишь один из компонентов.
Но гораздо чаще ответственность за разработку требований распределяется между совершенно разными специалистами. Отдельными задачами в этой области могут заниматься дизайнеры, бизнес-аналитики, собственники продукта (product owners), менеджмент, технические писатели, разработчики, архитекторы и т. д.
Если брать в целом, реализовать процесс работы с требованиями линейно (например, по методологии waterfall) довольно сложно. Такой подход предполагает, что сначала вы получаете список требований от стейкхолдеров, затем классифицируете задачи, распределяете их в команде и в итоге вручаете стейкхолдерам решение, реализованное разработчиками. Зачастую такой процесс просто нереален, особенно для долгосрочных проектов.
Требования к таким крупным проектам никогда нельзя определить идеально и исчерпывающе. Поэтому обычно работа идет итерациями, чтобы качество и детализация требований были достаточными для проектирования и принятия решений.
Отличие разработки требований от разработки программ в том, на какой именно работе вы фокусируетесь.
Вы как разработчик должны понимать, каким образом и в какой мере вы связаны с разработкой требований, потому что весьма вероятно, что на каком-то этапе вам придется участвовать в этом процессе.
Какое участие в работе с требованиями может принимать разработчик ПО?
В зависимости от процедуры работы над требованиями, принятой в вашей организации, и от задач, вмененных разработчикам, вас могут подключить к делу на любой стадии. То есть, от сбора требований до проверки их реализации.
Вот примеры задач, которыми вы можете заниматься в той или иной мере:
- Определение требований — сбор требований к программному обеспечению.
- Классификация — разбивка требований по категориям.
- Валидация — утверждение требований у стейкхолдеров.
- Разработка и реализация — создание программы, отвечающей требованиям.
- Обсуждение требований — улаживание конфликтов интересов со стейкхолдерами.
- Верификация — оценка созданной программы на предмет соответствия требованиям.
Стоит отметить, что это не дублирование процесса разработки требований. Последняя предполагает более глубокую вовлеченность и работу над специфическими задачами, такими как документирование и управление требованиями.
Разработчики ПО обычно не занимаются менеджментом требований и их документированием. Скорее всего и в вашем случае этим будут заниматься какие-то другие специалисты.
Но вы как разработчик должны уметь пользоваться системой для управления требованиями, чтобы иметь доступ к внесенным в них изменениям и заниматься их анализом.
Хм, а у нас нет никакой системы управления требованиями…
Не всегда для записи требований и управления ими используется какая-то специализированная система. Требования могут записываться, например, в программе для issue-трекинга, в каких-то инструментах для менеджмента проектов или хотя бы даже в системе контроля версий.
Бывает, что организации или команды, занимающиеся проектами, не разрабатывают никаких средств для документирования требований и управления ими. Вместо этого они могут полагаться на «видение» («vision») лидера (зачастую — основателя компании). Также отсутствие специальных систем может объясняться недостатком ресурсов. В таких случаях люди могут настаивать на том, что запись требований и управление ими не обязательны.
Но когда вы не записываете требования, ваша организация сильно рискует.
Например, если ваша компания разрабатывает решения для каких-то нужд клиентов, у вас точно будут определенные юридические обязательства. Там может быть обозначено, что ваше ПО должно обеспечить определенный функционал и предоставлять определенный уровень услуг.
Но в отношениях с заказчиком может возникнуть конфликт (возможно, юридического характера). Скажем, в вашей программе может быть упущен какой-то функционал или что-то может быть реализовано не так, как ожидал заказчик. Или вы, возможно, потратили время и деньги на какие-то функции, которые заказчику на самом деле не нужны. Как вы докажете, что реализовали все именно так, как было договорено со стейкхолдерами? Что на тот момент они считали все эти функции правильными и необходимыми?
Ваша организация должна иметь возможность продемонстрировать связь между:
- высокоуровневыми требованиями к решению (т. е., нуждами клиентов),
- утвержденными требованиями к ПО (на что согласились стейкхолдеры и что они сочли приемлемым),
- документацией и записями приемочного тестирования, показывающими, что вы создали именно то, что у вас заказывали.
Можно привести другой пример, более распространенный. По мере роста и развития организации растет и развивается созданное вами ПО. И если оно изначально не задумывалось как одноразовое, где-то должно быть предусмотрено, в течение какого времени это ПО должно быть в рабочем состоянии и на протяжении какого срока оно должно поддерживаться (включая создание нового функционала, выпуск обновлений и т. п.).
Все эти действия, связанные с развитием ПО, могут существенно изменить программу (вплоть до смены архитектуры всего приложения или его компонентов). И то, что получится в итоге, может существенно отличаться от первоначального плана, закрепленного в требованиях.
В таком случае вам нужно будет пересмотреть и проанализировать старые требования, чтобы понять мотивы, стоявшие за ними. Например:
- Почему это было реализовано именно так?
- Нужно ли вносить изменения в текущую работу?
- Актуально ли это требование?
Определение требований
Определение требований — действия, направленные на сбор и формулирование требований. Не все требования «отбираются» у потребителей. Они могут определяться системой или сферой деятельности, для которой разрабатывается программа. (Например, для критически важных систем важна надежность, но потребитель может и не высказать такое требование).
С точки зрения менеджмента определение требований абсолютно необходимо: на его основе определяется объем проекта и расставляются приоритеты, чтобы в первую очередь удовлетворить самые важные нужды клиента.
В чем заключается процесс определения требований?
Разработчики (в зависимости от их позиции в компании) могут принимать участие в получении требований от источника.
Участие в определении требований помогает в дальнейшем проектировать решение на основе полученной информации. Также для разработчика важно понимать, от кого исходят требования и что за ними стоит.
От кого исходят требования, от чего они зависят?
У требований может быть много источников, например:
- Цели бизнеса
- Знание отрасли
- Стейкхолдеры
- Законы бизнеса
- Операционная среда (общий контекст, операционная система пользователя, интерфейс пользователя и т. п.).
Если вас привлекли к определению требований, вам нужно:
- Уделить особенное внимание целям. Цели часто бывают расплывчатыми, например: «ПО должно быть реализовано с учетом передового опыта», «ПО должно быть дружественным к пользователю». Оцените относительную приоритетность требований. Изучите относительно недорогие способы достижения заявленных целей.
- Изучить, насколько сможете, отрасль, для которой создается ПО. Этот бэкграунд позволит вам разобраться в резонах, стоящих за требованиями. Ключом к хорошему анализу требований является моделирование реальных проблем, например, создание моделей взаимоотношений между сущностями. Старайтесь использовать онтологический подход.
- Выяснить точку зрения разных стейкхолдеров. Требования могут оказаться конфликтующими друг с другом, и у каждой заинтересованной стороны может быть своя мотивация. Важно выяснить разные нужды, особенно при предварительном планировании, когда формируется проект будущего ПО.
- Учесть среду, в которой будет работать программа. Операционная среда будет зависеть от структуры организации, ее культуры и внутренней политики. Общий принцип, которому в идеале должно соответствовать ваше ПО, — оно не должно вносить незапланированных или принудительных изменений в бизнес-процесс организации.
Как мне выяснить требования к программе?
Вас как технического эксперта могут попросить:
- принять участие в переговорах со стейкхолдерами,
- набросать разные сценарии,
- создать прототипы,
- исследовать проблемную зону,
- заняться user stories.
При создании прототипов старайтесь на ранних стадиях использовать не слишком точные прототипы. Таким образом вы сможете избежать фиксации сторонами второстепенных или побочных характеристик. Высококачественный прототип может непреднамеренно ограничить гибкость проектирования.
Продолжение следует.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]