Документирование требований. Уровни детализации требований
Модуль 2. Разработка требований к программному изделию
Тема 6
Требования к программному изделию
Понятие требований к программному изделию
Проблемы, которые приходится решать в процессе создания программного изделия, обычно очень сложны. В частности, необходимо достаточно четко описать те возможности, которые должны быть реализованы, и те условия и ограничения, с учетом которых эти возможности должны предоставляться. Такое описание функциональных возможностей создаваемого программного изделия и накладываемых ограничений называется требованиями к этому изделию.
Требования к программному изделию определяются с учетом потребностей пользователей и функционального назначения программного изделия. Отдельные требования могут быть независимыми друг от друга или связаны между собой.
Разработка требований – (requirements engineering) первый этап создания программного изделия. При этом предполагается, что у организации-заказчика уже существует четкое представление о том, зачем нужно создавать новое программное изделие (автоматизированную систему) и с какими другими изделиями (системами) оно должно взаимодействовать. Другими словами, у заказчика существует стратегия автоматизации предприятия в целом.
Разработка требований включает следующие виды работ:
1) сбортребований;
2) анализ требований;
3) документирование требований.
Значение тщательно обоснованных и полных требований нельзя недооценивать. Такая недооценка, особенно со стороны заказчика и пользователей, приводит к затягиванию сроков разработки и выпуску недоброкачественной продукции. При отсутствии четких требований разработчик делает то, что он хочет или может сделать, а не то, что надо заказчику. При реализации сложных программных изделий до 70 % всех возникающих проблем непосредственно связаны с несовершенством требований и только 30 % являются результатом ошибок в процессе разработки. Нечеткость и неполнота требований, нерешенные вопросы и ошибки, допущенные на этапе их разработки, порождают на последующих этапах создания программного изделия трудные, часто неразрешимые проблемы и, в конечном счете, приводят к неуспеху всей работы в целом.
Сбор требований
Сбор требований является основой всего процесса создания программного изделия. Первоначально сбор требований выполняют на этапе анализа автоматизируемого объекта, т.е. предприятия-заказчика и его отдельных подразделений. Затем требования могут уточняться на всех этапах жизненного цикла программного изделия.
Основными источниками требований являются:
- уже действующие на предприятии программные изделия, подлежащие совершенствованию, а если их нет, то коллектив, выполняющий функции, подлежащие автоматизации с учетом существующих документов, методик, стандартов и т.д.;
- представления будущих пользователей о новых возможностях, которые должны быть реализованы в новом программном изделии;
- известные программные изделия других предприятий.
Углубленное изучение нужд пользователей и личный опыт по созданию подобных программных изделий позволяет разработчику самостоятельно формулировать некоторые требования. При этом он должен всегда согласовывать эти формулировки с пользователями, так как ответственность за содержание требований несут именно они. Подавляющее же большинство требований пользователи должны сформулировать сами. Постоянное вовлечение будущих пользователей в процесс выработки решений на протяжении всего проектирования является одним из основополагающих принципов современных технологий разработки программных изделий.
Для сбора требований разработчик может использовать различные методы:
· изучение действующей документации;
· интервьюирование пользователей (беседа);
· анкетирование пользователей;
· протоколирование деятельности пользователей;
· стажировку на рабочем месте;
· "мозговой штурм";
· создание и апробацию прототипа будущего программного изделия;
· использование собственных знаний и опыта.
На первом этапе при активном участии пользователей составляют описание существующей системы с выявлением её недостатков. Если программное изделие создается на "голом месте", то требования разрабатывают на основе анализа действующего ручного метода обработки и представлений пользователей о желаемой технологии функционирования автоматизируемого объекта.
Важным фактором, который необходимо учитывать при разработке программного изделия, является недостаточное понимание пользователями того, что они действительно хотели бы получить от разрабатываемой системы. Многие проектные решения в процессе разработки ПИ подвергаются многократным уточнениям и корректировкам по результатам обсуждений.
Кроме этого, следует иметь в виду то, что хороший специалист (в любой области) все базовые понятия своей профессии считает общеизвестными. Поэтому свои объяснения он начинает с того, чем следовало бы закончить. Прочее - по умолчанию, причем перечень установок, сделанных по умолчанию, остается неизвестным. Такой специалист охотно ответит на все вопросы, но надо еще знать, о чем его спрашивать.
Еще более сложной проблемой является терминологический барьер. Специалист дает объяснения на привычном ему профессиональном жаргоне. Программист, не понимая объяснений, задает свои вопросы на языке, непонятном специалисту. Взаимопонимание требует огромных усилий и достигается не всегда. Наиболее курьезные результаты получаются в тех случаях, когда один и тот же термин означает в двух разных областях совершенно различные понятия.
Независимо от метода, применяемого при сборе первичных сведений, проектировщик обязан получить ответы на следующие вопросы:
- что требуется от системы?
- зачем это нужно?
- кому это необходимо?
- насколько это важно?
- чем можно измерить степень соблюдения требования?
С целью облегчения вовлечения пользователей в процесс разработки, необходимо интенсивно использовать представление проектных решений в графической форме, обеспечивающей достаточную наглядность и не требующей для понимания их сущности специальной подготовки в области информационных технологий.
Большое значение для обеспечения единства понимания между проектировщиками и будущими пользователями, уточнения существующих и выявления дополнительных требований имеет разработка и оценка демонстрационного прототипа. Прототип - это не завершенная, но уже работающая версия программного изделия. Создается на ранних этапах жизненного цикла и используется для исследования и выяснения концепции функционирования и требований к программному изделию, а также для экспериментальной проверки требований, структур данных и алгоритмов. После апробации прототипа техническое описание системы и структуры данных уточняют.
Анализ требований
После завершения сбора требований осуществляют их анализ, в процессе которого, как минимум, необходимо выявить:
1) одинаковые требования, сформулированные по-разному различными пользователями, а также требования, учтенные в других требованиях;
2) взаимосвязанные требования;
3) противоречивые и взаимоисключающие требования;
4) трудно реализуемые и нереализуемые требования.
Наиболее квалифицированные пользователи могут привлекаться в качестве экспертов для разрешения противоречий между требованиями, выдвинутыми различными группами пользователей.
В результате анализа требований с учетом имеющихся ресурсов (времени на разработку и денежных средств), а так же с учетом взаимоисключающих требований формируют несколько вариантов реализации программного изделия.
Документирование требований. Уровни детализации требований
Требования формулируются в виде отдельных предложений. Однако сам термин требования может трактоваться по-разному, так как на разных этапах создания программного изделия требуется разная детализация требований. В некоторых случаях под требованиями понимаются лишь самые обобщенные утверждения о функциональных возможностях и ограничениях программного изделия. Другая крайняя ситуация — детальное описание каждой автоматизируемой функции будущего программного изделия.
Если компания хочет выиграть контракт на разработку большого программного изделия, она вынуждена, пока решение не принято, представлять требования в самом обобщенном виде, чтобы, с одной стороны, удовлетворить требования заказчика, а с другой — иметь возможность для маневра при конкуренции с другими компаниями-разработчиками. После того как контракт выигран, компания должна представить заказчику более подробное описание программного изделия с указанием всех выполняемых ею функций.
Некоторые проблемы, возникающие в процессе разработки требований, порождены отсутствием четкого понимания различия между этими разными уровнями требований.
Чтобы различить требования разных уровней детализации, используют термины пользовательские требования (user requirements) для обозначения обобщенных требований и системные требования (system requirements) для детализированного описания выполняемых программным изделием функций. Кроме требований этих двух уровней применяется еще более детализированное описание программного изделия, предназначенное для программистов - проектная системная спецификация (software design specification). Три перечисленных вида требований можно определить следующим образом.
Пользовательские требования, как правило, описывают программное изделие в обобщенном виде. Они пишутся в первую очередь для заказчика, поэтому должны описывать функции и ограничения так, чтобы они были понятны даже пользователю, не имеющему специальных технических знаний в области информационных технологий. Эти требования должны определять только внешнее поведение программного изделия, избегая по возможности определения его структурных характеристик. Пользовательские требования должны быть написаны естественным языком с использованием простых таблиц, а также наглядных и понятных схем и диаграмм.
Вместе с тем при описании требований на естественном языке могут возникнуть различные проблемы, связанные с неточностью и "размытостью" требований.
1. Отсутствие четкости изложения. Иногда нелегко изложить какую-либо мысль естественным языком четко и недвусмысленно, не сделав при этом текст многословным и трудночитаемым. Естественно, разработчики интерпретируют требования, допускающие двоякое толкование, так, чтобы систему было проще реализовать. Но это толкование может не совпадать с ожиданиями заказчика. Такая ситуация приводит к разработке новых требований и внесению изменений в систему. Это, в свою очередь, ведет к задержке сдачи готовой системы и ее удорожанию.
2. Смешение требований. В пользовательских требованиях отсутствует четкое разделение на функциональные и нефункциональные требования, на системные цели и проектную информацию.
3. Объединение требований. Несколько различных требований к программному изделию могут описываться как единое пользовательское требование.
Системные требования — это более детализированное описание пользовательских требований. Системные требования описывают систему максимально подробно, включая ее входные и выходные данные, исключения из правил обработки данных и т.д. Такое описание также называют функциональной спецификацией. Она служит основой для заключения контракта между покупателем программного изделия и его разработчиком и предназначена для руководящего технического состава компании-разработчика и для менеджеров проекта.
Системные требования определяют, что должна делать система, не показывая при этом, как и пользовательские требования, механизма реализации. Но, с другой стороны, для полного описания системы требуется детализированная информация о ней, которая по возможности должна включать всю информацию о системной архитектуре. На то существует ряд причин.
1. Первоначальная архитектура системы помогает структурировать спецификацию требований. Системные требования должны описывать подсистемы, из которых состоит разрабатываемая система.
2. В большинстве случаев разрабатываемая система должна взаимодействовать с уже существующими системами. Это накладывает определенные ограничения на архитектуру новой системы.
3. В качестве внешнего системного требования может выступать условие использования для разрабатываемой системы специальной архитектуры.
В документе, содержащем требования к программному изделию, желательно отделять пользовательские требования от более детализированных системных требований. Иначе неподготовленный читатель пользовательских требований может "потонуть" в технических подробностях, понимание которых требует определенных профессиональных знаний.
Проектная системная спецификация — это подробное описание структуры программного изделия, которое будет основой для его проектирования и последующей реализации. Эта спецификация дополняет и детализирует функциональную спецификацию (системные требования). Проектная системная спецификация является документом, который ориентирован на разработчиков программного обеспечения.
Чтобы избежать проблем неоднозначности понимания требований, разработаны специальные методы их формализованного описания, которые структурируют спецификацию и уменьшают размытость определений. Кроме этого, разработаны другие подходы, например специальные языки описания требований, которые используются относительно редко.