Форум Сообщества Аналитиков

×


FAQ - Требования(Прочитано 61460 раз)
FAQ - Требования : 17 Июля 2007, 13:57:15
Последние обновления этого раздела см. здесь: http://www.uml2.ru/index.php?option=com_content&task=category&sectionid=3&id=29&Itemid=53


1. Что такое требования?
IEEE Standard Glossary of Software Engineering Terminology определяет требования как:
1. условия или возможности, необходимые пользователю для решения проблем или достижения целей;
2. условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам
3. документированное представление условий или возможностей для п. 1 и 2

2. Какие бывают требования?
Требования к ПО состоят из трех уровней — бизнес-требования, требования пользователей и функциональные требования. Вдобавок каждая система имеет свои нефункциональные требования. Модель на рис. ниже иллюстрирует способ представления этих типов требований.
- Бизнес-требования (business requirements) содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга. В этом документе объясняется, почему организации нужна такая система, то есть описаны цели, которые организация намерена достичь с ее помощью. Мне нравится записывать бизнес-требования в форме документа об образе и границах проекта, который еще иногда называют уставом проекта (project charter) или документом рыночных требований (market requirements document). Определение границ проекта представляет собой первый этап управление общими проблемами увеличения объема работ.
- Требования пользователей (user requirements) описывают цели и задачи, которые пользователям даст система. К отличным способам представления этого вида требований относятся варианты использования, сценарии и таблицы «событие — отклик». Таким образом, в этом документе указано, что клиенты смогут делать с помощью системы.
- Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».
Функциональные требования документируются в спецификации требований к ПО (software requirements specification, SRS), где описывается так полно, как необходимо, ожидаемое поведение системы.
- Системные требования (system requirements) - это высокоуровневые требования к продукту, которые содержат многие подсистемы. Говоря о системе, мы подразумеваем программное обеспечение или подсистемы ПО и оборудования. Люди — часть системы, поэтому определенные функции системы могут распространяться и на людей.
- Бизнес-правила (business rules) включают корпоративные политики, правительственные постановления, промышленные стандарты и вычислительные алгоритмы. Бизнес-правила не являются требованиями к ПО, потому что они находятся снаружи границ любой системы ПО. Однако они часто налагают ограничения, определяя, кто может выполнять конкретные ВИ, или диктовать, какими функциями должна обладать система, подчиняющаяся соответствующим правилам. Иногда бизнес-правила становятся источником атрибутов качества, которые реализуются в функциональности. Следовательно, вы можете отследить происхождение конкретных функциональных требований вплоть до соответствующих им бизнес-правил.
- Нефункциональные требования описывают цели и атрибуты качества. Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся:
* легкость и простота использования
* легкость перемещения
* целостность
* эффективность и устойчивость к сбоям
* внешние взаимодействия между системой и внешним миром
* ограничения дизайна и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта
- Характеристика продукта (feature) — это набор логически связанных функциональных требований, которые обеспечивают возможности пользователя и удовлетворяют бизнес-цели. В области коммерческого ПО характеристика представляет собой узнаваемую всеми заинтересованными лицами группу требований, которые важны при принятии решения о покупке — элемент маркированного списка в описании продукта.

3. Каких требований не должно быть?
Спецификация требований не содержит деталей дизайна или реализации (кроме известных ограничений), данных о планировании проекта или сведений о тестировании. Для проекта, как правило, создаются требования других типов: документ, где описана среда разработки, ограничения бюджета, руководство
пользователя или требования для выпуска продукта и продвижения его в поддерживаемую среду. Все это относится к требованиям к проекту, но не к продукту.

4. Какими характеристиками должны обладать хорошие требования?
Характеристики качества превосходных требований:
- Полнота Каждое требование должно полно описывать функциональность, которую следует реализовать в продукте. То есть оно должно содержать всю информацию, необходимую для разработчиков, чтобы тем удалось создать этот фрагмент функциональности. Если вы понимаете, что данных определенного рода не хватает, используйте пометку «TBD» (to be determined — необходимо определить) на полях как стан-
дартный флаг для выделения такого места. Восполните все пробелы в каждом фрагменте требований, прежде чем приступать к конструированию этой функции.
- Корректность Каждое требование должно точно описывать желаемую функциональность. Для соблюдения корректности необходима связь с источниками требований, например с пожеланиями пользователей или высокоуровневыми системными. Требования к ПО, которые конфликтуют с родительскими требованиями, нельзя считать корректными. Однако основная оценка здесь— за представителями пользователей, вот почему им или их непосредственным заместителям необходимо предоставлять требования для просмотра.
- Осуществимость Необходима возможность реализовать каждое требование при известных условиях и ограничениях системы и операционной среды. Чтобы не придумывать недостижимые положения, обеспечьте взаимодействие разработчиков с маркетологами и аналитиками требований на период всего извлечения требований. Разработчики реально оценят, что можно выполнить технически, а что нет, или что сделать можно, но при дополнительном финансировании. Инкрементальная разработка и подтверждающие концепцию прототипы позволяют проверить осуществимость требования.
- Необходимость Каждое требование должно отражать возможность, которая действительно необходима пользователям или которая нужна для соответствия внешним системным требованиям или стандартам. Кроме того, оно должно исходить от лица, которое имеет полномочия на запись положения. Отследите каждое требование вплоть до стадии сбора мнений пользователей, когда выявлялись варианты использовании,
бизнес-правила или другие источники.
- Назначение приоритетов Назначьте приоритеты каждому функциональному требованию, характеристике или варианту использования, чтобы определить, что необходимо для каждой версии продукта. Если все положения одинаково важны, менеджеру проекта будет трудно справиться с уменьшением бюджета, нарушением сроков, потерей персонала или добавлением новых требований в процессе разработки,
Дополнительная информация В главе 14 назначение приоритетов обсуждается в деталях.
- Однозначность Все читатели требований должны интерпретировать их одинаково, но естественный язык зачастую грешит многозначностью. Пишите документацию просто, кратко и точно, применяя лексику, понятную пользователям. «Ясность»— цель качества требований, связанная с точностью: читатели должны четко понимать каждое положение. Занесите все специальные и запутанные термины в словарь.
- Проверяемость Попробуйте разработать несколько тестов или примените другие приемы для проверки, например экспертизу или демонстрации, чтобы установить, действительно ли в продукте реализовано каждое требование. Если требование не проверяется, вопрос его корректной реализации становится предметом заключения, а не целью анализа. Неполные, несогласованные, невыполнимые или двусмысленные требования также не проверяются

5. Какими характеристиками должны обладать спецификации требований?
Набор требований, составляющий спецификацию должен отвечать характеристикам:
- Полнота Никакие требования или необходимые данные не должны быть пропущены.
- Согласованность Согласованные требования не конфликтуют с другими требованиями такого же типа или с высокоуровневыми пользовательскими, системными или бизнес-требованиями. Несогласованность документов следует устранить до начала процесса разработки. Вы не всегда знаете, какое именно положение некорректно (если какое-то некорректно), пока не выполните исследование. Рекомендуется записывать автора каждого требования, чтобы узнать, кто его высказал, если конфликт все-таки будет обнаружен.
- Способность к модификации Необходимо обеспечить возможность переработки требований, если
понадобится, и поддерживать историю изменений для каждого положения. Для этого все они должны быть уникально помечены и обозначены, чтобы вы могли ссылаться на них однозначно. Каждое требование должно быть записано в спецификации только единожды. Иначе вылегко получите несогласованность, изменив только одно положение из двух одинаковых. Лучше используйте ссылки на первоначальные утверждения, а не дублируйте положения. Модификация спецификации станет гораздо легче, если вы составите содержание документа и указатель. Сохранение спецификации в базе данных коммерческого инструмента управления требованиями сделает их пригодными для повторного использования.
- Трассируемость Трассируемость, или возможность для анализа, можно реализовать как в направлении назад, к первоисточникам, так и вперед, к элементам дизайна и исходному коду, который его реализует, а также к вариантам использования, которые позволяют проверить корректность, реализации. Трассируемые требования помечены соответствующими идентификаторами. Они записаны в структурированной, детализированной форме, в противоположность параграфам в длинной повествовательной форме. Избегайте слипания множества требований в один ком, отдельные требования можно трассировать к различным элементам дизайна и кода.

6. Что в себя включает дисциплина по управлению требований?
К действиям по управлению требованиями относятся:
- определение основной версии требований (моментальный срез требований для конкретной версии продукта);
- просмотр предлагаемых изменений требований и оценка вероятности воздействия каждого изменения до его принятия;
- включение одобренных изменений требований в проект установленным способом;
- согласование плана проекта с требованиями;
- обсуждение новых обязательств, основанных на оценке влияния изменения требований;
- отслеживание отдельных требований до их дизайна, исходного кода и вариантов тестирования;
- отслеживание статуса требований и действий по изменению на протяжении всего проекта.

7. Какие есть программные средства управления требовниями?
Наиболее известные - это Rational RequisitePro, Borland CaliberRM, Telelogic DOORS.
Все средства и их сравнительные характиристики указаны здесь:
http://www.uml2.ru/forum/index.php?topic=208.0

8. Какие есть права и обязанности у Клиента во время работы с требованиями?
- Перед началом проекта ознакомьте Клиента с его обязанностями:
1. Ознакомить аналитиков и разработчиков с особенностями вашего бизнеса
2. Потратить столько времени, сколько необходимо, на объяснение требований
3. Точно и конкретно описать требования к системе
4. Принимать своевременные решения
5. Уважать определённую разработчиком оценку стоимости и возможность реализации ваших
требований
6. Определять приоритеты требований
7. Просматривать документы с требованиями и оценивать прототипы
8. Своевременно сообщать об изменениях требований
9. Поддерживать принятый в организации-разработчике порядок контроля изменений
10.Уважительно относиться к методам, с помощью которых аналитики создают требования

- Перед началом проекта ознакомьте Клиента с его правами:
1. Иметь дело с аналитиком, который разговаривает на вашем языке
2. Иметь дело с аналитиком, хорошо изучившим ваш бизнес и цели, для которых создается
система
3. Потребовать, чтобы аналитик преобразовал требования, предоставленные вами устно,
в письменную спецификацию требований к программному продукту
4. Получить от аналитика подробный отчет обо всех рабочих продуктах, созданных
в процессе формулирования требований
5. На уважительное и профессиональное отношение к вам со стороны аналитиков
и разработчиков
6. Знать о вариантах и альтернативах требований и их реализации
7. Описать характеристики, упрощающие работу с продуктом
8. Изменить требования или разрешить использование имеющихся программных компо-
нентов
9. Получить исчерпывающие сведения о сумме затрат, ожидаемом эффекте и необходимых
компромиссах, которые возникают в связи с изменениями в ПО
10. Потребовать, чтобы система функциональностью и качеством удовлетворяла требования
заказчика

9. Что такое антитребования?
Антитребование - это некое утверждение, что не должна делать программа. Например: "Программа не должна иметь внешнего загрузчика файлов". Хорошая спецификация должна иметь антитребования, чтобы явно описать, что программа не должна делать.
« Последнее редактирование: 17 Сентября 2007, 11:46:43 от bas »
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Re: FAQ - Требования Ответ #1 : 17 Июля 2007, 15:12:39
Александр, здравствуйте!
Поясните, пожалуйста, с какой целью при наличии множетсва источников, формулирующих определения основных понятий дисциплины "Управление требованиями" (таких, как SWEBOK, работы Вигерса, Леффингуэлла и т.п.), Вы пытаетесь здесь давать свои формулировки этих понятий? Вы не согласны с классиками? Или хотите внести существенные дополнения к их позиции?

Извините, если я немного резковато формулирую, но я просто боюсь, что методически подкованный народ развернет здесь сейчас мощную дискуссию относительно нюансов Ваших формулировок (Вы извините, но есть к чему придраться). И я искренне не понимаю, а зачем??



Re: FAQ - Требования Ответ #2 : 17 Июля 2007, 15:18:56
В принципе, раздел определений имеет смысл держать на форуме.
Но при этом нужно делать библиографическую ссылку, либо указание - "предлагаю определение".
Кроме того, это полезно для индексации форума :)



Re: FAQ - Требования Ответ #3 : 17 Июля 2007, 16:18:39
ЭЭЭЭЭЭЭЭЭ, народ, чего накинулись сразу?????

Это только первый драфт того что должно здесь быть.
Давайте более точные формулировки со ссылками на источники, будем вместе править.
Это коллективный труд.
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Re: FAQ - Требования Ответ #4 : 17 Июля 2007, 19:52:46
Проблема в том, что не существует единого общепринятого варианта формулировок, который бы всех устроил. Вариантов формулировок много, и я бы не рискнул утверждать, что одни из них более "точные", чем другие.

Ну, вот раз вы просите, то вот, например, определение требований из IEEE Standart Glossary of Software Engineering Technology, 1990. На данное определение ссылается Вигерс, это же определение приводится в SWEBOK (русские формулировки взяты из перевода Орлика):
  • Условие или возможность, требуемая пользователем для решения задач или достижения целей
  • Условие или возможность, которые должны удовлетворяться системой/компонентом системы или которыми система/компонент системы должны обладать для обеспечения условий контракта, стандартов, спецификаций или др. регулирующих документов
  • Документальная репрезентация (зафиксированное определение, описание) условий или возможностей, зафиксированных в предыдущих пунктах



Re: FAQ - Требования Ответ #5 : 17 Июля 2007, 20:27:02
Относительно критериев качества требований тоже существует большое многообразие вариантов перечислений.
Например, в статье Розенберг http://satc.gsfc.nasa.gov/support/PNSQC_OCT96/pnq.html приводится список из 9 критериев качества требований, которые суть:
  • Complete
  • Consistent
  • Correct
  • Modifiable
  • Ranked
  • Traceable
  • Unambiguous
  • Understandable
  • Verifiable


Этот же список критериев качества требований можно найти и в книжке Леффингуэлла.

Другой пример. Вигерс отдельно рассматривает характеристики "превосходных" требований как отдельных атомарных высказываний (requirement statements), и отдельно - критерии качества спецификаций требований (requirement specifications).
Для отдельных требований Вигерс выделяет такие критерии качества:
  • полнота
  • корректность
  • осуществимость
  • необходимость
  • назначение приоритетов
  • недвусмысленность
  • проверяемость
Для наборов требований Вигерс приводит следующие критерии качества:
  • полнота
  • согласованность
  • способность к модификации
  • трассируемость

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



Re: FAQ - Требования Ответ #6 : 17 Июля 2007, 21:25:22
Михаил,

Задача именно собрать наиболее частые вопросы, которые встречаются у начинающего аналитика. А так же заинтересовать прочитать эти книги, т.к. есть аналитики, которые якобы все знают, а на самом деле это не так. Понятно, что этот ФАК не для опытных аналитиков.
Согласен, что в начале должен стоять пункт: А что мне надо прочитать?
« Последнее редактирование: 17 Июля 2007, 21:49:51 от bas »
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Re: FAQ - Требования Ответ #7 : 17 Июля 2007, 21:34:42
Саша, ты занимаешься правильным делом. Только это не FAQ, т.е. это не часто задаваемые вопросы. А просто темы, которые волнуют тебя и других. Пока еще нет у нас таких особо вопросов.
Но создать такую штуку думаю нужно. Хотя бы для систематизации своих знаний, уточнений разных формулировок, для создания некой базы вопросов - ответов, чтобы отсылать новичков и т.д.
Помнишь я тебе высылал переводы OpenUP, они и опубликованы, предлагаю и их использовать при анализе возможных вопросов и ответов



Re: FAQ - Требования Ответ #8 : 17 Июля 2007, 23:03:59
Только это не FAQ, т.е. это не часто задаваемые вопросы.
Понятно, что FAQ - это совсем на обязательно в буквальном смысле то, о чём кого-то постоянно спрашивают. Скорее, это рекомендация к FAQ, "о чём бы я спрашивал, будь я на твоём месте".

Цитировать
А просто темы, которые волнуют тебя и других. Пока еще нет у нас таких особо вопросов.
Что значит "у нас нет вопросов"?

Саша, возьми типы требований из Вигерса, плиз. Сгруппируй по категориям, исправь языковые ошибки. Функциональные требования не описывают функции в современном понимании, они описывают требуемое поведение. Набор требований определяется не на стадии анализа. Когда формировать требования - это уже методика организации процесса, мы до неё просто не добрались.



Re: FAQ - Требования Ответ #9 : 17 Июля 2007, 23:23:04
Что значит "у нас нет вопросов"?
Ну я имел в виду - часто заданых вопросов.
Ну, нет такой пока статистики.

Но, конечно, не в названии дело. Я же за собственно!



Re: FAQ - Требования Ответ #10 : 17 Июля 2007, 23:38:29
В книге Элизабет Халл, Кен Джексона, Джереми Дика "Разработка и управление требований" (практическое руководство пользователя). Второе издание. Перевод: Илья Корнипаев. Книга расположена на сайте http://www.telelogic.ru. Требуется регистрация.

Для описания требований предлагается такая классификация требований и их соответствие тестам, так называемая V-модель:
Пользовательские требования                                                          Приемочные тесты
     Системные требования                                                         Системные тесты
          Требования к подсистемам                                        Интеграционные тесты
                Требования к компонентам                           Модульные тесты

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



Re: FAQ - Требования Ответ #11 : 20 Июля 2007, 16:20:22
Изменил в соответствии с Вигерсом. Смотрим. Добавляем еще вопросы.
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Re: FAQ - Требования Ответ #12 : 20 Июля 2007, 16:39:16
Каков механизм управления требованиями?
Как это начинается и чем заканчивается?
Как это организуется, какие действия предпринимаются, что за чем выполняется?
(не плохо бы с примерами, вообще примеры по каждому пункту, гораздо нагляднее чем просто слова)

Какие инструменты управления требованиями существуют?
Какова их сравнительная характеристика?
Нет ли нужды организовать FAQ по инструментам сопровождения требований?



Re: FAQ - Требования Ответ #13 : 20 Июля 2007, 16:51:01
Вот столкнулся с термином "Антитребования" или "Антипрецедент".Что это?Как с этим бороться?



Re: FAQ - Требования Ответ #14 : 20 Июля 2007, 16:56:02
По мотивам описанной мною ранее книге.

Шаблоны
Типичное требование
<Тип пользователя> должен иметь возможность <описание возможности>

Требование с ограничениямими и условиями
<Тип пользователя> должен иметь возможность <описание возможности> с <показатель производительности> от <момент отсчета>, находясь в <условия эксплуатации>

Пример
Оператор должен иметь возможность произвести выстрел в течение 3 секунд с момента обнаружения цели радаром, находясь в сложных морских условиях.

Требование - ограничение
<Тип пользователя> не должен попадать под действие  <соответствующее законодательство>

Системное требование
<Система> должна <выполняемая функция> не менее чем <количество> <объект> функционируя в <условия эксплуатации>

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

Ну и так далее. Продолжать?

Периодическое требование
<Система> должна <выполняемая функция> <объект> каждые <показатель производительности> <единица измерения>

Кофе-машина должна производить горячий напиток каждые 10 секунд

Имеет смысл немного остановиться и спросить, а зачем нужны шаблоны, в чем их собственно прелесть.
Каждому или большинству требований можно назначить шаблон. Шаблон имеет некоторый идентификатор, скажем номер. Т.е. все требования со схожим шаблоном будут иметь соотвественно тот же самый номер шаблона и будут выглядеть структурно одинаковыми. Что это дает:
для быстрого и глобального изменения стиля формулировки досточно внести изменения в шаблон.
более простая и удобная технология обработки  информации, составления запросов по отдельному атрибуту шаблона требований, сортировки, фильтрация, поиск.
удобный способ защиты конфиденциальной информации - с помощью шаблона легко закрыть доступ к определенной части требования.

Примеры шаблонов требований с ограничением
Тип ограничения Шаблон
Производительность/возможность<Система> должна выполняемая функция> <объект> не менее чем
«производительность> раз в <единица измерения>
Производительность/возможность <Система> должна выполняемая функция> <объект> типа «характеристика> в течение <производительность> <единица измерения>
Производительность/мощность<Система> должна <выполняемая функция> не менее чем <количество> <объект>
Производительность/своевременность <Система> должна <выполняемая функция> <объект> в течение
<производительность> <единица измерения> с момента <событие>
Производительность/периодичность<Система> должна <выполняемая функция> не менее чем <количество> <объект> в течение <производительность> <единица измерения>
Способность к   взаимодействию/мощность <Система> должна <выполняемая функция> <объект> состоящий из не менее чем «производительность> <единица измерения> c <внешняя сущность>
Устойчивость/периодичность<Система> должна <выполняемая функция> <объект> с <производительность> <единица измерения> каждые <производительность> <единица измерения>
Окружение/работоспособность<Система> должна <выполняемая функция> <объект> функционируя в <условия эксплуатации>

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

Альтернативное представление детализации требований
Функционируя в условиях отсутствия внешнего источника электроэнергии
  телекоммуникационная система должна поддерживать телефонную связь
        не менее чем с 10 абонентами
  телекоммуникационная система должна поддерживать радиосвязь
        не менее чем с 15 водителями скорой помощи




« Последнее редактирование: 27 Августа 2007, 16:49:13 от Galogen »




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19