9 ) Задачи анализа требований. Основные виды работ при анализе.

Задача: исследование предметной области, выявление роли и места будущей программной системы, её основных функций и характеристик.

1. Исходная постановка задачи

Постановка задачи выполняется на самом общем уровне, часто неформально. Нередко в результате проводимого анализа изначальная постановка задачи меняется до неузнаваемости.

2. Сбор и исследование информации

Эта работа — главная часть процесса анализа требований. Источники информации могут быть любые: публикации в книгах и журналах, конференции и семинары, Internet, личные контакты. Тот, кто способен ставить общие задачи (например, начальник) ценен тем, что обладает широким видением проблемы и пониманием перспектив. Тот, кто с вашим продуктом будет работать, знает реальные, а не гипотетические трудности и множество важных деталей и нюансов. Можно смело утверждать, что без общения с реальными практиками-специалистами невозможно выполнить качественный анализ требований, а продукт, основанный на столь зыбком фундаменте, пользователи будут игнорировать или даже ненавидеть.

Важнейшие для анализа виды информации:

• Данные о предметной области в целом.

• Данные о существующих аналогах и конкурентах.

• Данные о специфике предприятия-заказчика:

  • Уровень квалификации пользователя/заказчика

  • Требования безопасности

  • Степень распределённости заказчика (речь о сети, её видах)

  • Унаследованное ПО

3. Выбор приоритетных критериев качества

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

4. Определение входных, хранимых и выходных данных

Представляя будущую программу как «черный ящик», необходимо определить, какие данные программа будет получать на входе, какие долговременно хранить и какие выдавать в результате своей работы. Описания данных даются в терминах рассматриваемой предметной области: счета, накладные, отчеты, сигналы с датчиков...

5. Формализация требований

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

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

Назначение ТЗ: юридическое и технологическое.

10 ) Варианты использования: определение, роль в жизненном цикле.

Вариант использования — это формальное описание взаимодействия системы и пользователя при решении конкретной задачи, например «Отправить почтовое сообщение». Название ВИ традиционно имеет форму команды и начинается с глагола. В описании ВИ используется более общий термин actor (действующее лицо), чем просто пользователь. Действующее лицо может быть как пользователем, так и другой программой или даже другой частью этой же системы.

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

• Краткий (brief) ВИ состоит из одного-двух описательных предложений. Он хорош при сведении функциональных требований в таблицу при планировании приоритетности, технической сложности, номера версии продукта и т. д.

• Бессистемный (casual) ВИ является более подробным и объёмным описанием развития событий, но без какой-либо строгой предопределённой структуры изложения.

• Детальный (detailed) ВИ — это формальный документ с предопределнной структурой разделов.

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

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

1. Название (Name). Краткое, максимально понятное, в виде команды (что сделать).

2. Цель (Goal). Краткая характеристика задачи, которую должен в результате решить ВИ.

3. Начальное состояние (Initial state). Формулировка условий, при которых данный ВИ может быть инициирован. Условие, помимо прочего, может быть упоминанием о выполнении других ВИ.

4. Основной сценарий (Main scenario). Сценарий — это последовательность шагов, описывающая процесс решения задачи, которой посвящен ВИ. Шаги удобно последовательно нумеровать.

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

Если в ВИ есть альтернативные сценарии, то каждый из них начинается с предусловия. Предусловие указывает шаг основного сценария (или другого альтернативного сценария) с формулировкой условия ветвления.

Кроме того, ВИ может содержать дополнительные разделы: список действующих лиц, использующих данный ВИ; условия успешности и неуспешности ВИ; требования к производительности, надёжности; важность; частота использования; автор; область действия (scope) и т. д.

Роль в жизненном цикле.

На этапе анализа ВИ используются как средство фиксации функциональных требований.

В процессе проектирования и программирования ВИ используются как источник информации о постановке задачи.

В процессе тестирования ВИ применяются как основа сценария тестирования. В процессе выполнения сценария тестирования проверяется, делает ли система то, что предусмотрено вариантом использования.

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