Какими свойствами обладают требования к
Аннотация: В практике разработки программных систем накопились определенные представления о том, какими свойствами должны обладать требования к программной системе. В этой лекции мы рассмотрим подробнее данные свойства
Ф. Брукс в своем, теперь уже ставшим классическим, эссе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. Полнота. Самое сложное требование. Полнота системы требований – свойство, означающее, что совокупность артефактов, описывающих требования, исчерпывающим образом описывает все то, что требуется от разрабатываемой системы. Иначе говоря, надо зафиксировать все, что система должна делать. Если на начальном этапе это не указать, то можно сильно ошибиться при проектировании и выборе архитектуры. При этом, надо понимать, что очень трудно сразу указать для системы, которую еще только надо спроектировать, весь функционал. Поэтому, часто на первых этапах указывают требования крупными мазками, а не в терминах функциональных требований.
При фиксации требований очень важно не делать такую ошибку, как формулировать требования в виде “как система должна работать”. Надо использовать подход “что система должна делать”. Пример плохих требований: Пользователь нажимает красную кнопку в углу формы и переходит на следующий этап выбора товара в интернет-магазине. Пример хорошего требования: при выборе определенного товара пользователю предлагается перейти в корзину для оформления заказа или продолжить просмотр каталога. Дело в том, что вариантов реализации может быть множество и не надо заранее себя ограничивать. Более того, очень важно избегать субъективного подхода. Если что-то удобно именно вам, это не означает, что удобно всем.
Источник
Аннотация: В практике разработки программных систем накопились определенные представления о том, какими свойствами должны обладать требования к программной системе. В этой лекции мы рассмотрим подробнее данные свойства
Ф. Брукс в своем, теперь уже ставшим классическим, эссе1, следующим образом охарактеризовал роль требований в разработке программного обеспечения.
Строжайшее и единственное правило построения систем программного обеспечения (ПО) – решить точно, что же строить. Никакая другая часть концептуальной работы не является такой трудной, как выяснение деталей технических требований, в том числе и взаимодействие с людьми, с механизмами и с иными системами ПО. Никакая другая часть работы так не портит результат, если она выполнена плохо. Ошибки никакого другого этапа работы не исправляются так трудно.
Наука извлечения и формализации качественных (иногда говорят “хороших”, “правильных”) требований носит во многом эмпирический характер. Однако, в практике разработки программных систем накопились определенные представления о том, какими свойствами должны обладать требования к программной системе. Это:
- полнота,
- ясность,
- корректность,
- согласованность,
- верифицируемость,
- необходимость,
- полезность при эксплуатации,
- осуществимость,
- модифицируемость,
- трассируемость,
- упорядоченность по важности и стабильности,
- наличие количественной метрики.
Большинство из этих свойств раскрыто в первом разделе стандарта IEEE [3.1] и широко обсуждается в работах [3.3,3.5]. Рассмотрим указанные выше свойства подробнее.
Полнота.
Как известно из теории искусственного интеллекта, неполнота – одно из фундаментальных свойств человеческого знания. При создании программных систем нам приходится иметь дело с характеристиками еще несуществующей системы. Идея о том, что необходимо сформулировать все требования полностью, т.е. исчерпывающим образом, до начала проектирования, а тем более – реализации системы, изжила себя вместе с так называемым каскадным подходом2[3.2], который поддерживал последовательную модель реализации системы. Спиральный3[3.2] подход, на котором базируется большинство современных методологий, предусматривает поэтапное выделение и детализацию требований на всем протяжении цикла разработки системы.
Тем не менее, требование полноты предъявляется к требованиям, формулируемым к системе. Надо понимать, что данное требование – это скорее тенденция, цель, к которой нужно постараться максимально приблизиться на как можно более ранних стадиях проекта.
Требование полноты можно рассматривать в двух аспектах: полнота отдельного требования и полнота системы требований.
Полнота отдельного требования – свойство, означающее, что текст требования не требует дополнительной детализации, то есть в нем предусмотрены все необходимые нюансы, особенности и детали данного требования.
Полнота системы требований – свойство, означающее, что совокупность артефактов, описывающих требования, исчерпывающим образом описывает все то, что требуется от разрабатываемой системы.
Ясность (недвусмысленность, определенность, однозначность спецификаций).
Каждый из совладельцев4 разрабатываемой системы обладает своим личным опытом восприятия событий внешнего мира. Слово, произнесенное вслух, вызывает индивидуальные ассоциации в семантическом пространстве каждого отдельного воспринимающего субъекта. То, что является ясным, допустим, для кардиохирурга, совсем необязательно будет таковым для специалиста в области программной инженерии.
Соответственно, требование обладает свойством ясности, если оно сходным образом воспринимается всеми совладельцами системы. На практике ясность требований достигается в том числе и в процессе консультаций, в ходе которых происходит “выравнивание тезаурусов” совладельцев системы. Хорошим подспорьем в этом служит согласованный сторонами глоссарий ключевых понятий предметной области.
К.Вигерс [3.3] дает следующий совет по повышению ясности документов: “Пишите документацию просто, кратко и точно, применяя лексику, понятную пользователям”.
Еще одной стороной понятия “ясность требования” является его прослеживаемость (см. также понятие трассируемости ниже по тексту). Требование, которое сформулировано ясно, может быть прослежено, начиная от того документа, где оно сформулировано впервые, вплоть до рабочих спецификаций.
Корректность и согласованность (непротиворечивость).
Корректность – одно из важнейших свойств требований. К. Вигерс в [3.3] вводит понятие корректности требования через точность описания функциональности. В этом смысле корректность в определенной степени конкурирует с полнотой. Но есть и различие: если свойство полноты носит скорее качественный характер: абсолютная полнота представляет недостижимый идеал, к которому можно приближаться, то свойство корректности носит оценочный характер и задает дихотомию: каждое из требований либо корректно, либо нет. Кроме того, можно рассуждать о взаимной корректности требований или согласованности (непротиворечивости): если два требования вступают в конфликт, значит – как минимум одно из них некорректно. В иерархии требований (см. материалы
“Понятие требования. Классификации требований”
) можно выделить вертикальную и горизонтальную согласованность. Иными словами, требования не должны противоречить, соответственно, требованиям своего уровня иерархии и требованиям “родительского” уровня. Так, требования пользователей не должны противоречить бизнес-требованиям, а функциональные требования – требованиям пользователя.
Верифицируемость (пригодность к проверке).
Признаки (свойства) требований, рассматриваемые в настоящей лекции, нельзя считать независимыми. В математической статистике такие признаки называются коррелируемыми. Так, свойство верифицируемости существенно связано со свойствами ясности и полноты: если требование изложено на языке, понятном и одинаково воспринимаемом участниками процесса создания информационной системы, причем оно является полным, т.е. ни одна из важных для реализации деталей не упущена – значит, это требование можно проверить. При этом в ходе проверки у сторон (принимающей и сдающей работу) не должно возникнуть неразрешимых противоречий в оценках. Методы верификации требований будут рассмотрены в
“Проверка требований”
. Так как хорошо сформулированные требования составляют основу успешного создания системы – роль верифицируемости трудно переоценить. Требования к системе представляют основу контракта между Заказчиком и Исполнителем и если данные требования нельзя проверить – значит и контракт не имеет никакого смысла, следовательно, успех или неудача проекта будут зависеть только от эмоциональных оценок сторон и их способности договориться, а это – слишком шаткая основа для осуществления работ.
Источник