Опубликован: 18.06.2007 | Уровень: для всех | Доступ: платный | ВУЗ: Сибирский федеральный университет (г. Красноярск)
Лекция 10:

Расширенный анализ требований. Иллюстрированные сценарии и прототипы

< Лекция 9 || Лекция 10: 123 || Лекция 11 >
Аннотация: Особенности восприятия человеком вербальной и невербальной информации по отношению к моделям следует относить к визуальным прототипам. В этой лекции мы поговорим о прототипировании, рассмотрим основные цели, требующие применение прототипов, а также рассмотрим иллюстрированные сценарии прецендентов, которые наряду с прототипами позволяют достичь лучшего понимания между Заказчиком и разработчиком

- Вы действительно хотите, чтобы я поставил свою подпись под этим документом?

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

- Хорошо, я подпишу, но это ровным счетом ничего не значит.

- ??

- Ведь это всего лишь бумага, слова… А мне нужна программа, которая реально облегчит жизнь сотрудникам моего предприятия. Подпишу я сейчас документ или не подпишу - не имеет никакого значения. Важно лишь - сможете Вы или нет сделать такую систему, которая действительно принесет пользу. А это выяснится лишь, когда я смогу ее "пощупать".

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

И эта ситуация - не нонсенс. Каждый, кто выполнял проекты автоматизации рано или поздно сталкивается с ней. Что же делать - отказываться от выгодного проекта? Или взять на себя риск, что проект не будет принят в эксплуатацию: ведь при таком подходе к документу описания требований наверняка найдется что-то, очевидное для Заказчика, неожиданное для Исполнителя и не вошедшее в ТЗ. Хорошо, если придется переделывать 5% функций. А что, если 30% или 50%?

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

Цели прототипирования

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

Рассмотрим основные цели, требующие применения прототипов [10.1-10.2]:

  • прояснить неясные требования к системе;
  • выбрать одно из различных концептуальных решений;
  • проанализировать осуществимость.
  1. Неясные требования. Часто Заказчику бывает трудно сформулировать требования к тому, что он ожидает от системы. В этом случае прототип интерфейса пользователя (User Interface, UI), оперативно созданный по результатам интервью, дает ему возможность увидеть схематичную реализацию того, как Исполнитель увидел соответствующую часть системы. Что интересно - в данном случае полезен любой исход прототипирования: если Исполнитель понял требования хорошо - польза очевидна; если не очень - польза заключается в том, что Заказчик может указать, в чем заключается непонимание, тем самым решив основную задачу - сделать неясное ясным.
  2. Разные варианты решения. Любую техническую задачу можно решить различными способами. Это касается как задачи формулировки требований, так и ее реализации в UI.

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

    А) Сценарий последовательной обработки требований.

    • А1. Система отображает реестр требований, имеющихся во входной очереди.
    • А2. Пользователь выбирает очередное требование.
    • А3. Система отображает перечень материалов требования и справочник поставщиков.
    • А4. Пользователь сопоставляет каждой из позиций требования поставщика из справочника поставщиков.
    • А5. Система придает требованию статус "обработано", высылает по электронной почте автору требования уведомление.
    • А6. Продолжать с шага А1, пока очередь не опустеет.

    Б) Сценарий группировки по материалам.

    • Б1. Система отображает позиции всех требований и справочник поставщиков.
    • Б2. Пользователь группирует позиции по типу (так, чтобы однотипные позиции, поставляемые одним и тем же поставщиком, находились рядом).
    • Б3. Пользователь выбирает группу позиций и сопоставляет ей поставщика.
    • Б4. Система проверяет - не появились ли полностью обработанные требования. При положительном исходе проверки присваивает этим требованиям статус "обработано" и высылает по электронной почте автору требования уведомление.
    • Б5. Продолжать с шага Б1, пока очередь не опустеет.

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

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

  3. Анализ осуществимости. Часто бывает так, что комбинация функциональных, нефункциональных требований и ограничений такова, что возникает риск невозможности их реализации. Как правило, такой риск связан с требованиями к быстродействию системы при известных ограничениях среды ее реализации. В этом случае создаются прототипы (не обязательно, связанные с UI), реализующие соответствующую часть системы, имитирующие потоки данных, поступающие на ее вход и их обработку.
< Лекция 9 || Лекция 10: 123 || Лекция 11 >
Ринат Гатауллин
Ринат Гатауллин

Здравствуйте. Интересует возможность получения диплома( https://intuit.ru/sites/default/files/diploma/examples/P/955/Nekommerch-2-1-PRF-example.jpg ). Курс пройден. Сертификат не подходит. В сертификате ошибка, указано по датам время прохождения около 14 дней, хотя написано 576 часов.

Аминат Албакова
Аминат Албакова

Здравствуйте, я прошла весь курс, но нигде не указано, что курс завершился удачно или что-то в этом роде, не знаю что делать, как получть диплом в электронном виде?

Анатолий Федоров
Анатолий Федоров
Россия, Москва, Московский государственный университет им. М. В. Ломоносова, 1989
Алексей Махонин
Алексей Махонин
Россия, Волжский, Средняя школа №12, 1990