Оглавление
1 Понятие и значение методов выявления требований. 3
2 Методы выявления требований. 6
2.3 Контекстные (когнитивные) методы.. 8
2.4 Познавательные методы.. 10
2.5 Методы быстрой разработки. 10
Введение
Методы выявления требований Основные методы выявления и формирования требований. Интервью, семинары, фокус-группы, наблюдение, опросные листы. Анализ полученных данных.
1 Понятие и значение методов выявления требований
Анализ требований, также известный как «разработка требований», — это процесс определения ожиданий пользователей в отношении нового программного обеспечения, которое создается или модифицируется. В разработке программного обеспечения его иногда называют по имени, например, сбор требований или сбор требований. Анализ требований включает в себя те задачи, которые входят в определение потребностей или условий, необходимых для нового или измененного продукта или проекта, с учетом возможных противоречивых требований различных заинтересованных сторон, анализа, документирования, проверки и управления требованиями к программному обеспечению или системе. Вот цели для выполнения анализа требований на ранней стадии программного проекта:
Процесс выявления требований проходит от… Что к Как: задача разработки программного обеспечения, устраняющая разрыв между проектированием системных требований и разработкой программного обеспечения.
Модель требований предоставляет разработчику программного обеспечения:
- системная информация (статическое представление)
- функция (функциональный вид)
- поведение (динамическое представление)
Требование к программному обеспечению — это способность, необходимая пользователю для решения проблемы или достижения цели. Другими словами, требование — это программная возможность, которой система или компонент системы должны соответствовать или обладать, чтобы удовлетворить контракт, стандарт, спецификацию или другую формально навязанную документацию. В конечном итоге важно разработать качественное программное обеспечение, отвечающее реальным потребностям клиентов в срок и в рамках бюджета.
Возможно, самая большая проблема, с которой сталкиваются разработчики программного обеспечения, заключается в том, чтобы поделиться с клиентом концепцией конечного продукта. Все заинтересованные стороны в проекте — разработчики, конечные пользователи, менеджеры программного обеспечения, менеджеры по работе с клиентами — должны прийти к общему пониманию того, каким будет продукт и чем он будет заниматься, иначе кто-то будет удивлен, когда он будет доставлен. Сюрпризы в программном обеспечении почти никогда не являются хорошими новостями.
Следовательно, нужны способы точного захвата, интерпретации и представления голоса клиентов при определении требований к программному продукту.
Анализ требований имеет решающее значение для успеха или провала системного или программного проекта. Требования должны быть задокументированы, действенными, измеримыми, проверяемыми, прослеживаемыми, относиться к определенным бизнес-потребностям или возможностям и определяться с уровнем детализации, достаточным для проектирования системы. Концептуально анализ требований включает четыре вида деятельности:
Выявление требований: задача общения с клиентами и пользователями, чтобы определить их требования. Иногда это также называется сбором требований.
Анализ требований: определение того, являются ли заявленные требования неясными, неполными, неоднозначными или противоречивыми, и затем решение этих проблем.
Моделирование требований. Требования могут быть задокументированы в различных формах, таких как документы на естественном языке, варианты использования, пользовательские истории или спецификации процесса.
Обзор и ретроспектива: члены команды размышляют о том, что произошло в итерации, и определяют действия по улучшению в будущем.
Анализ требований — это командная работа, которая требует сочетания аппаратного, программного и человеческого опыта, а также навыков общения с людьми. Вот основные виды деятельности, связанные с анализом требований:
- Определение потребности клиента.
- Оценка системы на предмет осуществимости.
- Проведение экономического и технического анализа.
- Распределение функций по системным элементам.
- Установка графика и ограничения.
- Создание системных определений.
2 Методы выявления требований
В программном обеспечении жизненного цикл разработки идентификации эффективных требований к программному обеспечению является одной из ключевых задач для разработки программного обеспечения системы высокого качества. Успех или провал усилий по разработке программного обеспечения в значительной степени зависят от качества требований.
Многие статьи и книги описывают методы сбора информации, которые можно разделить на четыре категории в зависимости от их характера связи — традиционные, контекстные (когнитивные), сотрудничества и познавательные.
2.1 Традиционные методы
Интервью представляет собой метод выявления фактов и мнений пользователей и других заинтересованных сторон системы в стадии разработки лицом к лицу разговор. Есть два различных вид интервью: замкнутые интервью, где интервьюируемый имеет заранее определенный набор вопросов и ищет ответы на них. Открытое интервью, где требуется инженер и заинтересованные стороны обсуждают в открытом пути, чтобы выяснить их ожидание от системы.
Анкета представляет собой метод продуцирования требование от большого числа людей и характеризуется меньшей стоимости и времени. Хорошо разработанная анкета может быть полезной для выявления однозначного и непротиворечивого требования от заинтересованных сторон. Успех опросника в зависимости от того, насколько хорошей сессии, дизайна вопросника и мастерства ведущего, которые проводят сеанс.
Данные собираются из существующей системы. Это полезный метод, чтобы собрать глубокие знания о системе. Когда используют эту технику, нужно быть очень осторожными, так как анализировать придется существующую систему, и есть опасения, что новая система станет слишком ограниченной.
2.2 Совместные методы
Фокус-группа представляет собой метод, где группа из четырех до девяти пользователей из разных слоев компании и с разными навыками обсуждает в свободной форме и высказывает озабоченность по поводу особенностей системы, которая будет создана. Фокус-группа помогает определить ожидания пользователей от системы, какие вещи важны для них, и каковы их ожидания от системы. Они часто приносят спонтанные реакции и идеи.
Мозговой штурм предоставляет открытую среду обсуждения, где пользователи могут свободно высказать свое требование и ожидание системы. Данные (идеи), собранные после этого процесса затем обсуждаются и анализируются. Мозговой штурм содержит две фазы — фазы генерации, где собираются идеи, и фазу эволюции, где обсуждаются собранные идеи.
Совместная разработка приложений является методом сбора требований и инженерной методологией, в которой заинтересованные стороны, эксперты по конкретным вопросам, конечные пользователи, разработчики программного обеспечения проводят интенсивные встречи по детализированию системы. Совместная разработка приложений фокусируется на бизнес-задаче, а не технических деталях. Ее успех зависит от эффективного руководства на сессиях, от участия ключевых конечных пользователей, администраторов, разработчиков, а также от достижения группового взаимодействия во время сеансов. Координатор процесса совместной разработки приложений представляет серию семинаров, которые принимают участие заинтересованных сторон, руководители, конечные пользователи, архитекторы программного обеспечения и разработчиками малых и средних предприятий.
Разработка прототипов. Прототип системы является начальным наброском системы, который часто используется для проверки требований системы. Есть два различных типа прототипа: одноразовые прототипы помогают понять общее требование. Эволюционные прототипы обеспечивают действенную систему и часто становятся частью конечной системы.
Работа над прототипом представляет собой совокупность различных типов совещания, проведенного с заинтересованными сторонами для сбора требований к проекту. Это очень полезно, чтобы выявить потребность в сложной и большой системы.
История интернат находится использует изображения, текст, аудио, видео, анимацию диаграмму для визуализации концепции системы программного обеспечения для заинтересованных сторон. Этот метод позволяет заинтересованным сторонам прийти к общему пониманию о функциональности разрабатываемой системы. Раскадровка очень легко делиться с большими группами, и не дают ложное впечатление о том, что система уже разработана.
2.3 Контекстные (когнитивные) методы
Анализ документов представляет собой процесс анализа документов, относящиеся к предметной области, чтобы собрать информацию, которая течет с в организациях. Это полезный метод, чтобы найти глубокие знания о конкретной задаче.
Сортировка карточек: метод сортировки карточек используется для получения информации в отношении к ассоциации и группировке набора элементов данных. Участники карточного рода просит организовать индивидуальные, несортированные элементы в группы. Сортировка карточек могут проводиться в виде серии отдельных упражнений, как параллельная деятельность небольшой группы, или как гибридный подход, при котором индивидуальная деятельности следует групповому обсуждение индивидуальных различий. Сортировка карточек, как правило, проводится в качестве специфической активности в начале фазы разработки проекта для определения архитектуры, но также может быть использована во время оценки продукта, чтобы определить, есть ли проблемы юзабилити из-за проблемы с группировкой или группы метками. Сортировка карточек может быть использована для:
- Определения темы или модели качественных данных.
- Разрабатывать информацию и навигационную архитектуру для веб-сайта или приложения.
- Дизайн или редизайн сайта или приложения.
- Организация иконки, изображений, пунктов меню и другие объекты в связанных группах.
- Определение того, как конкретное лицо классифицирует элементы из конкретного домена.
- Проверка, как различные группы (пользователи против разработчиков, например) смотрят один и тот же предмет.
- Ранг или скорость элементов системы.
Приведенные выше методы определения требований являются традиционной техникой выявления требования, основанных на процессе индукции. Другие методов также разрабатываются организациями, чтобы сделать требование выявления задач более эффективными. Некоторые из них описаны ниже.
Анализ протокола является способом проведения встреч, где заинтересованные стороны и аналитики встречаются для обсуждения требований к системе. Анализ протокола также обеспечивает необходимые действия, которые необходимо принять для выполнения требований пользователей, используя логическое обоснование.
Лэддеринг является формой структурированного интервью, в котором ограниченный набор стандартных вопросов дается заинтересованным сторонам. Набор вопросов, расположен в иерархическом порядке. Успех этого метода является зависит от области знаний заинтересованных сторон.
2.4 Познавательные методы
Наблюдение — это метод включает исследование работы пользователя и принимая к сведению деятельность, которая имеет место. Наблюдение может быть прямым или косвенным. Наблюдение позволяет наблюдателю просматривать то, что пользователи на самом деле делают в контексте преодоление проблем, что позволяет с заинтересованными сторонами, описывать идеализированные или упрощенные рабочие процессы.
Социальный анализ представляет собой процесс взаимодействия с заинтересованными сторонами и пользователями, чтобы выяснить политическую обстановку внутри организации. Наблюдатели стараются понять работу и культурную среду.
2.5 Методы быстрой разработки
Итеративный и инкрементный (эволюционный) подход к разработке программного обеспечения позволяет выполнять разработку в очень совместной манере самоорганизующихся команд в рамках эффективной структуры управления с достаточно простым алгоритмом, который производит высококачественные решения в экономически эффективной и своевременной манере, отвечающим изменяющимся потребностям ее заинтересованных сторон.
Гибкие методы являются адаптивными по своей природе, они были разработаны, чтобы адаптироваться и преуспеть в ответ на частые изменения. Гибкие методы, ориентированные на людей; они полагаются на знания персонала, компетентность и прямое сотрудничества, а не на документно-ориентированные процессы.
Заключение
На протяжении многих лет процесс разработки программного обеспечения становится все более затратным с точки зрения требований к контролю качества. Это приводит практикующего и исследователей искать новые пути для оптимизации процесса разработки системы качества программного обеспечения.
Процесс разработки аннотации программного обеспечения состоит из многих наукоемких процессов, среди которых процесс выявление требований является выявление, возможно, самым важным для успеха системы программного обеспечения. Процесс выявления требований предназначен для получения знаний о потребности пользователя или необходимости. Как правило, выбор методов сбора информации требование основано на практике компании или на личном опыте. Кроме того, существует мало указаний о том, как выбрать методы сбора информации для нового проекта программного обеспечения.
Это хорошо знают тот факт, что стоимость исправления ошибок в увеличении программного обеспечения экспоненциально на более поздних этапах разработки программного обеспечения. Следовательно, если один идентифицирует отсутствующие и неверные требования в самом процессе их выявления требований, то стоимость исправления этих ошибок в программном обеспечении можно будет резко сократить. Усилия, необходимые для определения всех недостающие и неправильных требований в этапе сбора требований огромны и требуется значительное время расходного. Таким образом, оптимизировать процесс выявления требования может значительно ускорить и удешевить процесс разработки программного обеспечения.
Процессом выявления требований является выявление процесса сбора требований к программному обеспечению от пользователей, клиентов и заинтересованных сторон. Это нетривиальный процесс, потому что это не практика просто сбора требований от заказчика, но это требует участия в потребностях клиентах, заинтересованных сторон и от аналитика ждут хороший и последовательный набор требований, которые на самом деле решить эту проблему. Этот процесс требует решения несколько важных вопросов, требующих ответа, что включает:
- Каковы функциональные и нефункциональные требования к системе?
- Каковы характеристики системы?
- Каковы ожидаемые результаты от процесса извлечения требования?
- Какие ограничения применимы для системы в контексте с аппаратным или программным обеспечением?
- Какого типа пользователи / заинтересованные стороны участвуют в системе?
Выбор подходящих методов требования сбора информации для конкретной области программного проекта является сложной проблемой. Ряд переменных влияют на этот процесс отбора. Широкое разнообразие методов или методов, были предложены различными авторами, такие как: интервью, анализ протокола, репертуарная решетка, рабочие группы и т.д.
Список литературы
- Абросимов, Л. И. Базисные методы проектирования и анализа сетей ЭВМ. Учебное пособие / Л.И. Абросимов. — М.: Университетская книга, 2015.
- Афонин, В. В. Моделирование систем / В.В. Афонин, С.А. Федосин. — М.: Интернет-университет информационных технологий, Бином. Лаборатория знаний, 2016.
- Вендров, А. М. Практикум по проектированию программного обеспечения экономических информационных систем / А.М. Вендров. — М.: Финансы и статистика, 2013.
- Гагарина, Л. Г. Технология разработки программного обеспечения / Л.Г. Гагарина, Е.В. Кокорева, Б.Д. Виснадул. — М.: Форум, Инфра-М, 2013.
- Голицына, О. Л. Программное обеспечение / О.Л. Голицына, И.И. Попов, Т.Л. Партыка. — М.: Форум, 2013.
- Грекул, В. И. Методические основы управления ИТ-проектами / В.И. Грекул, Н.Л. Коровкина, Ю.В. Куприянов. — М.: Интернет-университет информационных технологий, Бином. Лаборатория знаний, 2011.
- Емельянова, Н. З. Проектирование информационных систем / Н.З. Емельянова, Т.Л. Партыка, И.И. Попов. — М.: Форум, 2017.
- Заботина, Н. Н. Проектирование информационных систем / Н.Н. Заботина. — М.: ИНФРА-М, 2013.
- Залогова, Л. Разработка Паскаль-компилятора / Л. Залогова. — М.: Бином. Лаборатория знаний, 2015.
- Зыков, С. В. Основы современного программирования / С.В. Зыков. — М.: Горячая линия — Телеком, 2016.