Том ДеМарко
Deadline. Роман об управлении проектами
 
 
Из записной книжки мистера Томпкинса

1. Если человек не чувствует, что находится в безопасности, он
будет противиться переменам.
2. Перемены необходимы руководителю для успешной работы
(наверняка они необходимы и в любой другой деятельности).
3. Неуверенность заставляет человека избегать риска.
4. Избегая риска, человек упускает все новые возможности и
выгоды, которые могли бы принести ему перемены.
5. Человека легко запугать прямыми угрозами, но также можно
просто дать ему понять, что при случае с ним могут обойтись грубо
и жестоко. Эффект будет таким же
 
[ Читать дальше → ]

из книги К.И.Вигерса " Разработка требований к ПО"

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

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

2 Подробно документируйте, на каких функциональных требованиях основаны требования к системе, варианты использования, списки откликов на события и бизнес-правила. Это позволит вам быть уверенным, что аналитик описал всю необходимую функциональность.

3 Для выявления недостающих требований проверяйте пограничные значения. Предположим, в одном требовании указано: Если стоимость заказа меньше $100, стоимость доставки будет равна $5,95", а в другом —  6 Если стоимость заказа превышает $100, стоимость доставки составляет 5% от общей стоимости заказа≫. А как быть, если стоимость заказа составляет ровно $100? Это не оговорено, значит, отсутствует соответствующее требование.

4 Используйте разнообразные формы представления информации о требованиях. Трудно прочитать большой объем текста и заметить, что чего-то не хватает. Модели анализа визуально представляют требования высокого уровня абстракции — лес, а не отдельные деревья. Рассматривая модель, вы можете заметить, что от одною блока к другому должна идти стрелка; это тоже недостающее требование. Подобного рода ошибку легче заметить на рисунке, чем в длинном списке требований, который сливается перед глазамию

1. Введение
1.1 Назначение
1.2 Соглашения, принятые документах
1.3 Предполагаемая аудитория и рекомендации по чтению
1.4 Границы проекта
1.5 Ссылки
2. Общее описание
2.1 Общий взгляд на продукт
2.2 Особенности продукта
2.3 Классы и характеристики пользователей
2.4 Операционная среда
2.5 Ограничения дизайна и реализации
2.6 Документация для пользователей
2.7 Предположения и зависимости
3. Функции системы
3.x Функция системы X
3.x. 1 Описание и приоритеты
З.х.2 Последовательности «воздействие - реакция»
З.х.3 Функциональные требования
4. Требования к внешнему интерфейсу
4.1 Интерфейсы пользователя
4.2 Интерфейсы оборудования
4.3 Интерфейсы ПО
4.4 Интерфейсы передачи информации
5. Другие нефункциональные требования
5.1 Требования к производительности
5.2 Требования к охране труда
5.3 Требования к безопасности
5.4 Атрибуты качества
6. Остальные требования
Приложение А. Словарь терминов
Приложение Б. Модели анализа
Приложение Г. Список вопросов

Как избежать ошибок.( из книги К.И.Вигерса " Разработка требований к ПО"

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

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

2 Подробно документируйте, на каких функциональных требованиях основаны требования к системе, варианты использования, списки откликов на события и бизнес-правила. Это позволит вам быть уверенным, что аналитик описал всю необходимую функциональность

3 Для выявления недостающих требований проверяйте пограничные значения. Предположим, в одном требовании указано: Если стоимость заказа меньше $100, стоимость доставки будет равна $5,95",

а в другом —  6 Если стоимость заказа превышает $100, стоимость доставки составляет 5% от общей стоимости заказа≫. А как быть, если стоимость заказа составляет ровно $100? Это не оговорено, значит, отсутствует соответствующее требование.

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

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

 

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

(Ferdinand, 2002). Основные факторы успеха — терпение и искреннее желание работать с людьми. Не менее важны и навыки, описанные далее.

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

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

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

пользователей необходимо задавать правильные вопросы. Например, пользователи обычно делают акцент на ожидаемом поведении системы. Тем не менее, значительная часть кода будет обрабатывать исключения, поэтому вам следует определить возможные условия ошибок и реакцию системы на них. По мере приобретения опыта вы научитесь задавать вопросы, которые раскрывают и проясняют неопределенности, расхождения во мнениях, предположения и невысказанные ожидания (Cause и Weinberg, 1989).

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

Навыки создания комфортных условий общения. Умение организовать дружескую атмосферу на семинарах для уточнения требований — один из необходимых навыков аналитика (Gottesdiener, 2002). Нейтральный наблюдатель, имеющий опыт опроса, наблюдения и создания комфортных условий общения, создаст доверительные отношения в группе и уменьшит напряженность в отношениях между бизнесменами и ИТ-сотрудниками.

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

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

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

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

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

мы сущность — связь и т.д.) и заканчивая современным языком UML (Unified Modeling Language, унифицированный язык моделирования), Некоторые из этих средств полезны при общении с пользователями, другие — с разработчиками. Аналитику следует объяснить другим участникам проекта ценность использования этих методов и то, как работать с их данными. В главе 11 дан обзор некоторых типов моделей анализа.

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

аналитикам зачастую приходится наставлять своих коллег-новичков и объяснять клиентам суть процессов создания требований и разработки ПО.

Творческий подход. Аналитик — не просто клерк, записывающий высказывания клиентов. Лучшие аналитики изобретают требования (Robertson, 2002). Они предлагают инновационные функции продуктов, новые рыночные возможности и возможности для бизнеса и думают, как удивить и удовлетворить своих клиентов. Отличный аналитик творчески подходит к делу: рассказывая о системе, ему удается удивить клиента — тот даже не всегда подозревает, что такая функциональность возможна.

 Из книги  Карла И. Вигерса    «Разработка требований к программному обеспечению»