Какими свойствами обладают требования к
Аннотация: В практике разработки программных систем накопились определенные представления о том, какими свойствами должны обладать требования к программной системе. В этой лекции мы рассмотрим подробнее данные свойства
Ф. Брукс в своем, теперь уже ставшим классическим, эссе1, следующим образом охарактеризовал роль требований в разработке программного обеспечения.
Строжайшее и единственное правило построения систем программного обеспечения (ПО) — решить точно, что же строить. Никакая другая часть концептуальной работы не является такой трудной, как выяснение деталей технических требований, в том числе и взаимодействие с людьми, с механизмами и с иными системами ПО. Никакая другая часть работы так не портит результат, если она выполнена плохо. Ошибки никакого другого этапа работы не исправляются так трудно.
Наука извлечения и формализации качественных (иногда говорят «хороших», «правильных») требований носит во многом эмпирический характер. Однако, в практике разработки программных систем накопились определенные представления о том, какими свойствами должны обладать требования к программной системе. Это:
- полнота,
- ясность,
- корректность,
- согласованность,
- верифицируемость,
- необходимость,
- полезность при эксплуатации,
- осуществимость,
- модифицируемость,
- трассируемость,
- упорядоченность по важности и стабильности,
- наличие количественной метрики.
Большинство из этих свойств раскрыто в первом разделе стандарта IEEE [3.1] и широко обсуждается в работах [3.3,3.5]. Рассмотрим указанные выше свойства подробнее.
Полнота.
Как известно из теории искусственного интеллекта, неполнота — одно из фундаментальных свойств человеческого знания. При создании программных систем нам приходится иметь дело с характеристиками еще несуществующей системы. Идея о том, что необходимо сформулировать все требования полностью, т.е. исчерпывающим образом, до начала проектирования, а тем более — реализации системы, изжила себя вместе с так называемым каскадным подходом2[3.2], который поддерживал последовательную модель реализации системы. Спиральный3[3.2] подход, на котором базируется большинство современных методологий, предусматривает поэтапное выделение и детализацию требований на всем протяжении цикла разработки системы.
Тем не менее, требование полноты предъявляется к требованиям, формулируемым к системе. Надо понимать, что данное требование — это скорее тенденция, цель, к которой нужно постараться максимально приблизиться на как можно более ранних стадиях проекта.
Требование полноты можно рассматривать в двух аспектах: полнота отдельного требования и полнота системы требований.
Полнота отдельного требования — свойство, означающее, что текст требования не требует дополнительной детализации, то есть в нем предусмотрены все необходимые нюансы, особенности и детали данного требования.
Полнота системы требований — свойство, означающее, что совокупность артефактов, описывающих требования, исчерпывающим образом описывает все то, что требуется от разрабатываемой системы.
Ясность (недвусмысленность, определенность, однозначность спецификаций).
Каждый из совладельцев4 разрабатываемой системы обладает своим личным опытом восприятия событий внешнего мира. Слово, произнесенное вслух, вызывает индивидуальные ассоциации в семантическом пространстве каждого отдельного воспринимающего субъекта. То, что является ясным, допустим, для кардиохирурга, совсем необязательно будет таковым для специалиста в области программной инженерии.
Соответственно, требование обладает свойством ясности, если оно сходным образом воспринимается всеми совладельцами системы. На практике ясность требований достигается в том числе и в процессе консультаций, в ходе которых происходит «выравнивание тезаурусов» совладельцев системы. Хорошим подспорьем в этом служит согласованный сторонами глоссарий ключевых понятий предметной области.
К.Вигерс [3.3] дает следующий совет по повышению ясности документов: «Пишите документацию просто, кратко и точно, применяя лексику, понятную пользователям».
Еще одной стороной понятия «ясность требования» является его прослеживаемость (см. также понятие трассируемости ниже по тексту). Требование, которое сформулировано ясно, может быть прослежено, начиная от того документа, где оно сформулировано впервые, вплоть до рабочих спецификаций.
Корректность и согласованность (непротиворечивость).
Корректность — одно из важнейших свойств требований. К. Вигерс в [3.3] вводит понятие корректности требования через точность описания функциональности. В этом смысле корректность в определенной степени конкурирует с полнотой. Но есть и различие: если свойство полноты носит скорее качественный характер: абсолютная полнота представляет недостижимый идеал, к которому можно приближаться, то свойство корректности носит оценочный характер и задает дихотомию: каждое из требований либо корректно, либо нет. Кроме того, можно рассуждать о взаимной корректности требований или согласованности (непротиворечивости): если два требования вступают в конфликт, значит — как минимум одно из них некорректно. В иерархии требований (см. материалы
«Понятие требования. Классификации требований»
) можно выделить вертикальную и горизонтальную согласованность. Иными словами, требования не должны противоречить, соответственно, требованиям своего уровня иерархии и требованиям «родительского» уровня. Так, требования пользователей не должны противоречить бизнес-требованиям, а функциональные требования — требованиям пользователя.
Верифицируемость (пригодность к проверке).
Признаки (свойства) требований, рассматриваемые в настоящей лекции, нельзя считать независимыми. В математической статистике такие признаки называются коррелируемыми. Так, свойство верифицируемости существенно связано со свойствами ясности и полноты: если требование изложено на языке, понятном и одинаково воспринимаемом участниками процесса создания информационной системы, причем оно является полным, т.е. ни одна из важных для реализации деталей не упущена — значит, это требование можно проверить. При этом в ходе проверки у сторон (принимающей и сдающей работу) не должно возникнуть неразрешимых противоречий в оценках. Методы верификации требований будут рассмотрены в
«Проверка требований»
. Так как хорошо сформулированные требования составляют основу успешного создания системы — роль верифицируемости трудно переоценить. Требования к системе представляют основу контракта между Заказчиком и Исполнителем и если данные требования нельзя проверить — значит и контракт не имеет никакого смысла, следовательно, успех или неудача проекта будут зависеть только от эмоциональных оценок сторон и их способности договориться, а это — слишком шаткая основа для осуществления работ.
Аннотация: В практике разработки программных систем накопились определенные представления о том, какими свойствами должны обладать требования к программной системе. В этой лекции мы рассмотрим подробнее данные свойства
Ф. Брукс в своем, теперь уже ставшим классическим, эссе1, следующим образом охарактеризовал роль требований в разработке программного обеспечения.
Строжайшее и единственное правило построения систем программного обеспечения (ПО) — решить точно, что же строить. Никакая другая часть концептуальной работы не является такой трудной, как выяснение деталей технических требований, в том числе и взаимодействие с людьми, с механизмами и с иными системами ПО. Никакая другая часть работы так не портит результат, если она выполнена плохо. Ошибки никакого другого этапа работы не исправляются так трудно.
Наука извлечения и формализации качественных (иногда говорят «хороших», «правильных») требований носит во многом эмпирический характер. Однако, в практике разработки программных систем накопились определенные представления о том, какими свойствами должны обладать требования к программной системе. Это:
- полнота,
- ясность,
- корректность,
- согласованность,
- верифицируемость,
- необходимость,
- полезность при эксплуатации,
- осуществимость,
- модифицируемость,
- трассируемость,
- упорядоченность по важности и стабильности,
- наличие количественной метрики.
Большинство из этих свойств раскрыто в первом разделе стандарта IEEE [3.1] и широко обсуждается в работах [3.3,3.5]. Рассмотрим указанные выше свойства подробнее.
Полнота.
Как известно из теории искусственного интеллекта, неполнота — одно из фундаментальных свойств человеческого знания. При создании программных систем нам приходится иметь дело с характеристиками еще несуществующей системы. Идея о том, что необходимо сформулировать все требования полностью, т.е. исчерпывающим образом, до начала проектирования, а тем более — реализации системы, изжила себя вместе с так называемым каскадным подходом2[3.2], который поддерживал последовательную модель реализации системы. Спиральный3[3.2] подход, на котором базируется большинство современных методологий, предусматривает поэтапное выделение и детализацию требований на всем протяжении цикла разработки системы.
Тем не менее, требование полноты предъявляется к требованиям, формулируемым к системе. Надо понимать, что данное требование — это скорее тенденция, цель, к которой нужно постараться максимально приблизиться на как можно более ранних стадиях проекта.
Требование полноты можно рассматривать в двух аспектах: полнота отдельного требования и полнота системы требований.
Полнота отдельного требования — свойство, означающее, что текст требования не требует дополнительной детализации, то есть в нем предусмотрены все необходимые нюансы, особенности и детали данного требования.
Полнота системы требований — свойство, означающее, что совокупность артефактов, описывающих требования, исчерпывающим образом описывает все то, что требуется от разрабатываемой системы.
Ясность (недвусмысленность, определенность, однозначность спецификаций).
Каждый из совладельцев4 разрабатываемой системы обладает своим личным опытом восприятия событий внешнего мира. Слово, произнесенное вслух, вызывает индивидуальные ассоциации в семантическом пространстве каждого отдельного воспринимающего субъекта. То, что является ясным, допустим, для кардиохирурга, совсем необязательно будет таковым для специалиста в области программной инженерии.
Соответственно, требование обладает свойством ясности, если оно сходным образом воспринимается всеми совладельцами системы. На практике ясность требований достигается в том числе и в процессе консультаций, в ходе которых происходит «выравнивание тезаурусов» совладельцев системы. Хорошим подспорьем в этом служит согласованный сторонами глоссарий ключевых понятий предметной области.
К.Вигерс [3.3] дает следующий совет по повышению ясности документов: «Пишите документацию просто, кратко и точно, применяя лексику, понятную пользователям».
Еще одной стороной понятия «ясность требования» является его прослеживаемость (см. также понятие трассируемости ниже по тексту). Требование, которое сформулировано ясно, может быть прослежено, начиная от того документа, где оно сформулировано впервые, вплоть до рабочих спецификаций.
Корректность и согласованность (непротиворечивость).
Корректность — одно из важнейших свойств требований. К. Вигерс в [3.3] вводит понятие корректности требования через точность описания функциональности. В этом смысле корректность в определенной степени конкурирует с полнотой. Но есть и различие: если свойство полноты носит скорее качественный характер: абсолютная полнота представляет недостижимый идеал, к которому можно приближаться, то свойство корректности носит оценочный характер и задает дихотомию: каждое из требований либо корректно, либо нет. Кроме того, можно рассуждать о взаимной корректности требований или согласованности (непротиворечивости): если два требования вступают в конфликт, значит — как минимум одно из них некорректно. В иерархии требований (см. материалы
«Понятие требования. Классификации требований»
) можно выделить вертикальную и горизонтальную согласованность. Иными словами, требования не должны противоречить, соответственно, требованиям своего уровня иерархии и требованиям «родительского» уровня. Так, требования пользователей не должны противоречить бизнес-требованиям, а функциональные требования — требованиям пользователя.
Верифицируемость (пригодность к проверке).
Признаки (свойства) требований, рассматриваемые в настоящей лекции, нельзя считать независимыми. В математической статистике такие признаки называются коррелируемыми. Так, свойство верифицируемости существенно связано со свойствами ясности и полноты: если требование изложено на языке, понятном и одинаково воспринимаемом участниками процесса создания информационной системы, причем оно является полным, т.е. ни одна из важных для реализации деталей не упущена — значит, это требование можно проверить. При этом в ходе проверки у сторон (принимающей и сдающей работу) не должно возникнуть неразрешимых противоречий в оценках. Методы верификации требований будут рассмотрены в
«Проверка требований»
. Так как хорошо сформулированные требования составляют основу успешного создания системы — роль верифицируемости трудно переоценить. Требования к системе представляют основу контракта между Заказчиком и Исполнителем и если данные требования нельзя проверить — значит и контракт не имеет никакого смысла, следовательно, успех или неудача проекта будут зависеть только от эмоциональных оценок сторон и их способности договориться, а это — слишком шаткая основа для осуществления работ.
Продолжение серии статей о требованиях. Часть 2.
Требования должны обладать следующими характеристиками:
1. Единичность. Это означает, что требование относится только к одному свойству. Например, система должна выполнять такое-то действие. Пример хорошего требования: система должна позволять регистрацию пользователей. Пример плохого требования: система должна позволять авторизацию пользователей по данным социальных сетей и запрашивать из социальных сетей и публиковать на стене пользователя в социальной сети определенную информацию. Почему это требование некорректное — не указаны социальные сети, а далеко не все разрешают сторонним приложения размещать информацию на стене пользователя, а, во-вторых, тут объединены два требования.
2. Атомарность. Атомарность означает, что требования дальше нельзя разбить или уточнить. Например, пользователь может авторизоваться с помощью <конкретный список социальных сетей>. Плохое требование: пользователь может выбрать статью для чтения и прокомментировать ее. Это два требования, которые надо разбивать и конкретизировать дальше.
3. Завершённость. Требование целиком приведено в одном месте документации. Не должно быть такого, чтобы в разных частях документа с требованиями шла речь об одном и том же функционале.
4. Последовательность. Требование не должно противоречить другим требованиям и ограничениям системы. Пример плохого требования: система должна запрашивать из социальных сетей адрес электронной почты пользователя. Дело в том, что социальные сети не дают такой информации. Если требуется адрес электронной почты пользователя, то он должен быть запрошен от самого пользователя, а не от внешних источников.
5. Отслеживаемость (Трассируемость). Это означает, что требования зафиксировано в документации и можно понять откуда оно взялось. Например, требование подтверждения возраста это требование этического комитета заказчика.
6. Актуальность. Это означает, что требование не устарело. Например, требование должно соответствовать современному законодательству. Или техническим реалиям. Вряд ли сейчас найдется много пользователей IE5 и Netscape Navigator.
7. Выполнимость. Требование можно выполнить в рамках существующих технологий. Например, можно требовать, чтобы система давала отклик при маленькой нагрузке ( что такое маленькая нагрузка тоже надо конкретизировать) в течение не более 3-х секунд, но нельзя требовать 1 миллисекунду при больших нагрузках.
8. Понятность. Это означает, что нельзя использовать жаргон, фраза должна пониматься всеми одинаково. Т.е. фраза «казнить нельзя помиловать» не должна использоваться.
9. Проверяемость. Это означает, что выполнение требования можно проверить. Пример плохого требования: система должна работать быстро. Или сайт должен иметь понятную систему навигации. Или должен использовать интуитивно-понятный интерфейс. Кстати, на будущее, я напишу отдельную статью по поводу того, что не бывает интуитивного-понятного интерфейса.
10. Обязательность. Без выполнения этого требования пользователь не сможет в полной мере использовать систему. Не самое простое условие к требованию, между прочим. Например, рассмотрим интернет-магазин. Обычно, требования расписываются с точки зрения пользователя: посмотреть описание товара, выбрать товар, оформить заказ и прочее. Но в данном случае необходимым требованиями будут возможность добавления нового товара на витрину и удаление с витрины товара, которого нет в наличии.
11. Полнота. Самое сложное требование. Полнота системы требований – свойство, означающее, что совокупность артефактов, описывающих требования, исчерпывающим образом описывает все то, что требуется от разрабатываемой системы. Иначе говоря, надо зафиксировать все, что система должна делать. Если на начальном этапе это не указать, то можно сильно ошибиться при проектировании и выборе архитектуры. При этом, надо понимать, что очень трудно сразу указать для системы, которую еще только надо спроектировать, весь функционал. Поэтому, часто на первых этапах указывают требования крупными мазками, а не в терминах функциональных требований.
При фиксации требований очень важно не делать такую ошибку, как формулировать требования в виде «как система должна работать». Надо использовать подход «что система должна делать». Пример плохих требований: Пользователь нажимает красную кнопку в углу формы и переходит на следующий этап выбора товара в интернет-магазине. Пример хорошего требования: при выборе определенного товара пользователю предлагается перейти в корзину для оформления заказа или продолжить просмотр каталога. Дело в том, что вариантов реализации может быть множество и не надо заранее себя ограничивать. Более того, очень важно избегать субъективного подхода. Если что-то удобно именно вам, это не означает, что удобно всем.
Характеристики качества превосходных требований:
— Полнота Каждое требование должно полно описывать функциональность, которую следует реализовать в продукте. То есть оно должно содержать всю информацию, необходимую для разработчиков, чтобы тем удалось создать этот фрагмент функциональности. Если вы понимаете, что данных определенного рода не хватает, используйте пометку «TBD» (to be determined — необходимо определить) на полях как стан-
дартный флаг для выделения такого места. Восполните все пробелы в каждом фрагменте требований, прежде чем приступать к конструированию этой функции.
— Корректность Каждое требование должно точно описывать желаемую функциональность. Для соблюдения корректности необходима связь с источниками требований, например с пожеланиями пользователей или высокоуровневыми системными. Требования к ПО, которые конфликтуют с родительскими требованиями, нельзя считать корректными. Однако основная оценка здесь— за представителями пользователей, вот почему им или их непосредственным заместителям необходимо предоставлять требования для просмотра.
— Осуществимость Необходима возможность реализовать каждое требование при известных условиях и ограничениях системы и операционной среды. Чтобы не придумывать недостижимые положения, обеспечьте взаимодействие разработчиков с маркетологами и аналитиками требований на период всего извлечения требований. Разработчики реально оценят, что можно выполнить технически, а что нет, или что сделать можно, но при дополнительном финансировании. Инкрементальная разработка и подтверждающие концепцию прототипы позволяют проверить осуществимость требования.
— Необходимость Каждое требование должно отражать возможность, которая действительно необходима пользователям или которая нужна для соответствия внешним системным требованиям или стандартам. Кроме того, оно должно исходить от лица, которое имеет полномочия на запись положения. Отследите каждое требование вплоть до стадии сбора мнений пользователей, когда выявлялись варианты использования,
бизнес-правила или другие источники.
— Назначение приоритетов Назначьте приоритеты каждому функциональному требованию, характеристике или варианту использования, чтобы определить, что необходимо для каждой версии продукта. Если все положения одинаково важны, менеджеру проекта будет трудно справиться с уменьшением бюджета, нарушением сроков, потерей персонала или добавлением новых требований в процессе разработки,
Дополнительная информация В главе 14 назначение приоритетов обсуждается в деталях.
— Однозначность Все читатели требований должны интерпретировать их одинаково, но естественный язык зачастую грешит многозначностью. Пишите документацию просто, кратко и точно, применяя лексику, понятную пользователям. «Ясность»— цель качества требований, связанная с точностью: читатели должны четко понимать каждое положение. Занесите все специальные и запутанные термины в словарь.
— Проверяемость Попробуйте разработать несколько тестов или примените другие приемы для проверки, например экспертизу или демонстрации, чтобы установить, действительно ли в продукте реализовано каждое требование. Если требование не проверяется, вопрос его корректной реализации становится предметом заключения, а не целью анализа. Неполные, несогласованные, невыполнимые или двусмысленные требования также не проверяются.