Принципы работы с требованиями к программному обеспечению

Обновлено: 20.05.2024

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

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

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

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

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

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

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

Первый вариант полностью укладывается в схему модифицированной модели фазы—функции (см. рис. 9.1, 9.2). Если требование ( группа требований ) принимается для данной итерации и используется при разработке сценария, который будет реализовываться (контрольные точки 2, 8), то указанные на схеме трассировки работы включаются в аналитическую и конструкторскую деятельность . В противном случае оно либо откладывается до последующих итераций, либо отклоняется.

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

Трассировка требований, поступающих в ходе разработки итерации

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

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

На рис. 13.1 показано фазовое измерение модифицированной матрицы Гантера (см. рис. 9.1), дополненное мини-циклом обработки одного требования или группы требований , обрабатываемых совместно. Контрольные точки (события) в данной модели те же, что и в прежней матрице фазы—функции. При построении модели используется расщепление линии жизненного цикла (см. лекцию 8). Следует обратить внимание на прерывистую часть линии , ведущей от точки принятия решения к линии итеративного зацикливания. Она выделена затем, чтобы показать, что для анализируемого требования , реализация которого отложена до одной из последующих итераций, работы этапа программирования не проводятся. Возобновление непрерывности линии указывает, что на этапе оценки для данного требования начинаются работы по обоснованию включения его в планы реализации одной из будущих итераций.

Рис. 13.1. Фазовое измерение модели жизненного цикла при объектно-ориентированном развитии проекта, дополненное обработкой требования в мини-цикле

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Требование техники

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

Требование инженерного процесса

Это четырехэтапный процесс, который включает в себя:

Технико-экономическое обоснование
Сбор требований
Спецификация требований к программному обеспечению
Проверка требований к программному обеспечению

Давайте посмотрим на процесс вкратце —

Технико-экономическое обоснование

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

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

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

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

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

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

Спецификация требований к программному обеспечению

SRS — это документ, созданный системным аналитиком после сбора требований от различных заинтересованных сторон.

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

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

SRS должен придумать следующие функции:

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

Проверка требований к программному обеспечению

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

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

Процесс выявления требований

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

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

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

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

Методы выявления требований

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

Существуют различные способы определения требований

Интервью

Интервью являются сильной средой для сбора требований. Организация может проводить несколько типов интервью, таких как:

Обзоры

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

Анкетирование

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

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

Анализ задач

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

Анализ предметной области

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

мозговая атака

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

макетирования

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

наблюдение

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

Требования к программному обеспечению Характеристики

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

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

Очистить
Правильный
последовательный
Последовательный
понятный
модифицируемый
проверяемый
Приоритетное
недвусмысленный
прослеживаемый
Достоверный источник

Требования к программному обеспечению

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

В целом требования к программному обеспечению следует разделить на две категории:

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

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

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

Примеры —

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

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

Нефункциональные требования включают в себя —

Безопасность
логирование
Место хранения
конфигурация
Спектакль
Стоимость
Interoperability
гибкость
Аварийное восстановление
доступность

Требования классифицированы логически как

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

Требования к пользовательскому интерфейсу

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

прост в эксплуатации
быстрый ответ
эффективно обрабатывать ошибки в работе
обеспечение простого, но последовательного пользовательского интерфейса

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

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

Программный системный аналитик

Системный аналитик в ИТ-организации — это человек, который анализирует требования к предлагаемой системе и обеспечивает правильное и правильное оформление и документирование требований. Роль аналитика начинается на этапе анализа программного обеспечения SDLC. Аналитик обязан убедиться, что разработанное программное обеспечение соответствует требованиям клиента.

Системные аналитики имеют следующие обязанности:

Анализ и понимание требований предполагаемого программного обеспечения
Понимание того, как проект будет способствовать достижению целей организации
Определить источники требований
Проверка требований
Разработать и внедрить план управления требованиями
Документация по бизнес, техническим, технологическим и технологическим требованиям
Координация с клиентами для определения приоритетности требований и устранения и неоднозначности
Завершение критериев приемки с клиентом и другими заинтересованными сторонами

Метрики и показатели программного обеспечения

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

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

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

Давайте посмотрим некоторые метрики программного обеспечения:

Размер метрики — LOC (Lines of Code), в основном рассчитывается в тысячах доставленных строк исходного кода и обозначается как KLOC.

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

Метрики качества — Дефекты, их типы и причины, последствия, интенсивность и их значение определяют качество продукта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разработка требований - это первая из основных фаз процесса создания программных систем. Этот фаза состоит из следующих основных работ (рис. 5).

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

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

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

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

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

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

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

понимание пользователями возможностей системы, решаемых ею задач, может измениться;

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

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

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

К действиям по управлению требованиями относятся:

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

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

включение одобренных изменений при помощи определенной процедуры;

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

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

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

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

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

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

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

процесс передачи новых требований и изменений существующих требований заинтересованным лицам;

методы анализа влияния и стоимости внесения изменения.

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

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

Таблица 1. Состояния требования

Определение

Требование запрошено авторизированным источником

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

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

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

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

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

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

Диаграмма состояний для типового процесса внесения изменений в спецификацию приведена на рис. 6.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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