Обзор процесса определения требований

Цели процесса определения требований

Основная цель рабочего процесса определения требований состоит в том, чтобы

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

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

система). Описание требований должно быть достаточно хорошим для

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

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

должна.

Основное внимание следует обратить на то, что клиент, с которым мы работаем

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

способен прочесть и понять результаты определения требований. Чтобы выполнить

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

Как следствие, мы должны быть очень осторожны при включении в результаты

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

программы.

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

проекта планировать итерации и поставляемые клиентам выпуски (это

обсуждается в части 3).

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

вариаций типов систем, клиентов, организаций, занимающихся разработкой, технологий

и т. д. Также существуют и различные отправные точки для определения

требований. В некоторых случаях мы начинаем с разработки бизнес-модели. Мы

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

организацией (см. подраздел «Что такое бизнес-модель?» данной главы).

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

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

простую модель объекта, например модель предметной области (см. подраздел

«Что такое модель предметной области?»). В некоторых случаях клиент, возможно,

уже разработал полное, детальное техническое задание, не основанное на объектной

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

документа это техническое задание.

В других случаях клиенты могут иметь весьма неопределенное понятие о том,

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

высшего руководства. Между этими крайними положениями лежит все

многообразие вариантов. Мы рассмотрим в качестве отправной точки один из вариантов

— «неопределенное понятие», для чего введем пример, который будем

использовать в остальной части этой книги.

Пример. Консорциум Interbank обдумывает компьютерную систему. Консорциум

Interbank, гипотетическое финансовое учреждение, стоит перед серьезными

изменениями в связи с отменой государственного контроля, конкуренцией и возможностями,

открываемыми WWW. Консорциум планирует создать новые приложения

для работы на быстро меняющихся финансовых рынках. Это заставляет

его филиал, занимающийся разработкой программного обеспечения, Interbank

Software, приступить к разработке этих приложений.

Interbank Software решает разработать биллинговую и платежную систему

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

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

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

новых клиентов. Новых клиентов должно привлекать предложение низких

тарифов на проведение платежей. Банк будет также в состоянии уменьшить

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

Интернет вместо ручной обработки этих документов кассирами.

Мотивацией для покупателей и продавцов должно стать уменьшение затрат,

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

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

компьютером покупателя и компьютером продавца. Покупателям и продавцам

будет также удобнее просматривать информацию об их счетах и платежах.

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

концепции и детальные технические задания, предполагает, что аналитики

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

в любой ситуации.

Различные отправные точки влекут за собой различные типы рисков, так что

аналитики должны выбрать подход, максимально снижающий риски. Уменьшение

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

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

в большинстве случаев. Это позволяет нам предложить типовой рабочий процесс.

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

выполняются по отдельности

О Перечисление возможных требований.

О Осознание контекста системы.

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

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

Мы кратко опишем эти шаги в следующих пунктах.

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

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

хороших идей, которые могли бы превратиться в реальные требования. Мы храним

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

в будущих версиях нашей системы. Этот список предложений растет, когда в него

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

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

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

Каждое предложение имеет короткое название и содержит краткое объяснение

или определение, ровно столько информации, сколько необходимо, чтобы обеспечивалась

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

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

входить:

О состояние предложения (например, предложено, одобрено, включено в план,

или утверждено);

О сметная себестоимость выполнения (в терминах типов ресурсов и человеко-

часов);

О приоритет (например, критический, важный или вспомогательный);

о уровень риска, связанного с реализацией предложения (например, критический,

значительный или обычный, см. главу 5).

Эти планируемые значения вместе с другими аспектами (см, главу 12) используются

для того, чтобы оценить размер проекта и решить, как разбить проект на

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

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

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

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

или более вариантах использования или дополнительных требованиях (которые

мы вскоре обсудим).

Осознание контекста системы. Множество людей, вовлеченных в развитие

программного обеспечения, являются специалистами в вопросах, имеющих отношение

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

и правильно сформировать систему, ключевые разработчики — в частности, архитектор

и некоторые старшие аналитики — должны понимать контекст, в котором

работает система.

Имеется по крайней мере два подхода к описанию контекста системы в форме,

доступной для разработчиков программ: моделирование предметной области и бизнес-

моделирование. Модель предметной области описывает важные понятия контекста

как объекты предметной области. Предметная область при этом связывает

эти объекты друг с другом. Идентификация и наименование этих объектов помогают

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

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

и проектирование нашей системы, объекты предметной области помогут нам

распознать некоторые классы. Как мы увидим далее, бизнес-модель может быть

представлена как надмножество модели предметной области. Она содержит доменные

объекты, и не только их.

Цель бизнес-моделирования состоит в описании процессов — существующих

или воспринимаемых — для того, чтобы понять их. Бизнес-моделирование — единственная

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

[39]. Удовлетворимся замечанием, что бизнес-инжиниринг очень похож на бизнес-

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

Когда аналитики моделируют бизнес, они получают обширную информацию

о контексте программной системы и отражают ее в бизнес-модели. Бизнес-модель

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

вовлеченных в бизнес бизнес-объектов или объектов предметной области,

бизнес-моделирование также устанавливает компетентности, необходимые

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

Это знание является определяющим при идентификации вариантов использования.

Мы вскоре обсудим этот вопрос. Фактически подход бизнес-инжиниринга

для определения требований при разработке бизнес-приложений является

наиболее системным [39].

Архитектор и руководитель проекта совместно решают, ограничиться ли моделью

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

а может быть, не строить никакой модели вообще.__

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

требований основан на вариантах использования (варианты использования

подробно рассматриваются в главе 7). Эти варианты использования охватывают

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

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

Опишем вкратце, как варианты использования помогают нам правильно определять

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

какие-то действия, то есть осуществляла варианты использования. Для пользователя

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

Следовательно, если аналитики в состоянии описать все варианты использования,

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

система с точки зрения функциональности.

Каждый вариант использования представляет собой один способ работы с системой

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

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

по-своему. Чтобы определить варианты использования, которые необходимы

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

позволяют пользователям работать «удобным» для них способом, требуется, чтобы

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

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

предложения и т. д.

В дополнение к вариантам использования аналитики должны также определить,

как должен выглядеть пользовательский интерфейс для реализации того или иного

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

пользовательского интерфейса — это набросать несколько версий представления

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

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

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

относятся такие свойства системы, как ограничения среды и реализации, производительность,

зависимость от платформы, ремонтопригодность, расширяемость,

и надежность ~ все «-ости». Под надежностью понимаются такие характеристики,

как пригодность, точность, средняя наработка на отказ, число ошибок на тысячу

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

налагают специфические условия на выполнение функций: скорость, пропускная

способность, время отклика и используемая память. Большинство требований,

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

и должны быть приписаны к этим вариантам использования как именованные

значения (приложение А). Практически это означает, что эти требования

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

(возможно, в отдельном разделе «Специальные требования»).

Пример. Специальные требования к варианту использования «Оплата счета».

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

должна выдать результат проверки запроса не медленнее чем за 1.0 секунду

в 90 % случаев. Время проверки никогда не должно превышать 10.0 секунд, если

только связь не разорвана (в этом случае пользователь должен быть уведомлен

о разрыве связи).

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

например банковским счетам в системе, предназначенной для банка. Эти требова-

ния могут первоначально определяться в соответствующем бизнес-объекте или

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

Позднее, когда будут определены варианты использования и «понятия», на основе

которых они функционируют, эти нефункциональные требования будут связаны

с соответствующими понятиями. Под «понятием» мы понимаем или неформальную

статью в глоссарии, используемом для описания варианта использования

(см. главу 7), или более формальный класс аналитической модели (см. главу

8). Для простоты в этой главе мы рассматриваем первый случай, то есть считаем,

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

В заключение заметим, что некоторые нефункциональные требования являются

слишком обобщенными и не могут быть привязаны к конкретному варианту

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

в отдельный список дополнительных требований (приложение В).

Резюме, Чтобы эффективно определить требования, аналитики нуждаются

в наборе методов и артефактов, которые помогали бы им получить удобное изображение

системы, такое, чтобы оно способствовало осуществлению рабочих процессов.

Мы будем называть все эти артефакты в целом набором требований. Традиционные

технические задания прошлого сменил набор артефактов: модель вариантов

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

чтобы контекст системы был представлен в виде бизнес-модели или модели предметной

области (рис. 6.1). Отметим, что варианты рюпользования также содержат

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

Рис. 6.1. Набор требований состоит из различных артефактов,

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

требований порождает один или более артефактов

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

позволяющем контролировать вносимые изменения. Это делается посредством

итераций. Каждая итерация отражает некоторое изменение набора требований.

Число вносимых изменений будет постепенно уменьшаться, поскольку

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

Этот процесс описан в следующем подразделе. После этого мы сосредоточимся на__

описании контекста системы моделью предметной области (подраздел «Понимание

контекста системы с помощью модели предметной области») или бизнес-моделью

(подраздел «Понимание контекста системы с помощью бизнес-модели»).

В заключение мы рассмотрим дополнительные требования (раздел «Дополнительные

требования»).

Определение требований в виде вариантов использования — более обширная

тема, и мы вернемся к ней в главе 7.