Итак, вы хотите быть Аналитиком требований?

Ключевой посредник

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

Аналитик требований — это проектная роль, а не обязательно название должности. Её могут исполнять один и более выделенных специалистов, либо она может быть назначена любому количеству членов команды: менеджеру проекта, менеджеру продукта, эксперту предметной области, разработчику или даже пользователю. Тем не менее, талантливый аналитик может многое определить в успехе или провале проекта. В своей книге «Оценка Стоимости ПО с помощью модели COCOMO II» Барри Боэм (Barry Boehm) отмечает, что зрелые аналитики могут снизить объём требуемых для реализации проекта усилий на одну треть по сравнению со схожими проектами с участием неопытных аналитиков, а проекты с высококлассными аналитиками в 2 раза менее затратны по сравнению с теми, в которых работают наименее компетентные аналитики.

Задачи аналитика

Выстраивая мост между расплывчатыми идеями заказчика и чёткими детальными требованиями, которые будут направлять работу команды, аналитик должен сначала понять цели пользователей относительно новой системы и задать такие требования к функциональности и качеству, которые позволят менеджерами проекта оценить, разработчикам — спроектировать и построить, а тестировщикам — удостовериться в соответствии продукта этим требованиям. Вы можете загрузить обобщённое описание должностных обязанностей аналитика требований по адресу http://www.processimpact.com/goodies.shtml. Вот типичные виды деятельности, которые вы будете выполнять, играя в маске аналитика.

Определяйте бизнес-нужды. Ваша работа начинается с помощи бизнес-спонсору или менеджеру продукта в определении опорных бизнес-требований. Первый вопрос, который нужно задать, это «Зачем мы начинаем этот проект?» Бизнес-требования включают утверждения о бизнес-целях организации и конечное видение того, чем будет являться система и что она будет делать. Работая с людьми, которые обладают этим видением, вы поможете им его выразить, заполняя шаблон Документа об Образе и Границах продукта (Концепции продукта). Образец можно взять здесь: www.processimpact.com/goodies.shtml

Установите Заинтересованных лиц проекта и выделите Классы пользователей.

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

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

{Рисунок 1.} Аналитик требований выстраивает общение между заинтересованными лицами со стороны заказчика и разработки.

представители пользователя, другие заинтересованные лица, тестирование, управление проектом, спонсор проекта, Аналитик Требований, бизнес-требования, данные о сложности и объёме, ожидания и ограничения, функциональные и нефункциональные требования

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

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

Напишите спецификацию. Эффективная разработка требований приводит к общему пониманию и созданию системы, которая решает проблему заказчика. Вы отвечаете за написание хорошо-структурированных спецификаций, которые ясно выражают это общее понимание. Задействование стандартных шаблонов для описания способов применения и SRS ускоряет разработку требований, напоминая вам о темах, которые вам необходимо обсудить с пользователями. Несколько шаблонов вы можете найти по адресу: www.processimpact.com/goodies.shtml

Смоделируйте требования. Вам будет необходимо определиться, когда действительно полезно представлять требования на нетекстовом носителе, включая графические аналитические модели, таблицы, математические уравнения, раскадровки и прототипы. Аналитические модели отображают информацию на более высоком уровне абстракции, чем это делает текст. Для наибольшей передачи и ясности, рисуйте аналитические модели в соответствии с соглашениями стандартных нотаций, таких как Унифицированный Язык Моделирования (UML).

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

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

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

Коммуникационные навыки

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

1. Listening. Active listening involves eliminating distractions, maintaining an attentive posture and eye contact, and restating key points to confirm your understanding. You need to grasp what people are saying and also to read between the lines to detect what they might be hesitant to say. Learn how your collaborators prefer to communicate and try to avoid imposing your personal filter of understanding on what you hear the customers say. Watch for assumptions that underlie both what you hear from others and your own interpretation.

2. Interviewing and Questioning. Most requirements input comes through discussions, so an analyst must be able to ask the right questions. For example, users naturally focus on the system’s normal, expected behaviors. However, every programmer knows how much code is needed to handle exceptions. Ask questions such as, “What should happen if...?” or “Could <some problem> ever arise?” so you can determine how the system should handle anticipated exception conditions. With experience, you’ll become skilled in the art of asking questions that reveal and clarify uncertainties, disagreements, assumptions and unstated expectations. Donald Gause and Gerald Weinberg describe “context-free questions” in Exploring Requirements: Quality Before Design (Dorset House, 1989).

3. Analytical. You’ll need to be able to operate at various levels of abstraction. Sometimes you must drill down from high-level information into details. In other situations, you’ll need to generalize from a specific need that one user described to a set of requirements that pertain to a whole class of users. Critically evaluate the information gathered from multiple sources to reconcile conflicts, separate user wants from needs, and distinguish solution ideas from requirements.

4. Facilitation. Requirements elicitation workshops are a common technique; to succeed, they require a neutral facilitator. You’ll need strong questioning and observational skills to help groups build trust and to improve the sometimes tense relationship between business and information technology staff. In Requirements by Collaboration: Workshops for Defining Needs (Addison-Wesley, 2002), Ellen Gottesdiener provides a wealth of advice for the workshop facilitator.

5. Observation. If you conscientiously watch a user perform his job or put a current application through its paces, you can detect subtleties that the user might not mention and thus expose new areas for requirements discussion.

6. Writing. Your main deliverable will be a written specification for customers, marketing, managers and technical staff; for this task, you need a solid command of the English (or other natural) language. Strive for clarity; avoid ambiguous words and phrasing, grammatical errors and overly idiomatic expressions.

7. Organization. You’ll be faced with a vast array of jumbled information gathered during elicitation and analysis. Structuring all the rapidly changing bits into a coherent whole demands exceptional organizational skills, along with patience and tenacity.

8. Modeling. From the venerable flowchart through structured analysis models (data flow diagrams, entity-relationship diagrams and the like) to contemporary UML notations, diagrammatic tools should be included in every analyst’s kit. Some of these techniques will be useful when communicating with users; others, with developers. You’ll often need to educate other stakeholders on the value of these techniques and how to read them—and you’ll find that these tools are useful ways to represent information even when you’re not discussing a computer system.

9. Interpersonal. You must be able to get people with competing interests to work together, and you should feel comfortable talking with individuals in diverse job functions and at all levels of the organization. You might also need to work with distributed teams whose members are separated by geography, time zones, cultures or native languages.

. Whether you’re getting feedback from your boss or a client, having a proper perspective on criticism and a sound understanding of how to use it effectively is important.

Domain, Business and Task Knowledge

Enthusiasm alone won’t take you very far in requirements gathering; breadth of knowledge gained through experience is the only way to hone your ability. Start with a solid understanding of contemporary requirements-engineering techniques and how they fit in various software development lifecycles. Analysts need to know how to thread requirements development and

management activities through the entire product lifespan. A sound understanding of project management, risk management and quality engineering can help prevent requirements issues from torpedoing the project. In a commercial setting, you’ll benefit from knowledge of product management concepts and the way enterprise software products are positioned and developed.

Application domain knowledge is a powerful asset for an effective analyst, minimizing miscommunications with users. Analysts  who understand the application domain often detect unstated assumptions and implicit requirements. They can also suggest ways that users could improve their business processes. Such analysts sometimes propose valuable functionality that no user thought of. Conversely, they do a better job of detecting gold-plating—that is, excessive or unnecessary functionality—than does someone who’s unfamiliar with the problem domain.

Grown, Not Trained

There’s no standard educational curriculum or job description for a requirements analyst, which is why most come from diverse backgrounds. If you migrate into analysis from a career as a system user, you’ll need to balance your extensive knowledge of the business and work environment with supplemental training in software engineering and how to communicate with your technical counterparts. You’ll also have to work against any tendency to believe your user experience is all-encompassing, to focus excessively on the user interface, or to ignore input from real users of the new product. On the other hand, if you’re a former developer, you’ll need to beef up your understanding of the business domain and guard against lapses into technical thinking and jargon.

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

Врезка: Сбор данных

Попробуйте использовать следующие технологии для получения качественных требований

Интервью

Пакеты стандартных требований

Анализ документов

Обзоры

Статистика посещения сайта клиентами

Анализ бизнес-процессов

Анализ потока операций и задач

Список внешних событий и взаимосвязанных откликов системы

Сравнительный анализ продуктов

Ре-инжиниринг существующих систем

Ретроспективный взгляд на предыдущие проекты


-------------------------------------------------------------------------------
http://translated.by/you/so-you-want-to-be-a-requirements-analyst/into-ru/trans/
© 2003 by Karl E. Wiegers. All Rights Reserved
Оригинал (английский): So You Want to Be a Requirements Analyst? (http://www.processimpact.com/articles/be_analyst.pdf)
Перевод: © Денис, kamehb, tyler76.

translated.by переведено толпой