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

4.1. Определение предметной области

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

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

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

4.2. Анализ предметной области (анализ осуществимости, бизнес - моделирование)

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

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

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

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

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

Анализ предметной области является основой для анализа осуществимости проекта и определения образа (концепции) продукта и границ проекта.

Анализ осуществимости

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

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

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

Постановку бизнес-задачи надо обсуждать с Заказчиком, или будущим Владельцем системы.

Вопросы, которые ему стоит задать, это:

В качестве "Стандарта" на вопросы такого рода смотрите шаблон документа "Stakeholder Request", например, из RUP. Бизнес-требования может выразить Заказчик или Эксперты предметной области. Они обычно фиксируются в виде списка из 10-30 ключевых свойств продукта - в качестве шаблона см. Vision из RUP.

Бизнес-моделирование надо проводить на основе информации от, а лучше совместно с экспертами предметной области. Вопросы по сути сводятся к "Что, почему, когда, как и кем происходит в предметной области и как оно взаимосвязано?":

Существует российский стандарт функционального моделирования P 50.1.028-2001, созданный на основе IDEF0.

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

Результаты анкетирования/интервьюирования обычно представляют в виде пользовательских историй (User Story, Agile) или Пользовательских сценариев (Use-case), также возможно их диаграммное представление средствами диаграмм потока работ (IDEF3), ARIS, Activity/State UML Diagram. Подробнее про работу с Пользователями могут рассказать специалисты по Проектированию взаимодействия, интерфейсам и эргономике.

Системные требования нужно выяснять у IT-специалистов Заказчика, если таковые имеются, из специфики контекста использования системы, опыта построения аналогичных систем (у IT-Экспертов-Архитекторов) и Специалистов по отдельным аспектам системы, значимым для данного проекта (Юристы, Эргономисты, и т.д.) и Заказчика:

Переработанный результат оформляется в виде Системных требований (Software Requirement Specification, стандарт IEEE-STD-830-1998, или ТЗ ГОСТ 34-602-89 или неформально в виде Supplementary Specificaion из RUP).

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

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

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

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

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

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

4.3. Формирование и документирование требований к проекту

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

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

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