Методы первичного сбора требований. Модели системы. Языки специфики требований. Оценка требований

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

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

Методы  сбора требований

Проведение  опроса и документирование (интервьюирование).

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

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

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

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

После собрания делается черновик С-требований, например, в формате стандарта IEEE или по ГОСТ Р ИСО/МЭК 12207. Затем этот черновик посылается по электронной почте заказчикам для комментариев. Повторные опросы проводятся до полной удовлетворенности заказчиков С-требованиями.

Анкетирование.

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

 «Мозговой штурм»

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

Сценарии  и ролевые игры.

Метод заключается  в создании легко модифицируемого  схематичного сценария работы системы (не прототипа), который обсуждается  с пользователем. Метод направлен  на поиск актеров, участвующих в  работе системы и получения от будущих пользователей обратной связи, например по вопросам интерфейса или по вопросам «что будет если...». Для ролевых игр могут использоваться доски, простые листы бумаги или  даже интерактивные сценарии, главное, чтобы пользователь понимал, как  происходит взаимодействие с системой. Сценарии особенно полезны в случае когда в систему включены новые  функции, плохо поняты требования, не определены актеры и варианты использования. Они также позволяют обсудить пользовательский интерфейс, не прибегая к трудоемкому созданию прототипов.

Создание  прототипов.

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

Совместная  разработка приложений .

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

Моделирование.

Метод заключается в создании и обсуждении моделей автоматизируемых процессов, информационных потоков, отношений между объектами и т.д. Модели могут готовиться при помощи различных программных средств, таких как BPwin, Rational Rose, Visio и различных нотациях, которые понятны заинтересованным лицам. Нужно определять в каких случаях дешевле и проще создать модели, а в каких прототипы, поскольку прототип можно назвать моделью предварительного варианта использования. Обычно моделирование дешевле и гибче прототипирования, поскольку модель может иметь различные уровни абстракции от высокоуровневых до подробного и весьма детализированного описания системы. К недостаткам этого метода можно отнести высокие требования к квалификации как разработчиков, которые создают модели и обсуждают их с заинтересованными лицами так тех, кто эти модели рассматривает. Нельзя забывать и то, что слишком детализированное моделирование системы может занимать столько же времени, сколько заняло бы создание прототипа, и в то же время прототип можно «пощупать» и использовать его части в дальнейшем создании системы, тогда как модель – только иллюстрация

Изучить аналогичные системы

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

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

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

Такой процесс  может включать такие виды деятельности:

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

Классификация всех типов информации в этом документе. (пользователь, системное требование, элементы решения, планы, базовые материалы, не относящиеся к делу подробности)

Пометки в оригинальном тексте, чтобы выделить такие требования.

Поиск хорошей структуры для каждого из различных типов информации:

-сценарий для пользовательских требования,

-функциональный анализ (декомпозиция) для системных требований

-архитектурный стиль для проектирования.

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ЯЗЫКИ СПЕЦИФИКАЦИИ ТРЕБОВНИЙ (СЦЕНАРИИ, PDL, ПОТОКОВЫЕ ДИАГРАММЫ)

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

Отсутствие  четкости изложения. Иногда нелегко  изложить какую-либо мысль естественным языком четко и недвусмысленно, не сделав при этом текст многослойным и трудночитаемым.

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

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

Во избежание  этих проблем рекомендуется применять  специальные способы записи спецификаций требований:

1. Структурированный естественный язык. Использование стандартных форм и шаблонов для написания спецификации
2. Языки описания программ. Использование специальных структурированных языков, подобных языкам программирования, где спецификация требований строится на основе выбранной операционной модели системы.
3. Графический язык. Графический язык, использующий для описания функциональных требований диаграммы и блок-схемы, дополненные текстовыми пояснениями. Наиболее известный пример такого графического языка—диаграммы структурного анализа и проектирования ПО.
4. Математическое описание. Это системы нотаций, основанные на математических концепциях, таких, как теория конечных автоматов или теория множеств. Это формализованная однозначная и лишенная двусмысленности запись системных требований. Однако многие заказчики ПО не понимают формальных спецификаций, вследствие чего возникают определенные проблемы при заключении контрактов на разработку программных продуктов.