Право № 1. Иметь дело с аналитиком, что говорит на вашем языке
При дискуссии требований направляться узнать задачи и потребности вашего бизнеса, применяя наряду с этим принятую в вашем бизнесе терминологию. Вынудите аналитиков сказать с вами на вашем языке (быть может, для этого им направляться дать маленький словарь), не продирайтесь в беседах с ними через компьютерный жаргон.
Право № 2. Иметь дело с аналитиком, что изучил цели и ваш бизнес
Выявляя требования, аналитики смогут лучше осознать задачи вашего бизнеса и понять, какое место уготовано создаваемому ПО в вашем бизнесе. Это окажет помощь им удовлетворить ваши ожидания. Пригласите аналитиков и разработчиков к себе в офис. В случае, если заказанная совокупность заменит существующее приложение, предложите разработчикам поработать с ним. Так, им будет легче осознать его сильные и не сильный стороны да и то, как его возможно усовершенствовать.
Право № 3. настойчиво попросить, дабы аналитик преобразовал требования, предоставленные вами устно, в письменную спецификацию требований к ПО
Аналитик упорядочит все данные, предоставленную вами и другими клиентами, и распознает на базе бизнес-требований, бизнес-правил, функциональных требований, целей качества, прочих элементов и возможных решений область применения. Конечный результат этого анализа — спецификация требований к ПО (software requirements specification, SRS), воображающая собой соглашение между клиентами и разработчиками о функциях, ограничениях и качестве создаваемого продукта. Она должна быть организована и написана так, дабы вы ее легко осознали. В случае, если вам что-то не нравиться, выскажите собственный мнение: документ обязан совершенно верно и полно отражать чаяния и ваши нужды.
Право № 4. Взять подробный отчет обо всех рабочих продуктах, созданных в ходе формулирования требований
Аналитик может представить требования посредством разных диаграмм, дополняющих текст спецификации требований к ПО. В главе I рассматриваются пара моделей анализа. Другие представления требований крайне важны, потому, что время от времени графики разрешают яснее выразить кое-какие особенности по ведения совокупности, к примеру последовательность делаемых действий. И не смотря на то, что эти диаграммы смогут показаться непривычными, осознать их несложно. Попросите аналитика растолковать назначение каждой из них (и вторых продуктов, созданных в ходе формулирования требований), суть обозначений и процедуру проверки диаграмм на предмет неточностей.
Право № 5. На уважительное и опытное отношение к вам со разработчиков и стороны аналитиков
В случае, если разработчики и клиенты не знают друг друга, обсуждение требований может обернуться громадным разочарованием. Совместная работа разрешает открыть друг другу глаза на неприятности, с которым сталкивается любая из этих групп. Клиенты, участвующие в ходе выработки требований, имеют полное право потребовать от разработчиков и аналитиков уважительного отношения к себе и бережного отношения к затраченному времени. Со своей стороны, и клиентам направляться оказывать уважение разработчикам, поскольку они дружно сотрудничают с целью достижения неспециализированной цели — успешного проекта.
Право № 6. Знать о вариантах и их реализации и альтернативах требований
Дабы обеспечивать, что новая совокупность не будет автоматизировать неэффективные либо устаревшие процессы, аналитик обязан знать, по какой причине существующие совокупности не годятся для ваших бизнес-процессов. Аналитики, основательно разбирающиеся в предметной области бизнеса, время от времени предлагают те либо иные усовершенствования ваших бизнес-процессов. Нужен и аналитик, творчески подходящий к делу: он предлагает новые возможности программы, о которых пользователи кроме того и не грезили.
Право № 7. Обрисовать характеристики, упрощающие работу с продуктом
В полной мере возможно, что аналитики спросят вас о чертях ПО, выходящих за рамки функциональных потребностей пользователей. Благодаря им программный продукт делается более эргономичным в работе, что разрешает клиентам действеннее делать их задачи. Время от времени пользователи просят, дабы продукт был дружественным, надежным либо действенным, но эти термины через чур субъективны, дабы оказать помощь разработчикам. Исходя из этого аналитик обязан узнать конкретные характеристики, означающие для вас дружественность, надежность либо эффективность. Подробнее — в главе 12.
Право № 8. Поменять требования либо дать добро применение имеющихся программных компонентов
Отношение к требованиям должны быть эластичными. Аналитику смогут быть известны готовые программные компоненты, каковые полностью удовлетворят кое-какие названные вами потребности. При таких условиях вам направляться скорректировать отдельные требования, дабы разработчики имели возможность применять имеющееся ПО. Разумные возможности применения существующих модулей сэкономит ваши деньги и время. Если вы посчитаете разумным включить в собственный продукт готовые коммерческие компоненты, готовься показать гибкость, потому, что характеристики таких компонентов врядли будут совершенно верно соответствовать вашим потребностям.
Право № 9. Взять исчерпывающие сведения о сумме затрат, ожидаемом необходимых компромиссах и эффекте, каковые появляются в связи с трансформациями в ПО
Зная, что один вариант дороже другого, различные люди делают различный выбор. Для принятия верных бизнес-ответов нужны информацию об стоимости и эффективности предполагаемого трансформации требований. У вас имеется право ожидать от аналитиков добросовестной оценки результата, компромиссов и затрат. Разработчики не должны завышать предполагаемую цена трансформации лишь по причине того, что не желают его реализовывать.
Право № 10. настойчиво попросить, дабы совокупность качеством и функциональностью удовлетворяла требования клиента
Для того чтобы завершения проекта хотят все, но он вероятен, лишь если вы сумеете донести до разработчиков все данные, которая окажет помощь им создать подходящий продукт, и в случае, если разработчики четко изложат вам все ограничения и варианты. Убедитесь, что вы высказали все предположения и свои ожидания; в другом случае программисты, вероятнее, не смогут реализовать их.