Тема 5 Анализ требований к пи

Основное внимание следует уделить анализу предметной области с точки зрения определения потребностей конечных пользователей в отношении функциональных характеристик разрабатываемого ПИ. Обследование объекта, моделирование его информационной системы и бизнес-процессов, спецификация требований. Определение функциональных характеристик и технико-экономических показателей ПИ, может производиться на основании анализа комплексной иерархической взаимосвязи автоматизируемых функций и задач по каждой из них. При этом обследуются входные и выходные показатели, документы и процессы перехода информации от входа к выходу. Цели создания ПИ и требования к нему отражаются в техническом задании (ТЗ), которому может предшествовать технико-экономическое обоснование, где проводится анализ осуществимости разработки на основании сопоставления требований к ПИ и возможности его эффективной разработки и функционирования с использованием современных информационных технологий [2,4,15,17,19].

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

В соответствии с ГОСТ Р ИСО/МЭК эти материалы получаются в процессе выполнения работы «Анализ требований к программным средствам».

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

- Разработчик должен установить и документально оформить следующие требования к программным средствам, включая технические требования к характеристикам качества (рекомендации по определению характеристик качества приведены в ГОСТ Р ИСО/МЭК 9126):

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

b) требования к внешним интерфейсам программного объекта архитектуры;

с) квалификационные требования;

d) требования безопасности, включая требования, относящиеся к методам эксплуатации и сопровождения, воздействию окружающей среды и травмобезопасности персонала;

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

f) эргономические требования, включая требования, относящиеся к ручным операциям, взаимодействию «человек-машина», персоналу и областям, требующим концентрации внимания человека, связанным с чувствительностью объекта к ошибкам человека и обученности персонала;

g) требования к определению данных и базе данных;

h) требования по вводу в действие и приемке поставляемого программного продукта на объекте(ах) эксплуатации и сопровождения;

i) требования к документации пользователя;

j) требования к эксплуатации объекта пользователем;

к) требования к обслуживанию пользователя.

- Разработчик должен оценить требования к программным средствам по следующим критериям (при этом результаты оценок должны быть документально оформлены):

а) учет требований к системе и проекту системы;

b) внешняя согласованность с требованиями к системе;

с) внутренняя согласованность требований к объектам между собой;

d) тестируемость требований;

е) выполнимость программного проекта;

f) возможность эксплуатации и сопровождения.

- Разработчик должен провести совместный с заказчиком (пользователем) анализ требований. После успешного проведения анализа должно быть документально зафиксировано состояние требований к программному объекту («Техническое задание», «Спецификация требований» и т.п.)

Для выявления требований используются (в различных сочетаниях) следующие методы:

• собеседование (интервьюирование);

• анкетирование;

• моделирование и анализ бизнес-процессов;

• сессии по выявлению требований (мозговой штурм);

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

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

• опрашиваемое лицо может свободно и открыто отвечать на вопросы и почувствовать себя участником проекта;

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

Недостатки метода собеседования:

• метод трудоемкий и дорогой, поэтому может оказаться непрактичным;

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

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

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

Анкетирование позволяет с помощью анкет получать сведения от большого количества людей, контролируя правильность их ответов. При работе с большой аудиторией этот метод наиболее эффективен. Преимущества метода анкетирования заключаются в следующем:

• люди могут заполнять и возвращать анкеты в удобное для них время;

• люди склонны сообщать в ответах действительные факты, если анкетирование анонимное;

• это относительно недорогой способ сбора данных с участием большого количества людей.

Недостатки метода анкетирования:

• не все могут согласиться ответить на вопросы, анкеты могут возвращаться незаполненными;

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

• подготовка анкет может потребовать много времени.

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

Основная идея создания прототипа состоит в быстрой пост­ ройке модели системы, которая, как предполагается, нужна пользователю. Обычно в прототипах многие детали опускаются, в том числе процедуры контроля входных данных, обработки ошибок, резервного копирования и восстановления данных. Не учитываются также производительность и масштабируемость. Создание прототипа никак не противоречит и не препятствует применению других методов получения требований от пользователя. Однако иногда только с помощью прототипа удается заставить клиента начать обсуждение требований, которые при другом подходе кажутся слишком абстрактными. Кроме того, работа с прототипом часто помогает получить требования, которые в противном случае так и остались бы неизвестными. Прототип хорош еще и тем, что он является неким осязаемым доказательством (или иллюзией) прогресса в разработке системы. А в некоторых случаях он может даже поддерживать какие-то ограниченные рабочие возможности системы.

Контрольные вопросы:

1. Какие виды требований к ПИ Вам известны?

2. Перечислите наиболее распространенные методы проведения обследования предметной области.

3. Кто разрабатывает документ “Техническое задание”и в чем его назначение?

4. Каковы основные разделы документа “Техническое задание” и в чем их назначение?

5. Для спецификации каких требований в первую очередь используется моделирование бизнес-процессов предметной области?