ТЕХНИКИ  ВЫЯВЛЕНИЯ  ТРЕБОВАНИЙ  К  РАЗРАБОТКЕ  ПО

Пищикова  ЕкатеринаСергеевна

магистрант,  Белорусский  государственный  университет  информатики  и  радиоэлектроники,  Республика  Беларусь,  г.  Минск

E-mail:  e.pishchikova@gmail.com

Комличенко  Виталий  Николаевич

канд.  техн.  наук,  зав.  кафедрой  экономической  информатики,  доцент  Белорусского  государственного  университета  информатики  и  радиоэлектроники,  Республика  Беларусь,  г.  Минск

E-mail: 

TECHNIQUES  OF  REQUIREMENTS  IDENTIFICATION  TO  SOFTWARE  DEVELOPMENT

Ekaterina  Pishchikova

master  student,  Belarusian  State  University  of  Informatics  and  Radioelectronics,  Republic  of  Belarus,  Minsk

VitalyKomlitchenko

candidate  of  Science,  Head  of  Economic  Informaticsdepartment,  assistant  professor  of  Belarusian  State  University  of  Informatics  and  Radioelectronics,  Republic  of  Belarus,  Minsk

АННОТАЦИЯ

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

ABSTRACT

In  this  work,  the  methods  and  means  of  elicitation  and  reporting  requirements  to  software  development  are  reviewed.  There  a  combined  approach  is  proposed:  the  multiple  methods  are  combined,  thereby  reducing  the  time  to  identify  requirements  and  eliminating  contradictions  and  ambiguities  in  the  requirements  collection.  This  approach  is  cyclic,  the  number  of  steps  of  requirements  negotiations  with  key  stakeholders  depends  on  the  complexity  of  the  project  and  the  amount  of  time  that  is  allocated  to  the  primary  analysis  phase.

Ключевые  слова:  выявление  требований;  требование;  моделирование;  база  знаний.

Keywords:  requirements  elicitation;  requirement;  modeling;  base  of  knowledge.

Опыт  индустрии  информационных  технологий  однозначно  показывает,  что  вопросы,  связанные  с  разработкой  управлением  требованиями,  оказывают  критически-важное  влияние  на  программные  проекты,  в  определенной  степени  —  на  сам  факт  возможности  успешного  завершения  проектов  [1].  Ошибки,  допущенные  на  стадии  выявления  требований,  составляют  от  40  до  60  %  всех  дефектов  проекта  [2,  с.  4].  Удельная  стоимость  их  исправления  быстро  растет  по  мере  продвижения  продукта  к  стадии  эксплуатации.  В  различных  литературных  источниках  указывается,  что  стоимость  исправления  дефекта  допущенного  при  определении  требований  после  ввода  системы  в  эксплуатацию  от  100  до  1000  (в  зависимости  от  масштаба  проекта)  раз  превышает  аналогичную  стоимость  исправления  допущенной  ошибки  в  период  непосредственной  разработки  требований. 

Вопросам  разработки  требований  к  программному  обеспечению  (ПО)  уделяется  большое  внимание  в  стандартах  по  программной  инженерии,  а  рекомендации  по  лучшим  практикам  публикуются  в  разработках  типа  «Свод  знаний  по  программной  инженерии»  (SWEBOK  —  Software  Engineering  Body  of  Knowledge)  [3].  В  SWEBOK  разработка  программных  требований  (Software  requirements)  представлена  как  одна  из  десяти  важнейших  областей  знаний  создания  ПО.  На  практике  же  часто  применяются  подходы,  используемые  в  различных  методологиях  разработки  ПО  и  базирующиеся  на  определении  групп  требований  к  продукту.  Следует  также  отметить,  что  выявление  и  извлечение,  формализация  и  документирование  требований  к  ПО  составляют  основу  спецификации  на  разработку  проекта.  Кроме  того,  в  случае  сложных  программных  систем,  существует  целый  комплекс  спецификаций,  документов,  которые  являются  результатом  сбора  и  анализа  требований,  их  моделирования  и  архитектурного  проектирования.  Эти  документы  представляют  базовый  контекст  создания  программных  систем.  Требования  анализируются,  в  них  вносятся  изменения,  они  пересматриваются  и  утверждаются.  В  данной  статье  мы  сосредоточим  внимание  на  практике  выявления  и  фиксирования  программных  требований.

Начальным  этапом  разработки  проекта  является  этап  выявления  источников  требований  и  их  извлечения.  Это  первая  стадия  формирования  видения  автоматизирования  бизнес-процессов,  при  которой  формулируются  цели  и  задачи  проекта,  выделяются  основные  сущности  и  связи  между  ними.  Данный  этап  подразумевает  выявление  и  представление  требований  к  будущей  системе.  Первичное  выявление  требования  также  включает  в  себя  идентификацию  основных  источников  требований.  В  SWEEBOK,  при  определении  источников  требований,  рекомендуется  сосредоточить  внимания  на:  целях,  знании  предметной  области,  заинтересованных  лицах  (software  stakeholders),  операционном  окружении,  организационной  среде.  Только  глубокое  понимание  потребностей  источников  и  учета  их  степени  влияния  и  значимости,  а  также  использование  современных  выверенных  практик  (техник)  разработки  позволит  создать  стройную  систему  требований  к  ПО.

Существует  множество  техник  выявления  и  представления  требований.  Ниже  представлены  основные  из  них:

1.  Опрос  —  интервьюирование  пользователей  и  основных  заинтересованных  лиц  проекта; 

2.  Наблюдение  —  наблюдение  за  бизнес-процессом,  подлежащим  автоматизации  (например,  наблюдение  за  работой  пользователей); 

3.  Сценарии  —  описание  сценариев  работы  пользователей;

4.  Изучение  существующих  документов  (правил,  законодательства,  описания  существующего  аналога  системы  и  т.  п.).

5.  Прототипы  —  описание  и  моделирование  внешнего  вида  будущей  системы  и  ее  работы.

6.  Изучение  и  анализ  существующих  систем-аналогов  на  рынке;

7.  Разъясняющие  встречи  и  мозговые  штурмы  с  пользователями  и  экспертами;

8.  Маркетинговые  исследования;

9.  Моделирование  —  может  включать  в  себя  как  моделирование  существующих  бизнес-процессов,  так  и  верхнеуровневое  моделирование  будущей  системы.

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

Этап  извлечения  требований  можно  условно  разделить  на  4  стадии:

1.  Сбор  первичной  информации  и  требований;

2.  Первичный  анализ  требований;

3.  Документирование;

4.  Проверка.

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

1.  Единичность  —  требование  описывает  только  одну  потребность.

2.  Завершенность  —  вся  необходимая  информация  описана  и  присутствует  в  одном  месте  в  требованиях. 

3.  Последовательность  —  требование  не  противоречит  другим  требованиям  и  соответствует  внешней  проектной  документации.

4.  Атомарность  —  требование  нельзя  или  нет  смысла  декомпозировать  на  более  мелкие  требования.

5.  Отслеживаемость  —  требование  задокументировано  и  его  можно  отследить.

6.  Актуальность  —  требование  является  актуальным  в  текущее  время.

7.  Выполнимость  —  требование  реализуемо  в  пределах  данного  проекта.

8.  Недвусмысленность  —  требование  отражает  объективные  факты  и  возможна  только  одна  интерпретация  требования. 

9.  Обязательность  —  требование  нельзя  проигнорировать,  без  него  решение  представляется  неполноценным. 

10. Проверяемость  —  реализация  требования  может  быть  проверена  определенным  образом.

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

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

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

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

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

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

Моделирование  бизнес-процессов  компании  позволит  наиболее  явно  представить  их  в  наглядном  виде,  поможет  лучше  понять  особенности  бизнеса  и  возможные  ограничения  и  предпочтения  в  автоматизации  процессов.  Для  моделирования  бизнес-процессов  компании  можно  использовать  Idef0,  Idef3  (PFDD,  OSTN),  BPMN,  EPC,  а  также  такие  привычные  способы  моделирования,  на  основе  Процессов  и  Процедур.  После  того,  как  требования  представлены  в  виде  одной  из  моделей,  описанных  выше,  имеющееся  представление  требований  накладывается  и  сверяется  с  соответствующими  источниками  требований,  а  также  согласуется  со  всеми  основными  участниками  проекта.  При  обсуждении  и  согласовании  модели  выявляются  новые  требования  и  изменяются  предыдущие,  что  находит  свое  отражение  в  базе  знаний. 

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

Список  литературы:

1. Орлик  C.  Основы  программной  инженерии:  [Электронный  ресурс]  —  Режим  доступа.  —  URL:  http://swebok.sorlik.ru/1_software_requirements.html  (дата  обращения:  24.12.2014). 
2. Карл  И.  Вигерс.  Разработка  требований  к  программному  обеспечению,  2004:  2-е  изд.,  перераб.  и  доп.  Пер.  с  англ.  М.  :Русская  редакция.  —  554  c.
3. Software  Engineering  —  Guide  to  the  Software  Engineering  Body  of  Knowledge  (SWEBOK)  //  TECHNICAL  REPORT  ISO/IEC  TR  19759  IEEE.  First  edition  2005-  9—15.  [Electronic  resource].  –  ISO/IEC  2005.  –  Mode  of  access:  [Электронный  ресурс]  —  Режим  доступа.  —  URL:  http://  http://profs.etsmtl.ca/claporte/English/Enseignement/CMU_SQA/Lectures/Corpus/SWEBOK_ISO_IEC_TR_19759_2005%28E%29.pdf.  —  Date  of  access:  09.01.2015.