Руководство по выявлению для традиционной разработки

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

В TFS, шаблон процесса MSF для CMMI обеспечивает поддержку для управления требованиями и разработку требований, которые компания может использовать для организации их в соответствии модели качества CMMI уровня 3. В рамках этого руководства шаблона процесса Microsoft определил “персонажи”, которые могут быть использованы для определения пользователей, которые помогут выявить функциональные требования.

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

Дополнительные комментарии по традиционному выявлению

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

Для того чтобы обеспечить такую поддержку, используются следующие правила:

1. Если вы собираетесь получить требования от заинтересованных сторон:

   1. Планируйте работы и используйте рабочие элементы “Задача” для оценки и отслеживания работ выявления.

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

   3. Измените название шаблона, заполните его, добавьте свою контактную информацию и дату, когда он использовался, а затем сохраните результат в библиотеке документации артефактов Требований в TFS.

   4. Связывайте любые результирующие рабочие элементы с артефактами в библиотеке документации.

2. Если вы выявляете требования из ранее сформированной документации:

   1. Планируйте работы и используйте рабочие элементы “Задача” для оценки и отслеживания работ выявления.

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

   3. Измените название шаблона, заполните его, добавьте свою контактную информацию и дату, когда он использовался, а затем сохраните результат в библиотеке документации артефактов Требований в TFS.

   4. Связывайте любые результирующие рабочие элементы с артефактами в библиотеке документации.

3. Если по итогам интервью, “мозгового штурма” или другой сессии в рамках семинара по требованиям:

   1. Планируйте работы и используйте рабочие элементы “Задача” для оценки и отслеживания работ выявления.

   2. Разработайте и применяйте контрольные списки и шаблоны для документирования результатов работы. Храните их в шаблонах документации библиотеки TFS Team Project.

   3. Заполните шаблон, измените его название, добавьте имена и роли всех участников, а также добавьте даты события в документ перед его сохранением в библиотеке документации артефактов требований в TFS Team Project.

   4. Связывайте любые результирующие рабочие элементы с артефактами в библиотеке документации.

4. Если вы создаете больше, чем просто рабочий элемент для представления набора требований:

   1. Разработайте и используйте шаблон, который доступен для всей организации (хранится в шаблонах библиотеки документации TFS Team Project)

   2. Храните итоговые документы, таблицы, графики и т.д. в библиотеке документации требований TFS Team Project

   3. Связывайте результирующий файл с соответствующими рабочими элементами через URL ссылки в TFS.

1 – ChrKang92, p. 4 – Christel, M. G., & Kang, K. C. (1992). Issues in Requirements Elicitation. Pittsburgh, PA: Software Engineering Institute. 2 – SEI 91, p.26 – Software Engineering Institute. (1991). Requirements Engineering and Analysis Workshop Proceedings, Technical Report. Software Engineering Institute Requirements Engineering Project. Pittsburgh, PA: Software Engineering Institute. 3 – Rat99 – Rational Software Corporation. (1999). Guideline: Brainstorming and Idea Reduction. The Rational Unified Process . Rational Software Corporation.