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

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

Все требования разбиваются на три уровня:

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

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

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

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

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

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

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

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

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

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

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

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

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

Существует большое число атрибутов качества. Например, стандарт ISO 9126 предлагает оценивать программную продукцию по шести характеристикам качества , рекомендуя использовать 21 показатель (подхарактеристику ) качества . Этот же стандарт советует учитывать, что представления о качестве для разных групп заинтересованных лиц отличаются, приводя в качестве примера представления о качестве пользователей, разработчиков и руководителей проекта.

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

Производительность

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

Надежность и доступность

Надежность – это вероятность работы системы без сбоев в течение определенного времени. Для измерения надежности может быть использовано среднее время работы системы до сбоя.

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

Безопасность

Удобство и простота обслуживания

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

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

Легкость сопровождения и эксплуатации

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

Мобильность

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

Повторное использование

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

Тестируемость

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

Значительной популярностью при разработке автоматизированных систем в настоящее время в России пользуется универсальный язык моделирования (Unified Modeling Language - UML). Несмотря на безусловные плюсы, использование UML сопряжено с рядом трудностей методического характера, на которые мы хотели бы обратить внимание читателя. Прежде всего, в UML вводится собственный понятийный аппарат, в рамках которого традиционные термины и понятия, связанные с созданием автоматизированных систем и используемые в течение десятилетий, заменяются на термины и понятия, не нашедшие пока в полной мере отражения в международных и отечественных стандартах в области информационных технологий.

Особенно это касается базового элемента языка UML "Use Case", который трактуется отечественными переводчиками как "вариант использования", "прецедент". При этом контекст, в котором переводится термин, не учитывается. Несмотря на то, что понятие активно используется уже довольно давно - путаницы возникает все больше и больше. Так, участники некоторых Интернет- форумов дошли до того, что сравнивают "Use Case" с техническим заданием. По мнению авторов, все это обусловлено стандартным описанием UML, не связанным с процессом разработки автоматизированных систем (АС), а также упущенной возможностью при переводе оригинала такое сопоставление произвести. К тому же существующие современные методики создания программных систем от ведущих мировых производителей, основанных на использовании UML и других нотациях, к сожалению, большинству отечественных разработчиков в оригинале просто не доступны.

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

В данной статье представлен способ описания функциональных требований к АС и ее функций с использованием стандартов в области информационных технологий, современных методологий создания АС, и диаграмм "Use Case Diagram" и "Actvity Diagram" универсального языка моделирования UML 2.0. Авторы рассчитывают, что использование "Use Case" в контексте определения требований в соответствии со стандартами создания АС приобретет большую ясность.

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

При использовании стандартов создания АС в соответствии с на стадии "Техническое задание" в документе техническое задание (ТЗ) фиксируются функциональные и нефункциональные требования к АС. АС разрабатывается на стадии "Эскизное проектирование" и "Техническое проектирование", описание автоматизируемых функций АС производится на стадии "Техническое проектирование".

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

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

Как видно из табл. 1, создание АС на стадиях 3-5, подразумевает подготовку:

    технического задания;

    предварительной схемы функциональной структуры системы (эскизное проектирование);

    окончательной схемы функциональной структуры (техническое проектирование);

    описания автоматизируемых функций системы.

Таблица 1. Стадии создания АС и документы, связанные с требованиями к АС и функциями, их реализующими

№ стадии по ГОСТ 34.601-90

Наименование
стадии по ГОСТ 34.601-90

Документы, модели, создаваемые на стадиях по

ГОСТ 34.602-89,
ГОСТ 34.201-89

ГОСТ, в котором описан документ

Техническое задание

Техническое задание (ТЗ)

Эскизное
проектирование

Схема функциональной структуры

РД 50-34.698-90 п. 2.3.

Техническое
проектирование

Схема функциональной структуры

Описание автоматизируемых
функций

РД 50-34.698-90 п. 2.5

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

В ТЗ определяются:

    требования к системе в целом;

    требования к функциям (задачам), выполняемым системой;

    требования к видам обеспечения.

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

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

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

В описании автоматизируемых функций приводят:

    перечень подсистем АС с указанием функций и (или) задач, реализуемых в каждой подсистеме;

    описание процесса выполнения функций;

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

Теперь рассмотрим определение требований с использованием понятия "Use Case". Как уже говорилось ранее, в стандарте UML отсутствует привязка к стадиям создания АС, однако, производители CASE - средств для работы с UML и методологий использования UML, как правило, предлагают схожие подходы к работе с требованиями.

Рассмотрим, например, подход компании Sparx System, являющейся производителем инструментария Еnterprise Architect, поддерживающим создание моделей предметной области и АС с использованием UML 2.0. Ими предложен шаблон модели требований, представленный на рис. 1. На рис. 2 представлен пример модели требования с использованием шаблона.

Как видно из шаблона модели требований и его примера для моделирования требований предлагается использовать элемент UML "Requirement". Для моделирования функций системы предлагается использовать элемент "Use Case". При этом элемент "Use Case" в описании UML, представленном в инструменте Еenterprise Architect, трактуется следующим образом: "Use Case elements are used to build Use Case models . These describe the functionality of the system to be built. Use Case Model describes a system"s functionality in terms of Use Cases".

Другими словами, элемент "Use Case" используется для построения модели "Use case Model". Модель "Use case Model" используется для описания функциональности системы.

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

В спецификациях OMG UML (UML Superstructure Specification, v2.0, p. 17) элемент "Use Case" определяется как: "The specification of a sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system".

Другими словами, элемент "Use Case" определяет последовательность действий системы, которые она может выполнять, включая ее взаимодействие с пользователем системы.

Рис. 1. Способ моделирования требований к системе

Рис. 2. Пример реализации требования

В дополнении к сказанному выше, хотелось представить определение модели "Use Case Model" из популярного в нашей стране и за рубежом процесса разработки систем Rational Unified Process компании IBM: "The use-case model is a model of the system"s intended functions and its environment …" (рис. 3).

Рис. 3. Определение модели "Use Case Model"

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

В табл. 2 представлено сравнение определений схемы функциональной структуры в соответствии с ГОСТ и модели "Use Case Model", функции системы и элемента "Use Case" в соответствии с описанием UML 2.0.

Таблица 2. Сравнение определений моделей и их элементов

Определение схемы функциональной структуры

Определение модели "UseCaseModel"

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

Если требуется в разделе указывается время выполнения функции. Время формирования отчета не должно превышать 5 сек.

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

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

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

Связи с другими функциональными требованиями

Если требуется, в разделе указываются связи между требованиями.

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

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

Список литературы

    ГОСТ 34.601-90 "АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. СТАДИИ СОЗДАНИЯ";

    ГОСТ 34.602-89 "ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА СОЗДАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ";

    ГОСТ 34. 201-89. ВИДЫ, КОМПЛЕКТНОСТЬ И ОБОЗНАЧЕНИЕ ДОКУМЕНТОВ ПРИ СОЗДАНИИ АВТОМАТИЗИРОВАННЫХ СИСТЕМ;

    ГОСТ 34.003-90. "АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ";

    IBM/RATIONAL UNIFIED PROCESS;

    ГОСТ Р ИСО/МЭК 15026-2002. ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ. УРОВНИ ЦЕЛОСТНОСТИ СИСТЕМ И ПРОГРАММНЫХ СРЕДСТВ;

    РД 50-34.698-90. "АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ДОКУМЕНТОВ";

    ГОСТ 28806-90. ГОСТ КАЧЕСТВО ПРОГРАММНЫХ СРЕДСТВ. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ;

    требования к программному обеспечению - — [Л.Г.Суменко. Англо русский словарь по информационным технологиям. М.: ГП ЦНИИС, 2003.] Тематики информационные технологии в целом EN software requirement … Справочник технического переводчика

    ГОСТ Р 53195.4-2010: Безопасность функциональная связанных с безопасностью зданий и сооружений систем. Часть 4. Требования к программному обеспечению - Терминология ГОСТ Р 53195.4 2010: Безопасность функциональная связанных с безопасностью зданий и сооружений систем. Часть 4. Требования к программному обеспечению оригинал документа: 3.1 анимация (animation): Имитация работы программного… …

    ГОСТ Р 52980-2008: Системы промышленной автоматизации и их интеграция. Системы программируемые электронные железнодорожного применения. Требования к программному обеспечению - Терминология ГОСТ Р 52980 2008: Системы промышленной автоматизации и их интеграция. Системы программируемые электронные железнодорожного применения. Требования к программному обеспечению оригинал документа: 3.1 автоматическая локомотивная… … Словарь-справочник терминов нормативно-технической документации

    ГОСТ Р 8.654-2009: Государственная система обеспечения единства измерений. Требования к программному обеспечению средств измерений. Основные положения - Терминология ГОСТ Р 8.654 2009: Государственная система обеспечения единства измерений. Требования к программному обеспечению средств измерений. Основные положения оригинал документа: 3.18 алгоритм хэширования: Алгоритм, который сжимает… … Словарь-справочник терминов нормативно-технической документации

    МИ 2891-2004: Рекомендация. ГСОЕИ. Общие требования к программному обеспечению средств измерений - Терминология МИ 2891 2004: Рекомендация. ГСОЕИ. Общие требования к программному обеспечению средств измерений: Данные измерительная информация, представленная в виде, пригодном для передачи, интерпретации или обработки. Определения термина из… … Словарь-справочник терминов нормативно-технической документации

    ГОСТ Р 8.674-2009: Государственная система обеспечения единства измерений. Общие требования к средствам измерений и техническим системам и устройствам с измерительными функциями - Терминология ГОСТ Р 8.674 2009: Государственная система обеспечения единства измерений. Общие требования к средствам измерений и техническим системам и устройствам с измерительными функциями оригинал документа: вид средства измерений:… … Словарь-справочник терминов нормативно-технической документации

    МИ 3372-12: Рекомендация. Государственная система обеспечения единства измерений. Магистральный нефтепродуктопровод. Системы измерений количества и показателей качества нефтепродуктов. Общие технические и метрологические требования - Терминология МИ 3372 12: Рекомендация. Государственная система обеспечения единства измерений. Магистральный нефтепродуктопровод. Системы измерений количества и показателей качества нефтепродуктов. Общие технические и метрологические требования:… … Словарь-справочник терминов нормативно-технической документации

    СА 03-002-05: Стандарт ассоциации. Системы мониторинга агрегатов опасных производственных объектов. Общие технические требования - Терминология СА 03 002 05: Стандарт ассоциации. Системы мониторинга агрегатов опасных производственных объектов. Общие технические требования: 2.1. Агрегат: совокупность механически соединенных механизмов, узлов, машин и конструкций, работающих… … Словарь-справочник терминов нормативно-технической документации

    П ССФЖТ 45/ИСО 9001-2003: Системы менеджмента качества. Требования - Терминология П ССФЖТ 45/ИСО 9001 2003: Системы менеджмента качества. Требования: 3.7 запись: Документ, содержащий достигнутые результаты или свидетельства осуществленной деятельности (ГОСТ Р ИСО 9000). Определения термина из разных документов:… … Словарь-справочник терминов нормативно-технической документации

    ГОСТ Р 51904-2002: Программное обеспечение встроенных систем. Общие требования к разработке и документированию - Терминология ГОСТ Р 51904 2002: Программное обеспечение встроенных систем. Общие требования к разработке и документированию оригинал документа: 3.1 алгоритм: Конечное множество четко определенных правил, которые задают последовательность действий … Словарь-справочник терминов нормативно-технической документации

Книги

  • Технические средства автоматизации. Интерфейсные устройства и микропроцессорные средства. Учебное пособие , В. Ф. Беккер. В соответствии с тенденцией информатизации современных технических средств автоматизации описываются датчики, интерфейсные, микропроцессорные и компьютерные устройства. Излагаются основные…
  • Средства мультимедиа , С. В. Киселев. В учебном пособии предлагается применение компетентностного подхода к подготовке операторов ЭВМ. Изложены основы использования мультимедийных программ на IBM-совместимых персональных…

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

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

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

В базе хранятся не только сами описания и иллюстрации, но и шаблоны, задающие формат хранения материалов, определяющие интерфейс ввода/вывода и представление материала вразличного типа отчётах. Шаблоны описывают 3 компоненты: MVC – model, viewer, controller.

На рисунке 7 изображены доступные действия для пользователей ПС.

Пользователь должен иметь возможность:

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

    добавлять данные для составления отчёта.

    применять шаблоны для генерации отчётов.

    редактировать и просматривать сгенерированные отчёты.

    создаватьи редактировать картографические схемы и планы.

    применять темы оформления web-приложения.

Рисунок 7

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

    Добавление на карту специальных отметок.

    Сохранение карты в формате JPGи сохранение отметок в видеXML.

    Возможность загрузки карты по отметкам XML.

На рисунке 8 изображена файловая схема онлайн–редактора с подробным описанием функций и входных и выходных данных для всех файлов.

Рисунок 8

  1. Характеристика выбранных программных сред и средств

Скриптовый язык программирования общего назначения – PHP5 (PHPHypertextPreprocessor); PHP – язык написания скриптов, которые встраиваются непосредственно в гипертекстовые файлы и исполняются на Web-сервере.

HTML (HyperTextMarkupLanguage) – стандартный язык разметки документов во Всемирной паутине. Большинство веб-страниц содержат описание разметки на языке HTML (или XHTML). Язык HTML интерпретируется браузерами и отображается в виде документа в удобной для пользователя и понятной форме.

XML(eXtensibleMarkupLanguage);XML– язык разметки, определяющий ряд правил кодировки в формате, удобном для чтения как человеку, так и программным средствам. СпецификацияXML1.0 и ряд других стандартов это открытые стандарты заданыеW3C(WorldWideWebConsortium).

SQL(StructuredQueryLanguage)SQL– узконаправленный язык программирования, созданный для управления данных в системах управления реляционными базами данных.

JSON(JavaScriptObjectNotation);JSON– Открытый стандарт форматирования текста, удобного для пользователя, для передачи объектов состоящих из пар «атрибут-значение».JSONприменяется для приёма и передаче данных между серверами,web-приложением и сервером, как альтернативаXML.

Каскадные таблицы стилей – CSS3 (CascadingStyleSheets); CSS – технология описания внешнего вида документа, написанного языком разметки. CSS используется как средство оформления веб-страниц в формате HTML и XHTML, но может применяться с любыми видами документов в формате, включая XML и XVL.

Средства скриптового языка – JavaScript; JavaScript – скриптовый язык объектно-ориентированного программирования. JavaScript обычно используется как встраиваемое средство выполнения данных. В веб-программирование JavaScript применим в качестве средства динамического изменения веб-страницы.

Технология AJAX(AsynchronousJavaScriptandXML);AJAX– набор взаимосвязанных техникweb-разработки, позволяющие создавать асинхронныеweb-приложения. При помощиAJAXweb-приложение может асинхронно(в фоновом режиме) отправлять и получать данные, никак при этом не вмешиваясь в процесс отображения текущегоHTMLдокумента. Не смотря на наличие стандартаXMLв названии, данные могут быть различного типа.

Технология AJAJ(AsynchronousJavaScriptandJSON);AJAJ– это технология аналогичная технологииAJAX, однако в отличии отAJAXпередаются данные типаJSON.

Библиотека jQuery; – набор функций и инструментов, облегчающие поиск и манипулирование элементов на страницеHTML-документа, а так же ряд других возможностей, такие как анимация элементов, обработка событий и облегченныйAPIдля работы сAJAXилиAJAJ.

GIMP (GNU ImageManipulationProgram);GIMP– графический редактор, предназначенный для редактирования фотографий, который также применяется для создания дизайнаweb-сайтов.

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

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

XAMPP(X(cross)ApacheMySQLPHPPerl);XAMPP– Набор серверных приложений для созданияweb-приложения. Включает в себяweb-серверApache, СУБДMySQL, интерпретаторPHPиPerl, а так же множество других программных средств.

WAMP(WindowsApacheMySQLPHP);WAMP– Набор серверных серверных приложений для созданияweb-приложения. Включает в себяweb-серверApache, СУБДMySQL, интерпретаторPHP.

FileZilla – FTP-сервер(File Transfer Protocol). Удобный и простой в настройке и обращенииFTP-сервер, используется для хранения, скачивания и загрузки файлов наweb-серверApache.

ChromeDeveloperTools– Набор инструментов для отладкиweb-приложения, содержится вweb-браузереGoogleChrome. Позволяет выполнять отладкуJavaScriptиDOMкода.

GoogleMapsAPI–APIпредоставляемый корпорациейGoogleдля работы с динамическими картамиGoogleMaps. Имеет широкий функционал, позволяющий расставлять на карте маркеры с пользовательскими изображениями, выбирать и фиксировать позицию на карте, наносить рисунки на карту, отображать метки и информацию и многое другое.

GoogleMapsStaticAPI–APIпредоставляемый корпорациейGoogleдля работы со статическими картамиGoogleMaps. Предоставляет возможность выбора определенной части карты с помощью заданных параметров координат и параметра масштабирования.

YandexMapsJSv2 –APIпредоставляемый компаниейYandexдля работы с динамическими и статическими картамиYandexMaps. В отличии отAPIGoogleMapsимеет более удобный способ отправки параметров при помощиXML-документа.

EmbarcaderoDelphi2010 –IDE(IntegratedDevelopmentEnviroment) для создания консольных, оконных,webи мобильных приложений. Содержит компилятор для языкаObjectPascal, диалект языкаPascal.

HTML2Canvas– библиотека дляJavaScript, позволяет производит «снимок экрана» текущей страницы на основеDOMHTML-документа.

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

Целью нашей разработки было создание с нуля учетной системы для одной из крупных российских компаний. Система была призвана заменить текущую, написанную в конце 90-х. В результате были реализованы платформа и один из бизнес-модулей. В реализованной части было порядка 120 объектов, 180 таблиц, около 30 печатных форм.

Хочу оговориться, что подход, описанный ниже, не универсален для написания любого ПО. Он подходит для систем уровня предприятия, которые строятся на основе объектно-ориентированного подхода: учетных, CRM-, ERP-систем, систем документооборота и т.п.

Вся документация на наш программный продукт состояла из следующих разделов:

  • Общая часть
    Список терминов и определений
    Описание бизнес-ролей
  • Требования
    Бизнес-требования
    • Общие сценарии
    • Сценарии использования
    • Алгоритмы и проверки
    Системные требования
    Нефункциональные требования
    Требования к интеграции
    Требования к пользовательскому интерфейсу
  • Реализация
  • Тестирование
  • Руководства
  • Управление
Общая часть состояла всего из двух разделов: списка терминов и их определений и описания бизнес-ролей пользователей. Любая документация по системе, включая, например, тестовые сценарии, опиралась на определения, данные здесь.

Системные требования описывали свойства и методы всех объектов системы.

Нефункциональных требований в данной статье мы касаться не будем. Могу лишь отослать вас к отличной книге Architecting Enterprise Solutions авторов Paul Dyson, Andrew Longshaw.

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

Требования к пользовательскому интерфейсу – отдельная большая тема, возможно, для другой статьи.

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

Давайте рассмотрим подробнее, что такое список терминов и зачем он нужен.

Список терминов и определений

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

Поясню это на примере термина Пользователь . Википедия дает такое определение:

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

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

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

Термины связаны друг с другом. В термине Пользователь используется «операция», поэтому приведу и ее определение:

Операция - совокупность действий, составляющих содержание одного акта бизнес-деятельности. Операция должна соответствовать требованиям ACID (Atomicity, Consistency, Isolation, Durability). Совокупность операций одного модуля представляет интерфейс взаимодействия клиент-сервер этого модуля.

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

Работа над списком терминов происходила постоянно. Мы поддерживали его полноту, т.е. старались, чтобы в документации не было термина, который бы не был определен в этом списке. Кроме того, были случаи, когда мы меняли термины. Например, по прошествии нескольких месяцев с начала написания требований мы решили заменить Контрагент на Компания. Причина была проста: оказалось, что никто не в состоянии в речи, при разговоре, использовать слово «контрагент». А если так, то он должен был быть заменен на что-то более благозвучное.

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

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

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

Описание бизнес-ролей

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

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

Пара примеров:

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

Одной из важных концепций, которую мы применяли при разработке требований, было разделение их на уровни. Алистер Коберн в книге Современные методы описания функциональных требований к системам выделяет 5 уровней. Мы использовали 4 – три уровня бизнес-требований плюс системные требования:

Бизнес-требования

  1. Общие сценарии (соответствует уровню очень белого у Коберна)
  2. Сценарии использования (соответствует голубому)
  3. Алгоритмы и проверки (скорее черный)
4. Системные требования (нет прямого аналога, скорее черный)

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

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

На картинке ниже представлена часть нашей иерархии (о содержании речь пойдет дальше).

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

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

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

Бизнес-требования

Общие сценарии

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

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

Некоторые другие цели общих сценариев:

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

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

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

Наши сценарии использования имели следующий формат:

  • Заголовок со следующими полями:
    статус (В работе | Готов к рецензированию | Согласован)
    пользователи (по описанию бизнес-ролей)
    цель
    предусловия
    гарантированный исход
    успешный исход
    ссылка на описание пользовательского интерфейса (разработанного проектировщиком интерфейсов)
    ссылка на сценарий тестирования (заполнялось тестировщиками)
  • Основной сценарий
  • Расширения сценария

Сценарии использования

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

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

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

Алгоритмы и проверки

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

Например, рассмотрим простой алгоритм ниже.

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

Системные требования

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

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

Описание каждого объекта располагалось на одной wiki-странице и состояло из следующих частей:

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

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

Название
Названием свойства оперирует как пользователь (например, «я изменил номер счета», Номер – свойство объекта Счет), так и проектная команда. Повсеместно в документации использовались ссылки на свойства в виде простой нотации Объект.Свойство, очевидной для любого участника проекта.

Тип
Мы использовали Datetime, Date, Time, GUID, String, Enum, Int, Money, BLOB, Array(), Float, Timezone, TimeSpan. Тип имел отражение на всех уровнях приложения: на уровне БД, сервера приложения, в пользовательском интерфейсе в виде кода и графического представления. Каждому типу было дано определение, чтобы их реализация не вызывала вопросов у программистов. Например, было дано такое определение типу Money: содержит вещественное число с точностью до 4-го знака после запятой, число может быть отрицательным и положительным; одновременно со значением система хранит валюту; валюта по умолчанию - российский рубль.

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

Признак наличия нуля
Да или Нет в зависимости от того, может ли поле не содержать значения. Например, поле типа Bool должно содержать одно из возможных значений, а поле типа String обычно может быть пустым (NULL ). Это ограничение реализовывалось на уровне БД и на сервере приложения.

Признак уникальности
Да или Нет в зависимости от того, является ли это поле уникальным. Часто уникальность определяется на группе полей, в этом случае у всех полей в группе стояло Да+ . Это ограничение реализовывалось на уровне БД (индекс) и на сервере приложения.