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

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

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

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

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

Некоторые проблемы, возникающие в процессе разработки требований, порождены отсутствием четкого понимания различия между этими разными уровнями требований. Чтобы различить требования разных уровней, здесь используются термины пользователь­ские требования (user requirements) для обозначения высокоуровневых обобщенных требований и системные требования (system requirements) для детализированного описания вы­полняемых системой функций. Кроме требований этих двух уровней, применяется еще более детализированное описание системы - проектная системная спецификация (software design specification), которая может служить мостом между этапом разработки требований и этапом проектирования системы. Три перечисленных вида требований можно определить следующим образом.

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

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

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

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

Пример 1. Пользовательские и системные требования

Пользовательские требования

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

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

1.1.Пользователь должен иметь возможность определять тип внешних файлов.

1.2.Для каждого типа внешнего файла должно иметься соответствующее средство, при­менимое к этому типу файлов.

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

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

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

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

Рис.4.2. Различные типы спецификаций требований и их читатели

4.5. ФУНКЦИОНАЛЬНЫЕ И НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ (Functional and Non-functional Requirements)

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

Функциональные требования задают “что” система должна делать; нефункциональные – с соблюдением “каких условий” (например, скорость отклика при выполнении заданной операции); часто функциональные требования представляют в виде сценариев (вариантов использования) Use Сase.

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

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

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

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

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

Рисунок 4.3. Уровни требований по Вигерсу

  • Группа функциональных требований

o Бизнес-требования (Business Requirements) – определяют высокоуровневые цели организации или клиента (потребителя) – заказчика разрабатываемого программного обеспечения.

o Пользовательские требования (User Requirements) – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы. Эти требования часто представляют в виде вариантов использования (Use Cases) .

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

  • Группа нефункциональных требований (Non-Functional Requirements)

o Бизнес-правила (Business Rules) – включают или связаны с корпоративными регламентами, политиками, стандартами, законодательными актами, внутрикорпоративными инициативами (например, стремление достичь зрелости процессов по CMMI 4-го уровня), учетными практиками, алгоритмами вычислений и т.д. На самом деле, достаточно часто можно видеть недостаточное внимание такого рода требованиям со стороны сотрудников ИТ-департаментов и, в частности, технических специалистов, вовлеченных в проект. Business Rules Group дает понимание бизнес-правила, как “положения, которые определяют или ограничивают некоторые аспекты бизнеса. Они подразумевают организацию структуры бизнеса, контролируют или влияют на поведение бизнеса”. Бизнес-правила часто определяют распределение ответственности в системе, отвечая на вопрос “кто будет осуществлять конкретный вариант, сценарий использования” или диктуют появление некоторых функциональных требований. В контексте дисциплины управления проектами (уже вне проекта разработки программного обеспечения, но выполнения бизнес-проектов и бизнес-процессов) такие правила обладают высокой значимостью и, именно они, часто определяют ограничения бизнес-проектов, для автоматизации которых создается соответствующее программное обеспечение.

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

o Атрибуты качества (Quality Attributes) – описывают дополнительные характеристики продукта в различных “измерениях”, важных для пользователей и/или разработчиков. Атрибуты касаются вопросов портируемости, интероперабельности (прозрачности взаимодействия с другими системами), целостности, устойчивости и т.п.

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

  • Системные требования (System Requirements) – иногда классифицируются как составная часть группы функциональных требований (не путайте с как таковыми “функциональными требованиями”). Описывают высокоуровневые требования к программному обеспечению, содержащему несколько или много взаимосвязанных подсистем и приложений. При этом, система может быть как целиком программной, так и состоять из программной и аппаратной частей. В общем случае, частью системы может быть персонал, выполняющий определенные функции системы , например, авторизация выполнения определенных операций с использованием программно-аппаратных подсистем.

    требования к программному обеспечению - — [Л.Г.Суменко. Англо русский словарь по информационным технологиям. М.: ГП ЦНИИС, 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-документа.

Значительной популярностью при разработке автоматизированных систем в настоящее время в России пользуется универсальный язык моделирования (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. ГОСТ КАЧЕСТВО ПРОГРАММНЫХ СРЕДСТВ. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мобильность

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

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

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

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

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

Читайте также