Зачем беспокоиться о разграничении функциональных и нефункциональных требований?

Я понимаю разницу между ними, но мои коллеги спрашивают меня о преимуществах маркировки требований как функциональных или нефункциональных (или переходных). Зачем это делать? Он провел, как он сказал, два дня, просматривая список требований для одного проекта, и не увидел в этом никакой пользы, потому что конечным результатом была передача документа другому бизнес-субъекту с указом «Сделай все».

Чего я боюсь, так это требований, объединенных в один документ. Я пытался объяснить выгоду на практике, но не смог ее продать. Как продать преимущество документирования, какие требования являются функциональными, а какие - нет.

Явное разделение требований облегчит разработку правильной системы.

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

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

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

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

Энтони Латтанце из « Архитектурных программных систем с интенсивным использованием программного обеспечения: руководство для практиков» дает практический обзор архитектурных драйверов и причин, по которым с ними следует обращаться по-разному, гораздо более подробно, чем мое резюме

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

Тем не менее, есть несколько причин для разделения двух категорий требований:

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

Ответственность за тестирование Насколько хорошо пользователь или команда QA проверяют соответствие требованиям безопасности, отказоустойчивости, безопасности и надежности?

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

Управление версиями Если вы находитесь в корпоративной среде с множеством «стандартов» - вы можете написать конкретные документы с требованиями к пользовательскому интерфейсу или безопасности (чтобы назвать пару), которые могут быть версионированы. Таким образом, вы могли бы написать в специфических требованиях приложения (в основном функциональных требованиях): «Приложение должно соответствовать V2.3 Требования безопасности, определенные в XYZ-Company-SecReq-DocumnentNamingStandard.docx».

Зачем беспокоиться о разграничении функциональных и нефункциональных требований?

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

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

Чего я боюсь, так это требований, объединенных в один документ. Я пытался объяснить выгоду на практике, но не смог ее продать. Как продать преимущество документирования, какие требования являются функциональными, а какие - нет.

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

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

Большой отдельный документ со всеми требованиями не обязательно является плохой вещью ... Тратить 2 дня на его рассмотрение тоже неплохо. Проблема, как правило, заключается в том, что, как только один человек изучил требования, они понимают их, но кому-то еще не легче сделать то же самое. Это может быть большим подспорьем для обозначения требований метаданными, которые помогут другим людям, присоединяющимся к проекту.

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

Есть несколько преимуществ для разделения.

1. Экономьте время на тестировании (т.е. тестируйте только функциональные требования)
2. Экономит время на будущие изменения требований (т.е. нефункциональные требования будут занимать меньше времени для рассмотрения / утверждения / внедрения / тестирования)
3. В регулируемом мире (например, FDA и т. Д.) Нефункциональные требования требуют 1/10 от количества документов, которые требуются для функциональных требований.
4. Дает команде возможность разделить работу между старшими (функциональными) и младшими (нефункциональными) членами команды.

Я мог бы продолжить ...

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