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

Что такое требование

Хотя за долгие годы уже появилось множество определений требований к программ­ному обеспечению, вполне приемлемым является следующее определение, предложен­ное специалистами в области разработки требований Дорфманом (Dorfman) и Тэйером (Thayer)(1990).

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

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

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

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

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

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

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

• Поскольку невозможно удерживать в памяти более нескольких десятков фактов, для успешного взаимодействия различных участников процесса необходимо обес­печить документирование требований. Требования следует записать так. чтобы они были доступны для ознакомления; это может быть документ, модель, база данных или листок на доске объявлений.

Но как быть с управлением требованиями? Основными факторами в данном случае яв­ляются размер проекта и его сложность: никто не будет вспоминать об "управлении" тре­бованиями, если в проекте участвуют два человека и необходимо обеспечить выполнение десяти требований. Однако при проверке 1000 требований (как в небольшом коммерче­ском программном продукте) или 300 000 требований (как в системе управления самоле­том Боинг 777) нам, очевидно, придется столкнуться с задачами организации, определе­ния приоритетов, управления доступом, а также обеспечения ресурсов для выполнения всех этих различных требований.

• Кто из участников команды проектировщиков отвечает за требование, касающееся скорости ветра (№278), и кому из них разрешено вносить в него изменения или вообще удалить его?

• Если в требование №278 вносятся изменения, на какие другие требования это по­влияет?

• Как удостовериться в том, что в системе программного обеспечения уже написан код для выполнения требования №278, и какие тестовые примеры нз общего на­бора тестов предназначены для проверки того, что данное требование действи­тельно выполнено?

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

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

Конечно, мы — не первые, кто предложил идею организованных, формализованных про­цессов; хорошо известны модель повышения уровня зрелости процессов разработки про­граммного обеспечения Института программирования (SEI-СММ — Software Engineering Institute’s Capability Maturity Model), а также набор стандартов управления качеством ISO 9000. Мы коротко изложим подходы, принятые в SEI-СММ и ISO 9000, в Приложении Г.

Применение методов управления требованиями

Типы программных приложений

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

• Информационные системы и другие приложения, разработанные для использования внутри компании (такие, как система обработки платежных ведомостей, используемая для расчета выдаваемых на руки сумм). Эта категория является основой индустрии информационных систем/информационных технологий, или IS/IT.

• Программное обеспечение (ПО), разрабатываемое и продаваемое как коммерче­ский продукт (например, текстовый процессор, которым мы пользовались при на­писании данной книги). Разрабатывающие такое ПО компании обычно называют независимыми поставщиками программного обеспечения (independent software vendors), или ISV.

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

Эти три типа приложений существенно отличаются по своей природе. Приложения для больших универсальных ЭВМ могут состоять из 5 000 000 строк на языке COBOL - и создавать­ся на протяжении десяти и более лет командой из 50-100 сотрудников. Приложения WEB-клиента могут состоять из 10 000 строк программного кода на языке Java, и их может создать за год команда из одного-двух человек. Наконец, программное приложение для системы учета телефонных разговоров в реальном времени может состоять из 1 000000 строк, написанных на языке С с целью максимально сократить время выполнения.

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

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

Принципы управление требованиями можно также применять при разработке систем общего вида. Большинство предлагаемых в данной книге методов окажется пригодным для управления требованиями при разработке произвольных сложных систем, состоя­щих из механических, вычислительных и химических подсистем, а также их взаимосвя­занных элементов и частей. Понятно, что эта дисциплина носит достаточно общин ха­рактер, и необходимо продемонстрировать определенную избирательность, чтобы при­водимые сведения оказались полезными для членов команды, разрабатывающей программное обеспечение. Поэтому основное внимание будет уделено процессу управле­ния требованиями и соответствующим методам, которые можно непосредственно при­менять при разработке значительных программных предложений, относящихся к типам IS/IT, ISV или к встроенным системам.

Наш маршрут

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

• Это потребность или требование?

• Это то, что "хорошо бы иметь", или то, что "должно быть"?

• Это постановка задачи или же речь идет о формулировке решения?

• Это — цель системы или одно из условий контракта?

• Действительно ли нужно программировать на языке Java? И кто будет это делать?

• Кому это не нравится наша новая система и где был этот человек, когда мы прихо­дили сюда раньше?

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

Область проблемы

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

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

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

Область проблемы

В этой области мы должны использовать ряд профессиональных приемов (time skills), чтобы понять проблему, которая должна быть решена.

Потребности заинтересованных лиц

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

Переход к области решения

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

Функции системы

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

• "У автомобиля будут автоматические стеклоподъемники"

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

• "Необходимо предусмотреть возможность ввода заказов через Internet

• ".Автоматический цикл двойной сварки"

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

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

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

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

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

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

Понятие прецедентов

Наконец, еще одной важной конструкцией, которая поможет нам в нашем путешест­вии, является прецедент (use case). В простейшем случае прецедент описывает последова­тельность действии, выполняемых системой, чтобы предоставить зна­чимый результат полъзователю. Другими словами, прецедент описы­вает серии взаимодействий пользователь/система, в результате ко­торых пользователь решает некие свои задачи. Мы будем изображать прецедент в виде простой овальной пиктограммы, содержащей его название. Например, если мы хотим описать прецедент, когда клиент использует компьютер просто для вклю­чения или выключения света, его можно назвать "Управление освещением" и поместить это название в овал.

Заключение

Посмотрим теперь на составленную нами карту. Из рис. 2.1 видно, что в процессе об­суждения мы незаметно совершили очень важное продвижение в нашем понимании за­дачи. Мы перешли от представленной облаком области проблемы и выявленных нами потребности клиентов к образующему область решения определению системы, пред­ставленному функциями системы и требованиями к программному обеспечению, соглас­но которым будет выполняться проектирование и реализация системы. Более того, мы осуществили этот переход логично и постепенно, предварительно удостоверившись в том, что осознали проблему и потребности пользователя, и лишь затем приступив к рас­смотрению и определению решения. Эту "карту территории" мы будем еще не раз ис­пользовать в данной книге.

рис. 2.1. Характеристика области проблемы и области решения