Определение требований к программе

Аннотация: Приведены методы и инженерия требований к системе. Рассмотрен процесс сбора, накопления и спецификации требований. Дана классификация требований и характеристика функциональных и нефункциональных требований.

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

увеличить изображение
Рис. 3.1. Основные разделы разработки требований

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

Что такое функциональные требования ? Четкая постановка задач разработчику

Основные инструменты инженерии требований — UML и RUP , согласно которым требования определяются и уточняются с помощью вариантов использования use case , которые преобразуются к проектным решениям и к архитектуре системы.

Далее рассмотрим общие, практические и объектно-ориентированные подходы к разработке требований к системе, учитывая приведенные разделы на рис. 3.1.

3.1. Общие подходы к определению требований

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

3.1.1. Классификация требований

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

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

Требования — это утверждения о функциях и ограничениях системы.

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

Определение требований к подсистеме (исполнительному устройству)

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

Согласно международному глоссарию по терминологии требования включают описание:

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

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

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

Требования пользователей ( user requirements ) основываются на целях и задачах, которые пользователям позволит решать будущая система. К способам представления этого вида требований относятся варианты использования, сценарии, прецеденты, таблицы «событие-отклик» и т.п.

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

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

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

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

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

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

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

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

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

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

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

К выходному продукту предъявляются нефункциональные требования:

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

Процесс описания функциональных и нефункциональных требований, а также требований к характеристикам качества с учетом стандарта ISO/IEC 9126-94 уточняется при разработке архитектуры системы. При спецификации требований важной является проблема стандартизации терминологии для нескольких классов ПрО (например, информационные технологии, системы реального времени и др.). Имея стандартизированный понятийный базис для большинства ПрО, можно достигнуть единого с заказчиком понимания терминов, которые используются при описании концептуальной модели и спецификации требований к системе.

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

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

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

Источник: intuit.ru

Этапы разработки программы

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

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

1. Определение требований к программе
2. Разработка алгоритма
3. Написание команд (кодирование)
4. Отладка

Определение требований к программе

1. Проверяет текст исходной программы на отсутствие синтаксических ошибок.
2. Создает (генерирует) исполняемую программу — машинный код.

Язык Object Pascal

Язык Object Pascal является языком программирования Delphi и представляет собой объектно-ориентированное расширение стандартного языка Pascal. Система Delphi обеспечивает возможность визуального программирования на нем с помощью библиотеки визуальных компонентов VCL.

Источник: studfile.net

Что такое требования к программному продукту

Текстовая расшифровка первого видеоурока курса Введение в профессию аналитика.

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

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

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

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

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

Мне не нравится это определение тем, что оно ставит вопросов больше, чем даёт ответов.

Что значит «совокупность утверждений»? По каким критериям отбираются утверждения в эту совокупность? Она только одна, или их может быть много?

В какой форме существуют эти утверждения? Если у меня в голове есть утверждения относительно атрибутов системы, но я их нигде не документировал, то являются ли они требованиями?

Чем различаются атрибуты, свойства и качества?

Почему «системы, подлежащей реализации»? А если у нас уже есть реализованная система, и мы её дорабатываем?

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

Тем не менее, одно важное слово из этого определения мы запомним: требования — это утверждения относительно программной системы. Они не являются частью системы, а существуют отдельно от неё.

Есть такая книга: «Дин Леффингуэлл, Дон Уидриг. Принципы работы с требованиями к программному обеспечению». Многие аналитики начинали изучение работы с требованиями именно по этой книге. В ней даются такие определения требования:

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

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

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

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

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

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

В глоссарии IEEE даётся такое определение требования:

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

Как видим, это несколько изменённое и дополненное определение, которое было приведено в книге Леффингуэла и Удрига. Но эти изменения и дополнения, к сожалению, не добавляют ясности.

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

Чаще всего мы будем ссылаться на следующую книгу: «Карл Вигерс. Разработка требований к программному обеспечению». (В третьем издании у Карла Вигерса появился соавтор: Джой Битти.) Эта книга, наверное, уже на протяжении многих лет является своего рода библией для аналитиков. Это универсальный учебник по работе с требованиями, и многие концепции, описанные в этой книге, являются общепринятыми в индустрии разработки программ.

Вигерс в своей книге вообще отказывается давать однозначное определение требованиям. Вместо этого он пишет так:

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

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

Я предлагаю применить ещё такой взгляд на требования. Требования, как совокупность утверждений о создаваемом продукте, — это некоторая описательная модель этого продукта.

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

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

Что нам даёт такой взгляд?

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

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

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

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

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

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

Требования могут быть неполными. Часто так бывает, что определённая часть продукта описана в требованиях детально и точно, требования к другим его частям описаны более расплывчато, а некоторые части продукта не описаны вовсе.

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

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

Что ещё даёт нам взгляд на требования как на описательную модель создаваемого продукта? Он предполагает, что требования могут меняться со временем.

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

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

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

Подытожим всё сказанное в этой главе.

Что же такое требования? Это некоторая описательная модель программного продукта, которая:

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

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

Источник: www.webursitet.ru