Сегодня мне поручили подобрать инструмент для организации поддержки пользователей-клиентов организации-разработчика программного обеспечения. Имея небольшой опыт в развертывании подобных решений сразу подумал о trac. Но серьезным недостатком trac'а для подобных задач может оказаться его ориентированность на разработчиков. У системы достаточно высокий порог вхождения.
Размышления на данную тему привели меня к теории управления требованиями в разработке и проектировании программных продуктов. Собственно, никакой теории в России, наверняка нет, судя по тому, что до сих пор я встречаю только переводы, и то не всегда качественные.
Очевидно, что для меня и самого сейчас очень важно разобраться с тем, что ж такое "управление требованиями".
Об управлении требованиями можно говорить, как о дисциплине (http://www.uml2.ru). Данная дисциплина рассматривается в рамках проектирования ПО при помощи UML. Однако, наиболее предпочтителен (мной и не только :) ) итеративный жизненный цикл разработки ПО, поэтому, требованиями можно управлять и в процессе (уже хорошо для моей задачи).
Что в себя включает "управление требованиями", как дисциплина?
Ответ: действия по управлению требованиями.
Какими могут быть эти действия?
* определение основной версии требований (моментальный срез требований для конкретной версии продукта);
* просмотр предлагаемых изменений требований и оценка вероятности воздействия каждого изменения до его принятия;
* включение одобренных изменений требований в проект установленным способом;
* согласование плана проекта с требованиями;
* обсуждение новых обязательств, основанных на оценке влияния изменения требований;
* отслеживание отдельных требований до их дизайна, исходного кода и вариантов тестирования;
* отслеживание статуса требований и действий по изменению на протяжении всего проекта.
Все указанные задачи в полной мере справедливы для моей задачи.
Таким образом, требования - это (IEEE Standard Glossary of Software Engineering Terminology):
1. условия или возможности, необходимые пользователю для решения проблем или достижения целей;
2. условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам
3. документированное представление условий или возможностей для п. 1 и 2
Рекомендации по формулировки требований
Типичное требование
<Тип пользователя> должен иметь возможность <описание возможности>
Требование с ограничениями и условиями
<Тип пользователя> должен иметь возможность <описание возможности> с <показатель производительности> от <момент отсчета>, находясь в <условия эксплуатации>
Пример:
Оператор должен иметь возможность произвести выстрел в течение 3 секунд с момента обнаружения цели радаром, находясь в сложных морских условиях.
Требование - ограничение
<Тип пользователя> не должен попадать под действие <соответствующее законодательство>
Системное требование
<Система> должна <выполняемая функция> не менее чем <количество> <объект> функционируя в <условия эксплуатации>
Пример:
Телекоммуникационная система должна обеспечивать телефонную связь не менее чем с 10 абонентами, функционирую в условиях отсутствия источника внешнего электрического питания
Периодическое требование
<Система> должна <выполняемая функция> <объект> каждые <показатель производительности> <единица измерения>
Пример:
Кофе-машина должна производить горячий напиток каждые 10 секунд
Производительность/возможность
<Система> должна <выполняемая функция> <объект> не менее чем <производительность> раз в <единица измерения>
Производительность/возможность
<Система> должна <выполняемая функция> <объект> типа <характеристика> в течение <производительность> <единица измерения>
Производительность/мощность
<Система> должна <выполняемая функция> не менее чем <количество> <объект>
Производительность/своевременность
<Система> должна <выполняемая функция> <объект> в течение <производительность> <единица измерения> с момента <событие>
Производительность/периодичность
<Система> должна <выполняемая функция> не менее чем <количество> <объект> в течение <производительность> <единица измерения>
Способность к взаимодействию/мощность
<Система> должна <выполняемая функция> <объект> состоящий из не менее чем <производительность> <единица измерения> c <внешняя сущность>
Устойчивость/периодичность
<Система> должна <выполняемая функция> <объект> с <производительность> <единица измерения> каждые <производительность> <единица измерения>
Окружение/работоспособность
<Система> должна <выполняемая функция> <объект> функционируя в <условия эксплуатации>
Детализация требований
Пример:
Телекоммуникационная система должна поддерживать телефонную связь не менее чем с 10 абонентами (выделен показатель производительности) функционируя в условиях отсутствия внешнего источника электроэнергии (выделено ограничение)
Альтернативное представление детализации требований
Пример:
Функционируя в условиях отсутствия внешнего источника электроэнергии коммуникационная система должна поддерживать телефонную связь не менее чем с 10 абонентами
телекоммуникационная система должна поддерживать радиосвязь не менее чем с 15 водителями скорой помощи
Какие бывают требования?
Требования к ПО состоят из трех уровней — бизнес-требования, требования пользователей и функциональные требования. Вдобавок каждая система имеет свои нефункциональные требования.
Бизнес-требования (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) — это набор логически связанных функциональных требований, которые обеспечивают возможности пользователя и удовлетворяют бизнес-цели. В области коммерческого ПО характеристика представляет собой узнаваемую всеми заинтересованными лицами группу требований, которые важны при принятии решения о покупке — элемент маркированного списка в описании продукта.
Характеристики правильных спецификации требований:
* полнота
* корректность
* осуществимость
* необходимость
* однозначность
* согласованность с другими (в том числе высокоуравневыми)
* модифицируемость (переработки требований, если понадобится с поддержкой истории изменений и информации об авторе)
* трассируемость - возможность переработать требования в другие элементы UML. Например в usecase или элемент дизайн-модели (очевидно, справедливо не для всех видов требований)
* проверяемость
* приоритетность (по другому: у хорошего требования есть приоритет)
Требования не должны касаться деталей дизайна или реализации (кроме требований к дизайну и реализации :) ).
Итог: с требованиями мне все ясно. Будем искать программный продукт, способный удовлетворить:
<Программный продукт> должен уметь <принимать требования> от <пользователей>, предоставлять их в <удобном для разработчика виде>, давать возможность <следить за реакцией> <разработчиков>.
Данный материал "скопипастен" и переработан с http://www.uml2.ru/ и http://www.intuit.ru/ не корысти ради, а для более удобного понимания предмета в рамках поставленной задачи.
Комментариев нет:
Отправить комментарий