Текстовая расшифровка двенадцатого урока курса Введение в профессию аналитика.
Давайте теперь поговорим о критериях качества требований. Требования мы разрабатываем, но насколько они являются хорошими или плохими? По этим критериям определяется качество работы аналитиков.
Существует несколько подходов или моделей определения качества требований. Они в основном отражаются в виде таких списков. Я несколько таких списков сейчас вам приведу, а потом мы их сравним между собой и поймём, чем они отличаются, и в каких ситуациях они применимы.
Этот список я взял из статьи бывшего директора по маркетингу IBM (ссылка на статью здесь приведена).
Что такое хорошее требование? В данном случае речь идёт об отдельном требовании, можно сказать, атомарном.
Требование должно быть корректным. Требование должно быть полным в том смысле, что оно выражает
Предполагается, что каждое ваше требование, которое вы зафиксировали, должно соответствовать этим свойствам, чтобы оно считалось хорошим требованием. Это просто один из списков. Этот список относится к отдельному требованию. То есть к тому, что мы можем назвать атомарным требованием.
Если говорить об SRS. Вот этот стандарт, о котором я говорил: IEEE 830. В нём тоже есть критерии качества, но это критерии для оценки не отдельного требования, а их совокупности, всей спецификации в целом. Они перечислены прямо в этом стандарте, а здесь переведены на русский язык.
В стандарте для каждого из этих пунктов есть отдельные абзацы, где описывается, что имеется в виду. Спецификация должна быть корректной, однозначной (однозначно трактуемой). Спецификация должна быть полной,
Это критерии качества целой совокупности требований.
Я говорил, что буду использовать эту картинку на протяжении курса. Помните, мы говорили о том, что совокупность требований представляет собой модель продукта.
И модель продукта может быть полной, а может быть и неполной. То есть спецификация требований может описывать продукт с разных точек зрения, а может описывать только отдельные его части.
По этим критериям хорошей спецификации, мы понимаем, что предполагается, что спецификация описывает продукт со всех сторон. Тут явно это слово присутствует: полнота спецификации. В
Если говорить о современных методах, итерационных, то этой полноты часто достичь просто невозможно. Если мы говорим о разработке требований к
Давайте сначала посмотрим, какие критерии качества применяются к User Story, которая, собственно, является основным методом представления требований в Agile подходах, в Agile практиках. Они здесь перечислены.
Отдельная User Story, как атомарное требование, должна быть независимой. Этот принцип описан в книгах. Мы будем разбирать этот принцип более детально, что означает каждое из этих слов. Я пока очень коротко опишу.
Обсуждаемой. Очень важное свойство, потому что первоначально сформулированная User Story — это только повод для обсуждения. Она не должна сразу пускаться в реализацию, а должна пройти обсуждение всей командой разработки для того, чтобы к ней добавить
Полезная. Это вообще очень важный принцип Agile: любая доработка должна принести
Эстимируемая, или,
Компактная. То есть небольшая. Не буду здесь вдаваться в подробности.
Тестируемая. Это тоже обязательно. User Story должна быть проверяема. После того, как мы реализовали это требование, мы должны убедиться, что оно действительно реализовано, и реализация соответствует тому, что в этом требовании описано.
По начальным буквам вы видите так называемый принцип INVEST. Специально подбирали слова, что бы появилась такая аббревиатура, легко запоминаемая. И это, собственно, основной набор критериев хороших требований, которые используются в Agile.
А теперь давайте мы их сравним. Я вынес в левую часть свойства хороших требований по тому списку IBM, из которого торчат уши водопадного процесса. А справа описал критерии хорошей пользовательской истории. Посмотрел, какие из них соответствуют друг другу, и нашёл, на самом деле, только два. Тестируемая пользовательская история — это то же самое, что проверяемое требование. А независимая пользовательская история — это то же самое, что модульное требование (я говорил, что здесь тоже должно быть слово «независимое»). А все остальные критерии в
Например, полнота требования — этот критерий неприменим к пользовательской истории потому, что она должна быть обсуждаемой. И она станет полной и, может быть, однозначной, только после этого обсуждения. Перед тем как, запустить её в разработку, она обрастёт
Интересно, что польза, которая является важным критерием качества требований в Agile, слева вообще никак не упоминается. Требование должно быть корректным, однозначным, совместимым, а о его пользе вообще ничего не говорится. Конечно, предполагалось, что бесполезные требования в спецификацию не попадут, но, тем не менее, такого критерия оценки здесь нет.
Оцениваемая. Опять же, другой подход совершенно. Пользовательские истории предназначены сразу и для управления требованиями,
Компактность пользовательской истории. Этот критерий, на самом деле, связан с тем, что она должна быть оцениваемой. Опять же, слева такого явного критерия по отношению к требованиям нет.
К чему я это показываю? К тому, что это два крайних случая представлений о требованиях. Представление о том, что требования должны давать полную модель нашего продукта, которое было раньше распространено и которое проистекает из водопадного подхода, противоречит методу разработки с непрерывным изменением требований. И вы видите, что эти критерии во многом несовместимы.
Какие критерии нам использовать в нашей работе? Для того, чтобы это понять, мы должны сориентироваться по этой системе координат, понять, где мы находимся. По какому процессу мы разрабатываем продукт, что это за вид продукта, какие требования мы разрабатываем, насколько они важны и, соответственно, применять к ним те критерии, которые соответствуют нашей ситуации.
Я понимаю, что эта часть получилась достаточно абстрактной, но в курсе мы эти критерии попробуем применить к тем требованиям, которые мы разрабатываем, и там уже более конкретно поймём, что стоит за этими словами.
Предыдущий урок: Основные форматы представления требований
Введение в профессию аналитика (демо) Бесплатно | |
Введение в профессию аналитика 2 900 руб. | |
Вебинары Сообщества Аналитиков Бесплатно | |
SQL для непрограммистов (СЕРТИФИКАТ) 999 руб. | |
SQL для непрограммистов Бесплатно |