что такое полнота требований
WEBURSITET.RU
Онлайн-курсы профессиональной разработки ПО
Критерии качества требований
Текстовая расшифровка двенадцатого урока курса Введение в профессию аналитика.
Давайте теперь поговорим о критериях качества требований. Требования мы разрабатываем, но насколько они являются хорошими или плохими? По этим критериям определяется качество работы аналитиков.
Существует несколько подходов или моделей определения качества требований. Они в основном отражаются в виде таких списков. Я несколько таких списков сейчас вам приведу, а потом мы их сравним между собой и поймём, чем они отличаются, и в каких ситуациях они применимы.
Этот список я взял из статьи бывшего директора по маркетингу IBM (ссылка на статью здесь приведена).
Что такое хорошее требование? В данном случае речь идёт об отдельном требовании, можно сказать, атомарном.
Предполагается, что каждое ваше требование, которое вы зафиксировали, должно соответствовать этим свойствам, чтобы оно считалось хорошим требованием. Это просто один из списков. Этот список относится к отдельному требованию. То есть к тому, что мы можем назвать атомарным требованием.
Если говорить об SRS. Вот этот стандарт, о котором я говорил: IEEE 830. В нём тоже есть критерии качества, но это критерии для оценки не отдельного требования, а их совокупности, всей спецификации в целом. Они перечислены прямо в этом стандарте, а здесь переведены на русский язык.
В стандарте для каждого из этих пунктов есть отдельные абзацы, где описывается, что имеется в виду. Спецификация должна быть корректной, однозначной (однозначно трактуемой). Спецификация должна быть полной, должна описывать продукт со всех сторон. Непротиворечивой, то есть требования не должны противоречить друг другу. Упорядоченной по значимости или устойчивости. Спецификация должна быть проверяемой, то есть если мы описали требования в спецификации, то мы должны иметь способ убедиться, что эти требования реализованы. Модифицируемой, то есть она должна быть составлена таким образом, чтобы была возможность её изменять. И отслеживаемой — здесь речь идёт примерно о том, о чём она шла на предыдущем слайде: трассируемой, то есть мы должны уметь отслеживать изменения в спецификации.
Это критерии качества целой совокупности требований.
Я говорил, что буду использовать эту картинку на протяжении курса. Помните, мы говорили о том, что совокупность требований представляет собой модель продукта.
И модель продукта может быть полной, а может быть и неполной. То есть спецификация требований может описывать продукт с разных точек зрения, а может описывать только отдельные его части.
Давайте сначала посмотрим, какие критерии качества применяются к User Story, которая, собственно, является основным методом представления требований в Agile подходах, в Agile практиках. Они здесь перечислены.
Отдельная User Story, как атомарное требование, должна быть независимой. Этот принцип описан в книгах. Мы будем разбирать этот принцип более детально, что означает каждое из этих слов. Я пока очень коротко опишу.
Обсуждаемой. Очень важное свойство, потому что первоначально сформулированная User Story — это только повод для обсуждения. Она не должна сразу пускаться в реализацию, а должна пройти обсуждение всей командой разработки для того, чтобы к ней добавить уточнения, критерии приёмки, комментарии Только после этого обсуждения она будет пригодна для запуска в реализацию. Это свойство говорит о том, что User Story должна быть изначально написана так, что бы она была пригодна для обсуждения.
Полезная. Это вообще очень важный принцип Agile: любая доработка должна принести пользу пользователю. И, соответственно, пользовательская история должна давать пользу для развития продукта.
Компактная. То есть небольшая. Не буду здесь вдаваться в подробности.
Тестируемая. Это тоже обязательно. User Story должна быть проверяема. После того, как мы реализовали это требование, мы должны убедиться, что оно действительно реализовано, и реализация соответствует тому, что в этом требовании описано.
По начальным буквам вы видите так называемый принцип INVEST. Специально подбирали слова, что бы появилась такая аббревиатура, легко запоминаемая. И это, собственно, основной набор критериев хороших требований, которые используются в Agile.
А теперь давайте мы их сравним. Я вынес в левую часть свойства хороших требований по тому списку IBM, из которого торчат уши водопадного процесса. А справа описал критерии хорошей пользовательской истории. Посмотрел, какие из них соответствуют друг другу, и нашёл, на самом деле, только два. Тестируемая пользовательская история — это то же самое, что проверяемое требование. А независимая пользовательская история — это то же самое, что модульное требование (я говорил, что здесь тоже должно быть слово «независимое»). А все остальные критерии в друг друга заменяют, но не полностью, а в даже противоречат.
Например, полнота требования — этот критерий неприменим к пользовательской истории потому, что она должна быть обсуждаемой. И она станет полной и, может быть, однозначной, только после этого обсуждения. Перед тем как, запустить её в разработку, она обрастёт уточнениями, комментариями.
Интересно, что польза, которая является важным критерием качества требований в Agile, слева вообще никак не упоминается. Требование должно быть корректным, однозначным, совместимым, а о его пользе вообще ничего не говорится. Конечно, предполагалось, что бесполезные требования в спецификацию не попадут, но, тем не менее, такого критерия оценки здесь нет.
Оцениваемая. Опять же, другой подход совершенно. Пользовательские истории предназначены сразу и для управления требованиями, чтобы сразу их пускать в реализацию. Для этого нужна их оценка, чтобы понимать, сколько таких требований мы можем включить в одну итерацию. Мы должны понимать, сколько сил каждая из них у нас отберёт или времени. Слева, отчасти, может быть похож критерий — выполнимая в рамках бюджета и сроков. Но не очень понятно, как это можно оценивать. Для того, чтобы требование было выполнимым, мы всё равно должны его оценить, но явно этот критерий здесь не прописан.
Компактность пользовательской истории. Этот критерий, на самом деле, связан с тем, что она должна быть оцениваемой. Опять же, слева такого явного критерия по отношению к требованиям нет.
К чему я это показываю? К тому, что это два крайних случая представлений о требованиях. Представление о том, что требования должны давать полную модель нашего продукта, которое было раньше распространено и которое проистекает из водопадного подхода, противоречит методу разработки с непрерывным изменением требований. И вы видите, что эти критерии во многом несовместимы.
Какие критерии нам использовать в нашей работе? Для того, чтобы это понять, мы должны сориентироваться по этой системе координат, понять, где мы находимся. По какому процессу мы разрабатываем продукт, что это за вид продукта, какие требования мы разрабатываем, насколько они важны и, соответственно, применять к ним те критерии, которые соответствуют нашей ситуации.
Я понимаю, что эта часть получилась достаточно абстрактной, но в курсе мы эти критерии попробуем применить к тем требованиям, которые мы разрабатываем, и там уже более конкретно поймём, что стоит за этими словами.
Нефункциональные требования к программному обеспечению. Часть 1
Введение
Разрабатывая новую информационную систему или внедряя уже существующую, вы неизбежно сталкиваетесь с необходимостью определить нефункциональные требования к вашей системе.
Нефункциональные требования: какие они бывают
Начнем с того, что требования к программным продуктам или информационным системам можно разделить на две большие группы. Это функциональные требования (описывающие, что необходимо реализовать в продукте или системе, в т.ч. какие действия должны выполнять пользователи при взаимодействии с ними) и нефункциональные требования (описывающие, как должна работать система или программный продукт, и какими свойствами или характеристиками она должна обладать).
Как правило, говоря о нефункциональных требованиях, чаще всего говорят об атрибутах качества (т.е. требованиях, определяющих качественные характеристики разрабатываемого программного обеспечения или системы, такие как производительность, надежность, масштабируемость), не обращая внимания на другие виды нефункциональных требований, а именно:
Все эти требования должны быть определены и зафиксированы, прежде чем вы приступите к реализации вашей системы или продукта.
Нефункциональные требования: как их определять
Теперь, когда мы познакомились с различными видами нефункциональными требований, неплохо понять, что нужно делать дальше.
Нефункциональные требования: работа над определением
Как для определения функциональных, так и для определения нефункциональных требований используются рабочие группы, члены которых определяют, проверяют и утверждают требования. Для групп по определению нефункциональных требований особенно важно привлечь к этой работе не только аналитиков и пользователей, но и архитекторов и ключевых разработчиков продукта или системы, а также группу тестирования. Архитектор воспринимает нефункциональные требования как входные данные для выбора и проектирования архитектуры приложения, а группа тестирования планирует те сценарии нагрузочного тестирования, которые будут использоваться для проверки выполнения нефункциональных требований (в основном это касается атрибутов качества).
Роли, которые при этом играют участники рабочей группы по определению нефункциональных требований, описаны далее.
Пример сценария, используемого для определения требований к производительности модуля системы, рассылающего уведомления пользователям сайта по электронной почте:
1. Система получает оповещение о событии, инициирующем рассылку уведомлений.
2. Система осуществляет рассылку оповещений по адресам из списка рассылки X, используя шаблон Y. Для рассылки сообщений используется сервис Z.
3. В случае невозможности завершения рассылки, система предпринимает повторные попытку рассылки.
Требования к времени оповещения о событии, инициирующем рассылку уведомлений: система должна получать оповещение не позднее чем через XX секунд после возникновения события.
Требования к времени отправки уведомлений: все уведомления должны быть отправлены не позднее YY минут после получения оповещения о событии
Требования к повторной отправке рассылки после неудачной попытки: число повторных попыток должно быть равным 10, с интервалом в 10 мин после каждой неудачной попытки отправки.
Какие вопросы при этом нужно задавать заказчику? В сущности, только один: через сколько времени после возникновения события все пользователи сайта должны гарантированно получить уведомление.
Критерии качественных нефункциональных требований
Как к функциональным, так и к нефункциональным требованиям применяются критерии качества требований — т.е. описание тех качеств, которым должны удовлетворять качественные требования.
Качество нефункциональных требований непосредственно определяет качество разрабатываемого продукта или системы и достигается за счет итеративного процесса определения и анализа нефункциональных требований при слаженной работе всей группы, участвующей в их разработке.
Атрибуты качества
Этот раздел будет посвящен характеристикам качества продукта или системы.
Характеристики качества и модель качества ПО
Определение атрибутов качества тесно связано с выбранной для вашего продукта моделью качества. Разработкой модели качества занимается группа обеспечения качества (в которую входят тестировщики и которая ими, разумеется, не ограничивается).
В индустрии ПО есть несколько моделей качества, принятых в качестве стандарта. Эти модели были разработаны в 70-е-80-е годы прошлого века и продолжают совершенствоваться.
Характеристики качества с точки зрения влияния на архитектуру системы
Все атрибуты качества с точки зрения архитектуры системы можно разделить на две большие группы: первая группа (runtime) – это атрибуты, относящиеся ко времени работы приложения или системы; вторая группа (design time) определяет ключевые аспекты проектирования приложения или системы. Многие из этих атрибутов взаимозависимы.
Рассмотрим более подробно каждую из этих групп.
Группа runtime
Группа design time
О том, как, где, когда и откуда нужно взять конкретные значения для всех этих параметров, я расскажу в продолжении этой статьи.
Свойства требований
Свойства требований.
3. Свойства требований. 3-1
Корректность и согласованность (непротиворечивость) 3-4
Необходимость и полезность при эксплуатации. 3-5
Упорядоченность по важности и стабильности. 3-9
Наличие количественной метрики. 3-10
Каких требований не должно быть. 3-10
Литература к лекции. 3-10
Ф. Брукс в своём, теперь уже ставшим классическим, эссе[1], следующим образом охарактеризовал роль требований в разработке программного обеспечения. Строжайшее и единственное правило построения систем программного обеспечения (ПО) – решить точно, что же строить. Никакая другая часть концептуальной работы не является такой трудной, как выяснение деталей технических требований, в том числе и взаимодействие с людьми, с механизмами и с иными системами ПО. Никакая другая часть работы так не портит результат, если она выполнена плохо. Ошибки никакого другого этапа работы не исправляются так трудно (конец цитаты).
Наука извлечения и формализации качественных (иногда говорят «хороших», «правильных») требований носит во многом эмпирический характер. Однако, в практике разработки программных систем накопились определённые представления о том, какими свойствами должны обладать требования к программной системе. Это:
§ полезность при эксплуатации,
§ упорядоченность по важности и стабильности,
§ наличие количественной метрики.
Большинство из этих свойств раскрыто в первом разделе стандарта IEEE [1] и широко обсуждается в работах [3,5]. Рассмотрим указанные выше свойства подробнее.
Полнота. Как известно из теории искусственного интеллекта, неполнота – одно из фундаментальных свойств человеческого знания. При создании программных систем нам приходится иметь дело с характеристиками ещё несуществующей системы. Идея о том, что необходимо сформулировать все требования полностью, т. е. исчерпывающим образом, до начала проектирования, а тем более – реализации системы, изжила себя вместе с так называемым каскадным подходом[2] [2], который поддерживал последовательную модель реализации системы. Спиральный[3] [2] подход, на котором базируется большинство современных методологий, предусматривает поэтапное выделение и детализацию требований на всём протяжении цикла разработки системы.
Тем не менее, требование полноты предъявляется к требованиям, формулируемым к системе. Надо понимать, что данное требование – это скорее тенденция, цель, к которой нужно постараться максимально приблизиться на как можно более ранних стадиях проекта.
Требование полноты можно рассматривать в двух аспектах: полнота отдельного требования и полнота системы требований.
Полнота отдельного требования – свойство, означающее, что текст требования не требует дополнительной детализации, то есть в нём предусмотрены все необходимые нюансы, особенности и детали данного требования.
Полнота системы требований – свойство, означающее, что совокупность артефактов, описывающих требования, исчерпывающим образом описывает всё то, что требуется от разрабатываемой системы.
Ясность (недвусмысленность, определённость, однозначность спецификаций). Каждый из совладельцев[4] разрабатываемой системы обладает своим личным опытом восприятия событий внешнего мира. Слово, произнесённое вслух, вызывает индивидуальные ассоциации в семантическом пространстве каждого отдельного воспринимающего субъекта. То, что является ясным, допустим, для кардиохирурга, совсем необязательно будет таковым для специалиста в области программной инженерии.
Соответственно, требование обладает свойством ясности, если оно сходным образом воспринимается всеми совладельцами системы. На практике ясность требований достигается в том числе и в процессе консультаций, в ходе которых происходит «выравнивание тезаурусов» совладельцев системы. Хорошим подспорьем в этом служит согласованный сторонами глоссарий ключевых понятий предметной области.
К. Вигерс [3] даёт следующий совет по повышению ясности документов: «Пишите документацию просто, кратко и точно, применяя лексику, понятную пользователям».
Ещё одной стороной понятия «ясность требования» является его прослеживаемость (см. также понятие трассируемости ниже по тексту). Требование, которое сформулировано ясно, может быть прослежено, начиная от того документа, где оно сформулировано впервые, вплоть до рабочих спецификаций.
Корректность и согласованность (непротиворечивость). Корректность – одно из важнейших свойств требований. К. Вигерс в [3] вводит понятие корректности требования через точность описания функциональности. В этом смысле корректность в определённой степени конкурирует с полнотой. Но есть и различие: если свойство полноты носит скорее качественный характер: абсолютная полнота представляет недостижимый идеал, к которому можно приближаться, то свойство корректности носит оценочный характер и задаёт дихотомию: каждое из требований либо корректно, либо нет. Кроме того, можно рассуждать о взаимной корректности требований или согласованности (непротиворечивости): если два требования вступают в конфликт, значит – как минимум одно из них некорректно. В иерархии требований (см. материалы лекции 2) можно выделить вертикальную и горизонтальную согласованность. Иными словами, требования не должны противоречить, соответственно, требованиям своего уровня иерархии и требованиям «родительского» уровня. Так, требования пользователей не должны противоречить бизнес-требованиям, а функциональные требования – требованиям пользователя.
Верифицируемость (пригодность к проверке). Признаки (свойства) требований, рассматриваемые в настоящей лекции, нельзя считать независимыми. В математической статистике такие признаки называются кореллируемыми. Так, свойство верифицируемости существенно связано со свойствами ясности и полноты: если требование изложено на языке, понятном и одинаково воспринимаемым участниками процесса создания информационной системы, причём оно является полным, т. е. ни одна из важных для реализации деталей не упущена – значит, это требование можно проверить. При этом в ходе проверки у сторон (принимающей и сдающей работу) не должно возникнуть неразрешимых противоречий в оценках. Методы верификации требований будут рассмотрены в 12-Проверка требований. Так как хорошо сформулированные требования составляют основу успешного создания системы – роль верифицируемости трудно переоценить. Требования к системе представляют основу контракта между Заказчиком и Исполнителем и если данные требования нельзя проверить – значит и контракт не имеет никакого смысла, следовательно, успех или неудача проекта будут зависеть только от эмоциональных оценок сторон и их способности договориться, а это – слишком шаткая основа для осуществления работ.
Необходимость и полезность при эксплуатации. Одни из самых субъективных и трудно проверяемых свойств требований.
Возвращаясь к иерархии требований в лекции 2, наиболее бесспорными требованиями следует считать бизнес-требования. Данные требования формулируют первые лица, представляющие Заказчика, и вряд ли кто-нибудь лучше них сможет сказать, каким условиям должна соответствовать создаваемая информационная система, чтобы соответствовать бизнес-целям предприятия. Тем не менее, если у представителя Исполнителя возникают сомнения в необходимости того или иного бизнес-требования, вызванные интуитивными соображениями, либо опытом внедрения информационных систем на аналогичных предприятиях, он должен проявить инициативу и собрать совместное совещание сторон. Аргументы в пользу отсутствия необходимости требования несомненно будут восприняты, особенно если они будут мотивированы в бизнес-терминологии Заказчика и подтверждены выкладками, прогнозирующими соотношение затрат на выполнение требования и ожидаемой от него эффективности.
Необходимость требований пользователя может вытекать из соответствующих бизнес-требований. Кроме того, требования пользователя могут мотивироваться эргономичностью продукта и особенностями функционирования его отдела (подразделения), недостаточно полно раскрытыми на предыдущем уровне иерархии требований.
Большинство функциональных требований вытекают из требований первых двух уровней. Другие функциональные требования могут лежать вне сферы компетенции Заказчика (который, вообще говоря, не обязан быть экспертом в области IT) и их должен сформулировать Исполнитель. Так, например, информационная система в процессе её использования может начать снижать свою производительность из-за больших объёмов накапливаемых данных. Поэтому целесообразно заложить функции архивирования информации, переключения учётных периодов и т. п., необходимость которых следует не из особенностей бизнеса предприятия внедрения, а из общих принципов построения информационных систем.
Более слабой, чем «необходимость» формулировкой обладает свойство «полезность при эксплуатации». Разграничение между данными свойствами можно провести следующим образом. Необходимыми следует считать свойства, без выполнения которых невозможно, либо затруднено выполнение автоматизированных бизнес-функций пользователей; полезными при эксплуатации следует считать любые свойства, повышающие эргономические качества продукта.
Осуществимость (выполнимость). Является в некоторой степени конкурирующим по введённым выше двум свойствам.
В принципе никто не мешает сформулировать требование, выполнимость которого ограничивается сегодняшним уровнем развития техники и технологии, хотя многое из того, что было невыполнимо десять лет назад, вполне выполнимо сегодня. Можно сформулировать требование, выполнимость которого ограничена научными представлениями о строении Вселенной, например – требование мгновенной передачи информации с земной станции на Марс, хотя и фундаментальные представления иногда меняются, пусть и не так быстро, как развитие IT-технологий.
Возвращаясь с небес на землю, отринем те требования, которые можно признать абсурдными и остановимся на тех, которые выполнимы принципиально. С точки зрения науки управления требованиями, далеко не все из них являются осуществимыми.
Отличной иллюстрацией балансировки между ценностью и выполнимостью требований является так называемый треугольник компромиссов.
В качестве пояснения к рисунку приведём цитату из «белых страниц», размещённых Microsoft в открытом доступе [4]. Хорошо известна взаимозависимость между ресурсами проекта (людскими и финансовыми), его календарным графиком (временем) и реализуемыми возможностями (рамками). Эти три переменные образуют треугольник, показанный на рис. 3-1. После достижения равновесия в этом треугольнике изменение на любой из его сторон для поддержания баланса требует модификаций на другой (двух других) сторонах и/или на изначально измененной стороне.
Необходимо обеспечить возможность переработки требований, если понадобится, и поддерживать историю изменений для каждого положения. Для этого все они должны быть уникально помечены и обозначены, чтобы вы могли ссылаться на них однозначно. Каждое требование должно быть записано в спецификации только единожды. Иначе вы легко получите несогласованность, изменив только одно положение из двух одинаковых. Лучше используйте ссылки на первоначальные утверждения, а не дублируйте положения. Модификация спецификации станет гораздо легче, если вы составите содержание документа и указатель. Сохранение спецификации в базе данных коммерческого инструмента управления требованиями сделает их пригодными для повторного использования (конец цитаты).
Трассируемость. Трассируемость требования определяется возможностью отследить связь между ним и другими артефактами информационной системы (документами, моделями, текстами программ и пр.). Отдельная траса представляет собой направленное бинарное отношение, заданное на множестве артефактов ИС, где первый элемент отношения представляет соответствующее требование, а второй – артефакт, зависимый от данного требования. На практике трассировки анализируются при посредстве графовых, либо табличных моделей.
Процесс трассировки позволяет, с одной стороны, выявить уже на стадии проектирования системы проектные артефакты, к которым не ведёт связь ни от одного из артефактов, описывающих требования, с другой – артефакты, описывающие требования, не связанные с проектными артефактами. В первом из случаев целесообразно убедиться в том, что проектный артефакт действительно имеет право на существование, а не является избыточным. Во втором случае необходимо проанализировать полезность выявленных требований: либо эти требования несут недостаточную полезную нагрузку и могут быть игнорированы, либо имеют место ошибки проектирования: пропущены соответствующие артефакты.
Другая цель трассировки – повысить управляемость проектом: при изменении отдельно взятого требования становится понятно – какие из проектных, рабочих и других артефактов подлежат изменению (см. также материалы лекции 13-Введение в управление требованиями. doc).
Упорядоченность по важности и стабильности. Приоритет требования представляет собой количественную оценку степени значимости (важности) требования. Приоритеты требований обычно назначает представитель Заказчика. Разработчик, отталкиваясь от приоритетности требований, управляет процессом реализации информационной системы.
Стабильность требования характеризует прогнозную оценку неизменности требований во времени.
Наличие количественной метрики. Количественные метрики играют важную роль в верификации и аттестации информационных систем. В первую очередь это относится к нефункциональным требованиям, которые, как правило, должны иметь под собой количественную основу (запрос должен отрабатываться не более, чем ___ секунд; средняя наработка на отказ должна составлять не менее, чем ___ часов). Функциональные требования также могут расширяться количественными мерами при помощи так называемых аспектов применимости (см. материал лекции 10-Прототипирование требований).
Каких требований не должно быть
Согласно [5], спецификация требований не должна содержать деталей проектирования или реализации (кроме известных ограничений). Иными словами, требования должны отвечать на вопрос: «что должна делать система», абстрагируясь от вопроса «как она это должна делать». Стремление принимать детальные проектные решения на этапе анализа требований – одно из типичных «ловушек», типичных для неопытных команд разработчиков. Вариантов реализации всегда больше, чем один, а для принятия взвешенного решения нужна максимально более полная информация. Поэтому этапы работы с требованиями, проектирования и реализации планируются поочерёдно, хотя и могут быть частично запараллелены в рамках итерационного подхода к созданию программных систем (см. 15-Требования в управлении проектом).
Литература к лекции
1. IEEE Standard 830-1998, «IEEE Recommended Practice for Software Requirements Specifications»
3. требований к программному обеспечению/Пер, с англ. — М.:Издательско-торговый дом «Русская Редакция», 2004. —576с.: ил.
4. Microsoft Solutions Framework. Модель процессов MSF, версия 3.1
http://www. /Rus/Download. aspx? file=/Msdn/Msf/MSF_process_model_rus. doc
5. Принципы работы с требованиями к программному обеспечению. М.: ИД “Вильямс”, 2002.
[1] Brooks, Frederick P. Jr. 1987. No Silver Bullet: Essence and Accidents of Software Engineering. С River, NJ: Prentice Hall PTR.
[2] Royce, Walker W. Managing the development of large software systems: concepts and techniques. Proc. IEEE WESTCON, Los Angeles, August 1970, pp. 1-9
[3] Boehm, B. W. A spiral model of software development and enhancement. IEEE Computer, 21 (5), 1988, pp. 61-72.
[4] Терминология RUP, см. материалы лекции 04-Процесс анализа требований