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

(Software Requirements)
(Вигерс Карл, Битти Джой)

Введение

Несмотря на десятилетия опыта в отрасли, многие организации, занимающиеся разработкой программного обеспечения, испытывают трудности с пониманием, документированием и управлением требованиями к своим продуктам. Неадекватный пользовательский ввод, неполные требования, меняющиеся требования и неправильно понятые бизнес-цели являются основными причинами того, почему так много проектов в области информационных технологий не полностью успешны. Некоторые команды разработчиков программного обеспечения не умеют выявлять требования от клиентов и из других источников. У клиентов часто нет времени или терпения участвовать в мероприятиях по требованиям. Во многих случаях участники проекта даже не соглашаются с тем, что такое «требование». Как заметил один писатель, «Инженеры предпочли бы расшифровать слова классической песни для вечеринок 1963 года Kingsmen «Louie Louie», чем расшифровать требования клиентов» ([ref184]).
Второе издание «Требований к программному обеспечению» было опубликовано за 10 лет до этого. Десять лет — это большой срок в мире технологий. За это время многое изменилось, но многое — нет. Основные тенденции требований за последнее десятилетие включают:
Признание бизнес-анализа как профессиональной дисциплины и рост числа профессиональных сертификаций и организаций, таких как Международный институт бизнес-анализа и Международный совет по инжинирингу требований.
Развитие инструментов как для управления требованиями в базе данных, так и для содействия мероприятиям по разработке требований, таким как прототипирование, моделирование и имитация.
Более широкое использование методов гибкой разработки и эволюция методов обработки требований в гибких проектах.
Более широкое использование визуальных моделей для представления знаний о требованиях.
Итак, что же не изменилось? Два фактора способствуют сохранению важности и актуальности этой темы. Во-первых, многие учебные программы бакалавриата по программной инженерии и компьютерным наукам продолжают недооценивать важность разработки требований (которая охватывает как разработку требований, так и управление требованиями). И, во-вторых, те из нас, кто работает в сфере программного обеспечения, склонны быть очарованными техническими и процессными решениями наших задач. Иногда мы не понимаем, что выявление требований — и большая часть работы над программным обеспечением и системными проектами в целом — это в первую очередь задача человеческого взаимодействия. Никаких волшебных новых методов для автоматизации этого не появилось, хотя доступны различные инструменты, помогающие географически разделенным людям эффективно сотрудничать.
Мы считаем, что представленные во втором издании практики разработки и управления требованиями по-прежнему актуальны и применимы к широкому спектру программных проектов. Креативный бизнес-аналитик, менеджер по продукту или владелец продукта будут вдумчиво адаптировать и масштабировать практики для наилучшего соответствия потребностям конкретной ситуации. Недавно в это третье издание добавлены глава об обработке требований для agile-проектов и разделы во многих других главах, описывающие, как применять и адаптировать практики в этих главах к среде гибкой разработки.
Разработка программного обеспечения включает в себя по крайней мере столько же общения, сколько и вычислений, однако и учебные программы, и проектные мероприятия часто подчеркивают вычислительный аспект, а не коммуникационный. Эта книга предлагает десятки инструментов для облегчения этого общения и помощи специалистам по программному обеспечению, менеджерам, маркетологам и клиентам в применении эффективных методов инженерии требований. Представленные здесь методы представляют собой набор инструментов основных «хороших практик», а не экзотические новые методы или сложную методологию, которая претендует на решение всех ваших проблем с требованиями. Многочисленные анекдоты и боковые панели представляют истории — все правдивые — которые иллюстрируют типичный опыт, связанный с требованиями; у вас, вероятно, был подобный опыт. Ищите значок «правдивые истории», как тот, что слева, рядом с реальными примерами, взятыми из опыта многих проектов.
С момента выхода первого издания этой книги в 1999 году каждый из нас работал над многочисленными проектами и провел сотни занятий по требованиям к программному обеспечению для людей из компаний и государственных учреждений всех размеров и типов. Мы узнали, что эти практики полезны практически для любого проекта: небольших и крупных, новых разработок и усовершенствований, с локальными и распределенными командами и с использованием традиционных и гибких методов разработки. Эти методы применимы также к проектам по проектированию оборудования и систем, а не только к проектам по программному обеспечению. Как и в любой другой технической практике, вам нужно будет использовать здравый смысл и опыт, чтобы узнать, как заставить методы работать лучше всего для вас. Думайте об этих практиках как об инструментах, которые помогут вам обеспечить эффективные разговоры с нужными людьми в ваших проектах.

Преимущества, которые дает эта книга

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

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

Кому следует прочитать эту книгу?

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

Взгляд в будущее

Эта книга состоит из пяти частей. Часть I начинается с некоторых определений. Если вы работаете в технической сфере, поделитесь Главой 2 о партнерстве по развитию клиентов с вашими ключевыми клиентами. Глава 3 суммирует несколько десятков «хороших практик» для разработки и управления требованиями, а также общую структуру процесса для разработки требований. Роль бизнес-аналитика (роль, которая также известна под многими другими названиями) является предметом Главы 4.
Часть II начинается с методов определения бизнес-требований проекта. Другие главы в Части II рассматривают, как найти соответствующих представителей заказчика, получить от них требования и документировать требования пользователя, бизнес-правила, функциональные требования, требования к данным и нефункциональные требования. Глава 12 описывает многочисленные визуальные модели, которые представляют требования с разных точек зрения для дополнения текста на естественном языке, а Глава 15 рассматривает использование прототипов для снижения риска. Другие главы в Части II представляют способы приоритезации, проверки и повторного использования требований. Часть II завершается описанием того, как требования влияют на другие аспекты работы над проектом.
Впервые в этом издании, Часть III содержит главы, в которых рекомендуются наиболее эффективные подходы к требованиям для различных конкретных классов проектов: гибкие проекты по разработке продуктов любого типа, проекты по усовершенствованию и замене, проекты, включающие пакетные решения, аутсорсинговые проекты, проекты по автоматизации бизнес-процессов, проекты по бизнес-аналитике, а также встроенные и другие системы реального времени.
Принципы и практика управления требованиями являются предметом Части IV, с акцентом на методы работы с изменяющимися требованиями. Глава 29 описывает, как отслеживание требований связывает отдельные требования как с их истоками, так и с результатами разработки ниже по течению. Часть IV завершается описанием коммерческих инструментов, которые могут улучшить способ, которым ваши команды проводят как разработку требований, так и управление требованиями.
Заключительный раздел этой книги, Часть V, поможет вам перейти от концепций к практике. Глава 31 поможет вам включить новые методы требований в процесс разработки вашей группы. Общие риски проекта, связанные с требованиями, описаны в Главе 32. Самооценка в Приложении B может помочь вам выбрать области, которые созрели для улучшения. Два других приложения представляют руководство по устранению неполадок с требованиями и несколько образцов документов с требованиями, чтобы вы могли увидеть, как все части сочетаются друг с другом.

Практические примеры

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

От принципов к практике

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

(*-9 стр.- *) 
~