Разработка требований к ПО (билингв, для ИТ-переводчиков)

Содержание

Содержание

Источники:

  1. Software Requirements, Third Edition // Karl Wiegers
  2. Разработка требований к программному обеспечению. Издание третье, дополненное // Вигерс Карл

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

Если наше бюро, адаптируя эти материалы под переводчиков, нарушило ваши права, пожалуйста, напишите нам на bartov-e@yandex.ru. 

1. Основы разработки требований к ПО

«Привет, Фил, это Мария из отдела персонала. У нас проблема с системой управления персоналом, которую вы разрабатывали для нас. Одна из сотрудниц изменила имя на Спаркл Старлайт, а система не принимает это изменение. Ты можешь помочь?» “Hello, Phil? This is Maria in Human Resources. We’re having a problem with the personnel system you programmed for us. An employee just changed her name to Sparkle Starlight, and we can’t get the system to accept the name change. Can you help?”
«Она вышла замуж за парня по имени Старлайт?» “She married some guy named Starlight?”
«Нет, она просто взяла другое имя, — ответила Мария. — В этом-то и проблема. Похоже, что мы можем менять имя только при изменении семейного положения». “No, she didn’t get married, just changed her name,” Maria replied. “That’s the problem. It looks like we can change a name only if someone’s marital status changes.”
«Да, я не предусмотрел такой возможности. Я не помню, чтобы и ты говорила мне о ней, когда мы обсуждали систему», — сказал Фил. “Well, yeah, I never thought someone might just change her name. I don’t remember you telling me about this possibility when we talked about the system,” Phil said.
«Я полагала, ты знаешь, что люди могут законным образом менять имена, когда захотят, — ответила Мария. — Мы должны исправить это к пятнице, а то Спаркл не сможет обналичить чек. Ты сможешь исправить этот дефект к этому сроку?» “I assumed you knew that people could legally change their name anytime they like,” responded Maria. “We have to straighten this out by Friday or Sparkle won’t be able to cash her paycheck. Can you fix the bug by then?”
«Это не дефект, — резко парировал Фил. — Я и не знал, что вам нужна эта функциональность. Сейчас я занимаюсь новой системой оценки производительности системы, и скорее всего смогу исправить это в конце месяца, но не к пятнице. Приношу свои извинения. Но в следующий раз с такими просьбами обращайся пораньше и, пожалуйста, излагай их письменно». “It’s not a bug!” Phil retorted. “I never knew you needed this capability. I’m busy on the new performance evaluation system. I can probably fix it by the end of the month, but not by Friday. Sorry about that. Next time, tell me these things earlier and please write them down.”
«А что же я скажу Спаркл? — возмутилась Мария. — Она сильно расстроится, если не сможет обналичить чек». “What am I supposed to tell Sparkle?” demanded Maria. “She’ll be upset if she can’t cash her check.”
«Эй, Мария, это не моя вина, — запротестовал Фил. — Если бы ты сказала мне с самого начала, что вам понадобится изменять имена в любое время, этого не произошло бы. Я не медиум и читать твои мысли не умею». "Hey, Maria, it's not my fault,” Phil protested. "If you'd told me in the first place that you had to be able to change someone's name at any time, this wouldn't have happened. You can't blame me for not reading your mind."
Сердитая и смирившаяся, Мария отрезала: «Это как раз то, из-за чего я ненавижу компьютерные системы. Позвони мне, как только сможешь исправить недостаток». Angry and resigned, Maria snapped, “Yeah, well, this is the kind of thing that makes me hate computers. Call me as soon as you get it fixed, will you?”
Если вы когда-либо бывали в шкуре клиента на переговорах, подобных этому, то знаете, как расстраиваются пользователи продукта, не позволяющего решать элементарные задачи. Не очень приятно находиться в милости разработчиков, которые может быть удовлетворят ваш запрос. Разработчики тоже не очень довольны, когда узнают о функциональности, которую пользователи ожидали получить, только после развертывания системы. If you’ve ever been on the customer side of a conversation like this, you know how frustrating it is when a software system doesn’t let you perform an essential task. You hate to be at the mercy of a developer who might get to your critical change request eventually. On the other hand, developers are frustrated to learn about functionality that a user expected only after they’ve implemented the system. It’s also annoying for a developer to have his current project interrupted by a request to modify a system that does precisely what he was told it should do in the first place.
Масса проблем с ПО возникает из-за несовершенства способов, которые люди применяют для сбора, документирования, согласования и модификации требований к ПО. Как в случае с Филом и Марией, проблемы могут возникать из-за неформального сбора информации, предполагаемой функциональности, ошибочных или несогласованных предположений, недостаточно определенных требований и бессистемного изменения процесса. Many problems in the software world arise from shortcomings in the ways that people learn about, document, agree upon and modify the product’s requirements. As with Phil and Maria, common problem areas are informal information gathering, implied functionality, miscommunicated assumptions, poorly specified requirements, and a casual change process.
Многие исследования показывают, что на ошибки, внесенные на этапе сбора требований, приходится от 40 до 50% всех дефектов, обнаруженных в программном продукте (Davis, 2005). Некорректные сведения от пользователей и недостатки определения и управления требованиями клиентов — основные причины провалов проектов. Но невзирая на эти сведения многие организации все еще применяют неэффективные методы сбора требований. Various studies suggest that errors introduced during requirements activities account for 40 to 50 percent of all defects found in a software product (Davis 2005). Inadequate user input and shortcomings in specifying and managing customer requirements are major contributors to unsuccessful projects. Despite this evidence, many organizations still practice ineffective requirements methods.
Нигде более, как на стадии сбора требований так тесно не связаны интересы всех заинтересованных в проекте лиц с успехом проекта. Nowhere more than in the requirements do the interests of all the stakeholders in a project intersect.
К заинтересованным в проекте лицам относятся клиенты, пользователи, бизнес-аналитики, разработчики и многие другие. Хорошо справившись с этой стадией процесса, вы получите отличный продукт, восхищенных заказчиков и удовлетворенных разработчиков. В противном случае вам грозит непонимание, разочарование и разногласия, которые подрывают веру в продукт и его ценность. Так как требования представляют собой основу для действий и разработчиков и менеджеров проекта, все заинтересованные в проекте лица должны быть вовлечены в создание этого документа. These stakeholders include customers, users, business analysts, developers, and many others. Handled well, this intersection can lead to delighted customers and fulfilled developers. Handled poorly, it’s the source of misunderstanding and friction that undermine the product’s quality and business value. Because requirements are the foundation for both the software development and the project management activities, all stakeholders should commit to applying requirements practices that are known to yield superior-quality products.
Но разработка требований и управление ими — трудный процесс! Здесь нет быстрых или волшебных решений. Однако многие организации борются с одними и теми же трудностями, для преодоления которых мы можем найти общие приемы, годные в различных ситуациях. В этой книге описаны десятки таких приемов. But developing and managing requirements is hard! There are no simple shortcuts or magic solutions. On the plus side, so many organizations struggle with the same problems that you can look for techniques in common that apply to many different situations. This book describes dozens of such practices.
Из этой главы вы узнаете, как: This chapter will help you to:
· разобраться с ключевыми терминами, применяемыми при сборе требований к ПО; · Understand some key terms used in the software requirements domain.
· различать требования к продукту и к проекту; · Distinguish product requirements from project requirements.
· различать требования по разработке и управлению; · Distinguish requirements development from requirements management.
· обнаруживать тревожные симптомы некоторых связанных с требованиями проблем, которые могут иногда возникать. · Be alert to several requirements-related problems that can arise.
Внимание!
Мы используем термины «система», «продукт», «приложение» и «решение» для определения любого вида ПО или содержащего ПО компонента, который создается для внутрикорпоративного использования, на продажу или по заказу. 		Important
We use the terms “system,” “product,” “application,” and “solution” interchangeably in this book to refer to any kind of software or software-containing item that you build, whether for internal corporate use, for commercial sale, or on a contract basis.
Проверка текущего состояния дел с требованиями Taking your requirements pulse
Чтобы проверить текущую ситуацию с требованиями в вашей организации, посмотрите сколько из следующих условий выполняются в вашем последнем проекте. Если в вашей ситуации применимы три или четыре элемента, эта книга для вас: For a quick check of the current requirements practices in your organization, consider how many of the following conditions apply to your most recent project. If more than three or four of these items describe your experience, this book is for you:
· Бизнес-цели, концепция и границы вашего проекта никогда четко не определялись. · The project’s business objectives, vision, and scope were never clearly defined.
· У клиентов никогда не хватало времени на работу над требованиями с аналитиками или разработчиками. · Customers were too busy to spend time working with analysts or developers on the requirements.
· Ваша команда не может напрямую взаимодействовать с непосредственными пользователями, чтобы разобраться с их потребностями. · Your team could not interact directly with representative users to understand their needs.
· Клиенты считают все требования критически важными, поэтому они не разбивают их по приоритетам. · Customers claimed that all requirements were critical, so they didn’t prioritize them.
· В процессе работы над кодом разработчики сталкиваются с многозначностью и отсутствием информации, поэтому им приходится догадываться о многих вещах. · Developers encountered ambiguities and missing information when coding, so they had to guess.
· Общение между разработчиками и заинтересованными лицами концентрируется на окнах и функциях интерфейса, а не на задачах, которые пользователи будут решать с использованием программного продукта. · Communications between developers and stakeholders focused on user interface displays or features, not on what users needed to accomplish with the software.
· Ваши клиенты никогда не одобряли требования. · Your customers never approved the requirements.
· Ваши клиенты одобрили требования к выпуску или итерации, после чего продолжили вносить в них изменения. · Your customers approved the requirements for a release or iteration and then changed them continually.
· Область действия проекта увеличилась вместе с принятием изменений в требования, но сроки был нарушены из-за отсутствия дополнительных ресурсов и отказа от удаления части функциональности. · The project scope increased as requirements changes were accepted, but the schedule slipped because no additional resources were provided and no functionality was removed.
· Затребованные изменения требований были утеряны, и никто не знает состояние запроса на указанные изменения. · Requested requirements changes got lost; no one knew the status of a particular change request.
· Клиенты запросили определенную функциональность и разработчики реализовали ее, но никто ее не использует. · Customers requested certain functionality and developers built it, but no one ever uses it.
· В конце проекта спецификация была выполнена, но бизнес-задачи не были выполнены, и клиент не удовлетворен. · At the end of the project, the specification was satisfied but the customer or the business objectives were not.

Определение требований к ПО

Определение требований к ПО Software requirements defined
Когда группа людей начинает обсуждать требования, они обычно начинают с проблемы терминологии. Разные эксперты, говоря об одном и том же документе, могут называть его пользовательскими требованиями, требованиями к ПО, бизнес-требованиями, функциональными требованиями, системными требованиями, требованиями к продукту или проекту, пользовательской точкой зрения, функцией или ограничением.

Имена, которые они применяют к различным требованиям, также различаются. Заказчики зачастую считают, что определенные ими требования — это высокоуровневая концепция продукта, предназначенная для разработчиков. Те, в свою очередь, полагают, что в отношении клиентов это детализированная разработка интерфейса пользователя. Такое многообразие ведет к сумятице и раздражающим проблемам коммуникации. 		When a group of people begin discussing requirements, they often start with a terminology problem. Different observers might describe a single statement as being a user requirement, software requirement, business requirement, functional requirement, system requirement, product requirement, project requirement, user story, feature, or constraint.

The names they use for various requirements deliverables also vary. A customer’s definition of requirements might sound like a high-level product concept to the developer. The developer’s notion of requirements might sound like a detailed user interface design to the user. This diversity of understanding leads to confusion and frustration.
Особенности интерпретации требований Some interpretations of ”requirement”
Десятки лет спустя после появления программирования для компьютеров специалисты по ПО все еще увлеченно спорят о том, что из себя представляет требование. Мы не станем участвовать в этих дебатах, а просто представим ряд определений, которые мы считаем полезными. Many decades after the invention of computer programming, software practitioners still have raging debates about exactly what a “requirement” is. Rather than prolong those debates, in this book we simply present some definitions that we have found useful.
Консультант Брайан Лоренс предположил, что требования — это «нечто такое, что определяет выбор дизайна» (Lawrence, 1997). Это неплохое неформальное определение, потому что в эту категорию можно отнести много видов информации. И, в конце концов, весь смысл разработки требований заключается в принятии соответствующих проектировочных решений, которые в конечном итоге должны удовлетворить клиента. Другое определение требования заключается в том, что продукт должен обеспечивать выгоду заинтересованному лицу. Тоже неплохо, но не очень точно. Наше любимое определение сформулировано Иеном Соммервиллем и Питом Сойером (Ian Sommerville и Pete Sawyer, 1997): Consultant Brian Lawrence suggests that a requirement is “anything that drives design choices” (Lawrence 1997). This is not a bad colloquial definition, because many kinds of information fit in this category. And, after all, the whole point of developing requirements is to make appropriate design choices that will meet the customer’s needs in the end. Another definition is that a requirement is a property that a product must have to provide value to a stakeholder. Also not bad, but not very precise. Our favorite definition, though, comes from Ian Sommerville and Pete Sawyer (1997):
· Требования — это спецификация того, что должно быть реализовано.
· В них описано поведение системы, свойства системы или ее атрибуты.
· Они могут служить ограничениями в процессе разработки системы.		 · Requirements are a specification of what should be implemented.
· They are descriptions of how the system should behave, or of a system property or attribute.
· They may be a constraint on the development process of the system.
Это определение учитывает самые разные типы информации, которые в совокупности называются требованиями. Требования охватывают как видение пользователя, так и внешнее поведение системы, а также представление разработчика о некоторых внутренних характеристиках. Они включают как поведение системы в определенных условиях, так и свойства, которые делают систему полезной и даже доставляющей удовольствие конечным операторам. This definition acknowledges the diverse types of information that collectively are referred to as “the requirements.” Requirements encompass both the user’s view of the external system behavior and the developer’s view of some internal characteristics. They include both the behavior of the system under specific conditions and those properties that make the system suitable—and maybe even enjoyable—for use by its intended operators.
Внимание!
Не рассчитывайте, что все заинтересованные лица вашего проекта разделяют общее представление о том, что же такое требования. Задайте определения с самого начала, чтобы вы все говорили на одном языке. 		Trap
Don’t assume that all your project stakeholders share a common notion of what requirements are. Establish definitions up front so that you’re all talking about the same things.
Определение термина «требование» в словаре The pure dictionary “requirement”
Специалисты по ПО используют термин «требование» не совсем в том же смысле, что и его значение в словаре, то есть как что-то требуемое и обязательное, потребность или необходимость. Люди иногда задаются вопросом, стоит ли вообще приоритизировать требования, ведь низкоприоритетные требования никогда не реализуются.

Если это не очень нужная вещь, то ее и требованием-то назвать сложно. Возможно, но как тогда называть эту информацию? Если перенести требование из нынешнего проекта в неопределенный будущий выпуск, то можно ли его все равно считать требованием? Конечно да. 		Software people do not use “requirement” in the same sense as a dictionary definition of the word: something demanded or obligatory, a need or necessity. People sometimes question whether they even need to prioritize requirements, because maybe a low-priority requirement won’t ever be implemented.

If it isn’t truly needed, then it isn’t a requirement, they claim. Perhaps, but then what would you call that piece of information? If you defer a requirement from today’s project to an unspecified future release, is it still considered a requirement? Sure it is.
Требования к ПО включают измерение времени. Они могут относиться к настоящему времени — в этом случае они описывают текущие функции системы. Или могут относиться к ближайшему (высокоприоритетные), среднему (среднеприоритетные) или гипотетическому (низкоприоритетные) будущему. Они могут даже относиться к прошлому времени, когда описывают запросы, которые были ранее определены, а затем отброшены. Не стоит тратить время на споры является ли что-то требованием или нет, даже если вы знаете, что оно скорее всего не будет реализовано по какой-то серьезной причине. Это требование и точка. Software requirements include a time dimension. They could be present tense, describing the current system’s capabilities. Or they could be for the near-term (high priority), mid-term (medium priority), or hypothetical (low priority) future. They could even be past tense, referring to needs that were once specified and then discarded. Don’t waste time debating whether or not something is a requirement, even if you know you might never implement it for some good business reason. It is.
Уровни и типы требований Levels and types of requirements
Из-за такого большого числа разных типов информации требований нам требуется единый набор описаний, изменяющих слишком перегруженный термин требование. В этом разделе приводятся определения, которые будут использоваться для терминов, наиболее часто применяемых у такой сфере, как разработка требований (см. табл. 1-1). Because there are so many different types of requirements information, we need a consistent set of adjectives to modify the overloaded term “requirement.” This section presents definitions we will use for some terms commonly encountered in the requirements domain (see Table 1-1).
Табл. 1-1. Информация о некоторых типах требований TABLE 1-1 Some types of requirements information
Понятие
Term		 Определение
Definition
Бизнес-требование
Business requirement		 Высокоуровневая бизнес-цель организации или заказчиков системы
A high-level business objective of the organization that builds a product or of a customer who procures it.
Бизнес-правило
Business rule		 Политика, предписание, стандарт или правило, определяющее или ограничивающее некоторые стороны бизнес-процессов. По своей сути это не требование к ПО, но оно служит источником нескольких типов требований к ПО
A policy, guideline, standard, or regulation that defines or constrains some aspect of the business. Not a software requirement in itself, but the origin of several types of software requirements.
Ограничение
Constraint		 Ограничение на выбор вариантов, доступных разработчику при проектировании и разработке продукта
A restriction that is imposed on the choices available to the developer for the design and construction of a product.
Внешнее требование к интерфейсу
External interface requirement		 Описание взаимодействия между ПО и пользователем, другой программной системой или устройством
A description of a connection between a software system and a user, another software system, or a hardware device.
Характеристика

Feature 		Одна или несколько логически связанных возможностей системы, которые представляют ценность для пользователя и описаны рядом функциональных требований
One or more logically related system capabilities that provide value to a user and are described by a set of functional requirements.
Функциональное требование
Functional requirement		 Описание требуемого поведения системы в определенных условиях
A description of a behavior that a system will exhibit under specific conditions.
Нефункциональное требование
Nonfunctional requirement		 Описание свойства или особенности, которым должна обладать система, или ограничение, которое должна соблюдать система
A description of a property or characteristic that a system must exhibit or a constraint that it must respect.
Атрибут качества
Quality attribute		 Вид нефункционального требования, описывающего характеристику сервиса или производительности продукта
A kind of nonfunctional requirement that describes a service or performance characteristic of a product.
Системное требование
System requirement		 Требование верхнего уровня к продукту, состоящему из многих подсистем, которые могут представлять собой ПО или совокупность ПО и оборудования
A top-level requirement for a product that contains multiple subsystems, which could be all software or software and hardware.
Пользовательское требование
User requirement		 Задача, которую определенные классы пользователей должны иметь возможность выполнять в системе, или требуемый атрибут продукта
A goal or task that specific classes of users must be able to perform with a system, or a desired product attribute.
Требования к ПО состоят из трех уровней — бизнес-требования, пользовательские и функциональные требования. Вдобавок в каждой системе есть свои нефункциональные требования. Модель на рис. 1-1 иллюстрирует способ представления этих типов требований. Как гласит знаменитое высказывание статистика Джорджа Е. П. Бокса (George E. P. Box), «В конечном счете все модели врут, но некоторые оказываются полезными» (Box и Draper, 1987). Это, конечно же, применимо к рис. 1-1. Как и все модели, она не полная, но схематично показывает организацию требований. Software requirements include three distinct levels: business requirements, user requirements, and functional requirements. In addition, every system has an assortment of nonfunctional requirements. The model in Figure 1-1 illustrates a way to think about these diverse types of requirements. As statistician George E. P. Box famously said, “Essentially, all models are wrong, but some are useful” (Box and Draper 1987). That’s certainly true of Figure 1-1. This model is not all inclusive, but it does provide a helpful scheme for organizing the requirements knowledge you’ll encounter.
Рис. 1-1. Взаимосвязи нескольких типов информации для требований. Сплошные линии означают «содержатся в», а пунктирные — «являются отправной точкой» или «влияют на». FIGURE 1-1 Relationships among several types of requirements information. Solid arrows mean “are stored in”; dotted arrows mean “are the origin of” or “influence.”
Внимание!
Хотя мы и называем требования «документами», как на рис. 1-1, это не обязательно традиционные бумажные или электронные документы. Их можно считать просто контейнерами, в которых хранится знание о требованиях. Такой контейнер может быть традиционным документом или же электронной таблицей, набором диаграмм, базой данных, средством управления требованиями или сочетанием всех этих артефактов. Для удобства мы будем называть документом любой такой контейнер. Мы предоставим шаблоны, которые определяют типы информации, которые стоит хранить в каждой из таких группировок независимо от того, в какой форме они хранятся. Как называть такие артефакты не так важно, как добиться согласия в компании относительно их имен, какие виды информации в них содержатся, а также как эта информация организована. 		Important
Although we will refer to requirements “documents” as in Figure 1-1, those do not have to be traditional paper or electronic documents. Instead, think of them simply as containers in which to store requirements knowledge. Such a container could indeed be a traditional document, or it could be a spreadsheet, a set of diagrams, a database, a requirements management tool, or some combination of these. For convenience, we will use the term “document” to refer to any such container. We will provide templates that identify the types of information to consider storing in each such grouping, regardless of what form you store it in. What you call each deliverable is less important than having your organization agree on their names, what kinds of information go into each, and how that information is organized.
Овалы обозначают типы информации требований, а прямоугольники — документы, в которых хранится эта информация. Сплошные линии указывают, что в указанном документе хранится информация определенного типа. Бизнес-правила и системные требования хранятся отдельно от требований к ПО, обычно соответственно в каталоге бизнес-правил или в спецификации системных требований. Пунктирная линия указывает, что информация одного типа является источником или влияет на информацию другого типа или на требование. На этой схеме не показаны требования к данным. Функции манипулируют данными, поэтому требования к данным могут присутствовать на всех трех уровнях. The ovals in Figure 1-1 represent types of requirements information, and the rectangles indicate documents in which to store that information. The solid arrows indicate that a certain type of information typically is stored in the indicated document. (Business rules and system requirements are stored separately from software requirements, such as in a business rules catalog or a system requirements specification, respectively.) The dotted arrows indicate that one type of information is the origin of or influences another type of requirement. Data requirements are not shown explicitly in this diagram. Functions manipulate data, so data requirements can appear throughout the three levels.
Бизнес-требования (business requirements) описывают, почему организации нужна такая система, то есть цели, которые организация намерена достичь с ее помощью. Основное их содержание — бизнес-цели организации или клиента, заказывающих систему. Допустим, что авиакомпания хочет на 25% снизить затраты на сотрудников у стойки в аэропорту. В процессе достижения этой цели может возникнуть идея поставить терминал, который пассажиры будут использовать для самостоятельной регистрации в аэропорту.

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

Мне нравится записывать бизнес-требования в форме документа о концепции и границах (vision and scope document). К другим руководящим документам, которые еще иногда используют в этом качестве, относят устав проекта (project charter), вариант использования (business case) или документ рыночных требований (market requirements document). Для целей этой книги мы предполагаем, что бизнес-потребность (business need) или рыночная возможность (market opportunity) уже определена. 		Business requirements describe why the organization is implementing the system—the business benefits the organization hopes to achieve. The focus is on the business objectives of the organization or the customer who requests the system. Suppose an airline wants to reduce airport counter staff costs by 25 percent. This goal might lead to the idea of building a kiosk that passengers can use to check in for their flights at the airport.

Business requirements typically come from the funding sponsor for a project, the acquiring customer, the manager of the actual users, the marketing department, or a product visionary.

We like to record the business requirements in a vision and scope document. Other strategic guiding documents sometimes used for this purpose include a project charter, business case, and market (or marketing) requirements document. For the purposes of this book, we are assuming that the business need or market opportunity has already been identified.
Пользовательские требования (user requirements) описывают цели или задачи, которые пользователи должны иметь возможность выполнять с помощью продукта, который в свою очередь должен приносить пользу кому-то. Область пользовательских требований также включает описания атрибутов или характеристик продукта, которые важны для удовлетворения пользователей. К отличным способам представления этого вида требований относятся варианты использования (Kulak и Guiney, 2004), пользовательские истории (Cohn, 2004) и таблицы «событие — отклик». В идеале эту информацию предоставляют реальные представители пользователей. User requirements describe goals or tasks the users must be able to perform with the product that will provide value to someone. The domain of user requirements also includes descriptions of product attributes or characteristics that are important to user satisfaction. Ways to represent user requirements include use cases (Kulak and Guiney 2004), user stories (Cohn 2004), and event-response tables. Ideally, actual user representatives will provide this information.
Пользовательские требования описывают, что пользователь должен иметь возможность делать с системой. Примером сценария использования является регистрация на рейс с использованием веб-сайта или терминала в аэропорту. Будучи сформулированным в виде пользовательской истории, то же пользовательское требование может звучать так: «Как пассажир я хочу зарегистрироваться на рейс, чтобы можно было сесть на самолет».

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

Некоторые люди используют более широкий термин «требования заинтересованных лиц» для обозначения того факта, что требования будут предоставляться различными заинтересованными лицами, отличными от прямых пользователей системы. Это конечно же верно, но на данном уровне нам нужно понять, что реальные пользователи хотят достичь с помощью продукта. 		User requirements describe what the user will be able to do with the system. An example of a use case is “Check in for a flight” using an airline’s website or a kiosk at the airport. Written as a user story, the same user requirement might read: “As a passenger, I want to check in for a flight so I can board my airplane.”

It’s important to remember that most projects have multiple user classes, as well as other stakeholders whose needs also must be elicited.

Some people use the broader term “stakeholder requirements,” to acknowledge the reality that various stakeholders other than direct users will provide requirements. That is certainly true, but we focus the attention at this level on understanding what actual users need to achieve with the help of the product.
Функциональные требования (functional requirements) определяют, каким должно быть поведение продукта в тех или иных условиях. Они определяют, что разработчики должны создать, чтобы пользователи смогли выполнить свои задачи (пользовательские требования) в рамках бизнес-требований.

Такое соотношение между тремя уровнями требований жизненно важно для успеха проекта. Функциональные требования описываются в форме традиционных утверждений со словами «должен» или «должна»: «У пассажира должна быть возможность распечатать посадочные талоны на все рейсы, на которые он зарегистрировался» или «Если в профиле пассажира не указаны предпочтения по выбору места, система резервирования должна сама назначить ему место». 		Functional requirements specify the behaviors the product will exhibit under specific conditions. They describe what the developers must implement to enable users to accomplish their tasks (user requirements), thereby satisfying the business requirements.

This alignment among the three levels of requirements is essential for project success. Functional requirements often are written in the form of the traditional “shall” statements: “The Passenger shall be able to print boarding passes for all flight segments for which he has checked in” or “If the Passenger’s profile does not indicate a seating preference, the reservation system shall assign a seat.”
Бизнес-аналитик документирует функциональные требования в спецификации требований к ПО (software requirements specification, SRS), где описывается так полно, как необходимо, ожидаемое поведение системы. Спецификация требований к ПО используется при разработке, тестировании, гарантии качества продукта, управлении проектом и в связанных с проектом функциях.

Этот артефакт называют по-разному: документ бизнес-требований, функциональная спецификация, документ требований и т. п. Спецификация требований к ПО может представлять собой отчет, сгенерированный на основе информации, хранимой в средстве управления требованиями. Так как этот термин принят в отрасли, мы будем в этой книге использовать обозначение «SRS» (ISO/IEC/IEEE 2011). 		The business analyst (BA) documents functional requirements in a software requirements specification (SRS), which describes as fully as necessary the expected behavior of the software system. The SRS is used in development, testing, quality assurance, project management, and related project functions.

People call this deliverable by many different names, including business requirements document, functional spec, requirements document, and others. An SRS could be a report generated from information stored in a requirements management tool. Because it is an industry-standard term, we will use “SRS” consistently throughout this book (ISO/IEC/IEEE 2011).
Термин системные требования (system requirements) описывает требования к продукту, который содержит многие компоненты или подсистемы (ISO/IEC/IEEE 2011). В этом смысле «система» это не просто любая информационная система. Говоря о системе, мы подразумеваем программное обеспечение или подсистемы ПО и оборудования. Люди и процессы тоже часть системы, поэтому определенные системные функции могут распространяться и на людей. Некоторые используют термин «системные требования» для обозначения подробных требований к программной системе, но в этой книге мы не используем этот термин в таком смысле. System requirements describe the requirements for a product that is composed of multiple components or subsystems (ISO/IEC/IEEE 2011). A “system” in this sense is not just any information system. A system can be all software or it can include both software and hardware subsystems. People and processes are part of a system, too, so certain system functions might be allocated to human beings. Some people use the term “system requirements” to mean the detailed requirements for a software system, but that’s not how we use the term in this book.
Хороший пример «системы» — рабочее место кассира в супермаркете. В нем есть сканер штрих-кода, интегрированный с весами, а также ручной сканер штрих-кода. У кассира есть клавиатура, монитор и выдвижной ящик- касса. Есть также устройство чтения кредитных карточек и клавиатура для ввода ПИН-кода и чтения карт постоянного покупателя.

На рабочем месте может быть до трех принтеров: для печати чека, квитанции кредитной карты и купонов на скидку. Все эти устройства взаимодействуют под управлением программного обеспечения. На основе требований к системе или продукту в целом бизнес-аналитик формулирует конкретную функциональность, которую должны поддерживать тот или иной компонент или подсистема, а также интерфейсы взаимодействия между ними. 		A good example of a “system” is the cashier’s workstation in a supermarket. There’s a bar code scanner integrated with a scale, as well as a hand-held bar code scanner. The cashier has a keyboard, a display, and a cash drawer. You’ll see a card reader and PIN pad for your loyalty card and credit or debit card, and perhaps a change dispenser.

You might see up to three printers for your purchase receipt, credit card receipt, and coupons you don’t care about. These hardware devices are all interacting under software control. The requirements for the system or product as a whole, then, lead the business analyst to derive specific functionality that must be allocated to one or another of those component subsystems, as well as demanding an understanding of the interfaces between them.
Бизнес-правила (business rules) включают корпоративные политики, правительственные постановления, отраслевые стандарты и вычислительные алгоритмы. Бизнес-правила не являются сами требованиями к ПО, потому что они находятся за пределами любой системы ПО.

Однако они часто налагают ограничения, определяя, какими функциями должна обладать система, подчиняющаяся соответствующим правилам. Иногда, как в случае с корпоративными политиками безопасности, бизнес-правила становятся источником атрибутов качества, которые реализуются в функциональности. Следовательно, вы можете отследить происхождение конкретных функциональных требований вплоть до соответствующих им бизнес-правил. 		Business rules include corporate policies, government regulations, industry standards, and computational algorithms. Business rules are not themselves software requirements because they have an existence beyond the boundaries of any specific software application.

However, they often dictate that the system must contain functionality to comply with the pertinent rules. Sometimes, as with corporate security policies, business rules are the origin of specific quality attributes that are then implemented in functionality. Therefore, you can trace the genesis of certain functional requirements back to a particular business rule.
В дополнение к функциональным требованиям спецификация SRS содержит нефункциональные. Атрибуты качества (quality attributes) еще называют параметрами качества, требованиями по уровню обслуживания и т. п. Они представляют собой описание различных измерений характеристик продукта, которые важны для пользователей или для разработчиков и тех, кто будет обслуживать систему, таких как производительность, доступность и переносимость.

Другие нефункциональные требования описывают внешние интерфейсы между системой и внешним миром. Речь идет о подключениях к другим программным системам, аппаратным устройствам и пользователям, а также коммуникационные интерфейсы. Ограничения (constraints) проектирования и реализации накладывают границы на возможности выбора разработчика при проектировании продукта. 		In addition to functional requirements, the SRS contains an assortment of nonfunctional requirements. Quality attributes are also known as quality factors, quality of service requirements, constraints, and the “-ilities.” They describe the product’s characteristics in various dimensions that are important either to users or to developers and maintainers, such as performance, safety, availability, and portability.

Other classes of nonfunctional requirements describe external interfaces between the system and the outside world. These include connections to other software systems, hardware components, and users, as well as communication interfaces. Design and implementation constraints impose restrictions on the options available to the developer during construction of the product.
Если они нефункциональные, то что они из себя представляют? If they’re nonfunctional, then what are they?
Многие годы требования к программным продуктам в целом классифицировались как функциональные и нефункциональные. С функциональными требованиями все ясно: они описывают наблюдаемое поведение системы в различных обстоятельствах. Но многим не нравится термин «нефункциональные». Это прилагательное говорит, чем не являются требования, но не говорит, чем они являются. Мы понимаем проблему, но не можем предложить идеального решения. For many years, the requirements for a software product have been classified broadly as either functional or nonfunctional. The functional requirements are evident: they describe the observable behavior of the system under various conditions. However, many people dislike the term “nonfunctional.” That adjective says what the requirements are not, but it doesn’t say what they are. We are sympathetic to the problem, but we lack a perfect solution.
Требования, отличные от функциональных, могут описывать не что система делает, а как хорошо она это делает. Они могут описывать важные характеристики или свойства системы. К ним относятся доступность, легкость и простота использования, производительность и другие характеристики системы. Некоторые люди считают нефункциональные требования тем же, что атрибуты качества, но это слишком узкое понимание. Например, ограничения проекта или реализации также являются нефункциональными требованиями, как требования внешних интерфейсов. Other-than-functional requirements might specify not what the system does, but rather how well it does those things. They could describe important characteristics or properties of the system. These include the system’s availability, usability, security, performance, and many other characteristics. Some people consider nonfunctional requirements to be synonymous with quality attributes, but that is overly restrictive. For example, design and implementation constraints are also nonfunctional requirements, as are external interface requirements.
Другие нефункциональные требования описывают среду, в которой работает система, например платформу, переносимость, совместимость и ограничения. Многие продукты также должны подчиняться определенным правилам, требованиям регулирующих органов или требовать сертификации. Такими могут быть требования по локализации для продуктов, в которых должны учитываться региональные стандарты, языки, законы, валюты, терминология, орфография и другие характеристики пользователей. Хотя такие требования определяются с использованием нефункциональной терминологии, бизнес-аналитик на их основе может определить много функций, чтобы система обладала всеми необходимыми свойствами и вела себя соответствующим образом в разных ситуациях. Still other nonfunctional requirements address the environment in which the system operates, such as platform, portability, compatibility, and constraints. Many products are also affected by compliance, regulatory, and certification requirements. There could be localization requirements for products that must take into account the cultures, languages, laws, currencies, terminology, spelling, and other characteristics of users. Though such requirements are specified in nonfunctional terms, the business analyst typically will derive numerous bits of functionality to ensure that the system possesses all the desired behaviors and properties.
Несмотря на описанные ограничения, в этой книге мы будем придерживаться термина «нефункциональные требования» за неимением подходящего всеобъемлющего альтернативного термина. Не надо волноваться о точности названия всей подобной информации — лучше позаботьтесь, чтобы она вошла в ваши действия по выявлению и анализу требований. Можно создать продукт, обладающий всей требуемой функциональностью, но пользователи могут невзлюбить его за то, что тот не соответствует их (обычно невысказанным) ожиданиям по качеству. In this book, we are sticking with the term “nonfunctional requirements,” despite its limitations, for the lack of a suitably inclusive alternative. Rather than worry about precisely what you call these sorts of information, just make sure that they are part of your requirements elicitation and analysis activities. You can deliver a product that has all the desired functionality but that users hate because it doesn’t match their (often unstated) quality expectations.
Характеристика (feature) — это набор логически связанных функциональных требований, которые представляют ценность для пользователя и удовлетворяют бизнес-цели. Желательные характеристики продукта, которые перечисляет клиент, не эквивалентны тем, что входят в список необходимых для решения задач пользователей. В качестве примеров характеристик продуктов можно привести избранные страницы или закладки веб-браузера, средства проверки орфографии, запись макрокоманды, автоматическое обновление определений вирусов в антивирусной программе. Характеристики могут охватывать множество пользовательских требований, и для каждого варианта необходимо, чтобы множество функциональных требований было реализовано для выполнения пользователем его задач. Рис. 1-2 иллюстрирует дерево функций (feature tree) — модель анализа, которая показывает, как функцию можно разложить на иерархию более мелких функций, которые связаны с конкретными пользовательскими требованиями и ведут к определению наборов функциональных требований (Beatty и Chen, 2012). A feature consists of one or more logically related system capabilities that provide value to a user and are described by a set of functional requirements. A customer’s list of desired product features is not equivalent to a description of the user’s task-related needs. Web browser bookmarks, spelling checkers, the ability to define a custom workout program for a piece of exercise equipment, and automatic virus signature updating in an anti-malware product are examples of features. A feature can encompass multiple user requirements, each of which implies that certain functional requirements must be implemented to allow the user to perform the task described by each user requirement. Figure 1-2 illustrates a feature tree, an analysis model that shows how a feature can be hierarchically decomposed into a set of smaller features, which relate to specific user requirements and lead to specifying sets of functional requirements (Beatty and Chen 2012).
Чтобы вы лучше восприняли некоторые из различных видов требований, проанализируем проект по разработке следующей версии текстового редактора. Бизнес-требование может звучать так: «Увеличить продажи за пределами США на 25% за следующие полгода». В отделе маркетинга выяснили, что в продуктах-конкурентах есть только англоязычные средства проверки орфографии, поэтому было принято решение включить возможность проверки орфографии на других языках. Соответствующие требования пользователей могут содержать задачи вроде такой: «Выберите язык проверки орфографии», «Найдите орфографические ошибки» или «Добавьте слово в словарь». To illustrate some of these various kinds of requirements, consider a project to develop the next version of a text editor program. A business requirement might be “Increase non-US sales by 25 percent within 6 months.” Marketing realizes that the competitive products only have English-language spelling checkers, so they decide that the new version will include a multilanguage spelling checker feature. Corresponding user requirements might include tasks such as “Select language for spelling checker,” “Find spelling errors,” and “Add a word to a dictionary.”
Проверка грамматики имеет множество индивидуальных функциональных требований, которые имеют дело с такими операциями, как поиск и выделение слов с ошибками, автоисправление, отображение вариантов замены и замена слова с ошибкой корректным вариантом по всему тексту. Требования по удобству использования (usability) определяют, как нужно локализовать ПО для использования с различными языками и наборами символов. The spelling checker has many individual functional requirements, which deal with operations such as highlighting misspelled words, autocorrect, displaying suggested replacements, and globally replacing misspelled words with corrected words. Usability requirements specify how the software is to be localized for use with specific languages and character sets.
Рис. 1-2. Взаимоотношения между функциями и пользовательским и функциональными требованиями FIGURE 1-2 Relationships among features, user requirements, and functional requirements.
Три уровня требований Working with the three levels
На рис. 1-3 показано, как различные заинтересованные лица могут участвовать в выявлении трех уровней требований. В разных организациях используют разные имена для ролей, участвующих в этой деятельности; подумайте, кто выполняет эту работу в вашей организации. Имена ролей часто различаются в зависимости от того, является ли подразделение, разрабатывающее продукт, внутренним отделом организации или компанией, создающей ПО для коммерческого использования. Figure 1-3 illustrates how various stakeholders might participate in eliciting the three levels of requirements. Different organizations use a variety of names for the roles involved in these activities; think about who performs these activities in your organization. The role names often differ depending on whether the developing organization is an internal corporate entity or a company building software for commercial use.
На основе выявленной бизнес-потребности, требования рынка или интересной концепции нового продукта менеджеры и сотрудники отдела маркетинга определяют бизнес-требования для ПО, которые помогут компании работать эффективнее (для информационных систем) или успешно конкурировать на рынке (для коммерческих продуктов). В корпоративной среде после этого аналитики обычно работают с представителями пользователей для определения пользовательских требований. В компаниях, разрабатывающих коммерческие продукты, часто назначают менеджера продукта, который определяет, какие функции должны включаться в новый продукт. Based on an identified business need, a market need, or an exciting new product concept, managers or marketing define the business requirements for software that will help their company operate more efficiently (for information systems) or compete successfully in the marketplace (for commercial products). In the corporate environment, a business analyst then typically works with user representatives to identify user requirements. Companies developing commercial products often identify a product manager to determine what features to include in the new product.
Каждое пользовательское требование должно быть сопоставлено бизнес-требованию. На основе пользовательских требований аналитик или менеджер продукта определяет функции, которые дадут возможность пользователям выполнять их задачи. Разработчикам необходимы функциональные и нефункциональные требования, чтобы создавать решения с желаемой функциональностью, не выходя за рамки налагаемых ограничений. Тестировщики определяют, как проверять правильность реализации требований. Each user requirement and feature must align with accomplishing the business requirements. From the user requirements, the BA or product manager derives the functionality that will let users achieve their goals. Developers use the functional and nonfunctional requirements to design solutions that implement the necessary functionality, within the limits that the constraints impose. Testers determine how to verify whether the requirements were correctly implemented.
Рис. 1-3. Пример участия различных заинтересованных лиц в разработке требований FIGURE 1-3 An example of how different stakeholders participate in requirements development.
Важно понимать ценность письменной фиксации жизненно важных требований в доступной для совместного использования форме, а не сведений, передающихся от человека к человеку изустно. Однажды я работал над проектом, в котором часто менялись команды разработчиков. Основной заказчик был недоволен тем, что из каждой новой команды к нему приходили со словами: «Нам надо поговорить о требованиях». Его реакция на этот запрос звучала так: «Я уже рассказал вашим предшественникам о моих требованиях. Так что просто займитесь созданием системы!» К сожалению, никто не потрудился задокументировать никаких требований, поэтому каждой новой команде приходилось начинать с нуля. По крайней мере безответственно заявлять, что у вас «есть требование», если на самом деле у вас несколько сообщений электронной почты и голосовой почты, ряд записок-наклеек, протоколы совещаний и туманные воспоминания о разговорах с заказчиком. Аналитик должен выработать осмотрительный подход для определения, насколько полной должна быть документация требований в том или ином проекте. It’s important to recognize the value of recording vital requirements information in a shareable form, rather than treating it as oral tradition around the project campfire. I was on a project once that had experienced a rotating cast of development teams. The primary customer was sick to tears of having each new team come along and say, “We have to talk about your requirements.” His reaction to our request was, “I already gave your predecessors my requirements. Now build me a system!” Unfortunately, no one had ever documented any requirements, so every new team had to start from scratch. To proclaim that you “have the requirements” is delusional if all you really have is a pile of email and voice mail messages, sticky notes, meeting minutes, and vaguely recollected hallway conversations. The BA must practice good judgment to determine just how comprehensive to make the requirements documentation on a given project.
На рис. 1-1 были показаны три главных документа требований: документ концепции и границ, документ пользовательских требований и спецификация программных требований. Не всегда обязательно создавать эти три отдельных документа в каждом проекте. Часто имеет смысл объединять часть информации, особенно в небольших проектах. Однако надо понимать, что эти три документа содержат разную информацию, разрабатываются на разных этапах проекта, возможно даже разными людьми с разными целями и разной целевой аудиторией. Figure 1-1, shown earlier in this chapter, identified three major requirements deliverables: a vision and scope document, a user requirements document, and a software requirements specification. You do not necessarily need to create three discrete requirements deliverables on each project. It often makes sense to combine some of this information, particularly on small projects. However, recognize that these three deliverables contain different information, developed at different points in the project, possibly by different people, with different purposes and target audiences.
Модель на рис. 1-1 показывает простой «сверху вниз» поток информации требований. В реальности возможно наличие циклов и итераций пользовательских, функциональных и бизнес-требований. Каждый раз когда кто-то предлагает ввести новую функцию, пользовательское требование или улучшение функциональности, аналитик должен задаться вопросом: «Укладывается ли это в рамки проекта?» Если ответ положительный, требование должно присутствовать в спецификации. В противном случае требования в спецификации быть не должно, по крайней мере в текущем выпуске или итерации. The model in Figure 1-1 showed a simple top-down flow of requirements information. In reality, you should expect cycles and iteration among the business, user, and functional requirements. Whenever someone proposes a new feature, user requirement, or bit of functionality, the analyst must ask, “Is this in scope?” If the answer is “yes,” the requirement belongs in the specification. If the answer is “no,” it does not, at least not for the forthcoming release or iteration.
Третий возможный ответ звучит так: «Нет, но это поддерживает бизнес-цели, поэтому должно быть в спецификации». В этом случае, ответственный за область действия проекта — куратор, менеджер или ответственный за проект, должен решить, нужно ли расширять рамки текущего проекта или итерации, чтобы включить новое требование. Это бизнес-решение, которое оказывает влияние на график и бюджет проекта и может требовать пожертвовать другими возможностями. Эффективный процесс управления изменениями, включающий анализ последствий, гарантирует, что «правильные люди» принимают информированные бизнес-решения о том, какие изменения следует принять, а также что учитываются сопутствующие затраты времени или ресурсов или компромиссы в выборе функциональности. The third possible answer is “no, but it supports the business objectives, so it ought to be.” In that case, whoever controls the project scope—the project sponsor, project manager, or product owner—must decide whether to increase the current project’s or iteration’s scope to accommodate the new requirement. This is a business decision that has implications for the project’s schedule and budget and might demand trade-offs with other capabilities. An effective change process that includes impact analysis ensures that the right people make informed business decisions about which changes to accept and that the associated costs in time, resources, or feature trade-offs are addressed.
Требования к продукту и требования к проекту Product vs. project requirements
До этого момента мы обсуждали требования, описывающие свойства программной системы, которую планируется построить. Назовем их требованиями к продукту. Для проекта, как правило, создаются требования других типов: документ, где описана среда разработки, ограничения бюджета, руководство пользователя или требования для выпуска продукта и продвижения его в поддерживаемую среду. Это требования к проекту, но не к продукту. Спецификация требований содержит требования к продукту и не содержит деталей дизайна или реализации (кроме известных ограничений), данных о планировании проекта, сведений о тестировании и тому подобной информации. Удалите указанные элементы из требований, чтобы из этого документа было абсолютно ясно, что надлежит построить команде разработчиков. К требованиям проекта относятся: So far we have been discussing requirements that describe properties of a software system to be built. Let’s call those product requirements. Projects certainly do have other expectations and deliverables that are not a part of the software the team implements, but that are necessary to the successful completion of the project as a whole. These are project requirements but not product requirements. An SRS houses the product requirements, but it should not include design or implementation details (other than known constraints), project plans, test plans, or similar information. Separate out such items so that requirements development activities can focus on understanding what the team intends to build. Project requirements include:
• физические ресурсы, необходимые команде разработки, такие как рабочие станции, специальные аппаратные устройства, тестовые лаборатории, средства и оборудование тестирования, командные комнаты и оборудование для видеоконференций; • Physical resources the development team needs, such as workstations, special hardware devices, testing labs, testing tools and equipment, team rooms, and videoconferencing equipment.
• потребности в обучении персонала; • Staff training needs.
• пользовательская документация, включая обучающие материалы, пособия, справочные руководства и информация о выпусках ПО; • User documentation, including training materials, tutorials, reference manuals, and release notes.
• документация для поддержки, такая как ресурсы службы технической поддержки, а также информация о техническом обеспечении и обслуживании аппаратных устройств; • Support documentation, such as help desk resources and field maintenance and service information for hardware devices.
• инфраструктурные изменения, которые необходимо внести в рабочую среду; • Infrastructure changes needed in the operating environment.
• требования и процедуры для выпуска продукта, установки в рабочей среде, конфигурирования и тестирования; • Requirements and procedures for releasing the product, installing it in the operating environment, configuring it, and testing the installation.
• требования и процедуры для перехода со старой на новую систему, например требования по переносу и преобразованию данных, по настройке безопасности, переносу производства и обучению для восполнения недостатка квалификации — это требования иногда называют требованиями по переходу (transition requirements) (IIBA 2009); • Requirements and procedures for transitioning from an old system to a new one, such as data migration and conversion requirements, security setup, production cutover, and training to close skills gaps; these are sometimes called transition requirements (IIBA 2009).
• требования по сертификации продукта и его соответствия требованиям регулирующих органов; • Product certification and compliance requirements.
• скорректированные политики, процессы, организационные структуры и аналогичные документы; • Revised policies, processes, organizational structures, and similar documents.
• сорсинг, приобретение и лицензирование ПО сторонних производителей и компонентов оборудования; • Sourcing, acquisition, and licensing of third-party software and hardware components.
• требования по бета-тестированию, производству, упаковке, маркетингу и дистрибуции; • Beta testing, manufacturing, packaging, marketing, and distribution requirements.
• соглашения об уровне обслуживания с клиентами; • Customer service-level agreements.
• требования по правовой защите (патенты, товарные знаки или авторское право) интеллектуальной собственности, связанной с разрабатываемым ПО. • Requirements for obtaining legal protection (patents, trademarks, or copyrights) for intellectual property related to the software.
Эти требования к проекту не будут рассмотрены в этой книге. Это не значит, что они не важны, — просто они находятся за рамками нашей тематики, посвященной разработке и управлению требованиям к программному продукту. Определение этих требований к проекту является совместной ответственностью бизнес-аналитика и менеджера проекта. Они часто возникают при сборе требований к продукту. Информацию требований к проекту лучше всего хранить в плане управления проектом, который должен описывать все ожидаемые операции и результаты проекта. This book does not address these sorts of project requirements further. That doesn’t mean that they aren’t important, just that they are out of scope for our focus on software product requirements development and management. Identifying these project requirements is a shared responsibility of the BA and the project manager. They often come up while eliciting product requirements. Project requirements information is best stored in the project management plan, which should itemize all expected project activities and deliverables.
В частности бизнес-приложения люди иногда называют «решением», которое охватывает как требования к продукту (за которые отвечает бизнес- аналитик), так и требования к проекту (за которые отвечает менеджер проекта). Они могут употреблять термин «рамки решения» в смысле «все, что нужно сделать для успешного завершения проекта». Однако в этой книге мы сосредоточимся на требованиях к продукту, что бы это ни было — коммерческий программный продукт, аппаратное устройство с встроенным ПО, корпоративная информационная система, ПО для государственных учреждений и т. п. Particularly for business applications, people sometimes refer to a “solution” as encompassing both the product requirements (which are principally the responsibility of the business analyst) and the project requirements (which are principally the responsibility of the project manager). They might use the term “solution scope” to refer to “everything that has to be done to complete the project successfully.” In this book, though, we are focusing on product requirements, whether your ultimate deliverable is a commercial software product, a hardware device with embedded software, a corporate information system, contracted government software, or anything else.

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

Разработка и управление требованиями Requirements development and management
Путаница в терминологии возникает, как только речь заходит о требованиях, и затрагивает даже то, что именно называть этим словом. Некоторые авторы называют всю эту предметную область разработкой технических условий (нам такой подход ближе всего), вторые употребляют термин управление требованиями (requirements management), а третьи считают эту деятельность подмножеством более общей предметной области бизнес-анализа. Confusion about requirements terminology extends even to what to call the whole discipline. Some authors call the entire domain requirements engineering (our preference). Others refer to it all as requirements management. Still others refer to these activities as a subset of the broad domain of business analysis.
Мы считаем полезным разделить область разработки технических условий на разработку требований (requirements development) и управление требованиями (requirements management) — как показано на рис. 1-4. Независимо от методологии проекта — водопадная, поэтапная, итеративная, гибкая или смешанная — есть вещи, которые надо выполнить в отношении всех требований. В зависимости от методологии эти операции могут выполняться в разное время жизненного цикла проекта и с разным уровнем глубины и детализации. We find it useful to split requirements engineering into requirements development (addressed in Part II of this book) and requirements management (addressed in Part IV), as shown in Figure 1-4. Regardless of what development life cycle your project is following—be it pure waterfall, phased, iterative, incremental, agile, or some hybrid—these are the things you need to do regarding requirements. Depending on the life cycle, you will perform these activities at different times in the project and to varying degrees of depth or detail.
Рис. 1-4. Составные части предмета разработки технических условий FIGURE 1-4 Subdisciplines of software requirements engineering.
Разработка требований Requirements development
Как показано на рис. 1-4, мы подразделяем разработку технических условий на выявление (elicitation), анализ (analysis), документирование (specification) и утверждение (validation) (Abran и другие, 2004). В эти составные части входят все действия, включающие сбор, оценку, документирование и утверждение требований для ПО. Далее описаны основные действия в каждой из составных частей. As Figure 1-4 shows, we subdivide requirements development into elicitation, analysis, specification, and validation (Abran et al. 2004). These subdisciplines encompass all the activities involved with exploring, evaluating, documenting, and confirming the requirements for a product. Following are the essential actions in each subdiscipline.
Выявление и сбор требований Elicitation
Выявление и сбор требований (elicitation) охватывает все действия, связанные с выявлением требований, такие как интервью, совещания, анализ документов, создание прототипов и другие. К ключевым действиям относятся: Elicitation encompasses all of the activities involved with discovering requirements, such as interviews, workshops, document analysis, prototyping, and others. The key actions are:
• Определение классов ожидаемых пользователей продукта и других заинтересованных лиц. • Identifying the product’s expected user classes and other stakeholders.
• Понимание задач и целей, а также бизнес-целей, которым соответствуют эти задачи. • Understanding user tasks and goals and the business objectives with which those tasks align.
• Изучение среды, в которой будет использоваться новый продукт. • Learning about the environment in which the new product will be used.
• Работа с отдельными людьми, которые представляют каждый класс пользователей, чтобы понять их потребности и ожидания в отношении качества. • Working with individuals who represent each user class to understand their functionality needs and their quality expectations.
На что ориентироваться: на использование или на продукт? Usage-centric or product-centric?
При сборе требований обычно используется подход, ориентированный на использование, или подход, ориентированный на продукт, хотя возможны и другие стратегии. В ориентированном на использование подходе упор делается на понимание и исследование задач пользователей, и на основе этой информации выводится необходимая функциональность системы. Ориентированный на продукт подход сфокусирован на определение функций, которые, как ожидается, приведут к успеху на рынке или успеху бизнеса компании. В стратегиях, ориентированных на продукт, есть риск реализовать функции, которые не будут активно использоваться, несмотря на то, что во время сбора требований они казались очень нужными. Мы рекомендуем сначала изучить бизнес-цели и цели пользователей, а затем на основе этой информации определить нужные функции и характеристики продукта. Requirements elicitation typically takes either a usage-centric or a product-centric approach, although other strategies also are possible. The usage-centric strategy emphasizes understanding and exploring user goals to derive the necessary system functionality. The product-centric approach focuses on defining features that you expect will lead to marketplace or business success. A risk with product-centric strategies is that you might implement features that don’t get used much, even if they seemed like a good idea at the time. We recommend understanding business objectives and user goals first, then using that insight to determine the appropriate product features and characteristics.
Анализ Analysis
Анализ требований (analyzing requirements) подразумевает получение более обширного и точного понимания всех требований и представление наборов требований в различном виде. Далее перечислены основные действия: Analyzing requirements involves reaching a richer and more precise understanding of each requirement and representing sets of requirements in multiple ways. Following are the principal activities:
· анализ информации, полученной от пользователей, чтобы отделить их задачи от функциональных и нефункциональных требований, бизнес-правил, предполагаемых решений и другой информации; · Analyzing the information received from users to distinguish their task goals from functional requirements, quality expectations, business rules, suggested solutions, and other information
· разложение высокоуровневых требований до нужного уровня детализации; · Decomposing high-level requirements into an appropriate level of detail
· выведение функциональных требований из информации других требований; · Deriving functional requirements from other requirements information
· понимание относительной важности атрибутов качества; · Understanding the relative importance of quality attributes
· распределение требований по компонентам ПО, определенным в системной архитектуре; · Allocating requirements to software components defined in the system architecture
· согласование приоритетов реализации; · Negotiating implementation priorities
· выявление пробелов в требованиях или излишних требований, не соответствующих заданным рамкам. · Identifying gaps in requirements or unnecessary requirements as they relate to the defined scope
Документирование Specification
Документирование требований предусматривает представление и хранение совокупного знания о требованиях постоянным и хорошо организованным способом. К ключевому действию относится преобразование собранных потребностей пользователей в письменные требования и диаграммы, пригодные для понимания, анализа и использования целевой аудиторией. Requirements specification involves representing and storing the collected requirements knowledge in a persistent and well-organized fashion. The principal activity is:
· Translating the collected user needs into written requirements and diagrams suitable for comprehension, review, and use by their intended audiences.
Утверждение Validation
Утверждение требований (requirements validation) должна подтвердить правильность имеющегося набора требований, которые позволят разработчикам создать решение, удовлетворяющее бизнес-целям. Далее перечислены основные действия: Requirements validation confirms that you have the correct set of requirements information that will enable developers to build a solution that satisfies the business objectives. The central activities are:
• проверка задокументированных требований для устранения всех недостатков до принятия требований группой разработки; • Reviewing the documented requirements to correct any problems before the development group accepts them.
• разработка приемочных тестов и критериев, которые должны подтвердить, что созданный на основе требований продукт будет отвечать потребностям заказчика и удовлетворять поставленным бизнес-целям. • Developing acceptance tests and criteria to confirm that a product based on the requirements would meet customer needs and achieve the business objectives.
Итерация — ключевое условия успеха разработки. При планировании нужно предусмотреть не один цикл проверки требований для поступательного уточнения деталей высокоуровневых требований и подтверждения правильности пользователями. На это может уходить много времени, и подобная деятельность может быть не очень захватывающей, но это неизбежная процедура разрешения всех неясностей при определении новой программной системы. Iteration is a key to requirements development success. Plan for multiple cycles of exploring requirements, progressively refining high-level requirements into more precision and detail, and confirming correctness with users. This takes time and it can be frustrating. Nonetheless, it’s an intrinsic aspect of dealing with the fuzzy uncertainty of defining a new software system.
Внимание!
Вы никогда не сможете создать идеальные требования. С практической точки зрения цель разработки требований — накопить общее понимание требований, достаточно хорошее для создания очередной порции продукта — будь то один или сто процентов, чтобы продолжить работу при разумном уровне риска. Основной риск заключается в наличии большого объема незапланированных недоделок, потому что команда недостаточно глубоко разобралась с требованиями к очередному этапу работы перед началом проектирования и разработки. 		Important
You’re never going to get perfect requirements. From a practical point of view, the goal of requirements development is to accumulate a shared understanding of requirements that is good enough to allow construction of the next portion of the product—be that 1 percent or 100 percent of the entire product—to proceed at an acceptable level of risk. The major risk is that of having to do excessive unplanned rework because the team didn’t sufficiently understand the requirements for the next chunk of work before starting design and construction.
Управление требованиями Requirements management
К действиям по управлению требованиями относятся: Requirements management activities include the following:
• определение основной версии требований, моментальный снимок, который представляет согласованный, проверенный и одобренный набор функциональных и нефункциональных требований, обычно для конкретного выпуска продукта или итерации разработки; • Defining the requirements baseline, a snapshot in time that represents an agreed-upon, reviewed, and approved set of functional and nonfunctional requirements, often for a specific product release or development iteration
• оценка влияния предлагаемых требований и внедрение одобренных изменений в проект управляемым образом; • Evaluating the impact of proposed requirements changes and incorporating approved changes into the project in a controlled way
• обновление планов проекта в соответствии с изменениями в требованиях; • Keeping project plans current with the requirements as they evolve
• обсуждение новых обязательств, основанных на оцененном влиянии изменения требований; • Negotiating new commitments based on the estimated impact of requirements changes
• определение отношений и зависимостей, существующих между требованиями; • Defining the relationships and dependencies that exist between requirements
• отслеживание отдельных требований до их проектирования, исходного кода и тестов; • Tracing individual requirements to their corresponding designs, source code, and tests
• отслеживание состояния требований и действий по изменению на протяжении всего проекта. • Tracking requirements status and change activity throughout the project
Предмет управления требованиями заключается не в предотвращении изменении или усложнении их внесения — задача состоит в предугадывании и приспосабливании к ожидаемым реальным изменениям, чтобы снизить их разрушительное влияние на проект. The object of requirements management is not to stifle change or to make it difficult. It is to anticipate and accommodate the very real changes that you can always expect so as to minimize their disruptive impact on the project.
На рис. 1-5 показан другой способ разделения областей разработки требований и управления ими. В этой книге описаны десятки специальных приемов выявления требований, их анализа, документации, проверки и управления. Figure 1-5 provides another view of the boundary between requirements development and requirements management. This book describes dozens of specific practices for performing requirements elicitation, analysis, specification, validation, and management.
Рис. 1-5. Разделение областей разработки требований и управления ими FIGURE 1-5 The boundary between requirements development and requirements management.

Каждый проект имеет требования

Каждый проект имеет требования Every project has requirements
Фредерик Брукс выразительно определил критическую роль требований в проекте разработки ПО в классическом эссе 1987 года «No Silver Bullet: Essence and Accidents of Software Engineering»: Frederick Brooks eloquently stated the critical role of requirements to a software project in his classic 1987 essay, “No Silver Bullet: Essence and Accidents of Software Engineering”:
«Самая сложная часть построения систем ПО — решить точно, что же создавать. Никакая другая часть концептуальной работы не является такой трудной, как выяснение деталей технических требований, в том числе и взаимодействие с людьми, механизмами и иными системами ПО. Никакая другая часть работы так не портит результат, если она выполнена плохо. Никакая другая часть не дает более трудные для исправления ошибки». The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.
Каждая содержащая ПО система имеет пользователей, которые полагаются на нее. Время, которое тратится на выяснение потребностей пользователей, представляет собой высокоэффективную инвестицию в успех проекта. Если в команде проекта не регистрируют в письменном виде требования, с которыми заказчики уже согласились, как могут они удовлетворить этих заказчиков? Every software-containing system has stakeholders who rely on it. The time spent understanding their needs is a high-leverage investment in project success. If a project team does not have written representations of requirements that the stakeholders agree to, how can developers be sure to satisfy those stakeholders?
Зачастую невозможно — или не нужно — полностью определить требования до начала проектирования и реализации. В этом случае действуйте итеративно и постепенно: разрабатывайте одну порцию требований за раз и обязательно дожидайтесь ответной реакции заказчика, прежде чем приступать к следующему циклу. Это суть разработки по гибкой методологии — выяснение ровно такого объема требований, чтобы выполнить разумную приоритизацию и планирование выпуска, чтобы команда могла максимально быстро начинать создавать ценное ПО. Это не может служить оправданием написания кода до изучения требований перед следующим шагом. Итерации при кодировании стоят гораздо дороже, чем при разработке концепций. Often, it’s impossible—or unnecessary—to fully specify the functional requirements before commencing design and implementation. In those cases, you can take an iterative or incremental approach, implementing one portion of the requirements at a time and obtaining customer feedback before moving on to the next cycle. This is the essence of agile development, learning just enough about requirements to do thoughtful prioritization and release planning so the team can begin delivering valuable software as quickly as possible. This isn’t an excuse to write code before contemplating requirements for that next increment, though. Iterating on code is more expensive than iterating on concepts.
Люди иногда предпочитают не тратить время на написание требований, но этот этап не самый сложный. Самое трудное — выявить эти требования. Первоначально написание требований представляет собой процесс выяснения, разработки и расшифровки данных. Четкое понимание требований к продукту дает вам уверенность, что ваша команда работает над теми проблемами, над которыми нужно, и создает лучшее их решение. Не зная, что собой представляют требования, вы не сможете определить момент окончания проекта, установить, достигнуты ли цели, или выбрать компромиссное решение, когда придется корректировать границы проекта. Вместо того, чтобы отказываться от затрат времени на создание требований, откажитесь от потерь денег из-за недостаточного внимания к требованиям в проекте. People sometimes balk at spending the time that it takes to write software requirements. But writing the requirements isn’t the hard part. The hard part is determining the requirements. Writing requirements is a matter of clarifying, elaborating, and recording what you’ve learned. A solid under­standing of a product’s requirements ensures that your team works on the right problem and devises the best solution to that problem. Without knowing the requirements, you can’t tell when the project is done, determine whether it has met its goals, or make trade-off decisions when scope adjustments are necessary. Instead of balking at spending time on requirements, people should instead balk at the money wasted when the project doesn’t pay enough attention to requirements.

Когда плохие требования появляются у хороших людей

Когда плохие требования появляются у хороших людей When bad requirements happen to good people
Основное следствие проблем с требованиями — переделка того, что, как вы думаете, уже готово. На это расходуется от 30 до 50% общего бюджета разработки (Shull, et al., 2002; GAO, 2004), а ошибки в требованиях стоят от 70 до 85% стоимости переделки (Leffingwell, 1997). Небольшие переделки повышают ценность и улучшают продукт, но очень большой объем переделок не несет ничего кроме растраты ресурсов и разочарования. Вообразите, насколько изменилась бы ваша жизнь, если бы вы сократили объем переделок наполовину! Члены вашей команды могли бы создавать ПО быстрее и даже приходить домой вовремя. Создание более качественных требований это инвестиции, а не затраты. The major consequence of requirements problems is rework—doing again something that you thought was already done—late in development or after release. Rework often consumes 30 to 50 percent of your total development cost (Shull, et al. 2002; GAO 2004), and requirements errors can account for 70 to 85 percent of the rework cost (Leffingwell 1997). Some rework does add value and improves the product, but excessive rework is wasteful and frustrating. Imagine how different your life would be if you could cut the rework effort in half! Your team members could build better products faster and perhaps even go home on time. Creating better requirements is an investment, not just a cost.
Гораздо дороже исправить дефекты, которые найдены позднее в проекте, чем сразу после создания. Допустим, что стоимость нахождения и устранения дефекта требования в процессе работы над ним составляет один доллар (по относительной шкале). Если же ошибка обнаружится во время проектирования, придется потратить доллар на исправление ошибки в требовании и еще 2-3 доллара на переделку проекта, основанного на неправильном требовании. Но представьте, что никто не обнаружил ошибку, пока не позвонил пользователь и не пожаловался на нее. Стоимость устранения дефекта зависит от типа системы и может достигать на нашей относительной шкале 100 или больше долларов (Boehm, 1981; Grady, 1999; Haskins, 2004). Один из клиентов, которому я оказывал консалтинговые услуги, определил, что в среднем трудозатраты на обнаружение и исправление дефекта в их информационной системе составляли 200 долларов, при этом использовалась специальная методика проверки ПО, один из видов дружественной проверки (Wiegers, 2002). С другой стороны, исправление ошибки, обнаруженной пользователем, обходилось в 4200 долларов — в 21 раз дороже. Предотвращение ошибок в требованиях и обнаружение их на самых ранних этапах сильно снижает объем переделок. It can cost far more to correct a defect that’s found late in the project than to fix it shortly after its creation. Suppose it costs $1 (on a relative scale) to find and fix a requirement defect while you’re still working on the requirements. If you discover that error during design instead, you have to pay the $1 to fix the requirement error, plus another $2 or $3 to redo the design that was based on the incorrect requirement. Suppose, though, that no one finds the error until a user calls with a problem. Depending on the type of system, the cost to correct a requirement defect found in operation can be $100 or more on this relative scale (Boehm 1981; Grady 1999; Haskins 2004). One of my consulting clients determined that they spent an average of $200 of labor effort to find and fix a defect in their information systems using the quality technique of software inspection, a type of peer review (Wiegers 2002). In contrast, they spent an average of $4,200 to fix a single defect reported by the user, an amplification factor of 21. Preventing requirements errors and catching them early clearly has a huge leveraging effect on reducing rework.
Недостатки в требованиях представляют собой угрозу успеху проекта, где успех означает выпуск продукта, который удовлетворяет ожиданиям пользователей по качеству и функциональности при соблюдении бюджета и графика проекта. Некоторые из наиболее общих рисков описаны далее в этой главе. Shortcomings in requirements practices pose many risks to project success, where success means delivering a product that satisfies the user’s functional and quality expectations at the agreed- upon cost and schedule. Some of the most common requirements risks are described in the following sections.
Недостаточное вовлечение пользователей Insufficient user involvement
Заказчики зачастую не понимают, почему так важно тщательно собрать требования и обеспечить их качество. Разработчики не всегда придают значение вовлечению пользователей в процесс скорее всего из-за того, что они считают, что все уже знают о потребностях пользователей. В некоторых случаях трудно добраться до людей, которые непосредственно будут иметь дело с продуктом, а те, кто заменяет пользователей, не всегда понимают, что тем нужно в реальности. Недостаточное вовлечение пользователей ведет к обнаружению ошибок в требованиях на поздних стадиях проекта, а значит, к задержке завершения проекта. Customers often don’t understand why it is so essential to work hard on eliciting requirements and assuring their quality. Developers might not emphasize user involvement, perhaps because they think they already understand what the users need. In some cases it’s difficult to gain access to people who will actually use the product, and user surrogates don’t always understand what users really need. Insufficient user involvement leads to late-breaking requirements that generate rework and delay completion.
Еще один риск, связанный с недостаточным вовлечением пользователей, особенно при анализе и проверке требований, заключается в том, что бизнес-аналитик может не понять и неправильно задокументировать реальные бизнес-требования или потребности клиента. Иногда бизнес-аналитик идет по пути определения того, что кажется «идеальными» требованиями, а разработчики реализуют их, но никто не использует решение, потому что бизнес-задача была понята неправильно. Продолжающиеся совещания с пользователями могут помочь снизить риск, но если пользователи проверят требования недостаточно тщательно, у вас все равно могут быть проблемы. Another risk of insufficient user involvement, particularly when reviewing and validating the requirements, is that the business analyst might not understand and properly record the true business or customer needs. Sometimes a BA goes down the path of specifying what appears to be the “perfect” requirements, and developers implement them, but then no one uses the solution because the business problem was misunderstood. Ongoing conversations with users can help mitigate this risk, but if users don’t review the requirements carefully enough, you can still have problems.
Небрежное планирование Inaccurate planning
«Я кое-что придумал для нового продукта. Когда вы сможете это сделать?» Не отвечайте на подобный вопрос, пока больше не узнаете о проблеме. Неопределенные, плохо понятые требования порождают слишком оптимистические оценки, которые возвращаются и не дают нам покоя, когда возникает перерасход. Неподготовленная оценка звучит как обязательство для слушателя. Наибольшие вклады в проект при плохо просчитанной смете составляют затраты на частые изменения требований, пропущенные требования, недостаточное взаимодействие с пользователями, недетализированную спецификацию требований и плохой анализ (Davis, 1995). Оценка трудоемкости и продолжительности проекта на основе требований означает, что вы должны что-то знать об объеме своих требований и продуктивности команды разработчиков. “Here’s my idea for a new product; when will you be done?” No one should answer this question until more is known about the problem being discussed. Vague, poorly understood requirements lead to overly optimistic estimates, which come back to haunt you when the inevitable overruns occur. An estimator’s quick guess sounds a lot like a commitment to the listener. The top contributors to poor software cost estimation are frequent requirements changes, missing requirements, insufficient communication with users, poor specification of requirements, and insufficient requirements analysis (Davis 1995). Estimating project effort and duration based on requirements means that you need to know something about the size of your requirements and the development team’s productivity.
«Разрастание» требований пользователей Creeping user requirements
В процессе разработки требования могут меняться из-за чего проект часто выходит за установленные рамки как по срокам, так и по бюджету. Чтобы управлять пределами разрастания требований, для начала уточните бизнес-цели проекта, стратегическое видение, ограничения и критерии успеха. Оцените, как все предполагаемые новые характеристики или требования, отразятся на этих параметрах. Требования будут изменяться и расти. Менеджер проекта должен предусмотреть «буферы планирования» на случай непредвиденных обстоятельств, чтобы первое же новое требование не привело к срыву графика (Wiegers, 2007). В проектах гибкой методологии объем итерации корректируется так, чтобы вписаться в заданный бюджет и длительность итерации. При появлении новых требований они размещаются в резерве (backlog) и назначаются в будущие итерации на основе приоритета. Изменения зачастую критически важны для успеха, однако они всегда имеют цену. As requirements evolve during development, projects often exceed their planned schedules and budgets (which are nearly always too optimistic anyway). To manage scope creep, begin with a clear statement of the project’s business objectives, strategic vision, scope, limitations, and success criteria. Evaluate all proposed new features or requirements changes against this reference. Requirements will change and grow. The project manager should build contingency buffers into schedules so the first new requirement that comes along doesn’t derail the schedule (Wiegers 2007). Agile projects take the approach of adjusting the scope for a certain iteration to fit into a defined budget and duration for the iteration. As new requirements come along, they are placed into the backlog of pending work and allocated to future iterations based on priority. Change might be critical to success, but change always has a price.
Двусмысленные требования Ambiguous requirements
Один из симптомов двусмысленности заключается в том, что пользователь может интерпретировать одно и то же положение по-разному. (Lawrence, 1996). Другой симптом состоит в том, что у нескольких читателей требования возникает разное понимание, что оно означает. One symptom of ambiguity in requirements is that a reader can interpret a requirement statement in several ways (Lawrence 1996). Another sign is that multiple readers of a requirement arrive at different understandings of what it means.
Двусмысленность ведет и к формированию различных ожиданий у заинтересованных лиц. Впоследствии некоторые из них удивляются результату. Разработчики же впустую тратят время, занимаясь не теми задачами. А тестировщики готовятся к проверке не тех особенностей поведения системы. Ambiguity leads to different expectations on the part of various stakeholders. Some of them are then surprised at whatever is delivered. Ambiguous requirements cause wasted time when developers implement a solution for the wrong problem. Testers who expect the product to behave differently from what the developers built waste time resolving the differences.
Один из способов избавиться от двусмысленности — пригласить различных представителей пользователей для официальной экспертизы требований. (Wiegers, 2002). Неформальная дружественная оценка, в которой участники просто самостоятельно читают требования, часто не обнаруживает двусмысленности. Если они интерпретируют требования различными способами, но это имеет смысл для каждого из них, то неясность не проявится. Совместное выявление и проверка требований стимулирует обсуждение и уточнение требований в группе в рамках совещания. Другой способ обнаружить двусмысленность — написать вариант тестирования для требования и построить прототип. One way to ferret out ambiguity is to have people who represent different perspectives inspect the requirements (Wiegers 2002). Informal peer reviews in which reviewers simply read the requirements on their own often don’t reveal ambiguities. If different reviewers interpret a requirement in different ways but it makes sense to each of them, they won’t find the ambiguity. Collaborative elicitation and validation encourages stakeholders to discuss and clarify requirements as a group in a workshop setting. Writing tests against the requirements and building prototypes are other ways to discover ambiguities.
Требования-«бантики» Gold plating
Под «бантиками» (gold plating) понимают отсутствующие в спецификации требований функции, добавленные разработчиками, потому что им кажется, что это понравится пользователям. Если избыточные возможности оказываются ненужными для клиентов, получается, что время, отведенное на реализацию, тратится впустую. Прежде чем просто вставлять новые функции, разработчики и бизнес-аналитики должны представить свои творческие идеи на суд заказчиков. Задача команды — четко соблюдать требования спецификации, а не действовать за спиной клиентов, без их одобрения. Gold plating takes place when a developer adds functionality that wasn’t in the requirements specification (or was deemed out of scope) but which the developer believes “the users are just going to love.” If users don’t care about this functionality, the time spent implementing it is wasted. Rather than simply inserting new features, developers and BAs should present stakeholders with creative ideas for their consideration. Developers should strive for leanness and simplicity, not going beyond what stakeholders request without their approval.
Пользователи иногда требуют функции или элементы интерфейса, которые выглядят красиво, но не представляют особой ценности для продукта. Все, что вы захотите добавить, стоит времени и денег, поэтому постарайтесь максимизировать пользу от будущего продукта. Чтобы снизить количество «бантиков», отслеживайте каждый элемент функциональности до его источника, чтобы четко понимать, почему именно он включен в продукт. Убедитесь, что все специфицируемое и разрабатываемое находится в рамках проекта. Customers sometimes request certain features or elaborate user interfaces that look attractive but add little value to the product. Everything you build costs time and money, so you need to maximize the delivered value. To reduce the threat of gold plating, trace each bit of functionality back to its origin and its business justification so everyone knows why it’s included. Make sure that what you are specifying and developing lies within the project’s scope.
Пропущенные классы пользователей Overlooked stakeholders
Большинство продуктов предназначены для нескольких групп пользователей, которые могут применять различные наборы функций с разной частотой и иметь самый разный опыт работы с ПО. Если вы не определили важные классы пользователей для вашего продукта заранее, некоторые потребности клиентов не будут учтены. После идентификации всех классов удостоверьтесь, что голос каждого услышан. Помимо очевидных пользователей не забудьте о сотрудниках поддержки, у которых есть собственные требования, функциональные и нефункциональные. У сотрудников, которые конвертируют данные из унаследованных систем, есть требования по переходу, которые не влияют на конечный продукт, но определенно влияют на успех решения. Могут быть заинтересованные лица, которые даже не знают о существовании проекта, например государственные учреждения, определяющие стандарты, которые могут влиять на вашу систему, и вы должны знать о таких заинтересованных лицах и их влиянии на проект. Most products have several groups of users who might use different subsets of features, have different frequencies of use, or have varying levels of experience. If you don’t identify the important user classes for your product early on, some user needs won’t be met. After identifying all user classes, make sure that each has a voice, as discussed in Chapter 6, “Finding the voice of the user.” Besides obvious users, think about maintenance and field support staff who have their own requirements, both functional and nonfunctional. People who have to convert data from a legacy system will have transition requirements that don’t affect the ultimate product software but that certainly influence solution success. You might have stakeholders who don’t even know the project exists, such as government agencies that mandate standards that affect your system, yet you need to know about them and their influence on the project.

Выгоды от высококачественного процесса разработки требований

Выгоды от высококачественного процесса разработки требований Benefits from a high-quality requirements process
Многие люди ошибочно считают, что время, которое тратится на обсуждение требований, просто отсрочивает выпуск продукта. Они предполагают, что работа с требованиями не повышает рентабельность проекта. На самом деле, затраты на получение хороших требований практически всегда возвращаются с излишком. Some people mistakenly believe that time spent discussing requirements simply delays delivery by the same duration. This assumes that there’s no return on investment from requirements activities. In actuality, investing in good requirements will virtually always return more than it costs.
В удачных процессах создания требований к совместной партнерской работе над проектом привлекаются множество заинтересованных лиц, причем на протяжении всего проекта. Сбор требований позволяет команде разработчиков лучше понять пользователей или реалии рынка, что критически важно для любого проекта. Делая упор на задачи пользователей, а не на внешне привлекательные функции, команда избежит необходимости переписывать код, который даже не понадобится. Вовлечение клиентов в процесс снижает вероятность появления ложных ожиданий, возникающих из-за различия того, в чем пользователи нуждаются, и того, что разработчики выпускают. Рано или поздно вы начнете получать отзывы заказчиков. Причем намного дешевле добиться взаимопонимания до начала разработки продукта, чем после финальной поставки. Sound requirements processes emphasize a collaborative approach to product development that involves stakeholders in a partnership throughout the project. Eliciting requirements lets the development team better understand its user community or market, a critical success factor. Emphasizing user tasks instead of superficially attractive features helps the team avoid writing code that no one will ever execute. Customer involvement reduces the expectation gap between what the customer really needs and what the developer delivers. You’re going to get the customer input eventually; it’s far cheaper to reach this understanding before you build the product than after delivery.
Ясное разделение требований на те, что относятся к ПО, оборудованию или подсистемам, взаимодействующим с людьми, позволяет применять системный подход к разработке продукта. Эффективные процессы управления изменениями минимизируют неблагоприятные последствия от изменения требований. Недвусмысленно составленные документы облегчают тестирование продукта. В совокупности все это повышает шансы создать высококачественный продукт, который удовлетворит всех пользователей. Explicitly allocating system requirements to various software, hardware, and human subsystems emphasizes a systems approach to product engineering. An effective change control process will minimize the adverse impact of requirements changes. Documented and clear requirements greatly facilitate system testing. All of these increase your chances of delivering high-quality products that satisfy all stakeholders.
Никто не станет обещать конкретный возврат инвестиций в процесс улучшения требований. Вы можете мысленно проанализировать, как более качественные требования могут помочь вашим командам (Wiegers, 2006). Стоимость более качественных требований складывается из стоимости разработки новых процедур и шаблонов документов, тренинга команды и покупки инструментов. Наибольшая инвестиция — это время, которое ваша команда тратит на сбор, документирование, просмотр и управление требованиями. Возможные выгоды таковы: No one can promise a specific return on investment from using sound requirements practices. You can go through an analytical thought process to imagine how better requirements could help your teams, though (Wiegers 2006). The cost of better requirements includes developing new procedures and document templates, training the team, and buying tools. Your greatest investment is the time your project teams actually spend on requirements engineering tasks. The potential payoff includes:
• меньше дефектов в требованиях и в готовом продукте; • Fewer defects in requirements and in the delivered product.
• меньше переделок; • Reduced development rework.
• быстрее разработка и поставка готового продукта; • Faster development and delivery.
• меньше ненужных и неиспользуемых функций; • Fewer unnecessary and unused features.
• ниже стоимость модификации; • Lower enhancement costs.
• меньше недопонимания; • Fewer miscommunications.
• меньше расползание границ проекта; • Reduced scope creep.
• меньше беспорядок в проекте; • Reduced project chaos.
• выше удовлетворение заказчиков и членов команды; • Higher customer and team member satisfaction.
• продукты, которые делают то, что от них ожидается. • Products that do what they’re supposed to do.
Даже если вы не можете количественно оценить все преимущества, они все равно реальны. Even if you can’t quantify all of these benefits, they are real.

2. Требования с точки зрения клиента

2. Требования с точки зрения клиента Requirements from the customer’s perspective
Герхард, старший менеджер компании Contoso Pharmaceuticals, встретился с Синтией, начальником ИТ-отдела. Gerhard, a senior manager at Contoso Pharmaceuticals, was meeting with Cynthia, the manager of Contoso’s IT department.
«Нам нужно создать новую систему учета химических препаратов Chemical Tracking System, — начал Герхард. — Она должна обеспечить учет всех химических контейнеров на складе и в лабораториях. Если химикам понадобится новый реактив, который уже есть в компании, они смогут взять его в соответствующем отделе, не тратя деньги на заказ нового контейнера. Система сэкономит компании уйму денег. Кроме того, она позволит отделу охраны труда и техники безопасности тратить меньше сил на создание предоставляемых в контролирующие органы отчетов об использовании и утилизации химикатов. Ты сможешь создать систему к началу аудита, который у нас будет через пять месяцев?» “We need to build a chemical tracking information system,” Gerhard began. “The system should keep track of all the chemical containers we already have in the stockroom and in laboratories. That way, the chemists can get some chemicals from someone down the hall instead of always buying a new container. This should save us a lot of money. Also, the Health and Safety Department needs to generate government reports on chemical usage and disposal with a lot less work than it takes them today. Can you build this system in time for the compliance audit in five months?”
«Понимаю, почему этот проект важен, Герхард,— сказала Синтия. — Но прежде чем я набросаю график разработки проекта, нам потребуется собрать требования к системе». “I see why this project is important, Gerhard,” said Cynthia. “But before I can commit to a schedule, we’ll need to understand the requirements for the chemical tracking system.”
Герхард удивился: «Что вы имеете в виду? Я только что перечислил вам требования». Gerhard was confused. “What do you mean? I just told you my requirements.”
«На самом деле вы описали общие бизнес-цели проекта, — объяснила Синтия. — Бизнес-требования такого высокого уровня не дают достаточно информации, чтобы точно определить, какую систему создавать и сколько времени на это может потребоваться. Я хочу, чтобы мой аналитик поработал с несколькими пользователями и понял, что они ожидают от системы». “Actually, you described some general business objectives for the project,” Cynthia explained. “That doesn’t give me enough information to know what software to build or how long it might take. I’d like to have one of our business analysts work with some users to understand their needs for the system.”
«Химики — занятые люди, — запротестовал он. — Вряд ли у них найдется время объяснять все подробности до того, как вы начнете писать программу. Не могут ли ваши люди сами определить, что создавать?» “The chemists are busy people,” Gerhard protested. “They don’t have time to nail down every detail before you can start programming. Can’t your people figure out what to build?”
Синтия попыталась объяснить: «Если мы сами будем пытаться угадать ожидания пользователей, ничего хорошего не выйдет. Мы — разработчики ПО, а не химики. Я по собственному опыту знаю, что, если не потратить время на изучение проблемы до начала программирования, результат не понравится никому». Cynthia replied, “If we just make our best guess at what the users need to do with the system, we can’t do a good job. We’re software developers, not chemists. I’ve learned that if we don’t take the time to understand the problem, nobody is happy with the results.”
«У нас нет времени на это, — настаивал Герхард. — Я описал вам мои требования. Теперь, пожалуйста, просто создайте систему. Сообщайте мне о ходе работы». “We don’t have time for all that,” Gerhard insisted. “I gave you my requirements. Now just build the system, please. Keep me posted on your progress.”
Такие диалоги регулярно возникают при разработке ПО. Клиенты, которым требуется новая информационная система, зачастую не понимают, насколько важно непосредственно опросить будущих пользователей и других заинтересованных лиц. Специалисты по маркетингу, разработавшие концепцию нового замечательного продукта, считают, что могут адекватно представлять интересы предполагаемых покупателей. Тем не менее, мнение непосредственных покупателей ПО неоценимо, и заменить его чем-либо иным нельзя. Conversations like this take place regularly in the software world. Customers who request a new system often don’t understand the importance of obtaining input from actual users of the proposed system as well as other stakeholders. Marketers with a great product concept believe that they can adequately represent the interests of prospective buyers. However, there’s no substitute for eliciting requirements directly from people who will actually use the product.
Согласно некоторым современным методикам разработки ПО, например методики гибкого программирования (agile programming), представитель заказчика должен тесно взаимодействовать с командой разработчиков. Как говорится в одной книге по гибкой разработке, «успех проекта зависит от согласованных действий клиента и программистов» (Jeffries, Anderson и Hendrickson, 2001). Some agile development methods recommend that an on-site customer representative, sometimes called a product owner, work closely with the development team. As one book about agile development said, “The project is steered to success by the customer and programmers working in concert” (Jeffries, Anderson, and Hendrickson 2001).
Одна из проблем при формировании требований в том, что люди путают разные уровни требований, описанные в предыдущей главе:
• бизнес-уровень,
• уровень пользователя и
• функциональный.
 Part of the requirements problem results from confusion over the different levels of requirements described before:
• business,
• user, and
• functional.
Герхард перечислил несколько преимуществ, которые, по его мнению, получит компания Contoso, внедрив новую систему контроля химикатов под названием Chemical Tracking System. Однако он не знает требований пользователей, поскольку сам не работает с этой системой. С другой стороны, пользователи могут описать необходимые им возможности системы, но не способны грамотно перечислить функциональные требования, которые должны реализовать разработчики для предоставления им таких возможностей. Бизнес-аналитики должны поработать с пользователями, чтобы лучше понять будущую систему. Gerhard stated some business objectives, benefits that he expects Contoso to enjoy with the help of the new chemical tracking system. Business objectives are a core element of the business requirements. However, Gerhard can’t entirely describe the user requirements because he’s not an intended user of the system. Users, in turn, can describe tasks they must be able to perform with the system, but they can’t state all the functional requirements that developers must implement to let them accomplish those tasks. Business analysts need to collaborate with users to reach that deeper understanding.
В этой главе речь пойдет о взаимосвязи клиента и разработчика, жизненно важной для успеха проекта по разработке ПО. Я предлагаю вашему вниманию «Билль о правах клиента ПО» и соответствующий «Билль об обязанностях клиента ПО» при формировании требований. Таким образом, я надеюсь прояснить роль клиента, а конкретнее, пользователя, в процессе создания требований. В этой главе также обсуждается критичность достижения соглашения о наборе требований, планируемых на определенный выпуск или итерацию разработки. This chapter addresses the customer-development relationship that is so critical to software project success. We propose a Requirements Bill of Rights for Software Customers and a corresponding Requirements Bill of Responsibilities for Software Customers. These lists underscore the importance of customer—and specifically end user—involvement in requirements development. This chapter also discusses the critical issue of reaching agreement on a set of requirements planned for a specific release or development iteration.
Страх отказа Deliverable: Rejected
Недавно я побывал в отделе информационных систем одной фирмы и услышал печальную историю. Разработчики только что создали новую внутрикорпоративную систему. Пользователи с самого начала не хотели общаться с разработчиками, и когда те с гордостью представили новую систему, пользователи отвергли ее как совершенно неприемлемую. Разработчики, приложившие немало усилий, чтобы удовлетворить потребности пользователей, как они их понимали, испытали настоящий шок. И что же они предприняли? Да просто все исправили. При несоответствии требований систему всегда можно подправить, однако это значительно дороже, чем если бы пользователи оговорили свои потребности с самого начала. I heard a sad story when I visited a corporate IT department once. The developers had recently built a new information system for use within the company. They had obtained negligible user input from the beginning. The day the developers proudly unveiled their new system, the users rejected it as completely unacceptable. This came as a shock because the developers had worked hard to satisfy what they perceived to be the users’ needs. So what did they do then? They fixed it. Companies always fix the system when they get the requirements wrong, yet it always costs much more than if they had engaged user representatives from the outset.
Безусловно, разработчикам пришлось потратить на доводку проекта больше время и, значит, отложить следующий проект. Это абсолютно проигрышная ситуация. Разработчики растеряны и расстроены, клиенты разочарованы, так как система не оправдала их ожиданий, а компания потеряла кучу денег и возможностей, которые предоставили бы другие проекты, которые пришлось отложить. Когда клиенты с самого начала плотно и постоянно вовлечены в разработку системы, такого неудачного, но, к сожалению, нередкого итога удалось бы избежать. The developers hadn’t planned to spend time fixing the flawed information system, of course, so the next project in the team’s queue had to wait. This is a lose-lose-lose situation. The developers were chagrined, the users were unhappy because their new system wasn’t available when they expected it, and the executives were upset over a lot of wasted money and the opportunity costs of delaying other projects. Extensive and ongoing customer engagement from the start could have prevented this unfortunate—but not uncommon—project outcome.

Разрыв ожиданий

Разрыв ожиданий The expectation gap
Без адекватного участия клиента в конце проекта неизбежно возникает разрыв ожиданий (expectation gap) — пробел между тем, что клиенту реально нужно, и тем, что предоставили разработчики, основываясь на том, что они знали в начале проекта (Wiegers, 1996). Это показано пунктирными линиями на рис. 2-1. Разрыв ожиданий становится неприятной неожиданностью для всех заинтересованных лиц. По собственному опыту могу сказать, что сюрпризы в ПО никогда не бывают хорошими. Требования устаревают по мере изменения в бизнесе, поэтому взаимодействие с клиентами жизненно важно. Without adequate customer involvement, the inescapable outcome at the end of the project is an expectation gap, a gulf between what customers really need and what developers deliver based on what they heard at the beginning of the project (Wiegers 1996). This is shown as the dashed lines in Figure 2-1. As with the previous story, the expectation gap comes as a rude surprise to all stakeholders. In our experience, software surprises are never good news. Requirements also get out of date because of changes that occur in the business, so ongoing interactions with customers are vital.
Рис. 2-1. Частое взаимодействие с клиентом сокращает разрыв ожиданий FIGURE 2-1 Frequent customer engagement reduces the expectation gap.
Наилучший способ минимизации разрыва ожиданий — организация частых точек контакта с представителями клиента. Эти точки могут принимать форму интервью, собеседований, просмотра требований, просмотра дизайна пользовательского интерфейса, оценки прототипа, а в случае гибкой (agile) разработки — откликов клиентов на небольшие расширения функциональности исполняемого ПО. Каждая точка контакта предоставляет возможность закрыть разрыв ожиданий: создаваемое разработчиком ближе к тому, что требуется клиенту. The best way to minimize the expectation gap is to arrange frequent contact points with suitable customer representatives. These contact points can take the form of interviews, conversations, requirements reviews, user interface design walkthroughs, prototype evaluations, and—with agile development—user feedback on small increments of executable software. Each contact point affords an opportunity to close the expectation gap: what the developer builds is more closely aligned with what the customer needs.
Естественно, что разрыв начинает снова увеличиваться сразу же после каждой точки контакта. Чем чаще такие точки, тем проще двигаться в правильном направлении. Как иллюстрируют маленькие серые треугольники на рис. 2-1, набор таких точек контакта позволяют в конце проекта получить намного меньший разрыв ожиданий и решение, которое намного лучше соответствует реальным потребностям клиента. Вот почему основным принципом гибкой разработки является постоянный диалог между разработчиками и клиентами. Этот принцип отлично подходит для любого проекта. Of course, the gap will begin to grow again immediately as development proceeds after each contact. The more frequent the contact points are, the easier it is to stay on track. As the progressively shrinking small gray triangles in Figure 2-1 illustrate, a series of such contact points will lead to a far smaller expectation gap at the end of the project and a solution that is much closer to the actual customer needs. This is why one of the guiding principles of agile development is to have ongoing conversations between developers and customers. That’s an excellent principle for any project.

Кто же клиент?

Кто же клиент?
Прежде чем говорить о клиентах, нужно обсудить заинтересованных лиц. Заинтересованное лицо (stakeholder) — это человек, группа или организация, которая активно задействована в проекте, подвержена влиянию процесса или результата или может влиять на процесс или результат. Заинтересованные лица могут быть внутренними или внешними по отношению к команде проекта или разрабатывающей организации. На рис. 2-2 показаны возможные заинтересованные лица в этих категориях. Естественно, что не в каждом проекте присутствуют все эти лица. Before we can talk about customers, we need to discuss stakeholders. A stakeholder is a person, group, or organization that is actively involved in a project, is affected by its process or outcome, or can influence its process or outcome. Stakeholders can be internal or external to the project team and to the developing organization. Figure 2-2 identifies many of the potential stakeholders in these categories. Not all of these will apply to every project or situation, of course.
Рис. 2-2. Возможные заинтересованные лица в команде проекта, в разрабатывающей организации и за пределами организации FIGURE 2-2 Potential stakeholders within the project team, within the developing organization, and outside the organization.
Анализ заинтересованных лиц — важная часть разработки требований (Smith, 2000; Wiegers, 2007; IIBA, 2009). При определении возможных заинтересованных лиц конкретного проекта, надо смотреть максимально широко, чтобы не пропустить важных участников. После этого можно основательно проанализировать список возможных заинтересованных лиц, чтобы определить чье участие вам действительно нужно для понимания всех требований и ограничений проекта, которые позволят команде предоставить правильное решение. Stakeholder analysis is an important part of requirements development (Smith 2000; Wiegers 2007; IIBA 2009). When searching for potential stakeholders for a particular project, cast a wide net to avoid overlooking some important community. Then you can focus this candidate stakeholder list down to the core set whose input you really need, to make sure you understand all of the project’s requirements and constraints so your team can deliver the right solution.
Клиенты являются подмножеством заинтересованных лиц. Клиент (customer) — человек или организация, получающая от продукта прямую или косвенную выгоду. Клиенты это заинтересованные в проекте лица, запрашивающие, оплачивающие, выбирающие, определяющие, использующие и получающие результаты работы программного продукта. Показанные на рис. 2-2 клиенты включают непосредственного пользователя, непрямого пользователя, куратора, специалистов по закупкам и покупателя. Customers are a subset of stakeholders. A customer is an individual or organization that derives either direct or indirect benefit from a product. Software customers could request, pay for, select, specify, use, or receive the output generated by a software product. The customers shown in Figure 2-2 include the direct user, indirect user, executive sponsor, procurement staff, and acquirer.
Некоторые заинтересованные лица не являются клиентами, такие как юристы, аудиторы, поставщики, подрядчики и венчурные инвесторы. Менеджер Герхард — это клиент, оплачивающий или курирующий проект по разработке ПО. Клиенты уровня Герхарда определяют бизнес-требования к системе. Они формулируют высокоуровневую концепцию продукта и бизнес-обоснование для его развертывания. Бизнес-требования описывают бизнес-цели, которых хочет достичь клиент, компания или другие заинтересованные лица. Любые другие функции и требования к продукту должны удовлетворять бизнес-требованиям. Some stakeholders are not customers, such as legal staff, compliance auditors, suppliers, contractors, and venture capitalists. Gerhard, the manager we met earlier, represents an executive sponsor who is paying for the project. Customers like Gerhard provide the business requirements, which establish the guiding framework for the project and the business rationale for launching it. Business requirements describe the business objectives that the customer, company, or other stakeholders want to achieve. All other product requirements need to align with achieving those desired business outcomes.
Требования пользователей определяют те, кто прямо или косвенно взаимодействуют с продуктом. Эти пользователи (часто их называют конечными пользователями) являются подмножеством клиентов. Прямые пользователи непосредственно работают с продуктом. Непрямые пользователи могут получать результаты работы системы, не входя в непосредственный контакт с ней, например менеджер хранилища данных, получающий по почте ежедневный отчет о деятельности хранилища данных. Пользователи способны описать, какие задачи им нужно выполнять, какие результаты они ожидают и какие ожидаются качественные характеристики продукта. User requirements should come from people who will actually use the product, either directly or indirectly. These users (often called end users) are a subset of customers. Direct users will operate the product hands-on. Indirect users might receive outputs from the system without touching it themselves, such as a warehouse manager who receives an automatic report of daily warehouse activities by email. Users can describe the tasks they need to perform with the product, the outputs they need, and the quality characteristics they expect the product to exhibit.
Случай с отсутствующим заинтересованным лицом The case of the missing stakeholder
Я знаю проект, в котором на финальном этапе выявления требований при проверке правильности потока процессов аналитик поинтересовался у заинтересованного лица: «Вы уверены в правильности шагов вычисления налога в этом потоке?» На что получил такой ответ: «Ну, я не знаю. Я не занимаюсь налогами — для этого есть отдел по налогам». На протяжении многих месяцев работы над проектом никто из команды не разговаривал ни с одним сотрудником отдела по налогам. В команде даже не догадывались, что такой отдел вообще существует. При встрече с сотрудниками отдела по налогам аналитик обнаружил длинный список пропущенных требований, связанных с несоответствием реализации налоговой функциональности и требований регулирующих органов. В результате проект был задержан на несколько месяцев. Подобных неприятностей можно избежать, если заранее ознакомиться со структурной схемой организации и выявить всех заинтересованных лиц, на работу которых может повлиять новая система. I know of a project that was almost finished with requirements elicitation when, while reviewing a process flow, the business analyst (BA) asked the stakeholder, “Are you sure we have the tax calculation steps correct in this flow?” The stakeholder replied, “Oh, I don’t know. I don’t own tax. That’s the tax department.” The team hadn’t talked to anyone in the tax department over the course of working on the project for months. They had no idea that there even was a tax department. As soon as the BAs did meet with the tax department, they found a long list of missed requirements around the legal implications of how tax-related functions were implemented. The project was delayed several months as a result. Using an organization chart to search for all stakeholders who will be affected by a new system can avoid such unpleasantness.
Клиенты, предоставляющие бизнес-требования, иногда пытаются говорить от имени реальных пользователей, но обычно они слишком далеки от реальной работы, чтобы описать их точные требования. В случае с информационными системами или разработкой нестандартного приложения бизнес- требования должен определять тот, кто в конечном итоге отвечает за пользу для бизнеса, ожидаемую от продукта. Пользовательские требования должны определять те, кто будет стучать по клавишам, касаться экрана и получать результаты работы продукта. В случае серьезного рассогласования между заказчиками, оплачивающими проект, и конечными пользователями крупных проблем не избежать. Customers who provide the business requirements sometimes purport to speak for the actual users. They are often too far removed from the work to provide accurate user requirements, though. For corporate information systems, contract development, or custom application development, business requirements should come from the person who is ultimately accountable for the business value expected from the product. User requirements should come from people who will press the keys, touch the screen, or receive the outputs. If there is a serious disconnect between the acquiring customers who are paying for the project and the end users, major problems are guaranteed.
В области разработки коммерческого ПО, где клиент и пользователь зачастую представлены одним лицом, ситуация несколько иная. Представители клиента, например маркетологи или менеджеры по продукту, обычно пытаются на свой вкус определить, что клиент счел бы привлекательным. Тем не менее, без конечных пользователей сформулировать требования пользователей не удастся. В противном случае будьте готовы читать обзоры в журналах, описывающие недостатки вашего продукта, которых удалось бы избежать при активном участии пользователей. The situation is different for commercial software development, where the customer and the user often are the same person. Customer surrogates, such as marketing personnel or a product manager, typically attempt to determine what customers would find appealing. Even for commercial software, though, you should strive to engage end users in the process of developing user requirements. If you don’t, be prepared to read reviews pointing out product shortcomings that adequate user input could have avoided.
Возможны конфликты между заинтересованными лицами проекта. Бизнес-требования иногда отражают организационную стратегию или бюджетные ограничения, которые не всегда понятны пользователям. И те, раздраженные тем, что менеджмент насильно внедряет новую информационную систему, не всегда хотят общаться с разработчиками ПО, считая последних предвестниками неблагоприятного будущего. Таких пользователей иногда называют «группами неудачников» (Gause и Weinberg, 1989). Избежать таких трений помогает ясное и полное обсуждение целей и ограничений проекта, которое может убедить пользователей и избежать споров и обид. Conflicts can arise among project stakeholders. Business requirements sometimes reflect organizational strategies or budgetary constraints that aren’t apparent to users. Users who are upset about having a new information system forced on them by management might not want to work with the software developers, viewing them as the harbingers of an undesired future. Such folks are sometimes called “loser groups” (Gause and Weinberg 1989). To manage such potential conflicts, try communication strategies about project objectives and constraints that can build buy-in and avoid debates and hard feelings.

Сотрудничество клиентов и разработчиков

Сотрудничество клиентов и разработчиков The customer-development partnership
Отличные программные продукты — результат правильно выполненного проектирования, основанного на требованиях, полученных в результате эффективного, то есть тесного взаимодействия разработчиков и клиентов (и особенно, фактических пользователей). Совместная работа возможна только тогда, когда все участники процесса разработки знают, что именно необходимо им для успеха, и когда они понимают и уважают стремление их соратников к успеху. Когда при работе над проектом нагнетается напряжение, очень легко забыть, что у всех участников единая цель — создать программный продукт, ценный для бизнеса и отвечающий чаяниям всех участников проекта. Аналитик обычно оказывается ключевым человеком, на плечи которого ложится налаживание этого сотрудничества. An excellent software product results from a well-executed design based on excellent requirements. Excellent requirements result from effective collaboration between developers and customers (in particular, actual users)—a partnership. A collaborative effort can work only when all parties involved know what they need to be successful and when they understand and respect what their collaborators need to be successful. As project pressures rise, it’s easy to forget that all stakeholders share a common objective: to build a product that provides adequate business value and rewards to all stakeholders. The business analyst typically is the point person who has to forge this collaborative partnership.
«Билль о правах клиента ПО» (табл. 2-1) содержит 10 положений, на выполнении которых клиенты могут на вполне законных основаниях настаивать при общении с аналитиками и разработчиками на этапе формулирования требований к проекту. Каждый пункт этого права описывает соответствующую ответственность аналитиков и разработчиков ПО. Слово «вы» в правах и обязанностях указывает на клиента в проекте разработки ПО. The Requirements Bill of Rights for Software Customers in Table 2-1 lists 10 expectations that customers can legitimately hold regarding their interactions with BAs and developers during the project’s requirements engineering activities. Each of these rights implies a corresponding responsibility on the part of the BAs or software developers. The word “you” in the rights and responsibilities refers to a customer for a software development project.
Табл. 2-1. Билль о правах клиента ПО при формировании требований TABLE 2-1 Requirements Bill of Rights for Software Customers
У вас есть право You have the right to
1. Иметь дело с аналитиком, который разговаривает на вашем языке 1. Expect BAs to speak your language.
2. Иметь дело с аналитиком, хорошо изучившим ваш бизнес и цели, для которых создается система 2. Expect BAs to learn about your business and your objectives.
3. Потребовать, чтобы аналитик зафиксировал требования в надлежащей форме 3. Expect BAs to record requirements in an appropriate form.
4. Получить подробный отчет о будущих процедурах и результатах процесса формулирования требований 4. Receive explanations of requirements practices and deliverables.
5. На изменение ваших требований 5. Change your requirements.
6. На взаимное уважение 6. Expect an environment of mutual respect.
7. Знать о вариантах и альтернативах требований и их реализации 7. Hear ideas and alternatives for your requirements and for their solution.
8. Описать характеристики, упрощающие работу с продуктом 8. Describe characteristics that will make the product easy to use.
9. Узнать о способах корректировки требований для ускорения разработки за счет повторного использования 9. Hear about ways to adjust requirements to accelerate development through reuse.
10. Получить систему, функциональность и качество которой соответствует вашим ожиданиям 10. Receive a system that meets your functional needs and quality expectations.
Так как обратной стороной прав являются обязанности, «Билль об обязанностях клиента ПО» (табл. 2-2), напротив, содержит 10 положений, определяющих ответственность клиента перед аналитиком и разработчиком на этапе формулирования требований. Возможно, его стоит назвать «Билль о правах разработчика». Если эти документы не совсем точно подходят для вашей организации, измените их в соответствии с реалиями местной специфики. Because the flip side of a right is a responsibility, Table 2-2 lists 10 responsibilities that the customer has to BAs and developers during the requirements process. You might prefer to view these as a developer’s bill of rights. If these lists aren’t exactly right for your organization, modify them to suit the local culture.
Перечисленные права и обязанности распространяются непосредственно на клиентов в случае, когда программный продукт разрабатывается для внутрикорпоративного использования, на заказ или для определенной группы крупных клиентов. При разработке продуктов для массового рынка интересы клиентов представляют сотрудники, например отдел маркетинга. These rights and responsibilities apply to actual customers when the software is being developed for internal corporate use, under contract, or for a known set of major customers. For mass-market product development, the rights and responsibilities are more applicable to customer surrogates such as the product manager.
Табл. 2-2. Билль об обязанностях клиента ПО при формировании требований TABLE 2-2 Requirements Bill of Responsibilities for Software Customers
Клиент обязан You have the responsibility to
1. Ознакомить аналитиков и разработчиков с особенностями вашего бизнеса 1. Educate BAs and developers about your business.
2. Потратить столько времени, сколько необходимо на уточнение требований 2. Dedicate the time that it takes to provide and clarify requirements.
3. Точно и конкретно описать требования к системе 3. Be specific and precise when providing input about requirements.
4. Принимать своевременные решения относительно требований 4. Make timely decisions about requirements when asked.
5. Уважать определенную разработчиком оценку стоимости и возможности реализации ваших требований 5. Respect a developer’s assessment of the cost and feasibility of requirements.
6. Определять реалистичные приоритеты требований совместно с разработчиками 6. Set realistic requirement priorities in collaboration with developers.
7. Проверять требования и оценивать прототипы 7. Review requirements and evaluate prototypes.
8. Определить критерии приемки 8. Establish acceptance criteria.
9. Своевременно сообщать об изменениях требований 9. Promptly communicate changes to the requirements.
10. Уважительно относиться к процессам создания требований 10. Respect the requirements development process.
В процессе планирования проекта клиенту и разработчикам следует изучить оба этих списка и постараться достигнуть взаимопонимания. Убедитесь, что основные участники процесса формулирования требований понимают и принимают свои обязанности. Это позволит избежать трений позже, когда одна сторона будет ожидать чего-то, что другая не может или не желает предоставить. As part of project planning, the key customer and development stakeholders should review these two lists and negotiate to reach a meeting of the minds. Make sure the participants in requirements development understand and accept their responsibilities. This understanding can reduce friction later, when one party expects something that the other is not willing or able to provide.
Внимание! Не предполагайте, что участники проекта интуитивно знают, как сотрудничать при формулировании требований. Потратьте время и обсудите, каким образом организовать взаимодействие наиболее эффективно. Хорошо записать, как вы хотите решать и управлять вопросами требований в проекте. Это послужит ценным средством коммуникации в проекте. Trap. Don’t assume that the project participants instinctively know how to collaborate on requirements development. Take the time to discuss how those involved can work together most effectively. It’s a good idea to write down how you decide to approach and manage requirements issues on the project. This will serve as a valuable communication tool throughout the project.
Билль о правах клиента ПО Requirements Bill of Rights for Software Customers
Далее перечислены десять прав, наличие которых предполагают клиенты, когда речь идет о вопросах требований. Following are 10 rights that customers can expect when it comes to requirements issues.
Право № 1. Иметь дело с аналитиком, который разговаривает на вашем языке Right #1: To expect BAs to speak your language
При обсуждении требований следует выяснить потребности и задачи вашего бизнеса, используя при этом принятую в вашем бизнесе терминологию. Заставьте аналитиков говорить с вами на вашем языке (возможно, для этого им следует предоставить небольшой словарь). При разговоре с аналитиками не надо переходить на технический жаргон. Requirements discussions should center on your business needs and tasks, using business vocabulary. Consider conveying business terminology to the BAs with a glossary of terms. You shouldn’t have to wade through technical jargon when talking with BAs.
Право № 2. Иметь дело с аналитиком, хорошо изучившим ваш бизнес и цели, для которых создается система Right #2: To expect BAs to learn about your business and your objectives
Выявляя требования, аналитики смогут лучше понять задачи вашего бизнеса и осознать, какое место уготовано создаваемому ПО в вашем бизнесе. Это поможет им удовлетворить ваши ожидания. Пригласите разработчиков и аналитиков посмотреть на вашу работу. Если заказанная система заменит существующее приложение, предложите аналитикам поработать с ним. Таким образом, им будет легче понять его сильные и слабые стороны и то, как его можно усовершенствовать. Не надо предполагать, что аналитик уже знает все ваши бизнес-операции и терминологию (см. Обязанность №1). By interacting with you to elicit requirements, the BAs can better understand your business tasks and how the system fits into your world. This will help developers create a solution that meets your needs. Invite BAs and developers to observe what you and your colleagues do on the job. If the new system is replacing an existing one, the BAs should use the current system as you use it. This will show them how it fits into your workflow and where it can be improved. Don’t just assume that the BA will already know all about your business operations and terminology (see Responsibility #1).
Право № 3. Потребовать, чтобы аналитик зафиксировал требования в надлежащей форме Right #3: To expect BAs to record requirements in an appropriate form
Аналитик разберется со всей информацией, предоставленной заинтересованными лицами, и задаст дополнительные вопросы, чтобы пользовательские требования на основе бизнес-требований, бизнес-правил, функциональных требований, целей качества и прочих элементов. Конечный итог этого анализа — выверенный набор требований, хранящийся в одной из надлежащих форм, например спецификация требований к программному обеспечению (SRS) или средство управления требованиями. Этот набор требований является соглашением заинтересованных лиц относительно функций, качеств и ограничений продукта, который планируется построить. Требования должны быть написаны и организованы так, чтобы их было легко понимать. Ваша проверка этих спецификаций и других представлений требований, например моделей визуального анализа, помогает обеспечить точное представление ваших потребностей. The BA will sort through all the information that stakeholders provide and ask follow-up questions to distinguish user requirements from business rules, functional requirements, quality goals, and other items. The ultimate deliverable from this analysis is a refined set of requirements stored in some appropriate form, such as a software requirements specification document or a requirements management tool. This set of requirements constitutes the agreement among the stakeholders about the functions, qualities, and constraints of the product to be built. Requirements should be written and organized in a way that you find easy to understand. Your review of these specifications and other requirements representations, such as visual analysis models, helps to ensure that they accurately represent your needs.
Право № 4. Получить подробный отчет о будущих процедурах и результатах процесса формулирования требований Right #4: To receive explanations of requirements practices and deliverables
Различные процедуры могут сделать процесс формулирования и управления требованиями эффективным и продуктивным, а знание требований может представляться в самых разных формах. Аналитик должен объяснить рекомендуемые процедуры, а также определить какую информацию будет содержать каждый полученный в результате документ. Например, для иллюстрации текста аналитик может создать ряд диаграмм. Эти диаграммы могут показаться непривычными или сложными, но они просты. Аналитик должен объяснить назначение каждой из них, смысл обозначений и процедуру проверки диаграмм на предмет ошибок. Если он не предоставляет таких объяснений, попросите его представить их. Various practices can make requirements development and management both effective and efficient, and requirements knowledge can be represented in a variety of forms. The BA should explain the practices he’s recommending and explain what information goes into each deliverable. For instance, the BA might create some diagrams to complement textual requirements. These diagrams might be unfamiliar to you, and they can be complex, but the notations shouldn’t be difficult to understand. The BA should explain the purpose of each diagram, what the symbols mean, and how to examine the diagram for errors. If the BA doesn’t offer such explanations, feel free to ask for them.
Право № 5. Изменить свои требования Right #5: To change your requirements
Со стороны аналитиков или разработчиков нереалистично ожидать, что вы сразу сможете предоставить все требования или что эти требования останутся неизменными на протяжении всего цикла разработки. У вас есть право вносить изменения в требования по мере развития бизнеса, в процессе получения членами команды больше информации от заинтересованных лиц или когда вы лучше обдумаете, что на самом деле вам нужно. Тем не менее, у изменений всегда есть цена. Иногда при добавлении новой функции приходится приносить в жертву другие функции или вносить коррективы в график или бюджет проекта. Важная часть ответственности аналитика заключается в оценке, управлении или изменении последствий подобных действий. Совместно с аналитиком выработайте простой, но эффективный процесс работы с изменениями в своем проекте. It’s not realistic for BAs or developers to expect you to think of all your requirements up front or to expect those requirements to remain static throughout the development cycle. You have the right to make changes in the requirements as the business evolves, as the team gathers more input from stakeholders, or as you think more carefully about what you need. However, change always has a price. Sometimes adding a new function demands trade-offs with other functions or with the project’s schedule or budget. An important part of the BA’s responsibility is to assess, manage, and communicate change impacts. Work with the BA on your project to agree on a simple but effective process for handling changes.
Право № 6. На взаимное уважение Right #6: To expect an environment of mutual respect
Отношения между клиентами и разработчиками могут становиться конфликтными. Если клиенты и разработчики не понимают друг друга, обсуждение требований может обернуться большим разочарованием. Совместная работа позволяет открыть друг другу глаза на проблемы, с которыми сталкивается каждая из этих групп. Клиенты, участвующие в процессе выработки требований, имеют полное право требовать от аналитиков и разработчиков уважительного отношения к себе и бережного отношения к затраченному времени. В свою очередь, и клиентам следует оказывать уважение разработчикам, ведь они все вместе сотрудничают для достижения общей цели — успешного проекта. Все находятся по одну сторону баррикад. The relationship between customers and developers sometimes becomes adversarial. Requirements discussions can be frustrating if the participants don’t understand each other. Working together can open the eyes of the participants to the problems each group faces. Customers who participate in requirements development have the right to expect BAs and developers to treat them with respect and to appreciate the time they are investing in the project’s success. Similarly, customers should demonstrate respect for the development team members as everyone collaborates toward their mutual objective of a successful project. Everyone’s on the same side here.
Право № 7. Знать о вариантах и альтернативах требований и их решении Right #7: To hear ideas and alternatives for your requirements and for their solution
Чтобы гарантировать, что новая система не будет автоматизировать неэффективные или устаревшие процессы, аналитик должен знать, почему существующие системы не годятся для ваших бизнес-процессов. Аналитики часто предлагают те или иные усовершенствования ваших бизнес-процессов. Полезен и аналитик, творчески подходящий к делу: он предлагает новые возможности программы, о которых пользователи даже и не мечтали. Let the BA know about ways that your existing systems don’t fit well with your business processes to make sure that a new system doesn’t automate ineffective or obsolete processes. That is, you want to avoid “paving the cow paths.” A BA can often suggest improvements in your business processes. A creative BA also adds value by proposing new capabilities that customers haven’t even envisioned.
Право № 8. Описать характеристики, упрощающие работу с продуктом Right #8: To describe characteristics that will make the product easy to use
Вполне вероятно, что аналитики спросят вас о характеристиках ПО, выходящих за рамки функциональных потребностей пользователей. Благодаря им программный продукт становится более удобным в работе, что позволяет клиентам эффективнее выполнять свои задачи. Иногда пользователи просят, чтобы продукт был дружественным или надежным, однако эти термины слишком субъективны, чтобы помочь разработчикам. Поэтому аналитик должен выяснить конкретные характеристики, означающие для вас дружественность или надежность. Расскажите аналитику о том, какие стороны ваших текущих приложений кажутся вам «дружественными», а какие нет. Если вы не обсудите эти характеристики с аналитиком, вам должно сильно повезти, чтобы продукт получился именно таким, как вы надеялись. You can expect BAs to ask you about characteristics of the software that go beyond your functional needs. These characteristics, or quality attributes, make the software easier or more pleasant to use, which lets users accomplish their tasks more efficiently. Users sometimes request that the product be user-friendly or robust, but such terms are too subjective to help the developers. Instead, the analyst should inquire about the specific characteristics that mean “user-friendly” or “robust” to you. Tell the BA about which aspects of your current applications seem “user-friendly” to you and which do not. If you don’t discuss these characteristics with the BA, you’ll be lucky if the product comes out as you hope.
Право № 9. Узнать о способах корректировки требований для ускорения разработки за счет повторного использования Right #9: To hear about ways to adjust requirements to accelerate development through reuse
Отношение к требованиям должны быть гибкими. Аналитику могут быть известны готовые программные компоненты или требования, которые практически полностью удовлетворят некоторые названные вами потребности. В таком случае аналитику следует предложить скорректировать ваши требования, чтобы разработчики могли использовать имеющееся ПО. Разумные возможности применения существующих модулей сэкономят ваши время и деньги. Если вы посчитаете разумным включить в свой продукт готовые коммерческие компоненты, будьте готовы проявить гибкость, поскольку характеристики таких компонентов вряд ли будут точно соответствовать вашим потребностям. Requirements are often somewhat flexible. The BA might know of existing software components or requirements that come close to addressing some need you described. In such a case, the BA should suggest ways of modifying your requirements or avoiding unnecessary customizations so developers can reuse those components. Adjusting your requirements when sensible reuse opportunities are available saves time and money. Some requirements flexibility is essential if you want to incorporate commercial off-the-shelf (COTS) packages into the product, because they will rarely have precisely the characteristics you want.
Право № 10. Получить систему, функциональность и качество которой соответствует вашим ожиданиям Right #10: To receive a system that meets your functional needs and quality expectations
Это самое главное право клиента, но оно осуществимо, только если вы сумеете донести до разработчиков всю информацию, которая поможет им создать подходящий продукт, если разработчики четко изложат вам все варианты и ограничения и если все участники достигнут соглашения. Убедитесь, что вы высказали все свои ожидания и предположения; в противном случае программисты, скорее всего, не смогут реализовать их. Иногда клиенты не формулируют определенные вещи, считая их общеизвестными фактами. Однако проверка правильности понимания всеми членами команды так же важна, как выражение чего-то нового. This is the ultimate customer right, but it can happen only if you clearly communicate all the information that will let developers build the right product, if developers communicate options and constraints to you, and if the parties reach agreement. Be sure to state all your assumptions and expectations; otherwise, the developers likely can’t address them properly. Customers sometimes don’t articulate points that they believe are common knowledge. However, validating a shared understanding across the project team is just as important as expressing something new.
Билль об обязанностях клиента ПО Requirements Bill of Responsibilities for Software Customers
Не бывает прав без обязанностей, поэтому приводим следующие десять обязанностей представителя клиента в процессе определения и управления требованиями в проекте. Because the counterpart to a right is a responsibility, following are 10 responsibilities that customer representatives have when it comes to defining and managing the requirements for their projects.
Обязанность №1. Ознакомить аналитиков и разработчиков с особенностями вашего бизнеса Responsibility #1: To educate BAs and developers about your business
Только вы можете полноценно познакомить разработчиков с концепциями и терминологией своего бизнеса. Вам не надо делать аналитиков экспертами в предметной области, основная задача — помочь им понять ваши проблемы и цели. Не ожидайте, что аналитики постигнут нюансы и неявные особенности бизнеса. Скорее всего, у них нет знаний, воспринимаемых вами и вашими коллегами, как должное. The development team depends on you to educate them about your business concepts and to define business jargon. The intent is not to transform BAs into business experts but to help them understand your problems and objectives. BAs aren’t likely to be aware of knowledge that you and your peers take for granted.
Обязанность №2. Потратить столько времени, сколько необходимо на предоставление и уточнение требований Responsibility #2: To dedicate the time that it takes to provide and clarify requirements
Клиенты — занятые люди, и те, кто участвует в формулировании требований — обычно самые занятые из них. Тем не менее, вы обязаны потратить время на участие в совещаниях, мозговых штурмах, интервью и прочих процедурах, необходимых для выявления требований. Иногда аналитик считает, что понял вашу идею, а позже сообразит, что ему необходимы дополнительные разъяснения. Пожалуйста, терпеливо относитесь к такому поэтапному подходу к формулированию и прояснению требований; это — природа сложного человеческого общения и ключ к успеху создаваемого ПО. Общее затраченное время будет меньшим, если выделить несколько часов на целенаправленное формулирование требований, чем растягивать процесс на долгие недели, вырывая минутку там и здесь на работу с требованиями. Customers are busy people; those who are involved in requirements work are often among the busiest. Nonetheless, you have a responsibility to dedicate time to workshops, interviews, and other requirements elicitation and validation activities. Sometimes the BA might think she understands a point you made, only to realize later that she needs further clarification. Please be patient with this iterative approach to developing and refining the requirements; it’s the nature of complex human communication and a key to software success. The total time required is less when there is focused effort for several hours than when the time is spent in bits and pieces strung out over weeks.
Обязанность №3. Точно и конкретно описать требования к системе Responsibility #3: To be specific and precise when providing input about requirements
Весьма заманчиво оставить требования неопределенными и нечеткими, ведь прояснять подробности так утомительно и долго. Тем не менее, на каком-то этапе разработки участникам проекта необходимо устранить все неоднозначности и неточности. Вам, как клиенту, и карты в руки. В противном случае угадывать, что же вам именно нужно, будут аналитики или разработчики. В спецификацию требований к программному обеспечению рекомендуется включить маркеры «требует прояснения» (to be determined, TBD), указывающие на необходимость дополнительных исследований, анализа и информации. Однако иногда такие маркеры используют в случаях, когда конкретное требование трудно определить точно и никто не хочет с ним возиться. Попытайтесь прояснить цель каждого требования, чтобы аналитик мог точно выразить его. Это самый лучший способ гарантировать, что продукт будет отвечать вашим потребностям. It’s tempting to leave the requirements vague and fuzzy because pinning down details is tedious and time consuming (or because someone wants to evade being held accountable for his decisions). At some point, though, someone must resolve the ambiguities and imprecisions. You’re the best person to make those decisions. Otherwise, you’re relying on the BA or developers to guess correctly. It’s fine to temporarily include to be determined (TBD) markers in the requirements to indicate that additional exploration or information is needed. Sometimes, though, TBD is used because a specific requirement is difficult to resolve and no one wants to tackle it. Try to clarify the intent of each requirement so that the BA can express it accurately. This is the best way to ensure that the product will meet your needs.
Обязанность №4. По запросу принимать своевременные решения относительно требований Responsibility #4: To make timely decisions about requirements when asked
Точно так же, как и подрядчик при строительстве дома, аналитик задаст вам множество вопросов и попросит выбрать различные варианты и принять решения. Это может быть согласование противоречивых запросов от разных клиентов, выбор между конфликтующими атрибутами качества и оценка точности информации. Клиенты, обладающие соответствующими полномочиями, должны принять эти решения, когда их об этом попросят. Зачастую работа стопорится, так как клиент не может принять окончательного решения, и поэтому, медля с ответом, вы затягиваете работу над проектом. Когда потребности в вашем времени становятся обременительными, помните, что система создается для вас. Аналитики обучены помогать людям принимать решения, поэтому обратитесь к ним за помощью, когда не можете решиться на что-то. Just as a contractor does while building your fabulous dream home, the BA will ask you to make many decisions. These include resolving conflicting requests received from multiple customers, choosing between incompatible quality attributes, and evaluating the accuracy of information. Customers who are authorized to make such decisions must do so promptly when asked. Developers often can’t proceed with confidence until you render your decision, so time spent waiting for an answer can delay progress. When the demands for your time start to feel onerous, remember that the system is being built for you. Business analysts are often skilled at helping people think through making decisions, so ask for their help if you get stuck.
Обязанность №5. Уважать определенную разработчиком оценку стоимости и возможности реализации ваших требований Responsibility #5: To respect a developer’s assessment of the cost and feasibility of requirements
Все программные функции чего-то стоят. Разработчики лучше всего способны оценить эту стоимость. Может оказаться, что некоторые необходимые вам функции технически неосуществимы или их реализация слишком дорога, например недостижимая в рабочей среде производительность или доступ к данным, которые системе просто недоступны. Даже если сведения об осуществимости и стоимости некоторых функций, сообщенные разработчиком, вам не понравятся, следует уважать эту оценку. Иногда удается переписать требования так, чтобы они стали реализуемыми или стоили бы меньше денег. Например, требовать «моментального» выполнения операции неразумно, а более точное требование («в течение 50 миллисекунд») может оказаться вполне реализуемым. All software functions have a cost. Developers are in the best position to estimate those costs. Some features might not be technically feasible or might be surprisingly expensive to implement. Certain requirements might demand unattainable performance in the operating environment or require access to data that isn’t available to the system. The developer can be the bearer of bad news about feasibility or cost. You should respect that judgment, even if it means you might not get something you asked for in exactly the form you envisioned. Sometimes, you can rewrite requirements in a way that makes them attainable or cheaper. For example, asking for an action to take place “instantaneously” isn’t feasible, but a more precise timing requirement (“within 50 milliseconds”) might be achievable.
Обязанность №6. Определять реалистичные приоритеты требований совместно с разработчиками Responsibility #6: To set realistic requirement priorities in collaboration with developers
Лишь при работе над ограниченным кругом задач можно рассчитать время и ресурсы для реализации всей желаемой функциональности. Определить, какие возможности необходимы, какие полезны и без каких пользователи обойдутся — важная составляющая анализа требований. Именно вы определяете эти приоритеты, поскольку разработчики не в состоянии это сделать. Чтобы вам облегчить задачу, разработчики предоставляют информацию о стоимости и рисках всех требований. Определив приоритеты, вы поможете разработчикам вовремя и с минимальными затратами создать максимально эффективный продукт. Совместная приоритизация является ключевой в проектах гибкой (agile) разработки — она позволяет разработчикам максимально быстро поставлять полезный программный продукт. Few projects have the time and resources to implement every bit of functionality all customers want. Determining which capabilities are essential, which are useful, and which the customers can live without is an important part of requirements analysis. You have a lead role in setting requirement priorities. Developers can provide information about the cost and risk of each requirement or user story to help determine final priorities. When you establish realistic priorities, you help the developers deliver the maximum value at the lowest cost and at the right time. Collaborative prioritization is key for agile projects, so the developers can begin delivering useful software as quickly as possible.
Уважайте оценку команды разработчиков, какой объем функциональности они могут завершить за отведенное время и с имеющимися ограничениями по ресурсам. Если все необходимое не умещается в рамки проекта, ответственные за принятие решений лица должны сократить объем задач, основываясь на приоритетах, увеличить длительность проекта или предоставить дополнительный бюджет или людей. Просто объявить все требования высокоприоритетными нереалистично и не соответствует духу сотрудничества. Respect the development team’s judgment as to how much of the requested functionality they can complete within the available time and resource constraints. If everything you want doesn’t fit in the project box, the decision makers will have to reduce project scope based on priorities, extend the schedule, or provide additional funds or people. Simply declaring every requirement as high priority is neither realistic nor collaborative.
Обязанность №7. Проверять требования и оценивать прототипы Responsibility #7: To review requirements and evaluate prototypes
Рецензирование требований — одна из наиболее значимых операций, обеспечивающих качество ПО. Участие клиентов в таких мероприятиях — единственный способ узнать, отражают ли требования потребности клиента наиболее полно и точно. Обзор также является возможностью для представителей клиента оценить, насколько хорошо работа аналитика соответствует потребностям проекта. Занятые клиенты часто не хотят тратить время на обзор требований, но это стоит того. Аналитик должен предоставлять требования для обзора разумными порциями на всем протяжении процесса выявления требований, а не сваливать на ваш стол объемную пачку документации, когда требования «готовы». Peer reviews of requirements are among the most powerful software quality activities available. Having customers participate in reviews is a key way to evaluate whether the requirements demonstrate the desired characteristics of being complete, correct, and necessary. A review is also an opportunity for customer representatives to assess how well the BA’s work is meeting the project’s needs. Busy customers often are reluctant to devote time to a requirements review, but it’s well worth their time. The BA should make requirements available to you for review in manageable chunks throughout the requirements elicitation process, not in a massive tome dumped on your desk when the requirements are “done.”
Читая спецификацию требований, не всегда удается четко представить работу программы. Чтобы лучше понять потребности клиента и выявить оптимальные способы их удовлетворения, аналитики и разработчики иногда создают прототипы предполагаемого продукта. Ваши отклики на эти предварительные, частичные или пробные версии дают разработчикам необходимую информацию. It’s hard to develop a good mental picture of how software will work from written requirements alone. To better understand your needs and explore the best ways to satisfy them, BAs or developers sometimes build prototypes of the intended product. Your feedback on these preliminary, partial, or exploratory implementations provides valuable information to the developers.
Обязанность №8. Определить критерии приемки Responsibility #8: To establish acceptance criteria
Как разработчики определят, что выполнили свою задачу? Как им узнать, соответствует ли созданное ПО ожиданиям различных сообществ клиентов? Одна из обязанностей клиента — установить критерии приемки, то есть заданные условия, которым должен удовлетворять продукт, чтобы его можно было считать приемлемым. Такие критерии включают приемочные тесты, которые оценивают, позволяет ли продукт пользователям правильно выполнять те или иные их операции. Другие критерии приемки могут определять, допустимый уровень оставшихся в продукте дефектов, производительность определенных действий в рабочей среде или способность удовлетворить определенным внешним сертификационным требованиям. В проектах гибкой разработки (agile) вместо письменных требований активно используются приемочные тесты для наполнения «плотью и кровью» пользовательских историй. Тестировщики могут определить, правильно ли реализовано то или иное требование, но они не всегда знают, что вы считаете допустимым результатом. How do developers know when they’re done? How can they tell if the software they built will meet the expectations of the various customer communities? As a customer, one of your responsibilities is to establish acceptance criteria, predefined conditions that the product must satisfy to be judged acceptable. Such criteria include acceptance tests, which assess whether the product lets users perform certain of their important business operations correctly. Other acceptance criteria might address the estimated remaining defect levels, the performance of certain actions in the operating environment, or the ability to satisfy external certification requirements. Agile projects rely heavily on acceptance tests, instead of written requirements, to flesh out the details of user stories. Testers can judge whether a specified requirement was implemented correctly, but they don’t always know exactly what you will consider an acceptable outcome.
Обязанность №9. Своевременно сообщать об изменениях требований Responsibility #9: To promptly communicate changes to the requirements
Постоянное изменение требований — серьезная угроза для возможности своевременной сдачи проекта командой разработчиков. Изменение неизбежно, но чем позже в ходе разработки о нем сообщается, тем более сильное влияние оно окажет. Как только вы решите изменить требования, сразу же сообщите об этом аналитику, с которым работаете. Для снижения негативного влияния изменений следуйте определенному в проекте процессу управления изменениями. Это гарантирует, что запрошенные изменения не потеряются, влияние каждого изменения будет проанализировано и все предложенные изменения будут рассмотрены с соблюдением единой процедуры. В результате заинтересованные лица компании смогут принять разумные бизнес-решения по внедрению соответствующих изменений на правильном этапе проекта. Continually changing requirements pose a serious risk to the development team’s ability to deliver a high-quality product on schedule. Change is inevitable and often valuable, but the later in development a change is introduced, the greater its impact. Notify the BA as soon as you learn that you need to change a requirement. To minimize the negative impact of changes, follow the project’s defined change control process. This ensures that requested changes are not lost, the impact of each change is analyzed, and all proposed changes are considered in a consistent way. As a result, the business stakeholders can make sound business decisions to incorporate appropriate changes at the right stage of the project.
Обязанность №10. Уважительно относиться к процессам создания требований Responsibility #10: To respect the requirements development process
Выявление и спецификация требований — одни из самых трудных задач в разработке ПО. У всех подходов, применяемых аналитиками, есть рациональная основа. И хотя операции по созданию требований могут вас разочаровать, время, затраченное, чтобы разобраться в требованиях, — это отличные инвестиции. Процесс окажется менее болезненным, если вы разберетесь в методах, используемых аналитиками для создания требований. Не стесняйтесь и просите аналитиков объяснить, зачем необходимы те или иные сведения и почему они просят вас поучаствовать в некоторых операциях по созданию требований. Взаимопонимание и уважение приемов и потребностей друг друга имеют огромное значение для организации эффективного и даже доставляющего удовольствие сотрудничества. Eliciting and specifying requirements are among the greatest challenges in software development. There’s a rationale behind the BA’s approach to requirements development. Although you might become frustrated, the time spent understanding requirements is an excellent investment. The process will be less painful if you respect the techniques the BAs use. Feel free to ask BAs to explain why they’re requesting certain information or asking you to participate in some requirements-related activity. A mutual understanding of, and respect for, each other’s approaches and needs goes a long way toward establishing an effective—perhaps even enjoyable—collaboration.

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

Создание культуры уважения к требованиям Creating a culture that respects requirements
Руководитель отдела работы с требованиями однажды сформулировал проблему: «У меня сложность с получением согласия разработчиков на участие в разработке требований. Как мне помочь им понять ценность их участия?» В другой организации аналитик столкнулся с конфликтом между разработчиками, пытающимися получить подробные сведения о бухгалтерской системе, и ИТ-менеджером, который просто хотел провести мозговой штурм по определению требований вместо использования специальных приемов выявления требований. Этот аналитик спросил меня: «Решаются ли читатели вашей книги на конфронтацию культур?» The leader of a corporate requirements organization once posed a problem: “I’m experiencing issues in gaining agreement from some of our developers to participate in requirements development,” she said. “How can I help them understand the value of their participation?” In another organization, a BA experienced a clash between developers seeking detailed input for an accounting system and an IT manager who simply wanted to brainstorm requirements without using any specific elicitation techniques. “Do readers of your book risk cultural conflict?” this BA asked me.
Эти вопросы отображают проблемы, которые возникают при попытке привлечь аналитиков, разработчиков и клиентов к коллективному партнерству при работе над требованиями. Можно посчитать очевидным, что предоставление пользователем информации о требованиях повышает вероятность, что он получить то, что ему нужно. Разработчики должны понять, что участие в этом процессе сделает их жизнь проще, и не придется удивляться документам требований, которые приходят из-за воображаемой стены. Естественно, не всем нравятся требования, как вам, в противном случае они бы все стали аналитиками! These questions exemplify the challenges that can arise when trying to engage BAs, developers, and customers in a collaborative requirements partnership. You’d think it would be obvious to a user that providing requirements input makes it more likely that he’ll get what he needs. Developers ought to recognize that participating in the process will make their lives easier than being hit on the head by whatever requirements document flies over the proverbial wall. Obviously, not everyone is as excited about requirements as you are; if they were, they’d probably all become business analysts!
При работе над требованиями часто возникают конфликты культур. Есть люди, которые понимают риски, связанные с попытками разработать ПО на основе минимальных или «телепатически» передаваемых требований. Есть также те, что считают требования ненужными. Бывает тяжело добиться сотрудничества со стороны бизнес-подразделений в проектах по замене старых систем, если пользователи видят, что это не связано с их собственными бизнес-задачами и не стоит их времени. Понимание, почему пользователи сопротивляются участию в разработке требований, — первый шаг на пути к решению проблемы. Culture clashes frequently arise when teams are working on requirements. There are those who recognize the many risks associated with trying to develop software based on minimal or telepathically communicated requirements. Then there are those who think requirements are unnecessary. It can be tough to gain business-side cooperation on projects like legacy-system replacement if users see this as unrelated to their own business problems and not worth their time. Understanding why people resist participating in requirements development is the first step to being able to address it.
Возможно, что противники требований никогда не работали в коллективе с прочными традициями работы с требованиями. Или они стали жертвами неудачной реализации процессов работы с требованиями, например у них был опыт работы в проекте, где создавались огромные, неполные и неиспользуемые спецификации требований. Это у любого испортит отношение к требованиям. Возможно, противники не понимают и не осознают ценность процедур работы с требованиями, если они выполняются эффективно. Они могут не осознавать цену, которую пришлось заплатить при работе в случайной и неструктурированной среде в прошлом. Цена обычно выражается в неожиданных переделках, которые приводят к задержкам выпуска и низкому качеству ПО. Подобные переделки скрыты в ежедневной работе участников проекта, поэтому они не считают их серьезной проблемой с эффективностью. It’s possible that the resisters haven’t been exposed to solid requirements practices. Or they might have suffered from poor implementation of requirements processes, perhaps working on a project that produced a large, incomplete, and ignored requirements specification. That would leave a bad taste in anyone’s mouth. Perhaps the resisters don’t understand and appreciate the value of those practices when performed effectively. They might not realize the price they have paid for having worked in a casual and unstructured environment in the past. That price mostly shows up as unexpected rework that leads to late deliveries and poor software. Such rework is buried in the daily activities of the project participants, so they don’t recognize it as a serious inefficiency.
Пытаясь привлечь на свою сторону разработчиков, менеджеров и клиентов, позаботьтесь, чтобы все поняли, сквозь какие неприятности пришлось пройти организации и ее клиентам из-за проблем с требованиями. Представьте конкретные примеры, если люди не испытывали неприятности лично. Выразите затраты в единицах, понятных в организации, — это могут быть деньги, недовольство клиентов или потерянные бизнес-возможности. Менеджеры разработки не всегда понимают, насколько плохо недостатки требований сказываются на производительности их команд. Поэтому покажите им, как плохие требования замедляют проектирование и ведут к излишним и недешевым корректировкам курса. If you’re trying to get developers, managers, and customers on board, make sure everyone understands the past pain the organization and its customers have experienced because of requirements problems. Find specific examples to demonstrate the impact in case individuals haven’t felt the pain themselves. Express the cost in units that are meaningful to the organization, be it dollars, time, customer dissatisfaction, or lost business opportunities. Development managers aren’t always aware of how badly requirements shortcomings hurt their teams’ productivity. So show them how poor requirements slow down design and lead to excessive—and expensive—course corrections.
Разработчики являются заинтересованными лицами в проекте, но бывает так, что их никто не спрашивает и они становятся «жертвами» спущенных к ним сверху требований. Поэтому им выгодно участвовать, чтобы их вклад позволил сделать документацию по требованиям максимально полезной и показательной. Мне нравится, когда разработчики просматривают требования по мере их создания. Таким образом они знают, чего ожидать, и могут указать области, в которых им нужна большая ясность. Участие разработчика также требуется при определении внутренних атрибутов качества, которые невидимы для пользователей. Разработчики могут предоставить предложения, о которых другие как правило не думают: более простые способы выполнения определенных вещей, функциональность, реализация которой может занять очень много времени, ненужные ограничения на дизайн, отсутствующие требования, например как обрабатывать исключения, а также продуктивные возможности использования технологий. Developers are stakeholders in the project, but sometimes their input isn’t solicited and they become the “victims” of the requirements that are thrust upon them. Therefore, they benefit from providing input that will make the requirements documentation as useful and meaningful as possible. I like to have developers review requirements as they are evolving. That way they know what’s coming and can spot areas that need more clarity. You also need developer input when specifying internal quality attributes that aren’t visible to users. Developers can offer suggestions no one else might have thought about: easier ways to do certain things; functionality that would be very time-consuming to implement; unnecessary imposed design constraints; missing requirements, such as how exceptions should be handled; and creative opportunities to take advantage of technologies.
Вклад сотрудников отделов контроля качества и тестирования также важен для создания отличных требований. Не стоит откладывать на более поздние этапы привлечение этих наблюдательных людей к итеративной проверке требований. При разработке своих тестовых случаев и сценариев на основе требований они скорее всего обнаружат много неясностей, противоречий и проблем с требованиями. Тестировщики могут также предоставить информацию об определении поддающихся проверке требований к атрибутам качества. Quality assurance staff and testers are also valuable contributors to excellent requirements. Instead of waiting until later in the project, engage these sharp-eyed people in the iterative review of requirements early on. They’re likely to find many ambiguities, conflicts, and concerns with the requirements as they are developing their test cases and scenarios from the requirements. Testers can also provide input on specifying verifiable quality attribute requirements.
Причиной сопротивления изменениям процессов или культуры может быть страх, неуверенность или недостаток знаний. Если вы сумеете определить источник сопротивления, у вас появится возможность бороться с ним путем увещеваний, объяснений и просвещения. Покажите людям, что их участие принесет пользу не только им лично, но от этого выиграют все. Resistance to process or culture change can indicate fear, uncertainty, or lack of knowledge. If you can discern the source of the resistance, you can confront it with reassurance, clarification, and education. Show people how their participation not only is in their personal best interest but also will lead to collectively better results.
Руководство организации должно понимать необходимость иметь эффективные возможности бизнес-анализа и разработки требований как стратегические базовые корпоративные знания. Несмотря на то, что проектная и локализационная деятельность важны, без решимости руководства преимущества и выигрыш скорее всего будут утеряны по завершении проекта или после реорганизации. The organization’s leadership must understand the need for the organization to have effective business analysis and requirements engineering capabilities as strategic core competencies. Though project-specific and localized grassroots efforts are important, without management commitment, the improvements and benefits likely won’t be sustained after the project ends or following a reorganization.

Определение ответственных за принятие решений

Определение ответственных за принятие решений Identifying decision makers
В процессе реализации проектов по разработке ПО может потребоваться принимать сотни решений, причем часто они находятся на критическом пути и без них невозможно двигаться вперед. Может возникнуть необходимость уладить конфликт, принять (или отвергнуть) предложенное изменение или одобрить набор требований для определенного выпуска. На ранних этапах проекта определите лиц ответственных за принятие решений в области требований и то, как они должны принимать решения. There can be hundreds of decisions to make on software projects; often, they are on the critical path to being able to move ahead. You might need to resolve some conflict, accept (or reject) a proposed change, or approve a set of requirements for a specific release. Early in your project, determine who the requirements decision makers will be and how they will make decisions.
Мой друг Крис, опытный менеджер проектов, сказал: «Я обнаружил, что обычно есть один основной человек, принимающий решения в проекте, и очень часто это ключевой «куратор» в организации. Я обязательно нахожу этого человека, после чего слежу за тем, чтобы он всегда был в курсе продвижения проекта». Нет универсального правильного ответа на вопрос, кто должен принимать ключевые решения в проекте. Но лучше всего это получается у небольшой группы, представляющей самые важные области — руководство, клиентов, аналитиков, разработчиков и маркетинг. My friend Chris, a seasoned project manager, pointed out, “I have found that there is usually one primary decision maker on a project, oftentimes the key sponsor within the organization. I don’t rest until I have identified that person, and then I make sure he is always aware of the project’s progress.” There’s no single correct answer as to who should make key decisions. A small group representing key areas—such as management, customers, business analysis, development, and marketing—generally works best.
В группе принятия решений нужно определить главного ответственного за принятие решений и правило принятия решений, которой описывает порядок принятия решения в группе. Существует много правил принятия решений, в том числе следующие (Gottesdiener, 2001): The decision-making group needs to identify its decision leader and to select a decision rule, which describes how they will arrive at their decisions. There are numerous decision rules to choose from, including the following (Gottesdiener 2001):
• Решения принимает главный ответственный с или без предварительного обсуждения с другими. ■ The decision leader makes the choice, either with or without discussion with others.
• Члены группы голосуют и решение принимается большинством голосов. ■ The group votes and the majority rules.
• Члены группы голосуют, но решение принимается только единогласно. ■ The group votes, but the result must be unanimous to approve the decision.
• Члены группы обсуждают и договариваются, достигая консенсуса. Всех устраивает решение и каждый обязуется поддерживать его. ■ The group discusses and negotiates to reach a consensus. Everyone can live with the decision and commits to supporting it.
• Главный ответственный делегирует право принятия решения какому-то человеку. ■ The decision leader delegates authority for making the decision to one individual.
• Решение принимает группа, но у одного из ее членов есть право вето на принятие решения. ■ The group reaches a decision, but some individual has veto authority over that decision.
Нет одного самого правильного и подходящего всем правила принятия решений. Одно правило принятия решений не может работать во всех ситуациях, поэтому в группе нужно уставить соответствующие руководящие положения, чтобы членам было понятно, когда голосовать, когда нужен консенсус, когда делегировать и т. п. Люди, ответственные за принятие решений по требованиям, в любом из ваших проектов должны выбрать правило принятия решений до того, как начнут принимать свое первое значительное решение. There is no globally correct or appropriate decision rule. A single decision rule won’t work in every situation, so the group must establish guidelines so they know when to vote, when to reach consensus, when to delegate, and so on. The people who will be making requirements-related decisions on each of your projects should choose a decision rule before they confront their first significant decision.

Достижение соглашения о требованиях

Достижение соглашения о требованиях Reaching agreement on requirements
Достижение соглашения о требованиях к продукту или его части, которую планируется построить, — основа сотрудничества клиентов и разработчиков. В выработке соглашения участвует много сторон: Reaching agreement on the requirements for the product to be built, or for a specific portion of it, is at the core of the customer-developer partnership. Multiple parties are involved in this agreement:
• клиенты должны подтвердить, что требования удовлетворяют их потребности; ■ Customers agree that the requirements address their needs.
• разработчики подтверждают, что они понимают требования и в состоянии их реализовать; ■ Developers agree that they understand the requirements and that they are feasible.
• тестировщики подтверждают, что требования поддаются проверке; ■ Testers agree that the requirements are verifiable.
• руководство подтверждает, что требования соответствуют их бизнес-целям. ■ Management agrees that the requirements will achieve their business objectives.
Многие организации просят клиента поставить свою подпись на документах с требованиями: это означает, что клиент их подтверждает. Все участники процесса утверждения требований должны четко понимать, что означает такая подпись и какие проблемы она может создавать. Одна из таких проблем заключается в том, что представитель или менеджер клиента может посчитать эту процедуру бессмысленной: «Мне дали лист бумаги с моим именем, и я на этой бумаге расписался, иначе разработчики не начали бы программировать». Если такой заказчик захочет через некоторое время изменить требования или его не устроит результат работы, детским лепетом прозвучат слова: «Ну да, я подписал эти требования, но у меня не было времени их читать. Я доверял вам, ребята, а вы меня подвели!» Many organizations use the act of “signing off” (why not “signing on”?) on the requirements as the mark of stakeholder approval. All participants in the requirements approval process should know exactly what sign-off means or problems could ensue. One such problem is the customer representative or manager who regards signing off on the requirements as a meaningless ritual: “I was handed a piece of paper with my name on it, so I signed on the line above my name because otherwise the developers wouldn’t start coding.” This can lead to future problems when that individual wants to change the requirements or when he’s surprised by what is delivered: “Sure, I signed off on the requirements, but I didn’t have time to read them all. I trusted you guys—you let me down!”
Иногда проблему создает менеджер по разработке, если он рассматривает подпись как способ заморозить требования, сделав их неизменными. Когда клиент просит о каких-то изменениях, он будет протестовать: «Но вы же подписали эти требования, и именно такую систему мы и создаем. Если вам нужно было что-то другое, следовало сказать об этом раньше». Equally problematic is the development manager who views sign-off as a way to freeze the requirements. Whenever a change request comes along he can protest, “But you signed off on these requirements, so that’s what we’re building. If you wanted something else, you should have said so.”
Оба описанных подхода игнорируют реальность, которая такова, что на ранних этапах работы над проектом нельзя знать абсолютно всех требований и со временем они неизбежно меняются. Утверждение требований — операция, которая закрывает прения на определенном этапе создания требований. Тем не менее, участникам необходимо подтвердить свои слова подписями. Both of these attitudes ignore the reality that it’s impossible to know all the requirements early in the project and that requirements will undoubtedly change over time. Approving a set of requirements is an appropriate action that brings closure to some stage of requirements development. However, the participants have to agree on precisely what they’re saying with their signatures.
Внимание! Important
Не используйте подпись в качестве оружия. Применяйте ее как завершение этапа проекта и выработайте четкое коллективное понимание того, как подпись повлияет на возможные в будущем изменения. Если ответственные за принятие решений лица не должны читать каждое слово требований, выберите средство коммуникации, например презентацию слайдов, которое предоставит сводную информацию об основных элементах и позволит быстро достичь соглашения. Don’t use sign-off as a weapon. Treat it as a milestone, with a clear, shared understanding of the activities that lead to sign-off and its implications for future changes. If the decision makers don’t need to read every word of the requirements, select a communication technique—such as a slide presentation—that summarizes the essential elements and facilitates reaching agreement quickly.
Базовое соглашение о требованиях The requirements baseline
Гораздо важнее ритуала подписи концепция создания базового (baseline) соглашения о требованиях — снимка такого соглашения на какой-то момент времени (Wiegers, 2006). Базовое соглашение о требованиях является набором проверенных и согласованных требований, которые служат основой для дальнейшей разработки. Использует ваша команда формальный процесс подписи или другие средства достижения соглашения о требованиях, текст под подписью на странице подтверждения требований должен звучать примерно так: More important than the sign-off ritual is the concept of establishing a baseline of the requirements agreement, a snapshot of it at a point in time (Wiegers 2006). A requirements baseline is a set of requirements that has been reviewed and agreed upon and serves as the basis for further development. Whether your team uses a formal sign-off process or some other means of reaching agreement on requirements, the subtext of that agreement should read something like this:
«Подтверждаю, что настоящий набор требований наилучшим образом представляет наше понимание требований к этому проекту на данный момент и что описанная система удовлетворит наши потребности. Я согласен вносить в будущем изменения в это базовое соглашение в соответствии с процессом изменения требований, определенным в проекте. Я понимаю, что изменения могут потребовать переоценки стоимости, ресурсов и сроков сдачи проекта». “I agree that this set of requirements represents our best understanding of the requirements for the next portion of this project and that the solution described will meet our needs as we understand them today. I agree to make future changes in this baseline through the project’s defined change process. I realize that changes might require us to renegotiate cost, resource, and schedule commitments.”
В некоторых организациях подобный текст размещают прямо на странице подписи, чтобы лица, одобряющие документ, точно знали, что означает их подпись. Some organizations put text like this right on the signature page, so the requirement approvers know exactly what sign-off means in their world.
Согласованное понимание значения подписи позволяет избежать трений, возникающих при изменении взглядов на требования, а также при изменении рыночных и бизнес-требований к проекту. Осмысленный процесс создания базового соглашения о требованиях дает уверенность всем участникам проекта: A shared understanding along these lines helps reduce the friction that can arise as requirements oversights are revealed or marketplace and business demands evolve over the course of the project. A meaningful baselining process gives all the major stakeholders confidence in the following ways:
• руководство или отдел маркетинга клиента уверены, что границы проекта не выйдут из-под контроля, поскольку решения относительно границ принимает клиент; ■ Customer management or marketing is confident that the project scope won’t explode out of control, because customers manage the scope change decisions.
• представители клиента уверены, что разработчики будут взаимодействовать с ним для создания нужной системы, даже если перед началом работы над проектом они не успели продумать все требования; ■ User representatives have confidence that the development team will work with them to deliver the right solution, even if they didn’t think of every requirement before construction began.
• руководство проекта уверено, что команда разработчиков получила достойного делового партнера, который ориентирован на достижение поставленных целей и готов сотрудничать с разработчиками над достижением баланса затрат, функциональности и качества; ■ Development management has confidence because the development team has a business partner who will keep the project focused on achieving its objectives and will work with development to balance schedule, cost, functionality, and quality.
• бизнес-аналитики и менеджеры проекта уверены в том, что могут управлять изменениями проекта, минимизируя хаос; ■ Business analysts and project managers are confident that they can manage changes to the project in a way that will keep chaos to a minimum.
• команды контроля качества и тестирования могут спокойно разрабатывать свои сценарии тестирования, будучи полностью готовыми к выполнению своих обязанностей в проекте. ■ Quality assurance and test teams can confidently develop their test scripts and be fully prepared for their project activities.
После определения базового соглашения о требованиях аналитик должен разместить требования в системе управления версиями. Это позволит команде при необходимости контролируемым образом изменять границы требований, включая анализ влияния каждого предлагаемого изменения на график и другие факторы успеха. Скрепив начальные операции по формулированию требований явным соглашением, вы сплотите клиентов и разработчиков на пути к успеху проекта. After the decision makers define a baseline, the BA should place the requirements under change control. This allows the team to modify scope when necessary in a controlled way that includes analyzing the impact of each proposed change on the schedule and other success factors. Sealing the initial requirements development activities with an explicit agreement helps forge a collaborative customer-development partnership on the way to project success.
Что если не удается достичь соглашения? What if you don’t reach agreement?
Может быть сложным получить подпись всех нужных заинтересованных лиц. К возможным препятствиям на пути к решению этих задач относятся логистика, напряженный график или люди, которые не хотят брать на себя обязательства, за которые потом придется отвечать. Если заинтересованные лица боятся, что не смогут внести изменения после одобрения требований, они будут тянуть с одобрением. Это одно из обстоятельств, способных привести к ужасно нежелательной ситуации паралича анализа. It can be hard to achieve sign-off from all the relevant stakeholders. Barriers include logistics, busy schedules, and people who are reluctant to commit and be held accountable later. If stakeholders are afraid they won’t be able to make changes after they approve the requirements, they might drag their feet on the approval. This contributes to the dreaded trap of analysis paralysis.
Во многих командах пытаются отправить примерно такое сообщение электронной почты: «Если вы не представите ответ со своими коррективами или подписью до следующей пятницы, мы будем предполагать, что вы согласились с этими требованиями». Это один из вариантов, но на деле это способ не достичь соглашения. Есть также риск усложнения отношений с заинтересованными лицами, от которых вы ожидали молчаливого согласия. Попытайтесь понять, почему им не хочется ставить свою подпись, и решить саму проблему. Many teams have tried sending out an email message that says, “If you don’t reply by next Friday with your changes and/or sign-off, I’m going to assume you are agreeing to these requirements.” That’s one option, but really it equates to not reaching agreement. It also risks straining the relationship with those stakeholders for whom you’ve just assumed a tacit approval. Try to understand why they didn’t feel comfortable with a sign-off and address that directly.
В такой ситуации лучше двигаться вперед, но осторожно, предполагая что у вас нет одобрения упорствующих заинтересованных лиц. Задокументируйте тот факт, что определенные заинтересованные лица не завизировали требования, в своем списке рисков вместе с возможным влиянием от пропуска или неверности некоторых требований. Работу с этими лицами нужно рассматривать как часть процедур по управлению рисками. В позитивном ключе упомяните, что вы в курсе, что они пока не одобрили требования, но проект движется вперед с этими требованиями в качестве базовых, чтобы не задерживать работу. Сообщите им, что если они хотят что-то изменить, для этого есть соответствующий процесс. В сущности, вы действуете так, как будто заинтересованное лицо согласилось с требованиями, но вы четко отслеживаете отношения. In such a situation, you’re better off moving forward—cautiously—with the assumption that you don’t have approval from the recalcitrant stakeholders. Document the fact that certain stakeholders didn’t sign off on the requirements in your risk list, along with the likely impact of some of the requirements being missing or wrong. Follow up with these people as part of risk management. In a positive manner, mention that you recognize that they have not yet approved the requirements but that the project is still moving forward with those requirements as a baseline so as to not impede progress. Let them know that, if they want to change things, there’s a process in place to do that. Basically, you’re acting as though the stakeholder did indeed agree to the requirements, but you’re managing the communications closely.
Согласование требований в проектах гибкой разработки Agreeing on requirements on agile projects
В проектах гибкой разработки (agile) нет формальной операции визирования. В таких проектах требования обычно хранятся в виде пользовательских историй в резерве (backlog) продукта. Владелец продукта и команда согласовывают, какие рассказы будут реализовываться в следующей итерации, в процессе совещания по планированию. Набор историй выбирается на основе приоритетов и скорости работы (продуктивности) команды. После определения и согласования набора содержащиеся в итерации истории замораживаются. Agile projects do not include a formal sign-off action. Agile projects generally maintain requirements in the form of user stories in a product backlog. The product owner and the team reach agreement on what stories will be developed in the next iteration in a planning session. The set of stories is chosen based on their priority and the team’s velocity (productivity). After that set has been established and agreed to, the stories contained in the iteration are frozen.
Новые запрошенные изменения планируются только на будущие итерации. В проектах гибкой разработки никто не пытается получить одобрение заинтересованного лица сразу на весь набор требований. В таких проектах полный набор функциональности определяется со временем, хотя концепция и другие бизнес-требования должны быть определены с самого начала. Requested changes that come in are considered for future iterations. There’s no attempt on an agile project to achieve stakeholder approval on the full scope of requirements for the project up front, however. In agile projects the full set of functionality is identified over time, although the vision and other business requirements do need to be established at the outset.
Однажды мне пришлось работать в проекте, где клиент запросил подписание требований несмотря на то, что использовалась гибкая методика разработки. Команде пришлось проявить изобретательность, чтобы сделать это в контексте, который обычно не предусматривает визирования. Команда аналитиков тесно работала с пользователями, чтобы собрать и проверить требования в форме пользовательских историй и других моделей, таких как потоки процессов и таблицы состояний. Мы просили пользователей «завизировать», что на тот момент времени не было отсутствующих известных им важных требований и никаких известных им серьезных проблем с написанным нами. Так как пользователи участвовали в деятельности по определению требований, разработчики работали над решением, которое не могло оказаться слишком отходящим от базовых требований. Но такое понимание «визы» оставляет открытым право пользователей осознать, что им требуется добавить что-то новое или что-то исправить в существующих требованиях. I once worked with a client who requested sign-off on requirements even though they were following an agile development life cycle. The team had to be creative with how to do this in a context that doesn’t traditionally involve sign-offs. The BA team had worked closely with the users to elicit and review requirements in the form of user stories and other models such as process flows and state tables. We asked the users to “sign off” that, at that moment in time, there were no major requirements missing that they knew about, and there were no major issues with what we’d written down that they knew about. Because users did participate in the requirements activities, development would not be working on a solution that would be far off base. But this notion of “sign-off” also keeps open the right of the users to realize later on that they need something new or got something wrong.
В отличие от исторически сложившегося значения визы (или подписи) — «одобрение и заморозка всех требований с первого до последнего», — этот подход никого не загоняет в угол и не заставляет чувствовать, что дальнейшая жизнь будет зависеть от объемного документа требований, который полностью так и не удалось понять. И клиентов не вынуждают признать, что требования близки к идеальным и все сделано правильно с первого раза. Такая версия визирования оставляет дух гибкой разработки. Как и в случае с описанным ранее процессом подписания, суть заключается в достижении соглашения относительно конкретного набора базовых требований, которые будут реализованы в следующем цикле, с общим пониманием, что такое соглашение на самом деле означает. In contrast to the historical notion of sign-off as meaning “approve and freeze all the requirements up front,” this approach doesn’t force anyone into a corner where he feels like he’s signing away his life over a massive requirements document that he barely understands. Nor are customers forced to agree that the requirements are close to perfect and that everything was addressed the first time around. This version of sign-off allows the spirit of agile methods to prevail. As with the sign-off process described earlier, the essence is to reach agreement on a specific body of requirements—a baseline—to be implemented in the next construction cycle, with a clear, shared understanding of what that agreement really means.
В проектах гибкой разработки владелец продукта публично принимает или отвергает требования на итерацию, которые представляют собой набор историй и связанных критериев принятия и приемочных тестов. Конечное «подписание» заключается в приемке работающего и протестированного ПО, полученного на данной итерации. Commonly on agile projects, the product owner publicly accepts or rejects the requirements for an iteration, which consist of a set of stories and their accompanying acceptance criteria and acceptance tests. The ultimate “sign-off” is acceptance of the working, tested software delivered from the iteration.
Как сказала консультант Нанетт Браун (Nanette Brown): «Даже в среде гибкой разработки принцип визирования может играть полезную роль. Гибкость говорит нам «полагаться на изменения», но сама концепция изменения существует только в связке с точкой отсчета. Даже в команде, где ее члены тесно общающихся друг с другом, у людей могут быть разные интерпретации текущих планов и состояния. Предложение об изменении, представленное на рассмотрение одним человеком, другой может посчитать уже согласованным. Однако если процедуру визирования считать как упрощенный церемониал признания, что «мы находимся на таком и таком этапе», то это нормально. Такое утверждение не означает, что завтра мы не можем быть в другом месте, но как минимум это обеспечивает взаимопонимание и общую точку отсчета». As consultant Nanette Brown put it, “Even in an agile environment the concept of sign-off can fill a valid function. Agile tells us to ‘embrace change,’ but the concept of change only exists with respect to a reference point. Even within a team where there is close communication, people can have different interpretations of current plans and status. One person’s ‘change’ can be what another person thought was already agreed to. However, if you position a sign-off as a lightweight ceremony acknowledging that ‘We are Here’ I think it’s fine. Just because ‘We are Here’ today doesn’t mean we can’t be somewhere else tomorrow, but at least it ensures a common understanding and point of reference.”

3. Рекомендуемые приемы формулирования требований

«Добро пожаловать в команду, Сара, — сказала менеджер проекта Кристин. — Мы очень надеемся, что ты поможешь нам с требованиями в этом проекте. Я так понимаю, что на предыдущем месте ты работала бизнес-аналитиком. Есть ли у тебя идеи насчет того, с чего надо начать?» “Welcome to the group, Sarah,” said the project manager, Kristin. “We’re looking forward to having you help us with the requirements for this project. I understand that you were a business analyst in your previous job. Do you have some idea of how we should get started here?”
«Ну, — ответила Сара, — Я планировала проинтервьюировать ряд пользователей и узнать, что они хотят. После этого я запишу то, что они мне сообщат. Этого будет достаточно для начала работы разработчиков. В основном мы именно так и поступали ранее. Вы не подскажете, с какими пользователями я могла бы поговорить?» “Well,” Sarah replied, “I was thinking I should just interview some users and see what they want. Then I’ll write up what they tell me. That should give the developers a good place to start. That’s mostly what we did before. Do you know some users I could talk to?”
«Хм, ты действительно считаешь, что этого будет достаточно для проекта такого типа?» — спросила Кристин. — Мы пробовали такой подход ранее, но он оказался не очень хорошим. Я надеялась, что у тебя есть какие-то идеи насчет удачных приемов с предыдущих мест работы, которые окажутся лучше, чем просто интервьюирование нескольких пользователей. Если ли какие-то приемы, которые ты нашла особенно полезными?» “Hmmm. Do you think that will be good enough for this type of project?” Kristin asked. “We tried that approach before, but it didn’t work out very well. I was hoping you might have some ideas about best practices from your past BA experiences that might be better than just interviewing a couple of users. Are there any particular techniques that you’ve found to be especially helpful?”
Сара смешалась: «Я не знаю других способов работы с требованиями кроме разговора с пользователями и попыткой записать четкие спецификации на основе сказанного ими. На своем предыдущем рабочем месте я прикладывала максимум усилий и использовала свои знания и навыки бизнеса. Я посмотрю, что можно сделать». Sarah was rather at a loss. “I don’t really know about any specific ways to approach requirements other than talking to users and trying to write clear specifications from what they say. At my last job I just did the best I could based on my business experience. Let me see what I can find out.”
Каждому специалисту по ПО нужно завести набор приемов, которые он может использовать для решения задач, возникающих в процессе проекта. Практик, у которого нет такого набора, вынужден изобретать подходы, исходя из разумного выбора на той или иной стадии. Такие спонтанные методы редко дают хорошие результаты. Некоторые люди пропагандируют методологии разработки ПО — пакеты методик, которые, как ожидается, предоставляют собой целостный набор решений проблем, возникающих в процессе реализации проекта. Однако простое следование инструкции — стандартному процессу, который, как предполагается, работает в любой ситуации — тоже не всегда дает отличные результаты. Мы считаем, что более эффективно определять и применять рекомендуемые в отрасли приемы. Подход на основе рекомендуемых приемов позволяет создать набор различных методик, которые применимы к решению самых разных проблем. Every software professional needs to acquire a tool kit of techniques she can use to approach each project challenge. A practitioner who lacks such a tool kit is forced to invent an approach based on whatever seems reasonable at the moment. Such ad hoc methods rarely yield great results. Some people advocate for specific software development methodologies, packaged sets of techniques that purport to provide holistic solutions to your project challenges. However, simply following a script—a standard process that’s supposed to work in every situation—doesn’t work very well, either. We find it more effective to identify and apply industry best practices. The best-practice approach stocks your software tool kit with a variety of techniques you can apply to diverse problems.
Понятие рекомендаций довольно спорно: кто решает, что лучше, и на каком основании? Можно создать группу экспертов или исследователей и проанализировать проекты различных организаций. Таким образом экспертам удастся выявить приемы, которые обычно эффективно применялись в успешных проектах, а в неудачных — показали себя плохо или не применялись вообще. В процессе работы эксперты согласованно определяют, какие действия неизменно дают превосходный результат; обычно их называют рекомендуемыми приемами (best practices). The notion of best practices is debatable: who decides what is “best” and on what basis? One approach is to convene a body of industry experts to analyze projects from many organizations. These experts seek out practices whose effective performance is associated with successful projects and which are performed poorly or not at all on failed projects. Through these means, the experts reach consensus on the activities that consistently yield superior results and label them best practices.
Табл. 3-1. Приемы формулирования требований TABLE 3-1 Requirements engineering good practices
I. Сбор информации Elicitation
01. Определите концепцию продукта и границы проекта Define vision and scope
02. Определите классы пользователей Identify user classes
03. Выделите из пользователей ярых сторонников продукта Select product champions
04. Создайте фокус-группы Conduct focus groups
05. Определите пользовательские требования Identify user requirements
06. Определите системные события и реакцию на них Identify system events and responses
07. Проведите интервью для выявления требований Hold elicitation interviews
08. Проведите семинары по выявлению требований Hold facilitated elicitation workshops
09. Наблюдайте за пользователями на рабочих местах Observe users performing their jobs
10. Раздайте опросные листы Distribute questionnaires
11. Выполните анализ документов Perform document analysis
12. Изучите отчеты о проблемах Examine problem reports
13. Повторно задействуйте существующие требования Reuse existing requirements
II. Анализ Analysis
14. Смоделируйте среду приложения Model the application environment
15. Создайте прототипы Create prototypes
16. Проанализируйте осуществимость Analyze feasibility
17. Расставьте приоритеты для требований Prioritize requirements
18. Создайте словарь данных Create a data dictionary
19. Смоделируйте требования Model the requirements
20. Проанализируйте интерфейсы Analyze interfaces
21. Распределите требования по подсистемам Allocate requirements to subsystems
III. Спецификации Specification
22. Используйте шаблон спецификации требований Adopt requirement document templates
23. Определите источники требований Identify requirement origins
24. Задайте каждому требованию уникальный идентификатор Uniquely label each requirement
25. Задокументируйте бизнес-правила Record business rules
26. Определите атрибуты качества Specify nonfunctional requirements
IV. Проверка Validation
27. Изучите документы с требованиями Review the requirements
28. Протестируйте требования Test the requirements
29. Определите критерии приемлемости Define acceptance criteria
30. Смоделируйте требования Simulate the requirements
V. Управление требованиями Requirements management
31. Определите процесс управления изменениями Establish a change control process
32. Проанализируйте, какое влияние оказывают изменения Perform change impact analysis
33. Определите базовую и контрольную версии наборов требований Establish baselines and control versions of requirements sets
34. Отслеживайте хронологию изменений Maintain change history
35. Отслеживайте состояние требований Track requirements status
36. Отcлеживайте проблемы с требованиями Track requirements issues
37. Создайте матрицу связей требований Maintain a requirements traceability matrix
38. Используйте средство управления требованиями Use a requirements management tool
VI. Обучение Knowledge
39. Обучите аналитиков требований Train business analysts
40. Ознакомьте представителей пользователей и менеджеров с требованиями Educate stakeholders about requirements
41. Обучите разработчиков основам предметной области Educate developers about application domain
42. Определите процесс разработки требований Define a requirements engineering process
43. Создайте словарь терминов Create a glossary
VII. Управление проектом Project management
44. Выберите соответствующий цикл разработки проекта Select an appropriate life cycle
45. Планируйте подход к работе с требованиями Plan requirements approach
46. Оцените объем работ по реализации требований Estimate requirements effort
47. Планируйте на основании требований Base plans on requirements
48. Определите лиц, ответственных за принятие решений по требованиям Identify requirements decision makers
49. Своевременно пересматривайте обязательства Renegotiate commitments
50. Управляйте рисками, касающимися требований Manage requirements risks
51. Отслеживайте объем работ по реализации требований Track requirements effort
52. Делайте выводы из полученного опыта Review past lessons learned
В табл. 3-1 перечислено приблизительно 50 приемов; они разделены на 7 категорий. Некоторые приемы относятся к нескольким категориям, но в таблице они указаны только один раз. Большинство этих приемов способствуют более эффективной коммуникации между заинтересованными лицами проекта. Заметьте: глава называется «Рекомендуемые приемы формулирования требований», а не «Лучшие приемы». Сомневаюсь, что когда-либо будет проведена систематическая оценка всех их на предмет выбора лучшего. Тем не менее, многие практики, и я в том числе, считают данные приемы эффективными. Table 3-1 lists more than 50 practices, grouped into 7 categories, that can help all development teams do a better job on their requirements activities. Several of the practices contribute to more than one category, but each practice appears only once in the table. Most of these practices contribute to more effective communication among project stakeholders. Note that this chapter is titled “Good practices for requirements engineering,” not “Best practices.” It’s doubtful whether all of these practices will ever be systematically evaluated for this purpose. Nonetheless, many other practitioners have found these techniques to be effective.
В этой части кратко описывается каждый прием, а также указываются ссылки на другие главы и источники. Приемы годятся не для всех ситуаций, и поэтому стоит не слепо следовать сценарию, а руководствоваться трезвым расчетом, здравым смыслом и опытом. Даже самые лучшие приемы должны вдумчиво отбираться, применяться и внедряться в соответствующих ситуациях опытным аналитиком. Различные приемы могут подходить для понимания требований в разных частях проекта. Например, варианты использования системы и прототипы пользовательских интерфейсов могут пригодиться на стороне клиента, а на стороне сервера важнее анализ интерфейсов. This part describes each good practice briefly and provides references to other chapters in this book or to other sources where you can learn more about the technique. These practices aren’t suitable for every situation, so use good judgment, common sense, and experience. Even the best practices need to be selected, applied, and adapted thoughtfully to appropriate situations by skilled business analysts. Different practices might be most appropriate for understanding the requirements for different portions of a given project. Use cases and user interface prototypes might help for the client side, whereas interface analysis is more valuable on the server side, for example.
Люди, которые применяют или играют ведущую роль в применении этих приемов, разные в разных приемах и проектах. Аналитик будет играть ключевую роль во многих из них, но не в каждом проекте есть аналитик. Заказчик продукта может применить один из приемов в проекте гибкой разработки (agile). Но другие приемы относятся к сфере ответственности менеджера проекта. Подумайте, кто в вашей текущей команде будет играть ведущую роль или участвовать в применении приемов, которые вы выбрали для следующего проекта. The people who perform or take a lead role in these practices will vary from practice to practice and from project to project. The business analyst (BA) will play a major role with many of them, but not every project has a BA. The product owner could perform some of the practices on an agile project. Still other practices are the purview of the project manager. Think about who the right people in your team are to lead or participate in the practices you select for your next project.
Внимание!
Ни один из этих приемов не будет работать, если вы имеете дело с неблагоразумными людьми. Клиенты, менеджеры и специалисты по ИТ иногда бывают недоговороспособными, но может оказаться, что они просто недостаточно информированы. Они могут не знать, почему вы хотите применить те или иные приемы, или чувствовать себя неуютно с незнакомыми терминами и действиями. Попробуйте просветить своих коллег насчет своих приемов и почему вы хотите применить именно их, а также почему для их же собственного блага стоит сотрудничать с остальными членами команды.
Important
None of these techniques will work if you’re dealing with unreasonable people. Customers, managers, and IT people sometimes appear to be unreasonable, but perhaps they are just uninformed. They might not know why you want to use certain practices and could be uncomfortable with unfamiliar terms and activities. Try educating your collaborators about the practices, why you want to use them, and why it is important to their own goals to cooperate.

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

Каркас процесса создания требований A requirements development process framework
Как мы уже прояснили раньше, разработка требований состоит из выявления, анализа, документирования и проверки. Не ждите, что все действия удастся выполнить последовательно и за один проход. На практике эти действия выполняются попеременно, поэтапно и повторяются (рис. 3-1). «Поступательная очистка деталей» — вот, что должно быть основным девизом при разработке требований и переходе от начальных концепций к более точному пониманию и выражению. As we discussed before, requirements development involves elicitation, analysis, specification, and validation. Don’t expect to perform these activities in a simple linear, one-pass sequence, though. In practice, these activities are interwoven, incremental, and iterative, as shown in Figure 3-1. “Progressive refinement of detail” is a key operating phrase for requirements development, moving from initial concepts of what is needed toward further precision of understanding and expression.
Рис. 3-1. Итеративный процесс формулирования требований FIGURE 3-1 Requirements development is an iterative process.
Будучи аналитиком, вы будете задавать клиентам вопросы, слушать их ответы и наблюдать, что они делают (этап выявления требований). Вы обработаете эту информацию и разберетесь в ней, классифицируете ее на разные категории и свяжете потребности клиента с возможными программными требованиями (этап анализа). В результате анализа может оказаться, что нужно уточнить некоторые требования, поэтому вы возвращаетесь назад и дополняете набор требований. После этого вы структурируете информацию от пользователей и выведенные требования в виде письменных требований — утверждений и диаграмм (спецификация). При письменной фиксации может потребоваться вернуться назад и выполнить дополнительный анализ, чтобы закрыть пробелы в знаниях. Затем вы просите ряд заинтересованных лиц подтвердить, что представленное вами точно и полно отражает потребности, и исправить ошибки (проверка). Это выполняется по отношению к набору требований, которые важнее и своевременнее всего для начала разработки ПО. В процессе проверки может потребоваться переписать некоторые неясные требования, повторить некоторые действия анализа или даже вернуться и выполнить дополнительное выявление требований. После этого вы переходите к следующему этапу проекта и весь цикл повторяется. Такой итеративный процесс продолжается на всем протяжении разработки требований и возможно — как в проектах гибкой разработки — на протяжении всего времени проекта. If you’re the BA, you’ll be asking customers questions, listening to what they say, and watching what they do (elicitation). You’ll process this information to understand it, classify it in various categories, and relate the customer needs to possible software requirements (analysis). Your analysis might lead you to realize that you need to clarify some requirements, so you go back and do more elicitation. You’ll then structure the customer input and derived requirements as written requirement statements and diagrams (specification). While writing requirements, you might need to go back and do some additional analysis to close gaps in your knowledge. Next, you’ll ask some stakeholders to confirm that what you’ve captured is accurate and complete and to correct any errors (validation). You’ll do all this for the set of requirements that are most important and most timely for beginning software development. Validation could lead you to rewrite some unclear requirements, revisit some of your analysis activities, or even have to go back and perform additional elicitation. Then you’ll move on to the next portion of the project and do it all again. This iterative process continues throughout requirements development and possibly—as with agile projects—throughout the full project duration.
Из-за разнообразия проектов по разработке ПО и организационных культур единого, шаблонного подхода к созданию требований не существует. На рис. 3-2 показан каркас создания требований, который с разумными исправлениями подойдет для большинства проектов. Предшественником процесса показанного на рис. 3-2 является бизнес-потребность или рыночная возможность. Как правило, действия выполняются в основном по порядку, однако сам процесс не является строго последовательным. Первые семь действий обычно однократно выполняются на ранних стадиях работы над проектом (тем не менее, команде разработчиков придется периодически проверять эти действия). Остальные необходимы для каждого очередного выпуска или этапа работы над проектом. Многие из этих действий могут выполняться итеративно и попеременно. Например, шаги 8, 9 и 10 можно выполнять небольшими порциями, выполняя пересмотр (шаг 12) после каждой итерации. Because of the diversity of software development projects and organizational cultures, there is no single, formulaic approach to requirements development. Figure 3-2 suggests a process framework for requirements development that will work, with sensible adjustments, for many projects. The business need or market opportunity is the predecessor for the process shown in Figure 3-2. These steps are generally performed approximately in numerical sequence, but the process is not strictly sequential. The first seven steps are typically performed once early in the project (although the team will need to revisit all of these activities periodically). The remaining steps are performed for each release or development iteration. Many of these activities can be performed iteratively, and they can be interwoven. For instance, you can perform steps 8, 9, and 10 in small chunks, performing a review (step 12) after each iteration.
Рис. 3-2. Примерный процесс создания требований FIGURE 3-2 A representative requirements development process.
Пятый подраздел разработки требований — управление требованиями. К управлению требованиями относятся приемы работы с уже готовыми требованиями. Эти приемы включают управление версиями и определение базовых требований, управление изменениями, отслеживание состояния требований и отслеживание связей требований с другими элементами системы. Управление требованиями — это деятельность низкой интенсивности, происходящая на всем протяжении проекта. The fifth subdiscipline of requirements engineering is requirements management. Requirements management encompasses practices that help you deal with requirements after you have them in hand. These practices include version control and baselining, change control, tracking requirements status, and tracing requirements to other system elements. Requirements management will take place throughout the project’s duration at a low level of intensity.
На рис. 3-3 показано, как распределяются работы по созданию требований по этапам разработки продукта в жизненном цикле ПО общего вида. Общий объем работ по работе с требованиям может быть практически таким же, как и в проектах сравнимого размера с другими жизненными циклами, но распределение работ по времени может сильно отличаться. В чистом водопадном цикле планируется только один основной выпуск, поэтому основной объем работы с требованиями приходится на начало проекта (сплошная линия на рис. 3-3). Такой подход используется в очень многих проектах, но подходит для немногих. Но даже если вы спланируете традиционный этап «выявления требований» в начале проекта, после чего требования используются для проектирования, нужно рассчитывать на выполнение небольшого объема работ с требованиями на протяжении всего проекта. Figure 3-3 illustrates how some common software development life cycles allocate requirements effort across the product development period. The total requirements effort might not be much different for projects of comparable size that follow different life cycles, but the timing distribution of requirements work is very different. In the pure waterfall life cycle, you plan to do only one major release, so most of the requirements development effort is allocated for the beginning of the project (the solid line in Figure 3-3). This approach is still used on quite a few projects, and it is appropriate for some. But even if you plan a traditional “requirements phase” at the beginning of the project that then leads into design, you can count on having to do some additional requirements work throughout the project.
Рис. 3-3. Распределение работ с требованиями на протяжении жизненного цикла проекта в разных моделях разработки FIGURE 3-3 The distribution of requirements development effort over time varies for projects that follow different development life cycles.
В проектах, в которых используется итеративный процесс разработки, такой как Rational Unified Process, работа с требованиями ведется в каждой итерации процесса разработки, причем на первую итерацию приходится больший объем работы (пунктирная линия на рис. 3-3). Это же происходит, если вы запланировали серию поэтапных выпусков, в каждом из которых предоставляется значительная часть конечной функциональности продукта. Projects that follow an iterative development process, such as the Rational Unified Process, will work on requirements on every iteration through the development process, with a heavier emphasis in the first iteration (the dashed line in Figure 3-3). This is also the case if you are planning a series of phased releases, each of which delivers a significant fraction of the product’s ultimate functionality.
В проектах гибкой разработки (agile) планируется выпускать функциональность каждые несколько недель. В таких проектах работа над требованиями выполняется часто, но небольшими объемам, как показано на рис. 3-3 точечной линией. Работа начинается с выявления пользовательских требований в форме пользовательских историй, которые описывают основные задачи, которые пользователи хотят решить с помощью системы. В этом подходе из историй нужно извлечь достаточно информации, чтобы можно было оценить объем и определить приоритеты разработки. Приоритизация пользовательских требований позволяет определить, какие из них назначить на те или иные этапы разработки, которые называются итерациями или спринтами. Более подробно выделенные на ту или иную итерацию требования изучаются, когда разработка подойдет к этой итерации. Agile and other incremental development projects aim to release functionality every few weeks. They will have frequent but small requirements development efforts, as shown with the dotted line in Figure 3-3. Such projects begin by doing a first cut at collecting user requirements in the form of simple user stories that describe major objectives the user wants to accomplish with the help of the system. In this approach, you need to learn enough about the stories so that you can estimate their development effort and prioritize them. Prioritizing these user requirements lets you determine which ones to allocate to specific development increments, called iterations or sprints. Those allocated requirements can be explored in further detail in a just-in-time fashion for each development cycle.
Независимо от используемой в проекте модели, надо при каждом выпуске или итерации задавать себе вопрос, какие из действий, описанных на рис. 3-2, позволят увеличить ценность и снизить риск. По завершении шага 17 для любой части требований можно приступать к построению соответствующей части системы. Повторите шаги с 8 по 17 со следующим набором требований, который ляжет в основу следующего выпуска или итерации. Regardless of the life cycle your project follows, you should ask yourself for each release or iteration which of the activities shown in Figure 3-2 will add value and reduce risk. After you have completed step 17 for any portion of the requirements, you’re ready to commence construction of that part of the system. Repeat steps 8 through 17 with the next set of user requirements, which will lay the foundation for the subsequent release or increment.

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

Выявление требований Good practices: Requirements elicitation
Ранее мы обсуждали три уровня требований: бизнес-уровень, пользовательский уровень и функциональный. Они собираются из разных источников на различных этапах работы над проектом, имеют различные цели и аудиторию и должны документироваться по-разному. Также следует выявить и собрать нефункциональные характеристики, например предполагаемое качество в разных измерениях, из соответствующих источников. Далее приводятся приемы, которые помогут собрать информацию требований самых разных типов. Previously we discussed the three levels of requirements: business, user, and functional. These come from different sources at different times during the project, have different audiences and purposes, and need to be documented in different ways. You also need to elicit nonfunctional requirements, such as quality expectations in various dimensions, from appropriate sources. Following are some practices that can help with eliciting the myriad types of requirements information.
Определение концепции продукта и границ проекта Define product vision and project scope
Документ о концепции и границах содержит бизнес-требования к продукту. Описание концепции позволяет всем заинтересованным лицам в общих чертах понять назначение продукта. Границы проекта определяют, что следует реализовать в этой версии, а что — в следующих. Концепция и границы — хорошая база для оценки предлагаемых требований. Концепция продукта должна оставаться от версии к версии относительно стабильной, но для каждого выпуска необходимо составить отдельный документ о границах. The vision and scope document contains the product’s business requirements. The vision statement gives all stakeholders a common understanding of the product’s outcome. The scope defines the boundary between what’s in and what’s out for a specific release or iteration. Together, the vision and scope provide a reference against which to evaluate proposed requirements. The vision should remain relatively stable throughout the project, but each planned release or iteration needs its own scope statement.
Определение классов пользователей и их характеристик Identify user classes and their characteristics
Чтобы не упустить из виду потребности отдельных пользователей, выделите их в группы. Например, по частоте работы с ПО, используемым функциям, уровню привилегий и опыту работы. Опишите их обязанности, местоположение и личные характеристики, способные повлиять на архитектуру продукта. Создайте архетипы пользователей — описания выдуманных людей, которые будут представлять конкретные классы пользователей. To avoid overlooking the needs of any user community, identify the various groups of users for your product. They might differ in frequency of use, features used, privilege levels, or experience. Describe aspects of their job tasks, attitudes, location, or personal characteristics that might influence product design. Create user personas, descriptions of imaginary people who will represent particular user classes.
Выбор сторонника продукта (product champion) в каждом классе пользователей Select a product champion for each user class
Это человек, который сможет точно передавать настроения и нужды клиентов. Он представляет потребности определенного класса пользователей и принимает решения от их лица. В случае разработки внутрикорпоративных информационных систем, когда все пользователи — ваши коллеги, такого человека выбрать проще. При коммерческой разработке порасспросите клиентов или используйте площадки бета-тестирования. Identify an individual who can accurately serve as the literal voice of the customer for each user class. The product champion presents the needs of the user class and makes decisions on its behalf. This is easiest for internal information systems development, where your users are fellow employees. For commercial product development, build on your current relationships with major customers or beta test sites to locate appropriate product champions.
Проведение фокус-групп типичных пользователей Conduct focus groups with typical users
Создайте группы типичных пользователей предыдущих версий вашего продукта или похожих. Выясните у них подробности функциональности и качественных характеристик разрабатываемого продукта. Фокус-группы особенно ценны при разработке коммерческих продуктов, когда приходится иметь дело с большой и разнородной клиентской базой. В отличие от сторонников продукта, у фокус- групп обычно нет полномочий на принятие решений. Convene groups of representative users of your previous products or of similar products. Collect their input on both functionality and quality characteristics for the product under development. Focus groups are particularly valuable for commercial product development, for which you might have a large and diverse customer base. Unlike product champions, focus groups generally do not have decision-making authority.
Работа с пользователями для выяснения назначения продукта Work with user representatives to identify user requirements
Выясните у представителей пользователей, какие задачи им требуется выполнять средствами ПО и какую пользу они хотят из него извлечь. Пользовательские требования могут выражаться в форме сценариев использования, задач или пользовательских историй. Обсудите то, каким образом клиент должен взаимодействовать с системой для выполнения каждой такой задачи. Explore with your user representatives the tasks they need to accomplish with the software and the value they’re trying to achieve. User requirements can be expressed in the form of use cases, user stories, or scenarios. Discuss the interactions between the users and the system that will allow them to complete each task.
Определение системных событий и реакции на них Identify system events and responses
Перечислите возможные внешние события и ожидаемую реакцию системы на них. Существует три класса внешних событий. Это могут быть сигналы и данные, получаемые от внешнего оборудования. Есть также временные или основанные на времени события, вызывающие ответную реакцию, например ежевечерняя передача данных во внешний канал данных, инициируемая системой ежевечернее в одно и то же время. В бизнес-приложениях бизнес-события напрямую инициируют выполнение бизнес-задач. List the external events that the system can experience and its expected response to each event. There are three classes of external events. Signal events are control signals or data received from external hardware devices. Temporal, or time-based, events trigger a response, such as an external data feed that your system generates at the same time every night. Business events trigger use cases in business applications.
Проведение интервью для выявления требований Hold elicitation interviews
Интервью можно проводить в формате «один на один» или с небольшой группой заинтересованных лиц. Это эффективный способ выявления требований без слишком большого отвлечения заинтересованного лица от его работы, потому на таких встречах обсуждаются только конкретные требования, имеющие значение для интервьюируемого заинтересованного лица. Интервью полезны для раздельного выявления требований у людей при подготовке к семинарам, где они встречаются для разрешения возможных конфликтов. Interviews can be performed one-on-one or with a small group of stakeholders. They are an effective way to elicit requirements without taking too much stakeholder time because you meet with people to discuss only the specific requirements that are important to them. Interviews are helpful to separately elicit requirements from people in preparation for workshops where those people come together to resolve any conflicts.
Проведение совместных семинаров Hold facilitated elicitation workshops
Совместные семинары по выявлению требований, где тесно сотрудничают аналитики и клиенты — отличный способ выявить нужды пользователей и составить наброски документов с требованиями. Такие семинары иногда называют JAD-семинарами. Facilitated requirements-elicitation workshops that permit collaboration between analysts and customers are a powerful way to explore user needs and to draft requirements documents. Such workshops are sometimes called Joint Application Design, or JAD, sessions.
Наблюдение за пользователями на рабочих местах Observe users performing their jobs
Наблюдая за работой пользователей, выявляют контекст возможного применения нового продукта. Простые диаграммы рабочих потоков, а также диаграммы потоков данных позволяют выяснить этапы и принимаемые решения, а также то, как взаимодействуют различные группы пользователей. Документируя ход бизнес- процесса, удается определить требования к системе, рассчитанной на поддержку этого процесса. Watching users perform their business tasks establishes a context for their potential use of a new application. Simple process flow diagrams can depict the steps and decisions involved and show how different user groups interact. Documenting the business process flow will help you identify requirements for a solution that’s intended to support that process.
Раздача опросных листов Distribute questionnaires
Это один из способов определения потребностей больших групп пользователей. Опросные листы удобны при работе с любыми большими группами пользователей, но особенно полезны в распределенных группах. Качественные вопросы позволяют быстро выявить аналитическую информацию о потребностях. На основе результатов опросных листов можно более целенаправленно применять дополнительные усилия. Questionnaires are a way to survey large groups of users to determine what they need. Questionnaires are useful with any large user population but are particularly helpful with distributed groups. If questions are well written, questionnaires can help you quickly determine analytical information about needs. Additional elicitation efforts can then be focused according to the questionnaire results.
Анализ документов Perform document analysis
Имеющаяся документация может помочь выявить, как системы работают сейчас или что они должны делать. К документации относится вся письменная информация о текущих системах и бизнес-процессах, спецификации требований, исследования конкурентов и руководства имеющихся коммерческих программных пакетов. Просмотр и анализ этих документов может помочь выявить функциональность, которая должна остаться и которая больше не нужна, а также определить, как сейчас люди выполняют свою работу, что предлагают конкуренты и что говорят поставщики о том, что должно делать их ПО. Existing documentation can help reveal how systems currently work or what they are supposed to do. Documentation includes any written information about current systems, business processes, requirements specifications, competitor research, and COTS (commercial off-the-shelf) package user manuals. Reviewing and analyzing the documents can help identify functionality that needs to remain, functionality that isn’t used, how people do their jobs currently, what competitors offer, and what vendors say their software should do.
Изучение отчетов о проблемах работающих систем с целью поиска новых идей Examine problem reports of current systems for requirement ideas
Поступающие от клиентов отчеты о проблемах и предложения о расширении функциональности — отличный источник идей о возможностях, которые можно реализовать в следующей версии или новом продукте. За подобной информацией стоит обратиться к персоналу службы поддержки. Problem reports and enhancement requests from users provide a rich source of ideas for capabilities to include in a later release or in a new product. Help desk and support staff can provide valuable input into the requirements for future development work.
Повторное использование требований Reuse existing requirements
Если необходимая клиенту функциональность аналогична уже реализованной в другом продукте, подумайте, готовы ли клиенты гибко пересмотреть свои требования для использования существующих компонентов. Требования, соответствующие бизнес-правилам компании, можно применить в нескольких проектах, например требования к безопасности, определяющие порядок доступа к приложениям, и требования, соответствующие требованиям государственных органов, например Закону о гражданах США с ограниченными возможностями (Americans with Disabilities Act). К другим кандидатам на повторное использование относятся глоссарии, модели и определения данных, профили заинтересованных лиц, описаний классов и архетипы пользователей. If customers request functionality similar to that already present in an existing product, see whether the requirements (and the customers!) are flexible enough to permit reusing or adapting the existing software components. Projects often can reuse those requirements that comply with an organization’s business rules, such as security requirements, and requirements that conform to government regulations, such as accessibility requirements. Other good candidates for reuse include glossaries, data models and definitions, stakeholder profiles, user class descriptions, and personas.

Материалы обработал: admin