СМ-Консалт
 

Валидация требований

Статьи Технологии Microsoft: .NET, Visual Studio Team System Visual Studio 2010 Team Foundation Server Requirements Management Guidance

Содержание

Валидация требований

«Валидация гарантирует, что требования отвечают желаемым характеристикам правильно поставленных требований (полнота, правильность, возможность, необходимость, приоритеты, однозначность и проверяемость), а также правильной спецификации требований (полнота, последовательность, модифицируемость и трассируемость)» – Software requirements second edition, Karl E. Wiegers.

Валидация представляет собой процесс оценки, будет ли конечный продукт удовлетворять требованиям заказчика. Валидация помогает удостовериться, что требования были правильно поняты. Такой подход к поставке в последнее время называют » Test-First Development » или » Requirements-Based Testing «. С валидацией участник проекта устанавливает критерии приемки для достижения соглашения с заинтересованными лицами о том, что будет поставлено. Это включает в себя проверку бизнес-требований, функциональных требований, нефункциональных требований, сценариев использования, моделей, прототипов и т.д.

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

Валидация требований и их исправление в начале проекта поможет сократить затраты и время, отведенное для исправления их на более позднем этапе жизненного цикла. Это также требует вовлечения в начале проекта заинтересованных лиц, которые могут проверить требования.

Все типы требования должны быть проверены, в том числе бизнес-требования, функциональные требования и требований, такие как качества обслуживания или нефункциональные требования.

Примечание: руководство по проверке требований, описанное в этом разделе предполагает, что требование на бизнес-уровне, реализуются рабочим элементом «Feature» в Team Foundation Server. Авторы не настаивают на использовании рабочего элемента «Feature» для этой цели и признают, что это добавляет элемент формальности, который можно не использовать для более гибкой команды.

Методы

Убедитесь, что полученный продукт будет работать как необходимо пользовательской среде, используя некоторые методы по необходимости. К ним относятся: планы тестирования, контрольные списки, инспекции – неформальные и официальные, рабочие демонстрации. Демонстрации способствуют сбору мнений, которые члены команды могут добавить к пунктам мозгового штурма для проверяемости и точности их требований. Смотрите раздел Выявления требований для более детальной информации о демонстрациях в качестве метода.

Планы тестирования

V-модель является промышленным стандартом для создания модели управления тестированием на всех уровнях жизненного цикла разработки приложений. Эти принципы могут быть реализованы в водопаде или в любом варианте итеративной разработки.

Рисунок 1. V-модель для управления тестированием

При разработке каждого уровня требований, которые находятся по левую сторону, правила валидации с использованием методов, описанных выше, будут помогать в разработке тестов, которые будут использоваться для проверки после поставки приложения, компоненты или системы. Лучшие процессы, которым нужно следовать – это «Test First Development» или «Requirements-Based Testing», где составляющая часть не рассматривается как готовая, пока определенные тесты не выполняются и не проходят успешно.

Итак, на основе V-модели описанной выше, следующий сценарий может быть применен на этапах развития всех описанных элементов:

  • Определено бизнес-требования, но оно не готово для анализа на функциональные и нефункциональные требований, пока его приемочные тесты не будут установлены и подтверждены. Определите пользовательские приемосдаточные тесты (User Acceptance Test Cases) и свяжите с требованием Возможность (Feature Requirement).
    • Откройте форму Возможность (Feature) в проекте Team Foundation Server. Перейдите на вкладку Links, чтобы увидеть дочерние пользовательские истории (если вы откроете Возможность из шаблона процесса MSF Agile).
    • Из меню Team или панели инструментов на вкладке Links выберите Add New Linked Work Item …. В появившемся диалоговом окне выберите тип связи Tested by и рабочий элемент Test Case. Затем добавьте название для нового рабочего элемента. Можно также добавить комментарий.
    • Новый рабочий элемент позволяет тестировщику планировать, разрабатывать и вести вместе с разработкой модель тестирования для проекта разработки. На вкладке Steps пользователь может определить шаги для выполнения ручного тестирования. Мы не будем показывать это здесь, но этот рабочий элемент, при открытии в клиенте Microsoft Test and Lab Manager, позволяет запускать приложения для тестирования с просмотром этих шагов и отмечать успех или неудачу для каждого шага, а также наблюдаемых результатов (которые можно включать в стек вызовов!).
    • Поле Summary Task такое же, как и поле описания любого другого рабочего элемента. Здесь вводится высокоуровневое описание ожидания заказчика. Можно задать следующий вопрос заказчику, для того, чтоб быть уверенными, что заказчика правильно поняли: «Если будет сделана эта функция, что покажет, что она сделана правильно?» Ответ клиента, с небольшой доработкой аналитика, должен быть главным описанием процедуры приемочного теста.
    • Вкладка Tested Work Items отображает ссылку на Возможность (Feature), которая была только что связана:
    • Сохраните рабочий элемент, а затем дважды щелкните на Возможности (Feature) и выберите ее вкладку связей, чтобы увидеть новый тестовый сценарий связанный с ней.
  • Требования к функционалу и качеству обслуживания не могут быть переданы дизайнерам и архитекторам, пока их тестовые сценарии не определены (не обязательно записаны) и не утверждены. Опишите высокоуровневые шаги тестового сценария
    • Открыть дочернее требование одного из рабочих элементов возможности. Это будет рабочий элемент либо Требование (Requirement) или Пользовательская история (User Story), в зависимости от используемого шаблона процесса. Выберите вкладку Test Cases, чтобы начать определение тестов. Выберите Add New Linked Work Item … как показано в окне ниже.
    • В появившемся диалоговом окне введите название для нового сценария тестирования. Только один вариант доступен как тип ссылки Tested By и тип рабочего элемента Тестовый сценарий (Test Case), поэтому никаких других атрибутов выбирать не нужно.
    • Результирующий рабочий элемент, как и в предыдущий процедуре, связывается с пользовательской историей, также как тестовый сценарий связывается с возможностью. Есть одно концептуальное отличие. Тестовый сценарий связанный с возможностью является Пользовательским приемочным тестом (User Acceptance Test case), а тестовый сценарий связанный с рабочим элементом системного требования является Системным тестом (System Test case).
  • Разработка приложения не может быть передана разработчикам, пока каждый компонент не имеет интеграционных тестов и тесты по методу «черный ящик» не определены и не утверждены.
    • разработчик может разрабатывать связанные модульные тесты для его кода с целью написания тестируемого кода
  • Код должен пройти весь набор написанных модульных тестов, прежде чем мы перейдем в правую часть модели.
  • После того, модульные тесты проходят, компонент, который инкапсулируется протестированным кодом, может быть протестирован. Мы можем сделать это эффективно, поскольку интеграционные тесты и тесты по методу «черного ящика» были определены в ходе разработки.
  • Как только интеграционные и тесты по методу «черного ящика» проходят, системные функциональные и нефункциональные тесты могут быть выполнены. Опять же, мы можем сделать это эффективно, потому что функциональные и нефункциональные тесты были определены и утверждены в рамках спецификации требований. Т.к. ранее были описаны функциональные шаги для каждого рабочего элемента тестового сценария, мы можем просматривать их и создавать тестовые комплекты в клиенте Visual Studio Test and Lab Manager.
  • Далее, как только системные тесты проходят, не нужно ожидать пользовательских приемочных тестов, потому что они уже определены и утверждены во время спецификации бизнес-требований.
    • Пользовательские приемочные тесты могут быть организованы в тестовые комплекты в Visual Studio Test and Lab Manager.

Выполнение шагов этой процедуры выглядит как модель водопада, на самом деле это не обязательно. Каждый шаг должен выполняться для индивидуального требования, компонента или строки кода на своем уровне. Таким образом, гибкая методология нормально относится к этой модели.

Пользовательские приемочные (UAT) тесты должны быть созданы на основе бизнес-требований и функциональных требований, которые определены и описаны. Они должны быть разработаны или, по крайней мере, просмотрены конечными пользователями, которые представили бизнес-требования (или возможности), чтобы начать работу и ориентироваться, прежде всего, на функциональность.

По мере разработки этих сценариев тестирования, прежде всего, необходимо проверять требования на возможность их валидации. Когда вы получите завершенные и верные тестовые сценарии, вы получите разработанные и документированные требования, которые удовлетворяют потребностям заказчика. Если тестовый сценарий выполняется, то система, которую вы разрабатываете, будет удовлетворять потребностям заказчика. При этом необходимо убедиться, что тестовые сценарии связаны с функциональными требованиями и нет требований без такой связи.

Должны быть бизнес-пользователи, которые должны обеспечить установку приоритетов и позволят убедиться, что требования поддаются проверке на уровне бизнес-требований, обеспечивающих понимание как требования будут развиваться дальше.

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

Во многих традиционных методологиях разработки участники пытаются удалить все неопределенности перед выполнением анализа следующего уровня. Например, двусмысленность определений для бизнес-требования должны быть устранены, перед тем как аналитик будет формировать свои функциональные или нефункциональные требования.

В гибкой методологии двусмысленности приемлемы до тех пор, пока есть согласие продолжать работу и тестировать то, что может быть проверено. Гибкие методологии используют более свободный подход к валидации, поскольку эта методология допускает, что требования будут развиваться, изменять или даже «устаревать» в ходе проекта. Это не означает, что процедура валидации требований само по себе является менее строгим. На самом деле, для гибких команд выполнение проверки более жестко связано с тем, что они постоянно выполняют обзор реализации и достигают соглашение о поставках.

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

Модель, показанная ниже, отображает структуру Team Foundation Server, которая поддерживается V-моделью, описанной на предыдущем рисунке. Как видно, Возможность (Feature или бизнес-требование) используется как дополнение к тесту, определенного в тестовом проекте в Visual Studio. Team Foundation Server позволяет пользователю установить связь между рабочим элементом и тестом в тестовом проекте. Более тесная интеграция устанавливается, когда инженер-тестировщик регистрирует изменения проекта тестирования в системе контроля версий. При регистрации изменений, связывание рабочего элемента с набором изменений может быть выполнено в принудительном режиме с использованием политик регистрации Team Foundation Server.

Аналогичный механизм Team Foundation Server поддерживается для Сценариев (Scenario, функциональные) или QoS (качество обслуживания или нефункциональные) требования.

Когда речь идет о разработке кода, это руководство показывает задачи для каждой из многих частей, которые должны быть реализованы для поддержки отдельного требования. Основываясь на этом методе, связь один-к-одном может быть установлена между небольшими блоками разработки и их тестами, которые связанны с одной задачей. В разделе Трассировки требований будет описано подробно об особенностях связей и отчетов, которые могут быть на основе них созданы.

После дизайна и разработки исходного кода, соответствующие интеграционные тестовые сценарии и модульные тесты также будут разработаны. Эти тесты помогают большей степени в верификации, чем в валидации требований.

Контрольные списки

Можно разработать различные типы контрольных списков, позволяющих определить, что предоставленные требования имеют характеристики правильно поставленных требований (полнота, правильность, возможность, необходимость, приоритетность, однозначность и проверяемы), а также правильно сформированы спецификаций требований (полнота, последовательность, модифицируемость, возможность трассировки и т.д.).

Типичные контрольные списки используются для валидации требований на всех уровнях, как показано ниже. Примеры многих из них поставляются с данным руководством Requirements Engineering Checklists.zip.

  • Product Acceptance Checklist – используется в качестве вехи для проверки, что все требования были охвачены необходимой документацией, дизайном, кодом, тестом и других критичными необходимыми артефактами.
  • Requirements Review Checklist – используется в качестве руководства при рецензировании спецификации бизнес-требований, спецификации функциональных требований или спецификации технических требований. Оно проверяет, что стандарты документации были соблюдены и требования правильно сформированы (как описано выше).
  • Requirements Style Checklist – по аналогии с предыдущим.
  • Use Case Review Checklist – Используется для обзора требований сценария и его детального описания, которое должно включать в себя все шаги потоков, графические изображения для них и любые дополнительные сопроводительные данные. В тот же список применяется для пользовательских историй гибких проектов или традиционных функциональных требований.
  • High Level Design Review – Используется для проверки, что реализуемые требования на высоком уровне отвечают выбранной архитектуре.
  • Acceptance Test Planning, Results, Change Requests, WBS и другие списки покрывают другие требования и обязанности для проекта.

Обратите внимание, что даже присутствует список » Checklist for a Checklist » в этом пакете.

Используйте шаблон документа «Non-Functional Requirements Template» в качестве контрольного листа для выявления и проверки качества обслуживания (производительности, масштабируемости, бизнес-цикла, обслуживания, поддержки, размещения и т.д.).

Инспекция

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

Хороший процесс выполнения инспекций приведен ниже:

  1. Отправлять материалы, которые будут рассмотрены, независимо для каждого рецензента.
  2. Укажите, что каждый рецензент должен анализировать при инспектировании составляющих. Например, тестер должен определить тестируемость составляющих. То есть, могут ли быть тесты написаны и выполнены по завершению. Скажите им внести в документацию пометки, комментарии и критические замечания. Если они находят ошибки, они должны быть готовы для определения альтернативы по этой ошибке.
  3. Наметьте встречи, выделяя участникам достаточно времени для ознакомления с материалом. Неделю, как правило, достаточно времени для этого.
  4. Рассматривайте только те проблемы, которые были определены. Таким образом, совещания эффективно обеспечат, что рецензии будут завершены без потерь чьего-либо времени. Важно отметить, что рецензирование требований или инспекция это не мозговой штурм и сессия генерации идей. Объясните участникам важность их готовности.
  5. Документируйте любые расхождения и определите задачи для авторов на исправление и повторное внесение на инспекцию.

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

Техническая поддержка

Используйте Team Foundation Server для поддержки вышеуказанных действий. Используйте Team Foundation Server для хранения результатов инспекций и принятия рецензий требований. Рассмотрите раздел Выявление для ознакомления с библиотекой документов Team Foundation Server, где хранятся контрольные списки и конечные продукты.

Специфика CMMI

«Анализируйте требования для определения риска связанного с тем, что конечный продукт не будет работать правильно в его предполагаемой среде использования» – CMMI, Guidelines for Process Integration and Product Improvement, Chrissis, Konrad, Shrum.

04.07.2010

Комментарии

  • Фабрика Интердизайн
    Автор: #file_links["C:\Link\donor.txt",1,L]  ·  11.09.2017 18:28:27
    гостиная Роза http://bigwork.info/ ----------
  • peaceful music for sleep youtube breath of life
    Автор:   ·  24.08.2017 21:36:02
    Perfect instrumental background music for romantic and sentimental films, presenting your business, new products or your company in general with an optimistic and motivational touch. Visit site: Music for romantic https://audiojungle.net/user/momentumofmelody/portfolio?ref=MomentumOfMelody https://audiojungle.net/item/piano-inspiration/18285725?ref=MomentumOfMelody https://audiojungle.net/user/ie_sound/portfolio?ref=IE_Sound https://audiojungle.net/item/motivation-ambient-kit/19508793?ref=IE_Sound
  • АЛКОВЕРИН - АКТИВИРУЕТ РЕЖИМ АЛКОГОЛЬНОГО ОТТОРЖЕНИЯ
    Автор:   ·  12.05.2017 22:57:42
    АЛКОВЕРИН АКТИВИРУЕТ РЕЖИМ АЛКОГОЛЬНОГО ОТТОРЖЕНИЯ С ALCOVIRIN выпить ПРОСТО НЕ УДАСТСЯ! Это первый биогенный растительный комплекс, способствующий выработке непереносимости алкоголя при совместном приеме капель и спиртных напитков, вызывая тошноту и его полное отторжение организмом! Кроме того, он оказывает мощное оздоровительное действие, устраняя алкогольную интоксикацию и способствуя восстановлению правильной работы органов и систем. Официальный сайт: http://alcovirin.bxox.info
  • easy piano music to sleep and relax music and rain
    Автор:   ·  26.04.2017 13:38:13
    Perfect instrumental background music for romantic and sentimental films, presenting your business, new products or your company in general with an optimistic and motivational touch. Visit site: https://audiojungle.net/user/commercial_music https://audiojungle.net/user/corporate_sound https://audiojungle.net/user/elijah_studio https://audiojungle.net/user/ie_sound https://audiojungle.net/user/momentumofmelody ===========
  • Tinedol – эффективное средство от грибка
    Автор:   ·  18.01.2017 21:13:43
    Tinedol – эффективное средство от грибка стопы, неприятного запаха и зуда. Перейти на сайт: http://tinedol.1stbest.info/
  • unowoOtpWyq
    Автор: Please teach the rest of these internet hoaonglis how to write and research!  ·  01.12.2015 15:06:18
    Please teach the rest of these internet hoaonglis how to write and research!
  • 1178
    Автор: Cartier love bracelet lady stainless steel  ·  21.01.2015 07:26:09
    Maybe I agree with you. I have long perceived Glenn Beck to be the most foresighted and hindsighted person on the radio since Rush Limbaugh. Cartier love bracelet lady stainless steel http://cartierlovebraceletunisexwhitegold.blogspot.com/
  • http://www.thejapanbrandteam.com/
    Автор: http://www.thejapanbrandteam.com/  ·  11.10.2013 15:00:24
    In all size categories, more firms reported a fall in export orders than enjoyed a rise. http://www.thejapanbrandteam.com/ http://www.thejapanbrandteam.com/ http://www.thejapanbrandteam.com/
  • http://www.propertysolutionslanguedoc.com/sales/michaelkorsfactory.html
    Автор: Replica Michael Kors  ·  30.09.2013 12:34:38
    http://www.ablazewithlight.com/cityscapes.html#.UZI8YCKmdH4 Replica Michael Kors http://www.propertysolutionslanguedoc.com/sales/michaelkorsfactory.html
  • http://www.polio-ni.org/links/louisvuitton.asp
    Автор: Louis Vuitton  ·  29.09.2013 18:49:48
    Conditions of the Act Louis Vuitton http://www.polio-ni.org/links/louisvuitton.asp
  • http://phonecasemall-jp.tk
    Автор: http://phonecasemall-jp.tk  ·  26.09.2013 16:35:57
    I would like to begin with a request. I write in peace. Please do not break my nose after reading this letter. I am aware such a request does not augur well for a correspondence, yet I insist you grant me this small wish before getting on with the rest of the letter. Unnatural. Thats what I thought when I first heard about what had happened at the Taj Colaba with you the other night. I mean can you believe it? Is this for real? Nawab saab, for a few minutes I felt I was transported to a different country, a country with a constitution, a real government with a real police force full of real anally retentive gems. http://phonecasemall-jp.tk http://phonecasemall-jp.tk
  • http://basketslissabelmarant.tumblr.com
    Автор: Isabel Marant  ·  23.09.2013 21:28:09
    Nous avons oublie une application incontournable (c'est possible) ? Vous avez envie une remarque ? N'hesitez pas a nous laisser des commentaires un peu plus bas sur la page !Les policiers surveillaient depuis quelque temps un garage d'Aubervilliers, qui pouvait, selon eux, servir de lieu de stockage pour des trafiquants de drogue. Lundi apres-midi, ils y ont repere lundi une voiture gr?ce a un chien antidrogue.

Добавить комментарий (анонимные комментарии не публикуются!!!)

ФИО: 
E-mail: 
Тема: 
Комментарий: 
Оценка:   
 
 
 
 
 
Код подтверждения:
   

Новости СМ-Консалт

Вышла версия BIPULSE 6.2

Мастер-класс для тренеров и руководителей "Работа в аудитории". 1 ступень уже в марте

Обновлено расписание тренингов до марта 2017 года

Новые статьи в библиотеке

Мифы про ГОСТ 34

Примеры отраслевых решений на основе BIPULSE

Практика реализации модуля интеграции для Rational Software Architect, позволяющего преобразовывать низкоуровневое представление процесса из IBM Rational ClearQuest в UML

Что удивляет в русских менеджерах иностранцев

Разработка ПО с использованием лучших мировых практик и инструментов на Иркутском авиационном заводе

Презентация доклада для IT Global Meetup Санкт-Петербург: "Почему Agile так популярен? Взгляд циника и психолога"

Заказчики и истории успеха

Наши тренинги, семинары, курсы

Дружите с нами на FaceBook

Проверить настройки
Компания
Сделано в СМ-Консалт
Услуги 
Компетенция
  • CMC-TotalTest (скоро)
    уникальная разработка автоматизации функционального тестирования. Альтернатива HP UFT, IBM RFT и Microsoft!
  • CMC-Bisquiter
    автоматизированное тестирование АБС "Бисквит"
  • CMC-Formater
    тестирование печатных и экранных форм
  • CMC-TerminalTest
    тестирование терминальных приложений
  • ProjectTracker
    интеграция ALM и MS Project
  • GanttChart
    модуль управления проектами для IBM Rational ClearQuest и TeamConcert
    Все разработки СМ-Консалт >
  • ИТ-консалтинг
  • Автоматизированное тестирование
  • Ручное тестирование
  • Аутсорсинг тестирования
  • Оптимизация бизнес-процессов
  • Внедрение методологии и инструментов ALM
  • Обучение и коучинг
  • Разработка ПО
  • Интеграция
ООО СМ-Консалт (СМК), 2004-2017.
Карта сайта