Ім'я файлу: ГЛАВА 1.docx
Розширення: docx
Розмір: 350кб.
Дата: 29.03.2021
скачати
Пов'язані файли:
Питання з Стародавнього світу.docx
ЗНМ2.docx
5 клас.docx
Розглянемо популярні стратегії виявленння вимог детальніше.docx
Лабораторна робота.docx
АСФІКСІЯ.rtf
перспективи розвитку профілактичного напрямку медицини.ppt

ГЛАВА 1. АНАЛИЗ НЕФУНКЦИОНАЛЬНЫХ ТРЕБОВАНИЙ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ

    1. ВИДЫ НЕФУНКЦИОНАЛЬНЫХ ТРЕБОВАНИЙ К

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

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

На практике мы часто используем макет, используемый в различных методологиях разработки программного обеспечения и основанный на определении групп заявок для продукта. Такой макет обычно включает группы (типы, категории) требований, например: системные, программные, активные, нефункциональные (в частности, атрибуты качества) и т. Д. Традиционный пример высокоуровневого структурирования групп требований в виде требований к продукту описан в работах Карла Вигерса, одного из классиков дисциплины управления претензиями [1].



Рисунок 1.1 - Классификация требований К. Вигерса

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

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

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

Нефункциональные требования, соответственно, регулируют внутренние и внешние условия или атрибуты функционирования системы. К. Вигерс [2] выделяет следующие основные группы нефункциональных требований:

Бизнес правила. Они определяют, почему система должна работать именно так, как написано. Это могут быть ссылки на законодательство, внутренние правила заказчика и другие причины. Этот раздел часто опускают, и оказывается, что некоторые системные решения выглядят нетипично и совершенно неочевидно. Например, многие табачные и алкогольные компании требуют постоянного доказательства того, что рекламные сайты используются людьми определенного возраста. Это бизнес-правило (подтверждение возраста) возникает по запросу этических комитетов заказчика, хотя в некоторой степени противоречит маркетинговым целям и требованиям к удобству использования.

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

Атрибуты качества. Атрибуты касаются вопросов прозрачности взаимодействия с другими системами, целостности, устойчивости и т. Д. К таким атрибутам относятся:

  • легкость и простота использования (юзабилити)

  • спектакль

  • ремонтопригодность

  • надежность и отказоустойчивость (надежность)

  • системное взаимодействие с внешним миром (интерфейсы)

  • масштабируемость

  • требования к пользовательскому и программному интерфейсам (пользовательский и программный интерфейс).

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

До сих пор нет согласия по составу групп функциональных и нефункциональных требований [3]. Разные авторы и эксперты могут как добавлять, так и удалять подгруппы требований. Например, ограничения часто сочетаются с бизнес-правилами, а бизнес-требования - с ключевыми требованиями.

    1. ФОРМИРОВАНИЕ НЕФУНКЦИОНАЛЬНЫХ ТРЕБОВАНИЙ К

Формирование нефункциональных требований к системе начинается со сбора необходимой информации. На первом этапе работы проводится анкетирование компании, необходимое для формирования представления о компании, ее целях, задачах и бизнес-процессах, которые необходимо автоматизировать. Также необходимо описать информационный ландшафт компании, чтобы определить место в нем для внедренного решения. Существует несколько различных подходов к обследованию объектов автоматизации: экспресс-съемка и информационная съемка [4].

Экспресс-опрос компании

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

Отчет, полученный в рамках экспресс-опроса, обычно содержит информацию следующего характера:

  • Краткое описание компании: виды деятельности, организационная и функциональная структура.

  • Описание основных бизнес-процессов компании (как есть).

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

  • Описание выявленных проблем в компании.

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

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

Такой тип опроса помогает команде проекта лучше познакомиться с компанией заказчика и показать его способность улучшить существующие бизнес-процессы.

Информационный обзор компании

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

  • Сбор информации о компании (документация, анкеты, интервью и др.).

  • Анализ и систематизация данных, полученных на первом этапе.

  • Представление результатов на утверждение заказчику.

На первом этапе решаются все организационные вопросы: утверждается состав проектной команды и порядок проведения опроса, определяются сроки и состав работ, формируются анкеты и график собеседований с экспертами.

Основными источниками информации для опроса (как экспресс, так и информационного) являются анкеты, интервью и внутренняя документация компании-клиента. Для лучшей оценки ситуации в компании готовятся анкеты трех типов:

  • Анкеты для руководителей высшего звена;

  • Анкеты для линейных руководителей;

  • Анкеты для линейного персонала.

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

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

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

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

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

Следующий этап - формирование требований к автоматизированной системе.

Программные требования - это набор данных, на основе которых строится система [5]. Требования составляются на основе информации, полученной в ходе опроса компании, соответственно, чем лучше были собраны и обработаны данные, тем лучше будут сформированы требования и тем меньше потребуется корректировок при их утверждении. Существуют различные методы формирования требований, некоторые из которых будут рассмотрены ниже.

Нефункциональные требования по методологии Карла Вирджеса

В своей работе Карл Вирджес выделяет три уровня требований к программному обеспечению: бизнес-требования, требования пользователей и функциональные требования. Согласно этой методологии, каждый уровень помимо функциональных требований содержит нефункциональные требования [11].

Нефункциональные требования:

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

  • Атрибуты качества - это требования, которые являются дополнительным описанием функций или производительности системы. Такими требованиями могут быть простота использования, логичность, отказоустойчивость, отказоустойчивость и другие.

  • Ограничения - технические ограничения на разработку типа и структуры продукта.

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

Согласно этой методологии функциональные требования основываются на описании бизнес-объектов организации (ее структурных подразделений, процессов, ролей, систем), а нефункциональные требования формируются путем опроса компании посредством анкетирования, интервью и наблюдений за сотрудниками. вовлечены в автоматизированный бизнес-процесс.

FURPS и FURPS +

Эта методология охватывает все аспекты системы и является более широким представлением методологии FURPS. Оба метода основаны на методологии Карла Вирджеса и разделяют требования на функциональные и нефункциональные, но, кроме того, имеют несколько иную логику разделения. Название методики представляет собой аббревиатуру [12]:

  • Функциональность - это все требования, относящиеся к функциональному назначению системы. Сюда входят: безопасность, отчетность, лицензирование, ведение журнала и другие.

  • Юзабилити - это требование, основанное на человеческом факторе. То есть субъективные пожелания пользователей системы. Эти требования могут включать требования к интерфейсу (его интуитивность, эстетика, логика), к рабочей документации (ее полнота и понятность), а также к защите от ошибок.

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

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

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

В методологии FURPS +, помимо требований исходного стандарта, были добавлены некоторые ограничения:

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

  • Ограничения разработки - это ограничения, которые устанавливают необходимые стандарты кодирования: язык программирования, стандарты, инструменты или платформы.

  • Ограничения по интерфейсам - требования к взаимодействию с другими системами, которые формируются пользователями.

  • Физические ограничения - это те, которые влияют на аппаратное обеспечение системы (размер, вес, условия эксплуатации и т. Д.)

SWEBOK

Как и FURPS, SWEBOK является аббревиатурой (свод знаний по программной инженерии). Это документ, призванный объединить знания о разработке программного обеспечения и содержащий 10 различных областей знаний, первая из которых - разработка требований.

Согласно этому документу, работа по формированию требований должна проходить в несколько этапов: определение, анализ, спецификация, проверка и управление, а область знаний «Требования к программному обеспечению» состоит из 6 разделов [13]:

  • Разработка требований - это процесс анализа и документирования требований к программному обеспечению, который состоит из преобразования требований заказчика в их описание и мониторинга их соответствия.

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

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

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

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

  • Управление требованиями - это процесс внедрения требований на всех этапах жизненного цикла, мониторинг выполнения требований и корректировка требований при необходимости.

Эти подходы к формированию требований могут применяться в разных проектах в зависимости от конкретной ситуации. Таким образом, методология Карла Вирджеса - одна из первых методологий, на которой был основан ряд других. Методологии FURPS аналогичны этой методологии, но их требования не связаны с конкретными нормативными документами. Последняя методология (SEEVOK) является результатом сбора и анализа многолетнего опыта разработки программного обеспечения и описывает этапы сбора требований.

    1. ОШИБКИ ПРИ ОФОРМЛЕНИИ НЕФУНКЦИОНАЛЬНЫХ ТРЕБОВАНИЙ

Одно из основных правил: будьте более конкретными. Грамотно составленные требования с указанием ГОСТа, ссылки на другие нормативные акты предотвратят двоякое толкование, исключат непонимание исполнителя задания. Для составления ТЗ использовать сухой научный стиль изложения. Использование сравнений нежелательно. Необходимо использовать терминологию отрасли, в которой разрабатывается проект.

Вам следует руководствоваться следующими правилами:

  • все обозначенные требования сформированы объективно, использование субъективного видения заказчика нежелательно;

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

  • риски подрядчика не должны превышать риски заказчика (это приведет к увеличению стоимости оказываемых услуг).

Проблемы с определением нефункциональных требований:

  • Разработка требований - самая сложная часть разработки программного обеспечения

  • Требования пользователей постоянно меняются

  • Неясные, неоднозначные и противоречивые требования

  • Отсутствие определенности в спецификациях

  • Недостаточное представительство пользователей

скачати

© Усі права захищені
написати до нас