37.Классификация и спецификация требований

Требование - это условие или возможность, которой должна соответствовать система.

1. условия или возможности, необходимые пользователю для решения проблем или достижения целей;

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

3. документированное представление условий или возможностей для пунктов 1 и 2

Требования - это исходные данные, на основании которых проектируются и создаются АИС.

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

ФОРМИРОВАНИЕ ТРЕБОВАНИЙ К ИС - это этап анализа.

Стадии и этапы создания ИС - ГОСТ 34.601-90

1. Формирование требований к АС: 1.1. Обследование объекта и обосн-ние необходимости создания АС. 1.2. Форм-ние требований пользователя к АС. 1.3. Оформление отчёта о выполненной работе и заявки на разработку АС (тактико-технического задания)

КЛАССИФИКАЦИЯ ТРЕБОВАНИЙ

1. Требования к продукту и процессу (проекту)

2. Системные требования и требования к ПО

3. Функциональные и нефункциональные требования и характеристики продукта

Требования к продукту - (являются основополагающим классом требований)

Цель создания ИС - получить хороший конечный продукт: функциональный и удобный в использовании

Требования к процессу

1.согласованный план работ c детализацией с точностью до конкретных исполнителей.

2.ежедневные сборки, регрессионное тестирование компонент ИС и тестирование ИС в целом.

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

Системные требования(system requirements) - это высокоуровневые требования к продукту, системе.

Система – это комбинация взаимодействующих элементов, созданная для достижения определенных целей; может включать аппаратные средства, программное обеспечение, встроенное ПО, другие средства, людей, информацию, техники (подходы), службы и другие поддерживающие элементы (INCOSE: International Council on Systems Engineering)

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

Пример требований - тактовая частота процессора, объем памяти, требования к выбору операционной системы.

35. Источники требований. Стратегии выявления требований

Источники требований:

• Заказчики ИС

• Совладельцы системы: сотрудники аналитической группы исполнителя, внешние эксперты

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

• «лучшие практики»: описания моделей деятельности успешных компаний отрасли, используемые длительное время в сотнях и тысячах компаний по всему миру

Стратегии выявления требований:

1. Интервью с экспертами (Подготовка, Проведение, Завершение)

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

Типы интервью: (Структурированное (готовится заранее, отличается четкостью и ясностью постановки вопросов); Неструктурированное (неформальная встреча, вопросы заранее неизвестны. Цель интервью подтолкнуть заказчика к тому, чтобы он поделился мыслями и в процессе беседы подошел к требованиям))

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

Рекомендации: После интервью: (Составьте черновик С-требований (требований заказчика); Свяжитесь по электронной почте с Заказчиком для получения замечаний.

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

Недостатки: Большие затраты времени и денег. Требует прослушивание записей, подготовка к личной встрече, согласование с заказчиком; Результаты интервью могут искажаться неверно интерпретироваться; Результаты могут противоречить данным, полученным из других источников

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

3. Наблюдение (пассивное наблюдение. Активное. Объяснительное наблюдение.) Недостатки: наблюдатель, как и всякий "измерительный прибор", вносит помехи в результаты измерений: сотрудники организации, находясь "под колпаком" могут начать вести себя принципиально по другому, чем обычно

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

5. Совместные семинары Участники JAD-совещания: Ведущий - специалист в области межличностных коммуникаций. Должен ориентироваться в предметной области, но не обязательно хорошо ориентироваться в проблемах IT. Секретарь - стенографист встречи. Фиксирует ее результаты на компьютере. Возможно применение CASE-средств. Заказчики - пользователи или руководители, основные участники, формирующие, обсуждающие требования и принимающие решения. Разработчики - аналитики и другие участники проектной команды. Работают в большей части в пассивном режиме с целью наилучшего понимания проблемной области.

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