6 советов по успешной реализации вашего инструмента управления требованиями
Зачем вам нужен инструмент управления требованиями:
Это не секрет, что pтребования приводят к некачественной продукции и что эти проекты часто наполнены расширением масштабов. При подходе к требованиям, основанном на документах, существует множество проблем, в том числе и тот факт, что их сложно поддерживать в актуальном состоянии при постоянно меняющихся процессах разработки программного обеспечения. Даже если вы проделали звездную работу по сбору и документированию требований пользователей, задача управления требованиями только начинается.
Вот несколько основных причин использования автоматизированного инструмента управления требованиями по словам Карла Вигерса (статья www.processimpact.com об автоматизации управления требованиями).
- Управляйте версиями и изменениями. Большинство систем сегодня выпускаются итеративным (или гибким) способом. Это означает, что у требований будут версии, связанные с выпуском. Возможность отслеживать изменения и определять влияние изменений позволяет управлять изменениями и расширением масштабов.
- Сохраните дополнительную информацию о требовании в атрибутах требований. Нам нужно знать гораздо больше о требовании, чем формулировка требования. Например: статус требований, приоритет, кто запросил, статус теста. Это всего лишь несколько предложений.
- Свяжите требования с другими элементами системы. Чтобы гарантировать, что все требования являются частью продукта, все требования проверены, изменения оценены и т. Д., Нам необходимо иметь возможность связывать требования с другими элементами системы.
- Отслеживание статуса. Подумайте о возможности создать список всех требований, которые не утверждены, всех требований, которые не связаны с требованиями более низкого уровня, и всех требований, которые не были протестированы. Это информация, которая помогает нам действительно узнать статус проекта.
- Просмотр подмножеств требований. Подумайте о возможности просматривать все высокоприоритетные требования, которым не назначен метод тестирования. Или служба безопасности, которая хочет проверить только требования, связанные с безопасностью. Возможность фильтровать требования для включения только информации, которая интересует пользователя, сокращает время, необходимое для проверки этих требований.
- Контроль доступа. Вы должны убедиться, что бизнес-аналитики могут изменять только требования пользователей; системные аналитики могут только изменять системные требования и т. д. После утверждения доступ к требованиям должен быть ограничен, чтобы никакие дальнейшие изменения не могли быть внесены без проверки.
- Общайтесь с заинтересованными сторонами. Уведомление об изменениях необходимо для того, чтобы заинтересованные стороны знали обо всех потенциальных изменениях. Большинство инструментов управления требованиями могут помочь в автоматическом предоставлении такого рода уведомлений.
Тем из нас, кто использовал инструменты управления требованиями, трудно представить, что они вернутся к этой работе на бумаге. И я считаю, что немногие из нас захотят вернуться к этому методу. Лично я предпочел бы любой инструмент управления требованиями документированному подходу. Однако для меня удивительно, что многие организации любого размера продолжают полагаться на инструменты на основе документов для управления своими требованиями. Использование инструмента управления требованиями - это необходимый первый шаг к получению контроля над требованиями.
Перед покупкой инструмента управления требованиями:
Ни для кого не секрет, что профессиональные инженерные решения по требованиям помогают повысить эффективность при работе с требованиями. Они также помогают свести к минимуму количество ошибок что обычно приводит к дорогостоящим исправлениям на более поздних этапах жизненного цикла разработки.
Поэтому многие компании ищут такие решения по проектированию требований, но, к сожалению, то же правило, что и практически для любого другого типа программных инструментов, также применяется к решениям по проектированию требований: дурак с инструментом остается дураком ...
Лучший в своем классе требования инженерных решений как платформа Visure Requirement ALM очень гибкие при возможности для поддержки практически любого процесса разработки требований. Конечно, мы - как поставщик инструментов - рады продать вам некоторое программное обеспечение, но мы убеждены, что одно это вам не поможет. Вместо we хочу помочь тебе добиться успеха в использовании наших продуктов.
Итак, перед покупкой инженерного решения требований пожалуйста, убедитесь, что у вас есть надлежащий процесс разработки требований определяется определенными действиями, назначенными определенным ролям. Конечно, мы также можем поделиться с вами своим опытом в этой области. Если вы знаете подробные характеристики вашего процесса это намного проще для Вас найти подходящее решение, отвечающее потребностям процесс.
6 советов по успешному внедрению инструмента управления требованиями в сложной системе
Много лет назад я несколько лет работал над очень сложной системой управления оружием. Как вы понимаете, требования были большими, сложными и часто менялись. Мы потратили много времени, просто пытаясь управлять этими надоедливыми изменениями, которые продолжали поступать как от клиентов, так и от разработчиков. В те далекие дни у нас не было никаких инструментов управления требованиями, которые помогли бы оценить эти изменения. Мы использовали Interleaf и Excel (Теперь я слышу стоны боли). Все было вручную, в том числе наша комплексная прослеживаемость. У нас была пара человек, которые ничего не делали, кроме как поддерживали матрицы прослеживаемости и оценивали влияние изменений. В то время у нас была прослеживаемость только от концепции операций до требований к системе и требований к подсистеме. Я говорю «только», но в то время наличие такого уровня прослеживаемости было большим достижением.
Когда у нас было достаточно изменений, мы выпустили новый документ с требованиями к системе и новый документ с требованиями к подсистеме. Этим бедным подрядчикам пришлось пройти через огромные требования к подсистеме и вручную определить, в чем были изменения. Я не могу себе представить, сколько времени подрядчики потратили, просто пытаясь понять, о каких изменениях им нужно было позаботиться.
Именно в середине этого проекта обновления заказчик сказал достаточно и поручил моей команде оценить и выбрать инструмент управления требованиями. Выбранный нами инструмент не важен для данного обсуждения, но важно то, что мы узнали из этого выбора и реализации инструмента. Вот некоторые извлеченные уроки.
(1) – Нет ни одного инструмента, который понравился бы всем. У нас были пользователи, которым понравился наш выбор, и те, кто боролся с нами на каждом этапе пути. Без поддержки клиента и обеспечения изменений это было бы невозможно в такой большой программе, как эта. Один пользователь пожаловался на размер столбца в матрице прослеживаемости, созданной инструментом, полностью игнорируя тот факт, что это сэкономило ему дни ручной работы.
(2) – Наша ручная прослеживаемость была не очень чистой. После того, как мы импортировали всю нашу информацию в инструмент и связали ее, мы обнаружили много пробелов в отслеживаемости. Еще больше тревожило то, что у нас были ссылки, которые действительно не имели смысла. Нам пришлось проделать большую работу, чтобы очистить вверх по нашим матрицам прослеживаемости.
(3) – Простое отслеживание требований было отличным решением, но теперь мы могли приложить те же усилия, чтобы связать требования с планами тестирования, и зашли так далеко, что связали требования подсистем с проектными документами, которые мы могли просмотреть.. Это произошло не в одночасье, но все же произошло. В конце концов, мы смогли проследить системные требования до требований подсистемы, от проектного документа до модуля кода. Мы даже использовали инструмент для определения сложности модулей кода и использовали его, чтобы определить, насколько сложно будет реализовать и протестировать изменение.
(4) – Метрики из инструмента требований являются ключом к пониманию полноты тестирования.. Мы часто думали, что прошли тестирование на 50%. Ведь 50% тестов прошли. Однако мы обнаружили, что сначала мы были склонны тестировать самые простые и наиболее понятные части системы. Так что, даже если подумать, что мы были готовы на 50%, все, что осталось, было очень высоким риском. Мы научились определять приоритеты нашего тестирования, глядя на приоритеты требований и сложность программного обеспечения, информацию, которую мы не могли определить с помощью отслеживания вручную.
(5) - Очень легко было растеряться. Начни с простого. Нам пришлось отказаться от наших амбициозных идей и начать с простой модели прослеживаемости.. По мере того, как мы изучили и приобрели больший опыт работы с инструментом, мы добавили больше информации в нашу модель. Мы постоянно оценивали наш процесс, чтобы выяснить, что еще мы можем сделать, чтобы улучшить его.
(6) - Не экономьте на обучении и наставничестве. Мы обучили всех участников проекта и создали экспертов, которые помогали пользователям преодолевать первоначальные препятствия. Мы отправляли наших экспертов к подрядчикам на несколько недель, чтобы помочь им освоить этот инструмент. У нас даже была своя собственная группа внутренних пользователей. Будьте готовы к таким усилиям.
Для меня это был отличный опыт обучения. Если вы хотите внести подобное изменение, чтобы улучшить процесс обработки требований, связаться с Visure Solutions. Мы будем рады обсудить с вами ваш процесс.
