ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 06.11.2023
Просмотров: 817
Скачиваний: 6
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
4.3. Уровни требований к программным системам
Можно выделить следующие уровни требований к ПС [20]: бизнес- требования, требования пользователей, функциональные и нефункцио- нальные требования. К этому нужно еще добавить системные требо- вания. Модель на рис. 4.3 иллюстрирует способ представления этих ти- пов требований. Как и все модели, она не полная, но схематично пока- зывает организацию требований. Овалы обозначают типы информации для требований, а прямоугольники — способ хранения информации
(документы, диаграммы).
Рис. 4.3. Модель типов требований
Бизнес-требования содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финанси- руют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга и т. п. В документе об образе и границах проекта объ- ясняется, почему организации нужна такая система, т.е. описаны биз- нес-цели, которые организация намерена достичь с ее помощью. Опре- деление границ проекта представляет собой первый этап управление общими проблемами расползания границ.
Требования пользователей описывают цели и задачи, которые поль- зователям позволит решить система. К отличным способам представле- ния этого вида требований относятся варианты использования, сцена- рии и таблицы «событие-отклик». В документе о вариантах использова- ния указано, что клиенты смогут делать с помощью системы. Кто бы, когда бы ни предложил новые характеристики, варианты использования или функциональные требования, аналитик должен спросить: “Они по-
146 падают в указанные границы?” Если ответ “да”, то они соответствуют спецификациям. Если “нет”, то их и учитывать не надо. А если ответ такой: “нет, но они должны там быть”, то заказчик или тот, кто финан- сирует проект, дожжен решить, готов ли он раздвинуть границы проек- та, чтобы принять новые требования.
Функциональные требования определяют функциональность про- граммной системы, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес- требований. Последние иногда именуют требованиями поведения, они содержат положения с традиционным «должен» или «должна». Напри- мер, «Система должна по электронной почте отправлять пользователю подтверждение о заказе».
Системные требования обозначают высокоуровневые требования к продукту, который содержит многие подсистемы, то есть к системе.
Система – это совокупность программного обеспечения или подсистем
ПО и оборудования. Люди – часть системы, поэтому определенные функции системы могут распространяться и на них.
Бизнес-правила включают корпоративные политики, правительст- венные постановления, промышленные стандарты и вычислительные алгоритмы. Бизнес-правила не являются требованиями к ПО, потому что они находятся снаружи границ любой системы ПО. Однако они час- то налагают ограничения, определяя, кто может выполнять конкретные варианты использования или диктовать, какими функциями должна об- ладать система, подчиняющаяся соответствующим правилам. Иногда бизнес-правила становятся источником атрибутов качества, которые реализуются в функциональности.
Функциональные требования документируются в спецификации
требований к программной системе, где описывается так полно, как необходимо, ожидаемое поведение системы. Спецификация требований к ПО используется при разработке, тестировании, гарантии качества продукта, управлении проектом, приемке проекта и программного про- дукта.
Атрибуты качества определяют нефункциональные требования, предъявляемые к программной системе. Они представляют собой до- полнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся легкость и простота использования, легкость перемещения, целостность, эффективность и устойчивость к сбоям. Другие нефункциональные требования описывают внешние взаимодействия между системой и внешним миром, а также ограниче- ния дизайна и реализации. Ограничения касаются выбора возможности разработки внешнего вида и структуры продукта.
Хотя в модели на рисунке показан поток требований в направлении сверху вниз, следует ожидать и циклов, и итераций между бизнес- требованиями, требованиями пользователей и функциональными требо- ваниями.
147
В определении и управлении требованиями существует много про- блем, связанных с трудностью получения правильных и законченных требований до окончательного выпуска программного продукта [4]. Во многих исследованиях отмечена корреляция проблем, возникающих с требованиями, с высоким процентом неудачных завершений ИТ- проектов. Более того, в некоторых работах указывается, что от 60 до 70 процентов ИТ-проектов завершаются неудачей из-за слишком плохого сбора, анализа и управления требованиями. Отсутствие четко опреде- ленных и актуальных требований является наиболее веской причиной этих неудач.
Выпущенная программная система может оказаться неудачной по разным причинам, но чаще это вызвано такими причинами, как наличие кода, который был написан, но никогда не выполнялся, или тем, что слишком плохо был организован процесс сбора, анализа и управления требованиями (рис. 4.4).
Рис. 4.4. Причины неудачной разработки программной системы
По данным исследовательской организации Standish Group, наи- большее количество ошибок происходит на этапе сбора, анализа и до- кументирования требований. Доля ошибок в различных артефактах при разработке программных систем представлена на рис. 4.5 [4]. Вследст- вие ошибок на разных этапах разработки программных систем прихо- дится затрачивать 30–50% средств от общего бюджета проекта на их исправление. Причем 70–85% от общего числа исправлений связанно именно с ошибками, допущенными на этапе сбора, анализа и докумен- тирования требований.
При определении требований зачастую бывает трудно выявить окончательные требования до поставки программного продукта. Обыч-
148 но этот процесс организован очень неформально. Даже после того как необходимая информация была собрана, зачастую она не обновляется и не отражает изменения, происходящие в процессе разработки. Для мно- гих организаций совершенствование процесса определения требований способно повысить показатели возврата инвестиций (ROI) даже больше, чем совершенствование процесса управления требованиями.
Рис. 4.5. Доля ошибок в различных артефактах при разработке программных систем
4.4. Определение требований к программным системам
4.4.1. Постановка задачи и принципы разработки требований
Как отмечалось выше, один из наиболее ответственных этапов соз- дания ПС – этап постановка задачи. Как правило, заказчик выдает не- сколько страниц текста задания и просит оценить время исполнения заказа и его стоимость. Автор пособия по технологии программирова- ния [20] замечает, что надо быть сумасшедшим, чтобы на это согласить- ся.
Чтобы избежать такой ситуации, нужно предложить заказчику оформить начальный договор с той целью, чтобы системные аналитики смогли понять, что требуется заказчику, выполнили декомпозицию сис- темы на компоненты, предварительно определили объем этих компо- нентов и время их реализации. Такая начальная стадия ЖЦ ПС называ- ется оценкой осуществимости. Организация-разработчик может, ко- нечно, выполнить эту работу за свой счет (и многие крупные предпри- ятия так и делают), но, во-первых, отношение к внутренним разработ- кам – более спокойное, а, во-вторых, оплаченный договор гарантирует серьезность намерений сторон.
Постановка задачи – наиболее творческая часть разработки про- граммной системы, которая поднимает почти философские проблемы
[6, 11]. В процессе постановки задачи четко формулируется назначение
149 программной системы, и определяются основные требования к ней. Ка- ждое требование представляет собой описание необходимого или же- лаемого свойства ПС. Различают функциональные требования, опреде- ляющие функции, которые должна выполнять разрабатываемая система, и эксплуатационные (не функциональные) требования, определяющие особенности функционирования ПС.
IEEE Standard Glossary of Software Engineering Terminology [2] опре- деляет требования как:
1) условия или возможности, необходимые пользователю для ре- шения проблем или достижения целей;
2) условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетво- рять стандартам, спецификациям или другим формальным документам
3) документированное представление условий или возможностей для п. 1 и 2.
Требования, предъявляемые к разрабатываемой программной систе- ме, будем обозначать следующим образом [13]:
TR
S
= TR
F
U TR
E
, TR
F
= {L
F
, r f
f f
i
, i = 1, 2, …, N
F
},
TR
E
= {L
E
, r e
e e
i
, j= 1, 2, …, N
E
}, где: TR
S
– множество требований, предъявляемых к разрабатывае- мой системе;
TR
F
– множество функциональных требований;
TR
E
– множество нефункциональных требований;
L
F
– язык описания функциональных требований;
L
E
– язык описания нефункциональных требований;
r f
f f
i
– некоторое функциональное требование; r e
e e
i
– некоторое нефункциональное требование;
N
F
– количество различных функциональных требований;
N
E
– количество различных нефункциональных требований;
Остановимся более подробно на типах требований. В [14] предлага- ется рассматривать следующие типы требований:
1.
Запрос заинтересованного лица или совладельцев (Stakeholder
Request - STRQ) – Общие требования заинтересованных лиц к системе.
Используется для разметки всех требований, содержащихся во всех до- кументах, поступивших от Заинтересованных лиц и пользователей. Эти документы могут не соответствовать словарю проекта. STRQ являются основой для создания в проекте трех основных документов, в которых требования (при необходимости) переформулируются в терминах сло- варя проекта: Концепция Системы (Vision), Дополнительные техниче- ские требования, Спецификация сценариев использования (для каждого сценария).
2.
Свойство системы (Feature – FEAT).
Используется для описания требований, относящихся к определению высокоуровневых функцио- нальных и нефункциональных требований системы (подсистемы), в до- кументе Концепция Системы (Vision)
150 3.
Вариант или сценарий использования (Use Case – UC). Функ- циональные требования. Используется для описания сценариев исполь- зования (формирование функциональных требований).
4.
Дополнительные спецификации (Supplementary Requirement –
SUPP). Нефункциональные требования. Используется для описания не- функциональных требований в документах типа Дополнительные тех- нические требования.
5.
Термин (Term – TERM). Терминологические требования.
Типы требований определяются в самом начале проекта, и на число типов нет никаких ограничений. Каждый тип требования должен иметь уникальный набор атрибутов, связанных с требованиями. Например, атрибутами запроса заинтересованного лица могут быть Приоритет,
Статус, Тип запроса и т.д. Каждый из атрибутов может иметь одно или несколько состояний. Например, атрибут Приоритет может, иметь три состояния: высокий, средний и низкий.
Характеристики качественных требований по-разному определены различными источниками. Характеристики требований, являющиеся общепризнанными, приведены в табл. 4.1.
Таблица 4.1
Характеристики требований
Характеристика
Объяснение
Единичность
Требование описывает одну и только одну вещь.
Завершённость
Требование полностью определено в одном месте и вся необходимая информация присутствует.
Последовательность
Требование не противоречит другим требованиям и полностью соответствует внешней документации.
Атомарность
Требование «атомарно». То есть оно не может быть разбито на ряд более детальных требований без по- тери завершённости.
Отслеживаемость
Требование полностью или частично соответствует деловым нуждам как заявлено заинтересованными лицами и документировано.
Актуальность
Требование не стало устаревшим с течением време- ни.
Выполнимость
Требование может быть реализовано в пределах проекта.
Недвусмысленность
Требование кратко определено без обращения к тех- ническому жаргону, акронимам и другим скрытым формулировка. Оно выражает объективные факты, не субъективные мнения. Возможна одна и только одна интерпретация. Определение не содержит не- чётких фраз. Использование отрицательных утвер- ждений и составных утверждений запрещено.
151
Обязательность
Требование представляет определённую заинтересо- ванным лицом характеристику, отсутствие которой приведёт к неполноценности решения, которая не может быть проигнорирована. Необязательное тре- бование — противоречие самому понятию требова- ния.
Проверяемость
Реализуемость требования может быть определена одним из четырёх возможных методов: осмотр, демонстрация, тест или анализ.
Процесс разработки требований зависит от ряда факторов. Одним из них является контроль над ходом выполнения проекта и организация управления проектом. Возможные варианты показаны на рис. 4.6. В случае проекта, управляемого пользователем, требования к ПС разра- батываются непосредственно организацией-пользователем. Разработчик
ПС является субподрядчиком организации-пользователя, и требования представляют собой контракт или его часть. Проекты такого типа ха- рактерны для правительственных организаций, госслужб, министерства обороны и т. п.
В проекте, контролируемом пользователем, требования к про- граммному обеспечению формулируются либо его разработчиком, либо совместными усилиями разработчика и пользователя. В таких проектах организация-пользователь имеет право утверждать требования и, как правило, спецификации следующих уровней.
В независимом от пользователя проекте вся ответственность за оп- ределение требований ложится на разработчика ПС (большинство ПС, поставляемых на рынок).
Требования к программной системе дают возможность пользовате- лям сформулировать свои потребности в отношении конкретного про- граммного продукта. С этой точки зрения привлекателен проект, кон- тролируемый пользователем. Участие в этом процессе организации- разработчика, безусловно, увеличивает его шансы правильно понять и интерпретировать требования.
Рис. 4.6. Варианты организации контроля над ходом выполнения проекта
152
Требования к программной системе, имеющей прототипы, обычно определяются по аналогии, учитывая структуру и характеристики уже существующих систем. Для формулировки требований к ПС, не имею- щей аналогов, бывает необходимо провести специальные исследования, называемые предпроектными (см. модели As Is и As To Be). В процессе таких исследований определяют разрешимость задачи, возможно, раз- рабатываются методы ее решения (если требуются новые) и устанавли- вают наиболее существенные характеристики разрабатываемой про- граммной системы.
В общем случае разработку системных требований выполняют пред- ставители организации-пользователя (заказчика) и организации- разработчика (проектировщика), решающих следующие задачи:
1) выявление наличия информации, необходимой для выполнения пла- нируемых функций;
2) обеспечение полноты и точности определения функций, подлежа- щих выполнению программной системой, и взаимосвязей этих функций;
3) выработка заключения по трудоемкости предстоящей работы.
Требования для ПС среднего и большого размера должны разраба- тываться небольшой группой лиц, например, по два представителя от пользователей и разработчиков. Пользователи должны быть представ- лены ведущими специалистами, наделенными правом принятия оконча- тельного решения, и специалистом, являющимся непосредственным пользователем проектируемой системы.
Разработчики должны быть представлены специалистом, который будет играть ведущую роль во внешнем проектировании системы, и лицом, которое будет в последующем участвовать в одном из процессов внутреннего проектирования (кодирования). Подобный подход гаранти- рует, что системные требования пользователя были установлены по возможности более точно при условии, что проектировщики могут пе- ревести эти требования в программную систему с минимальным числом ошибок.
Сам процесс определения требований предполагает анализ сущест- вующих систем, беседы с пользователями, проведение исследований осуществимости и оценки достоинств проекта. Основная цель процесса определения требований – направить процесс разработки на получение правильной системы, которая делает что необходимо и ничего больше.
Описание требований должно быть достаточно хорошим и полным, чтобы между пользователями и разработчиками могло быть достигнуто понимание того, что система должна делать и чего не должна. В про- тивном случае пользователи будут считать, что система может для них все, а программисты не будут понимать, какие функции будущей систе- мы обязательно должны быть включены в первую версию и без них нельзя обойтись, а какие можно отложить до будущего релиза.
Можно определить следующие шаги процесса разработки требова- ний:
Можно выделить следующие уровни требований к ПС [20]: бизнес- требования, требования пользователей, функциональные и нефункцио- нальные требования. К этому нужно еще добавить системные требо- вания. Модель на рис. 4.3 иллюстрирует способ представления этих ти- пов требований. Как и все модели, она не полная, но схематично пока- зывает организацию требований. Овалы обозначают типы информации для требований, а прямоугольники — способ хранения информации
(документы, диаграммы).
Рис. 4.3. Модель типов требований
Бизнес-требования содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финанси- руют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга и т. п. В документе об образе и границах проекта объ- ясняется, почему организации нужна такая система, т.е. описаны биз- нес-цели, которые организация намерена достичь с ее помощью. Опре- деление границ проекта представляет собой первый этап управление общими проблемами расползания границ.
Требования пользователей описывают цели и задачи, которые поль- зователям позволит решить система. К отличным способам представле- ния этого вида требований относятся варианты использования, сцена- рии и таблицы «событие-отклик». В документе о вариантах использова- ния указано, что клиенты смогут делать с помощью системы. Кто бы, когда бы ни предложил новые характеристики, варианты использования или функциональные требования, аналитик должен спросить: “Они по-
146 падают в указанные границы?” Если ответ “да”, то они соответствуют спецификациям. Если “нет”, то их и учитывать не надо. А если ответ такой: “нет, но они должны там быть”, то заказчик или тот, кто финан- сирует проект, дожжен решить, готов ли он раздвинуть границы проек- та, чтобы принять новые требования.
Функциональные требования определяют функциональность про- граммной системы, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес- требований. Последние иногда именуют требованиями поведения, они содержат положения с традиционным «должен» или «должна». Напри- мер, «Система должна по электронной почте отправлять пользователю подтверждение о заказе».
Системные требования обозначают высокоуровневые требования к продукту, который содержит многие подсистемы, то есть к системе.
Система – это совокупность программного обеспечения или подсистем
ПО и оборудования. Люди – часть системы, поэтому определенные функции системы могут распространяться и на них.
Бизнес-правила включают корпоративные политики, правительст- венные постановления, промышленные стандарты и вычислительные алгоритмы. Бизнес-правила не являются требованиями к ПО, потому что они находятся снаружи границ любой системы ПО. Однако они час- то налагают ограничения, определяя, кто может выполнять конкретные варианты использования или диктовать, какими функциями должна об- ладать система, подчиняющаяся соответствующим правилам. Иногда бизнес-правила становятся источником атрибутов качества, которые реализуются в функциональности.
Функциональные требования документируются в спецификации
требований к программной системе, где описывается так полно, как необходимо, ожидаемое поведение системы. Спецификация требований к ПО используется при разработке, тестировании, гарантии качества продукта, управлении проектом, приемке проекта и программного про- дукта.
Атрибуты качества определяют нефункциональные требования, предъявляемые к программной системе. Они представляют собой до- полнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся легкость и простота использования, легкость перемещения, целостность, эффективность и устойчивость к сбоям. Другие нефункциональные требования описывают внешние взаимодействия между системой и внешним миром, а также ограниче- ния дизайна и реализации. Ограничения касаются выбора возможности разработки внешнего вида и структуры продукта.
Хотя в модели на рисунке показан поток требований в направлении сверху вниз, следует ожидать и циклов, и итераций между бизнес- требованиями, требованиями пользователей и функциональными требо- ваниями.
147
В определении и управлении требованиями существует много про- блем, связанных с трудностью получения правильных и законченных требований до окончательного выпуска программного продукта [4]. Во многих исследованиях отмечена корреляция проблем, возникающих с требованиями, с высоким процентом неудачных завершений ИТ- проектов. Более того, в некоторых работах указывается, что от 60 до 70 процентов ИТ-проектов завершаются неудачей из-за слишком плохого сбора, анализа и управления требованиями. Отсутствие четко опреде- ленных и актуальных требований является наиболее веской причиной этих неудач.
Выпущенная программная система может оказаться неудачной по разным причинам, но чаще это вызвано такими причинами, как наличие кода, который был написан, но никогда не выполнялся, или тем, что слишком плохо был организован процесс сбора, анализа и управления требованиями (рис. 4.4).
Рис. 4.4. Причины неудачной разработки программной системы
По данным исследовательской организации Standish Group, наи- большее количество ошибок происходит на этапе сбора, анализа и до- кументирования требований. Доля ошибок в различных артефактах при разработке программных систем представлена на рис. 4.5 [4]. Вследст- вие ошибок на разных этапах разработки программных систем прихо- дится затрачивать 30–50% средств от общего бюджета проекта на их исправление. Причем 70–85% от общего числа исправлений связанно именно с ошибками, допущенными на этапе сбора, анализа и докумен- тирования требований.
При определении требований зачастую бывает трудно выявить окончательные требования до поставки программного продукта. Обыч-
148 но этот процесс организован очень неформально. Даже после того как необходимая информация была собрана, зачастую она не обновляется и не отражает изменения, происходящие в процессе разработки. Для мно- гих организаций совершенствование процесса определения требований способно повысить показатели возврата инвестиций (ROI) даже больше, чем совершенствование процесса управления требованиями.
Рис. 4.5. Доля ошибок в различных артефактах при разработке программных систем
4.4. Определение требований к программным системам
4.4.1. Постановка задачи и принципы разработки требований
Как отмечалось выше, один из наиболее ответственных этапов соз- дания ПС – этап постановка задачи. Как правило, заказчик выдает не- сколько страниц текста задания и просит оценить время исполнения заказа и его стоимость. Автор пособия по технологии программирова- ния [20] замечает, что надо быть сумасшедшим, чтобы на это согласить- ся.
Чтобы избежать такой ситуации, нужно предложить заказчику оформить начальный договор с той целью, чтобы системные аналитики смогли понять, что требуется заказчику, выполнили декомпозицию сис- темы на компоненты, предварительно определили объем этих компо- нентов и время их реализации. Такая начальная стадия ЖЦ ПС называ- ется оценкой осуществимости. Организация-разработчик может, ко- нечно, выполнить эту работу за свой счет (и многие крупные предпри- ятия так и делают), но, во-первых, отношение к внутренним разработ- кам – более спокойное, а, во-вторых, оплаченный договор гарантирует серьезность намерений сторон.
Постановка задачи – наиболее творческая часть разработки про- граммной системы, которая поднимает почти философские проблемы
[6, 11]. В процессе постановки задачи четко формулируется назначение
149 программной системы, и определяются основные требования к ней. Ка- ждое требование представляет собой описание необходимого или же- лаемого свойства ПС. Различают функциональные требования, опреде- ляющие функции, которые должна выполнять разрабатываемая система, и эксплуатационные (не функциональные) требования, определяющие особенности функционирования ПС.
IEEE Standard Glossary of Software Engineering Terminology [2] опре- деляет требования как:
1) условия или возможности, необходимые пользователю для ре- шения проблем или достижения целей;
2) условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетво- рять стандартам, спецификациям или другим формальным документам
3) документированное представление условий или возможностей для п. 1 и 2.
Требования, предъявляемые к разрабатываемой программной систе- ме, будем обозначать следующим образом [13]:
TR
S
= TR
F
U TR
E
, TR
F
= {L
F
, r f
f f
i
, i = 1, 2, …, N
F
},
TR
E
= {L
E
, r e
e e
i
, j= 1, 2, …, N
E
}, где: TR
S
– множество требований, предъявляемых к разрабатывае- мой системе;
TR
F
– множество функциональных требований;
TR
E
– множество нефункциональных требований;
L
F
– язык описания функциональных требований;
L
E
– язык описания нефункциональных требований;
r f
f f
i
– некоторое функциональное требование; r e
e e
i
– некоторое нефункциональное требование;
N
F
– количество различных функциональных требований;
N
E
– количество различных нефункциональных требований;
Остановимся более подробно на типах требований. В [14] предлага- ется рассматривать следующие типы требований:
1.
Запрос заинтересованного лица или совладельцев (Stakeholder
Request - STRQ) – Общие требования заинтересованных лиц к системе.
Используется для разметки всех требований, содержащихся во всех до- кументах, поступивших от Заинтересованных лиц и пользователей. Эти документы могут не соответствовать словарю проекта. STRQ являются основой для создания в проекте трех основных документов, в которых требования (при необходимости) переформулируются в терминах сло- варя проекта: Концепция Системы (Vision), Дополнительные техниче- ские требования, Спецификация сценариев использования (для каждого сценария).
2.
Свойство системы (Feature – FEAT).
Используется для описания требований, относящихся к определению высокоуровневых функцио- нальных и нефункциональных требований системы (подсистемы), в до- кументе Концепция Системы (Vision)
150 3.
Вариант или сценарий использования (Use Case – UC). Функ- циональные требования. Используется для описания сценариев исполь- зования (формирование функциональных требований).
4.
Дополнительные спецификации (Supplementary Requirement –
SUPP). Нефункциональные требования. Используется для описания не- функциональных требований в документах типа Дополнительные тех- нические требования.
5.
Термин (Term – TERM). Терминологические требования.
Типы требований определяются в самом начале проекта, и на число типов нет никаких ограничений. Каждый тип требования должен иметь уникальный набор атрибутов, связанных с требованиями. Например, атрибутами запроса заинтересованного лица могут быть Приоритет,
Статус, Тип запроса и т.д. Каждый из атрибутов может иметь одно или несколько состояний. Например, атрибут Приоритет может, иметь три состояния: высокий, средний и низкий.
Характеристики качественных требований по-разному определены различными источниками. Характеристики требований, являющиеся общепризнанными, приведены в табл. 4.1.
Таблица 4.1
Характеристики требований
Характеристика
Объяснение
Единичность
Требование описывает одну и только одну вещь.
Завершённость
Требование полностью определено в одном месте и вся необходимая информация присутствует.
Последовательность
Требование не противоречит другим требованиям и полностью соответствует внешней документации.
Атомарность
Требование «атомарно». То есть оно не может быть разбито на ряд более детальных требований без по- тери завершённости.
Отслеживаемость
Требование полностью или частично соответствует деловым нуждам как заявлено заинтересованными лицами и документировано.
Актуальность
Требование не стало устаревшим с течением време- ни.
Выполнимость
Требование может быть реализовано в пределах проекта.
Недвусмысленность
Требование кратко определено без обращения к тех- ническому жаргону, акронимам и другим скрытым формулировка. Оно выражает объективные факты, не субъективные мнения. Возможна одна и только одна интерпретация. Определение не содержит не- чётких фраз. Использование отрицательных утвер- ждений и составных утверждений запрещено.
151
Обязательность
Требование представляет определённую заинтересо- ванным лицом характеристику, отсутствие которой приведёт к неполноценности решения, которая не может быть проигнорирована. Необязательное тре- бование — противоречие самому понятию требова- ния.
Проверяемость
Реализуемость требования может быть определена одним из четырёх возможных методов: осмотр, демонстрация, тест или анализ.
Процесс разработки требований зависит от ряда факторов. Одним из них является контроль над ходом выполнения проекта и организация управления проектом. Возможные варианты показаны на рис. 4.6. В случае проекта, управляемого пользователем, требования к ПС разра- батываются непосредственно организацией-пользователем. Разработчик
ПС является субподрядчиком организации-пользователя, и требования представляют собой контракт или его часть. Проекты такого типа ха- рактерны для правительственных организаций, госслужб, министерства обороны и т. п.
В проекте, контролируемом пользователем, требования к про- граммному обеспечению формулируются либо его разработчиком, либо совместными усилиями разработчика и пользователя. В таких проектах организация-пользователь имеет право утверждать требования и, как правило, спецификации следующих уровней.
В независимом от пользователя проекте вся ответственность за оп- ределение требований ложится на разработчика ПС (большинство ПС, поставляемых на рынок).
Требования к программной системе дают возможность пользовате- лям сформулировать свои потребности в отношении конкретного про- граммного продукта. С этой точки зрения привлекателен проект, кон- тролируемый пользователем. Участие в этом процессе организации- разработчика, безусловно, увеличивает его шансы правильно понять и интерпретировать требования.
Рис. 4.6. Варианты организации контроля над ходом выполнения проекта
152
Требования к программной системе, имеющей прототипы, обычно определяются по аналогии, учитывая структуру и характеристики уже существующих систем. Для формулировки требований к ПС, не имею- щей аналогов, бывает необходимо провести специальные исследования, называемые предпроектными (см. модели As Is и As To Be). В процессе таких исследований определяют разрешимость задачи, возможно, раз- рабатываются методы ее решения (если требуются новые) и устанавли- вают наиболее существенные характеристики разрабатываемой про- граммной системы.
В общем случае разработку системных требований выполняют пред- ставители организации-пользователя (заказчика) и организации- разработчика (проектировщика), решающих следующие задачи:
1) выявление наличия информации, необходимой для выполнения пла- нируемых функций;
2) обеспечение полноты и точности определения функций, подлежа- щих выполнению программной системой, и взаимосвязей этих функций;
3) выработка заключения по трудоемкости предстоящей работы.
Требования для ПС среднего и большого размера должны разраба- тываться небольшой группой лиц, например, по два представителя от пользователей и разработчиков. Пользователи должны быть представ- лены ведущими специалистами, наделенными правом принятия оконча- тельного решения, и специалистом, являющимся непосредственным пользователем проектируемой системы.
Разработчики должны быть представлены специалистом, который будет играть ведущую роль во внешнем проектировании системы, и лицом, которое будет в последующем участвовать в одном из процессов внутреннего проектирования (кодирования). Подобный подход гаранти- рует, что системные требования пользователя были установлены по возможности более точно при условии, что проектировщики могут пе- ревести эти требования в программную систему с минимальным числом ошибок.
Сам процесс определения требований предполагает анализ сущест- вующих систем, беседы с пользователями, проведение исследований осуществимости и оценки достоинств проекта. Основная цель процесса определения требований – направить процесс разработки на получение правильной системы, которая делает что необходимо и ничего больше.
Описание требований должно быть достаточно хорошим и полным, чтобы между пользователями и разработчиками могло быть достигнуто понимание того, что система должна делать и чего не должна. В про- тивном случае пользователи будут считать, что система может для них все, а программисты не будут понимать, какие функции будущей систе- мы обязательно должны быть включены в первую версию и без них нельзя обойтись, а какие можно отложить до будущего релиза.
Можно определить следующие шаги процесса разработки требова- ний: