После того, как ограничения выявлены, некоторые из них станут требованиями к новой системе. Например, для компании торговли через интернет выявлены следующие ограничения: +-----------------+------------------+--------------------------+ |Источник |Ограничения |Пояснения | +-----------------+------------------+--------------------------+ |Эксплуатационный |Копия данных зака-|Риск потери данных слишком| | |за на покупку дол-|высок. Необходима беспере-| | |жна оставаться в | | | |унаследованной БД | | | |в течение одного | | | |года | | |Системы и ОС |Приложение должно |Количество доступной памя-| | |занимать на серве-|ти ограничено | | |ре не более 200 МБ| | |Средства, выде- |Система должна |+----------- | |ленные на обору- |быть разработана || | | |дование |на существующем | ----------+ | | |сервере. Для поль-| | | |зователей можно | | | |предложить новое | | | |клиентское АО | | |Средства, выде- |Фиксированный |Фиксированные расходы на | |ленные на оплату |штат, не привле- |зарплату по отношению к | |труда |кать новых работ- |текущему бюджету | | |ников со стороны | | |Технические огра-|Должна испльзова- |Надеемся +------------ | |ничения |ться объектно-ори-| | | | | |ентированная мето-| ------------+ | | |дология | | +-----------------+------------------+--------------------------+ Функции программного продукта и потребности заинтересованных лиц и пользователей Команда разработчиков может создать хорошую систему только в том случае, если она понимает реальные потребности заинтересованных лиц. Потребность - это отражение некой лично, рабочей или бизнес-проблемы, решение которой оправдывает замысел, покупку или использование нового программного продукта. Говоря о потребностях, пользователи обычно представляют их в виде функций. Недостатком подхода, основанного только на функциях, является то, что часто непонятно, какая потребность стоит за функцией, что может привести к ошибкам при создании программного продукта. Функция - это обслуживание, предоставляемое системой для выполнения одной или нескольких потребностей заказчика. Примеры функций: прикладная область: система управления элеватором, функция: осуществлять вручную управление дверью при угрозе пожара; прикладная область: система управления запасами, пример функции: предоставлять свежую информацию о состоянии всех инвентарных единиц; система обработки платёжных ведомостей: сообщать текущее начисление по категориям. Количество функций рекомендуется от 25 до 99. Атрибуты функций программного продукта Атрибуты функций обеспечивают дополнительную информацию о каждой функции. Присваивая функциям различные атрибуты, можно успешно управлять сложностью представления информации. +----------------------+------------------------------------+ |Атрибут |Описание | +----------------------+------------------------------------+ |Статус |Отслеживает ход процесса определения| | |базового уровня проекта | |Приоритет/полезность |Функции различаются своей важностью,| | |нужно определять их масштаб и оче- | | |рёдностью: критическое, важное, по- | | |лезное | |Трудоёмкость |Желательно записать этот атрибут в | | |виде человекочасов или командочасов | | |(командонедель) | |Риск |+-------------- | | || | | | | --------------+ | |Стабильность |Вероятность того, что данная функция| | |будет меняться или будет меняться её| | |понимание командой; обычно приводят-| | |ся качественные характеристики: вы- | | |сокая/средняя/низкая. | |Целевая версия |Версия продукта, в которой впервые | | |появится данная функция. Комбиниро- | | |вание этого атрибута с атрибутом | | |статуса позволяет команде предла- | | |гать, записывать или обсуждать раз- | | |личные функции, не прибегая к их | | |разработке | |Назначение |Во многих проектах функции будут | | |приписываться "функциональным коман-| | |дам", ответственным за их дальнейшую| | |доработку, написание программных | | |требований, а также, возможно, и ре-| | |ализацию | |Обоснование появления |Используется для отслеживания источ-| | |ника функции, например, ссылка может| | |указывать на номер строки специфика-| | |ции продукта, или видеомаркер на | | |важном интервью с клиентом | +----------------------+------------------------------------+ Выявление требований Проблемы, связаные с выявлением требований: 1) проблема непонимания пользователем того, что будет представлять собой разрабатываемая система: пользователь никогда раньше не видел новую систему, не понимает её описание, структуру и т. д.: в других областях техники веками сложилась технология моделей: чертежи, физические макеты, действующие прототипы, пробные промышленные изделия; все они осязаемы и действуют аналогично разрабатываемому устройству; 2) проблема новых требований: чем больше найдено требований, тем лучше известно, что это ещё не всё; 3) проблема общения пользователя и разработчика. Синдром пользователя и разработчика заключается в том, что пользователь и разработчик обычно принадлежат к разным мирам, говорят на разных языках, имеют различный опыт, мотивацию и цели. +---------------------+--------------------------------+ |Проблема |Решение | +---------------------+--------------------------------+ |Пользователи не зна- |Назначить пользователя экспертом| |ют, чего они хотят, а|предметной области, ценить его в| |если знают, то не мо-|этом положении, использовать | |гут сформулировать |альтернативные методы общения и | | |выявления требований | |Пользователи думают, |Как можно раньше предлагать аль-| |что они знают, чего |тернативные методы выявления: | |хотят, до тех пор, |раскадровку, прототипы, ролевые | |пока разработчики не |игры и т. д. | |предоставят им то, | | |что они якобы хотели | | |Аналитики думают, что|Поставить аналитика на место | |они понимают проблему|пользователя, провести игру в | |пользователя лучше |течение часа или целого дня | |него самого | | |Все считают, что дру-|Такова человеческая натура, тут | |гие руководствуются |ничего не изменишь | |политическими мотива-| | |ми | | +---------------------+--------------------------------+ Методы выявления требований Существует множество методов выявления требований, основные: интервьюирование и анкетирование, совещание, посвящённое требованиям, мозговой штурм и отбор идей, описание прецедентов, раскадровки, обыгрывание ролей, создание прототипов. Выбор конкретного метода (методов) зависит от типа приложения, опыта и уровня подготовки команды разработчиков, заказчика, масштаба проблемы, критичности приложения, его уникальности и используемой технологии. Интервьюирование - это форма очного проведения опроса, при котором исследователь находится в непосредственном контакте с респондентом. Этот метод предпочтительнее анкетирования исходя из следующих соображений: 1) при таком методе вопросов без ответов практически не бывает; 2) неопределённые или противоречивые ответы могут быть уточнены; 3) имеется возможность наблюдения за респондентом и фиксации не только его вербальных ответов, но и невербальных реакций. Недостатки: 1) малая оперативность; 2) существенные затраты времени; 3) необходимость большого числа интервьюеров; 4) высокие требования к подготовке аналитика: для начинающих аналитиков этот метод представляет большие трудности, поскольку требует специальной подготовки и длительного тренинга. Контекстно-свободные вопросы Нужно избежать предубеждения пользователя при ответах на вопросы. Для этого нужно задавать вопросы о природе проблемы пользователя, никак не связывая их с возможным решением. Для этого Гаусс и Вайнберг ввели понятие "контекстно-свободный вопрос". Примеры таких вопросов: "Кто является пользователем?", "Кто является клиентом?", "Отличаются ли их потребности?", "Где ещё можно найти решение данной проблемы?". Эти вопросы позволяют выслушать заказчика прежде, чем пытаться предложить потенциальное решение. Добавление контекста После ответов на контекстно-свободные вопросы полезно сместить вопросы в область исследования решений, обсуждение предлагаемых решений поможет пользователю углубить или даже изменить взгляд на проблему, найти ещё не обнаруженные требования. Образец интервью Часть I: определение профиля заказчика или пользователя Компания Отрасль Должность Фамилия Каковы Ваши основные обязанности? Что Вы в основном производите? Для кого? Как измеряется успех Вашей деятельности? Какие проблемы влияют на успешность Вашей деятельности? Какие тенденции (если такие существуют) делают Вашу работу проще или сложнее? Часть II: оценка проблемы Для каких проблем (прикладного типа) Вы ощущаете нехватку хороших решений? Назовите их (ещё вопросы). Для каждой проблемы выясняйте следующее: почему существует эта проблема, как она решается в настоящее время, как заказчик (пользователь) хотел бы её решить. Часть III: понимание пользовательской среды Кто такие пользователи? Какое у них образование? Каковы их навыки в компьютерной области? Имеют ли пользователи опыт работы с приложениями подобного типа? Какая платформа пспользуется? Каковы планы относительно будущих платформ? Используются ли дополнительные приложения, которые имеют отношение к данному? Если используются, то пусть о них немного расскажут. Каковы ожидания заказчика относительно практичности продукта? Сколько времени необходимо на обучение? В каком виде должна быть представлена справочная информация для пользователя? Часть IV: резюме (перечисляются основные пункты, чтобы проверить, правильно ли всё понято) Итак, Вы сказали мне, что... Адекватно ли этот список передаёт проблемы, которые имеются в настоящее время? Какие ещё проблемы Вы испытываете? Часть V: предложения аналитика относительно проблемы заказчика Выяснить, какие проблемы, если они есть, связаны с (перечислите все потребности или дополнительные проблемы, которые по Вашему мнению может испытывать заказчик или пользователь; для каждой из этих проблем выясните следующее: является ли она реальной, каковы её причины, как она решается в настоящее время, как бы заказчик или пользователь хотел её решить, насколько важно для заказчика или пользователя решение этой проблемы в сравнении с другими упомянутыми им). Часть VI: оценка предлагаемого Вами решения (если это уместно) Охарактеризовать основные возможности предлагаемого Вами решения, а потом задавать пользователю следующие вопросы: Что, если Вы сможете... Как Вы расцениваете важность... Часть VII: оценка возможностей Кто в организации нуждается в данном приложении? Сколько пользователей указанных типов будут использовать его? Насколько значимо для Вас успешное решение? Часть VIII: оценка необходимого уровня надёжности и производительности, а также потребности в сопровождении Каковы Ваши ожидания относительно надёжности? Какой, по-Вашему, должна быть производительность? Будете ли Вы заниматься поддержкой продукта или этим будут заниматься другие? Испытываете ли Вы потребность в поддержке? Что Вы думаете о доступе для сопровождения и обслуживания? Каковы требования относительно безопасности? Каковы требования относительно установки и конфигурации? Существует ли специальное требование по лицензированию? Как будет распределено ПО? Есть ли требования по маркетингу и упаковке? Часть IX: другие требования Существуют ли законодательные требования, требования информационной среды, инструкции или другие стандарты, которых необходимо придерживаться? Нет ли других требований, о которых нам следовало бы знать? Часть X: окончание интервью Существуют ли другие вопросы, которые мне следовало бы задать? Если мне понадобится задать Вам несколько вопросов, могу ли я Вам позвонить? Будете ли Вы принимать участие в обсуждении требований? Часть XI: заключение аналитика После интервью, пока его данные свежи в Вашей памяти, зафиксируйте наиболее важные проблемы с наиболее высшими приоритетами, выявленные в беседе. Подготовка к проведению интервью Подготовьте интервью и запишите его в записную книжку, просмотрите вопросы непосредственно перед беседой. Перед интервью соберите информации о клиенте, о его компании. Не задавайте вопросы, ответы на которые можно узнать заранее, однако полезно кратко сверить эти ответы. Кратко записывайте ответы в записную книжку, не пытайтесь в это время сохранять данные в электронном виде. Интервьюер должен стараться, чтобы сценарий не был слишком увлёкся. Если клиент увлёкся, не перебивайте его следующим вопросом. Уже после нескольких интервью исследователь получает некоторые знания о предметной области, понимание решения проблемы, а также представления пользователя об её успешном решении. Если проблемы начинают повторяться, это значит, что исследователь нашёл общие потребности и дальше можно приступать к уточнению функций.