2. РАЗРАБОТКА И АНАЛИЗ ТРЕБОВАНИЙ  К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ

2.1. Введение в анализ требований

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

Результатом анализа требований является документ, который обычно называют спецификацией требований или спецификацией требований к программному обеспечению (SRS — Software Requirements Specification).

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

Этапы сбора и анализа требований

Процесс работы с требованиями к продукту можно разделить на 4 этапа:

•      определение концепции продукта;

•      сбор требований;

•      анализ требований;

•      проектирование системы.

Определение концепции продукта

Конце́пция (от лат. conceptio — понимание, система) — определённый способ понимания, трактовки каких-либо явлений, основная точка зрения. На этапе определения концепции продукта проводится работа с его заказчиком (инвестором), целью которой является выработка единого видения будущего программного продукта. По окончании этого этапа производится вывод о том, будет ли этот продукт разрабатываться или нет.

Сбор требований

На этапе сбора требований основная работа ведется с заказчиком системы и её будущими пользователями. Цель этапа — точно определить функции продукта и способы его интеграции в существующие процессы.

Качественное выполнение работ на этом этапе гарантирует то, что будущий продукт будет соответствовать ожиданиям заказчика. Четкая расстановка приоритетов обеспечивает реализацию наиболее востребованной функциональности и исключение второстепенной/невостребованной функциональности, что сэкономит бюджет проекта и время на разработку.

Анализ требований

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

Правильно сгруппированные требования помогут обойтись минимальным количеством функционала для удовлетворения максимально большего количества целей. 

Проектирование системы

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

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

На основе технического задания начинается моделирование работы программного продукта (ПП) с конечными пользователями (в качестве примера могут использоваться макеты пользовательского интерфейса) и производится тестирование технического задания. Это позволяет повысить качество продукта и снизить его стоимость, так как стоимость внесения изменений в техническое задание всегда меньше, чем в конечный продукт.

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

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

Таблица 2.1 Влияние качества работ на характеристики конечного продукта

Этап	Характеристики продукта
Разработка концепции	Ожидаемая прибыль, срок вывода на рынок и бюджет продукта. Дальнейшие перспективы развития продукта
Сбор требований	Качество — соответствие продукта ожиданиям заказчика. Срок вывода на рынок и ориентировочный бюджет продукта
Анализ требований	Эффективность разработки. Возможность корректировать функционал продукта в процессе реализации с целью его удешевления или охвата новых рынков пользователей
Проектирование системы	Эффективность разработки позволяет уменьшить количество вносимых изменений в уже готовый продукт. Качество реализации. Риски проекта (возможность их снижения). Эффективность разработки большими и/или распределенными командами

 

С-требования и D-требования

В течение некоторого времени среди программистов проходили споры относительно того, кому «принадлежат» требования: заказчику или разработчикам. Для решения этого вопроса анализ требований разделили на два уровня.

Первый уровень документирует желания и потребности заказчика и пишется на языке, понятном заказчику. Результаты иногда называют требованиями заказника, С-требованиями (customer). Первичной аудиторией для С-требований будет сообщество заказчиков, а уже вторичной — сообщество разработчиков. 

Второй уровень документирует требования в специальной, структурированной форме. Эти документы называются требованиями разработчика или  D-требованиями (detail). Первичной аудиторией для D-требований будет сообщество разработчиков, а уже вторичной — сообщество заказчиков.

Требования оформляются таким образом, что каждое из них должно быть:

•   четко выражено;

•   легко доступно;

•   пронумеровано;

•   сопровождаться подтверждающими тестами;

•   предусматриваться проектом;

•   учтено кодом;

•   протестировано отдельно;

•   протестировано совместно с другими требованиями;

•   подтверждено тестированием после того, как выполнена сборка приложения.

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

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

2.2. Описание С-требований (требований заказчика)

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

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

Например, возможным представлением о работе бюро погоды может быть следующее:

•   средство для преобразования необработанных материалов метеоцентра в графическое представление;

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

•   приложение, предупреждающее пользователей о погодных аномалиях.

Эти различные представления о работе программного продукта приведут к совершенно разным программным приложениям.

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

Ведущую роль в разработке концепции ведет бизнес аналитик (или Program/Product Manager), занимающийся этим продуктом. Для определения потребностей заказчика/рынка на весь срок разработки концепции проводится интенсивная работа с инвестором проекта. Цель — выработка единого видения будущего продукта. Если это заказной продукт, то инвестором является конечный заказчик. Если продукт предназначен для открытого рынка, то ответственными за него являются учредители компании или совет директоров. Далее на основе изученных и систематизированных требований аналитик вместе с командой экспертов создают образ будущего продукта. В заключение аналитик с экспертной командой определяют границы проекта, которые должны содержать ориентировочные сроки и бюджет продукта. На рисунке 2.1 показаны этапы разработки концепции продукта.

 

Рис. 2.1

Этапы разработки концепции продукта

Результатом разработки концепции является PVD (Product Vision Document — документ образа продукта, если продукт разрабатывается под заказ) или MRD (Marketing Requirement Document — документ рыночных требований, если продукт предназначен для открытого рынка). Эти документы содержат подробную информацию о требованиях заказчика, возможностях продукта, которые должны удовлетворять эти требования, а также ориентировочные сроки его реализации и бюджет. Различием между PVD и MRD является то, что в MRD обычно более детально описаны целевые сегменты рынка и сделан детальный обзор конкурентов. 

По окончании разработки концепции продукта делается вывод о целесообразности разработки ПП.

Сбор и анализ бизнес-требований

Первым и самым важным этапом в разработке продукта является сбор бизнес-требований. Цель этой работы — определить основные требования бизнеса (исходные данные, истинные цели, которым должен служить продукт, и проблемы, которые нужно преодолеть).

Для продуктов под заказ и продуктов для открытого рынка процесс сбора бизнес-требований существенно различается.

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

(табл. 2.2).

Таблица 2.2

Последовательность задач, выполняемых на этапе сбора бизнес-требований

Продукт под заказ	Продукт для открытого рынка
Определение исходных стимулов. Определение целей продукта и критериев успеха. Определение потребностей клиента. Обзор конкурентов	Определение исходных стимулов. Обзор конкурентов. Определение целевого сегмента рынка. Определение потребностей клиента. Определение целей продукта и критериев успеха

 

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

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

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

•   потребность рынка;

•   производственная необходимость;

•   потребность заказчика;

•   технический прогресс;

•   юридические ограничения или нормы.

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

Например, финансовые:

•   освоить Х% рынка за Y месяцев;

•   увеличить сектор рынка в стране X на Y% за Z месяцев;

•   достигнуть объема продаж X единиц или дохода, равного $Y, за Z месяцев;

•   получить Х% прибыли или дохода по инвестициям в течение Y меся-

цев;

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

•   сэкономить $Х в год, которые в настоящий момент расходуются на обслуживание системы;

•   уменьшить затраты на поддержку на Х% за Z месяцев;

•   увеличить валовую прибыль для существующего бизнеса с Х до Y%;

•   и другое.

Нефинансовые:

•   достигнуть показателя удовлетворения покупателей, равного X, в течение Y месяцев со времени выпуска товара;

•   увеличить производительность обработки транзакций на Х% и снизить уровень ошибок данных до величины не более Y%;

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

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

•   разработать специальную базовую технологическую основу для организации;

•   получить X положительных отзывов в отраслевых журналах к определенной дате;

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

•   соответствовать определенным федеральным и государственным постановлениям;

•   и другое.

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

Рынок домашних пользователей (может быть также разделен на обычных и квалифицированных пользователей).

Рынок корпоративных пользователей:

1.  SMB (Small and Medium Business) — компании, насчитывающие от 1 до 250 сотрудников. Также может быть разделен на Micro (или Soho) — 1– 10 сотрудников, Small — 10–25 — и Medium — 25–250.

2.  Large — компании, насчитывающие 250–2500 сотрудников.

3.  Corporation — корпорации с числом сотрудников более 2500.

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

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

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

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

Создание сценариев

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

Для продуктов под заказ сценарии использования продукта формируются самим заказчиком. Как правило, сколько заказчиков, столько и сценариев. Наиболее эффективным методом является живой диалог с заказчиком, в котором аналитик задает наводящие вопросы, а заказчик отвечает на них. Если личный контакт невозможен, то используют вопросники, содержащие «нужные» вопросы, по которым заказчику легче будет написать сценарий.

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

Важно не путать понятия клиента и пользователя. Клиентом может являться компания, в которой множество сотрудников будут являться пользователями системы. В таком случае профиль клиента описывает характерные черты и проблемы компании, а профиль пользователя (описываемый позднее) — характеристики её сотрудников.

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

Каждый сценарий должен содержать:

•                имя конкретного заказчика или его профиль (в качестве заголовка);

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

•                все процессы, которые будут затрагивать продукт;

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

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

•                приоритет. Зависит от того, насколько важен этот заказчик или как много покупателей будут попадать под профиль клиента, описанного в сценарии.

Определение функциональных требований и требований к дизайну

После сбора всей информации от пользователей необходимо ее систематизировать.

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

Функциональные бизнес-требования описывают потребность (заказчика/покупателя), которую должен удовлетворить будущий продукт. Основной вопрос, на который должны отвечать бизнес-требования, — зачем нужна та или иная функциональность.

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

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

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

Обзор конкурентов

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

Вторая цель обзора конкурентов — рассмотрение идей, реализованных в продукте.

Цель проста — использовать наиболее удачные решения, реализованные в конкурирующих продуктах, и исключить неудачные.  Структура обзора конкурентов следующая:

•                конкурентное положение на рынке;

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

•                список возможностей продуктов.

1.      Определить список конкурентов на рынке и выделить лидеров.

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

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

2.      Узнать цену и способ доставки ПП у конкурентов. 

Нужно посмотреть демонстрационную версию продукта или маркетинговые материалы, содержащие список возможностей и руководство пользователя.

3.      Составить список проблем конкурентов.

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

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

По завершении исследования проблем, которые решают ПП конкурентов, следует провести повторный анализ бизнес-требований к будущему продукту.

Полученная информация может улучшить бизнес-требования к ПП.

4.      Составить список возможностей. 

Здесь нужно описать все важные возможности, которые были реализованы в конкурентных продуктах для удовлетворения проблем, описанных в предыдущем пункте. На основе этого списка можно узнать, как хорошо продукт решает заявленные проблемы, какие у него сильные и слабые стороны.

На этом этапе изучается сам продукт либо его документация.

Результатом работы будет таблица со списком возможностей, которые предоставляют все продукты. В столбце продукта напротив каждой возможности должно быть указано, предоставляет ли конкретный продукт эту возможность (обычно помечаются как «+» или «−»).

5.      Резюме по сильнейшим конкурентам. 

Следует описать их преимущества и недостатки, выделить интересные идеи.

6.      Конкурентное положение на рынке.

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

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

Создание образа и списка возможностей будущего продукта 

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

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

Образ решения служит доказательством того, что разработчики выбрали правильный путь (или напротив), и оказывает наибольшее влияние при выборе команды разработчика для тендерных проектов.

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

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

Нефункциональные возможности должны содержать:

•   имя возможности;

•   приоритет возможности;

•   наличие этой функции у конкурентов (для каждого конкурента);

•   краткое описание возможности;

•   примечание для конкурентов.

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

Каждый элемент списка возможностей должен содержать:

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

•   приоритет;

•   наличие у конкурентов (желательно для каждого из конкурентов);

•   краткое описание (если требуется);

•   отметки о конкурентах;

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

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

В результате список возможностей должен содержать все высокоуровневые возможности, которые будут реализованы в продукте, а также уникальные, никем не реализованные возможности. 

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

•   «для» — целевая аудитория покупателей;

•   «который» — положение о потребностях или возможностях;

•   «этот» — имя продукта;

•   «является» — категория продукта;

•   «который» — ключевое преимущество, основная причина для покупки или использования;

•   «в отличие от» — основной конкурирующий продукт, текущая система или текущий бизнес-процесс;

•   «наш продукт» — положение об основном отличии и преимуществе нового продукта.

Список возможностей должен полностью соответствовать образу решения. 

Определение содержания контрольных событий проекта

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

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

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

Определение контрольных событий — это обязательный этап процесса разработки проекта, который тесно переплетен со сбором и детализацией требований к проекту. После определения концепции проекта невозможно точно определить срок его реализации. Бюджет может быть определен лишь на основе экспертной оценки, его точность обычно не превышает 50%. По завершении сбора и анализа требований точность оценки, сделанной на их основе, уже может достигать 60–70%. И только после завершения проектирования опытный менеджер сможет определить бюджет с точностью до 80–90%.

Определение основных профилей пользователей

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

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

 

Рис. 2.2

Пример диаграммы профилей пользователей продукта

Powered by TCPDF (www.tcpdf.org)

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

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

Для этого производится сбор пользовательских историй.

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

Ошибка, которую делают при сборе требований к продуктам, — это формирование образа продукта на основе ответов на вопросы: «Что должен делать продукт?» или «Как должен работать продукт?». Целью сбора требований является получение ответа на вопрос: «Для чего нужен продукт?». А потому единственный вопрос, который должен задаваться пользователю, — это «Зачем?».

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

Заказчики часто представляют себе приложение в форме графического пользовательского интерфейса. Описать работу ПП можно, используя черновой вариант пользовательского интерфейса. 

2.3. Шаги разработки пользовательских интерфейсов

Предлагается 11 этапов разработки пользовательских интерфейсов. 

1.  Узнайте своего пользователя (С) (обработка С-требований).

2.  Поймите назначение проектируемой системы (С).

3.  Примените принципы хорошего экранного дизайна (С, D (D-требования)).

4.  Подберите подходящий тип окон (С, D).

5.  Разработайте системные меню (С, D).

6.  Выберите соответствующие аппаратные устройства управления (С).

7.  Выберите соответствующие экранные элементы управления (С).

8.  Организуйте и создайте раскладку окон (С, D).

9.  Выберите подходящие цвета (D).

10.                      Создайте осмысленные значки (С, D)

11.                      Предоставьте эффективные сообщения, обратную связь и руководство (D).

Шаг 1 (знакомство с пользователем). На этом шаге рекомендуется оценить общество конечных пользователей программы. В общих чертах основные факторы приведены в таблице 2.3.

Таблица 2.3

Критерии, по которым оцениваются потенциальные пользователи ПП

Характеристика	Градации
Уровень знаний и опыт
Компьютерная грамотность	Высокий
	Средний
	Низкий → объяснить каждый термин
Системный опыт	Высокий
	Средний
	Низкий → представить примеры и анимацию
Опыт работы с подобными программами	Высокий
	Средний
	Низкий → представить примеры и анимацию
Образование	вуз
	Колледж
	Школа → использовать термины 12-го класса
Уровень чтения	> 12 лет в школе/5–7 классы/
	< 5 лет → использовать очень простой язык
Машинопись	135 слов в минуту/55/[10 → предоставить небольшие поля для ввода текста, примеры, уделить особое внимание формам для заполнения]
Физические характеристики пользователя
Возраст	Молодой/среднего возраста/пожилой
Пол	Мужской/женский
Развитие рук	Левша/правша/владеющий одинаково обеими руками
Физические недостатки	Слепой/дефекты зрения/глухой/моторные недостатки
Характеристики заданий и работы пользователя
Способ использования этой программы	По усмотрению/[обязательная → сделать программу интересной в использовании]
Частота использования	Постоянная/частая/случайная/[разовая → предоставить всю справочную информацию с каждым экраном]
Коэффициент текучести кадров	Низкий/средний/[высокий → предоставить всю справочную информацию с каждым экраном]

Продолжение табл. 2.3

Характеристика	Градации
Важность задания	Высокая/средняя/[низкая → сделать интересной в использовании]
Повторяемость задания	Низкая/средняя/[высокая → автоматизировать как можно больше шагов, предоставить разнообразие в представляемых данных, предоставить возможности обучения]
Предварительное обучение	Нет/самостоятельное изучение по справочникам/[интенсивное → предоставить интерактивную систему обучения]
Категория работы	Администратор/менеджер/профессионал/секретарь/[клерк и т. д. → использовать знакомый язык, примеры и описания]
Психологические характеристики пользователя
Вероятное отношение к работе	Положительное/безразличное/отрицательное
Вероятные мотивации	Высокие/средние/[низкие → сделать приложение особенно привлекательным]
Стиль процесса познания	Словесный или [пространственный → подчеркнуть геометрический вид] Аналитический или [интуитивный → подчеркнуть символы в тексте] Конкретный или [абстрактный → разработать обобщения]

 

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

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

Шаг 3 (понимание принципов хорошего экранного дизайна). Основные элементы хорошего экранного дизайна могут быть следующими:

1.                     Убедитесь в единообразии экранов приложения, а также в логичности каждого отдельно.

2.                     Сделайте предположение о том, откуда обычно пользователь будет начинать работу («первый» элемент размещают в верхнем левом углу).

3.                     Сделайте навигацию как можно более простой:

•      выровняйте похожие элементы;

•      сгруппируйте похожие элементы;

•      учтите границы вокруг похожих элементов.

4.      Примените иерархию для подчеркивания порядка важности.

5.      Примените принципы приятных визуальных эффектов:

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

•      простота, единообразие, пропорциональность.

6. Предоставьте подписи.

В качестве примера используем информацию о заказчиках и их банковских счетах. Для улучшения интерфейса в левом верхнем углу разместим наиболее важные элементы и сгруппируем похожие элементы (рис. 2.3). Далее производим «улучшение» интерфейса (рис. 2.4, 2.5).

 

Рис. 2.3

Применение принципов хорошего экранного дизайна — исходный вид

 

Рис. 2.4

Применение принципов хорошего экранного дизайна — улучшенный вид

 

Рис. 2.5

Применение принципов хорошего экранного дизайна

Шаг 4 (выбор подходящего типа окна). Цели каждого пользовательского интерфейса могут обслуживаться наиболее эффективно одним или двумя конкретными типами окон. Пять основных целей графического пользовательского интерфейса (ГПИ) и типы окон перечислены на рисунке 2.6.

 

Рис. 2.6 (начало) 

Использование окон 

 

Рис. 2.6 (окончание)  Использование окон 

Шаг 5 (разработка системного меню).  Правила для создания главных меню:

•   сделать главное меню;

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

•   привести структуру меню в соответствие со структурой задачи приложения;

•   минимизировать число уровней меню.

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

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

Шаг 7 (выбор подходящих экранных элементов управления). Экранные элементы управления — это символы, появляющиеся на мониторе, с помощью которых пользователь передает программе вводимые данные и своинамерения. Сюда относятся значки, кнопки, текстовые окна, списки, изображенные на рисунке 2.8. Правила организации экранных элементов управления в окне практически те же, что и для дизайна экрана в общем. Их число также обычно варьируется от пяти до девяти. Это число может быть увеличено в случае использования иерархии. 

Шаг 8 (организация и планирование окон). Правила для компоновки многочисленных окон аналогичны правилам для дизайна одиночных окон (в том числе симметрия, пропорциональность и т. д.), но сюда включена также и организация окон — соприкасающиеся или каскадные (рис. 2.7). 

 

Рис. 2.7

Общие соглашения по графическому пользовательскому интерфейсу

Шаг 9 (выбор подходящих цветов). Если цвет выбран с умением и со вкусом, то это может обогатить экран. Использование цвета не делает автоматически пользовательский интерфейс более полезным или привлекательным, однако может легко его испортить. По выражению знаменитого дизайнера Поля Рэнда, «цвет — это воплощение сложности». Инженеры-программисты, не сотрудничающие с профессиональными дизайнерами, должны быть очень умеренными и консервативными в использовании цветов. 

Шаг 10 (осмысленные значки). Значки в интерфейсе должны быть продуманы как в качественном, так и в количественном соотношении.

Шаг 11 (сообщения, обратная связь, руководства). Сообщения пользователю должны быть краткими и понятными. Пишется руководство по работе с программным проектом. 

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

2.4. Методологии и инструментальные средства  для С-требований

Для выражения требований используются многочисленные методологии. 

Структурный анализ формализует потоки данных и функциональную декомпозицию. В частности, технология структурного анализа и проектирования (SADT — Structured Analysis and Design Technique) является систематизированным подходом к работе с системными спецификациями. SADT описывает проблему на самом высоком функциональном уровне как прямоугольник с входами, ограничениями и выходами («диаграмма контекста»). Она разделяется в следующий уровень диаграммы потоков данных, который затем аналогично разделяется дальше. В результате появляется иерархия диаграмм с возрастающим уровнем детализации потоков данных. Структурный анализ рассматривает приложение с точки зрения функциональности. Эта функциональность и реализуется в иерархии функций. Системы реального времени могут быть эффективно описаны с помощью диаграмм переходов состояний, используемых объективным подходом. Большинство обозначений заимствованы в UML (Unified Modeling Language).

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

Чем детальнее прототип, тем легче понять требования заказчика. С другой стороны, прототипы сами по себе являются программами, поэтому чем детальнее прототип, тем он дороже. По мере того, как возрастают расходы на прототип, возрастает и его пригодность, но также возрастают и расходы из выделенного бюджета (рис. 2.8). Существуют момент, в который затраты оптимальны (точка максимума на кривой), и некоторая точка, за которой деньги уже потрачены зря (где кривая пересекает горизонтальную ось).

 

Рис. 2.8

Выгода от прототипа

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

Как только С-требования собраны, SРМР (Software Project Management Plan — план управления программным проектом) можно обновлять. Такое обновление происходит в течение всего жизненного цикла ПП.

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

2.5. D-требования (детальные требования)

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

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

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

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

Первым этапом анализа требования является выделение пользовательских историй в отдельные пакеты требований. Для специализированных систем управления требованиями вроде Borland Caliber RM или Rational Request Pro, в которых все требования хранятся в базе данных и представлены древовидным списком, пакетами являются элементы первого уровня, которые будут играть роль контейнера для всех остальных требований. При использовании текстовых документов пакетами будут являться отдельные файлы, возможно, с общим индексом.

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

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

2.6. Методы проектирования 

Существует два основных метода проектирования — проектирование на основе вариантов использования и проектирование на основе требований.

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

•                если необходимо сократить затраты на стадию анализа до минимума, а количество пользовательских историй в пакете невелико (их содержимое можно просмотреть не дольше чем за 10 мин).

•                команда разработки не умеет или не хочет работать с вариантами использования и требует предоставления требований к системе в классическом виде.

Варианты использования

Как правило, у всех пользовательских историй в пакете есть одна или несколько главных целей и история, которая описывает наиболее простой способ их достижения. Такая история называется базовой, а описание её действия — базовый путь. Остальные истории описывают альтернативный способ достижения результата или содержат дополнительные действия для достижения результата и являются дополнениями к базовой истории.

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

Главным критерием определения базового варианта использования является наличие общих со всеми остальными вариантами использования действий. Базовым вариантом использования могут быть существующая пользовательская история, которая имеет результат (приносит пользу), или абстрактный набор действий, который создан лишь для выделения общих шагов. Для определения базового варианта использования нет четкого правила, часто в одном и том же пакете есть возможность создать абстрактный вариант использования или взять за базу одну простейшую или несколько более сложных историй — и все эти решения будут верными.

Когда есть один или несколько базовых вариантов использования, описываются его связи с другими вариантами использования. Лучшим способом для этого является использование диаграммы вариантов использования. Этот вид диаграмм входит в стандарт UML и получил широкое распространение в сфере проектирования ПО. 

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

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

После того, как все отношения между вариантами использования определены, следует их отредактировать.

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

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

Цель этой работы — повысить информативность описания вариантов использования и избавиться от дублирования данных в пакете. В итоге каждый вариант использования должен содержать только уникальную информацию.

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

Если считать, что при сборе требований аналитик не дал возможности пользователям принимать проектные решения и в результате пользовательские истории содержат только «правильную» информацию, то будет два типа взаимоисключающих требований:

1.                     Ошибка в пользовательской истории. Автор допустил ошибку в описании истории, указав неправильное поведение системы. Как правило, основным признаком таких историй является невозможность их интеграции с другими элементами, но для уверенности нужно проконсультироваться с автором или специалистом в предметной области, прежде чем их удалить.

2.                     Разные взгляды на одну и ту же проблему. Несколько авторов имеют разные мнения о том, как должна работать система. Эта проблема может иметь два решения:

•                можно выбрать «более правильную» точку зрения и оставить только её.

Такое решение, как правило, можно принять на основе приоритетов историй;

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

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

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

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

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

•                элементы, являющиеся расширениями, должны стать дочерними элементами списка по отношению к тем, кого они расширяют. Если элемент имеет несколько родителей, то следует воспользоваться средствам трассировки или скопировать элемент в каждую ветку (с пометкой, что это копия).

Далее работы будут вестись как со списком, так и с диаграммой, поэтому оба этих представления следует поддерживать в рабочем состоянии.

Спецификация требований

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

Необходимо выделить все уникальные результаты пользовательских историй в отдельные требования. Если результат истории оказался уникальным, то его нужно преобразовать в требования (просто скопировать его тело, используя повелительное наклонение). Если же похожий результат уже был вынесен в требование в рамках другой пользовательской истории, то надо проанализировать их возможные отличия и, если они есть, модернизировать существующее требование или создать дополнительное дочернее требование/ограничение. Приоритет требования должен быть унаследован от родительской истории с максимальным приоритетом.

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

В результате этой работы должен быть получен древовидный список требований.

Каждое требование списка должно быть самостоятельным и не являться контейнером (структурной единицей для хранения дочерних элементов). Требования должны быть приоритезированы, причем дочернее требование не может иметь больший приоритет, чем родительское требование (которое оно дополняет).

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

Результатом этого процесса должен быть список требований, каждый элемент которого должен являться:

•                самостоятельным требованием — может расширять, а следовательно, и зависеть от родительского требования, но не должно быть зависимо от дочерних требований или требований того же уровня. Это означает, что реализация требования не должна требовать реализации каких-либо дочерних требований или требований того же уровня. Если требования связаны настолько сильно, что могут быть реализованы только вместе, их нужно объединить.

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

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

2.7. Типы D-требований

Существуют несколько типов требований.

1. Функциональные требования:

• функциональность приложения.

2. Нефункциональные требования:

1) производительность:

•      скорость;

•      пропускная способность (трафик);

•      использование памяти (оперативная память, жесткий диск);

2) надежность и доступность;

3) обработка ошибок;

4) интерфейсные требования (как программа взаимодействует с пользователем и с другими программами). Ограничения:

•   точность;

•   ограничения на инструменты и язык, например «должен использоваться С#»;

•   ограничения проектирования;

•   стандарты, которые должны быть использованы;

•   платформы, которые должны быть использованы.

3. Обратные требования (чего программа не делает).

1.      Функциональные требования.

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

2.      Нефункциональные требования.

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

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

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

Например, приложение, управляющее радарами аэропорта, должно давать не более двух ошибок в месяц.

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

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

Интерфейсные требования описывают формат, в котором программа общается с окружением. Например, требование пользователей программы: «Стоимость посылки статьи от адресата получателю должна постоянно показываться в текстовом окне „Цена“».

Ограничения на проектирование или реализацию описывают границы или условия того, как приложение должно быть задумано и разработано. Эти требования не должны использоваться вместо процесса проектирования — они всего лишь определяют условия, наложенные на проект заказчиком, а также окружение или другие обстоятельства. Например, точность: «Вычисления оценки ДТП ПС должны быть выполнены с точностью до одного сантиметра».

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

Обратные требования определяют, чего программа не будет делать. Логично, что существует бесконечное число обратных требований: мы выбираем только те, которые разъясняют возможное непонимание. Например: «ПС (см. предыдущий раздел) не обязательно должна анализировать данные ДТП».

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

2.1. Что такое требования к программному обеспечению?

2.2. Этапы сбора и анализа требований.

2.3. Как влияет качество работ на характеристики конечного продукта?

2.4. Понятие С-требований и D-требований.

2.5. Сбор и анализ бизнес-требований.

2.6. Для чего нужны сценарии?

2.7. Определение функциональных требований и требований к дизайну.

2.8. Обзор конкурентов на рынке ПП.

2.9. Создание списка возможностей будущего продукта.

2.10. Определение основных профилей пользователей.

2.11. Шаги разработки пользовательских интерфейсов.

2.12. Разработка прототипа ПО.

2.13. Детальные требования.

2.14. Проектирование на основе вариантов использования.

2.15. Проектирование на основе требований.

2.16. Функциональные детальные требования.

2.17. Нефункциональные детальные требования.