Анализ и разработка требований к программному обеспечению

Размещено на http://www.allbest.ru/

Во всех моделях разработки ПО в той или иной форме выполняется выявление и описание требований к ПО.

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

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

Процесс выявления, анализа, документирования называется разработкой требований.

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

Существует 3 основных стороны, заинтересованные в создании новой ПС: 1.Заказчик 2.Разработчик 3.Пользователи 

Каким-то образом требования к ПС, которые будут удовлетворять потребностям заказчиков и заботам пользователей должны быть переданы разработчикам. Между этими участниками проекта разработки имеется коммуникационный разрыв (не понимание). СТПО является средством (мостом) для преодоления такого разрыва, т.к. они являются общим представление разрабатываемого ПО.

Целью деятельности по работе с требования является создание Спецификаций Требований к ПО (СТПО), которые детально описывают, что должна уметь делать разрабатываемое ПО.

С помощью СТПО заказчик явно описывает, что он ожидает от поставщика, а разработчик явно понимает, какими возможностями должно обладать разрабатываемое ПО. 

Процесс формирования и анализа требований проходит через ряд этапов:

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

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

В процессе сбора требований важно принимать во внимание возможные противоречия требований различных заинтересованных лиц

o Опрос стейкхолдеров является широко используемой техникой при сборе требований. Эти опросы могут выявлять требования, не попавшие в рамки проекта либо противоречащие ранее собранным. Однако каждый стейкхолдер будет иметь собственные требования, ожидания и видение системы

o Интервью, опросы, анкетирование;

o Мозговой штурм, семинар;

o Наблюдение за производственной деятельностью, «фотографирование» рабочего дня;

o Анализ нормативной документации;

o Анализ моделей деятельности;

o Анализ конкурентных продуктов;

o Анализ статистики использования предыдущих версий системы

· Классификация требований. На этом этапе бесформенный набор требований преобразуется в логически связанные группы требовании.

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

Сеансы совместного развития требований

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

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

· Проверка требований. На этом этапе определяется их полнота, последовательность и непротиворечивость.

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

· Где система будет использоваться?

· Как система достигнет целей миссии?

· : Какие параметры системы являются критическими для достижения миссии?

· : Как различные компоненты системы должны использоваться?

· : Насколько эффективной должна быть система для выполнения миссии?

· : Как долго система будет использоваться?

· : Каким окружением система должна будет эффективно управлять?

Функционал Функциональные требования объясняют, что должно быть сделано. Они идентифицируют задачи или действия, которые должны быть выполнены.

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

Нефунк

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

Производные требования

Требования, которые подразумеваются или преобразованы из высокоуровневого требования. Например, требование для большего радиуса действия или высокой скорости может привести к требованию низкого веса.

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

Преимущества

· Обеспечивает контрольный список требований.

· Обеспечивает договор между заказчиками и разработчиками.

· Для большой системы может обеспечить описание высокого уровня.

Недостатки

· Такие списки могут занимать сотни страниц. Фактически невозможно прочитать такие документы в целом и получить чёткое понимание системы.

· Такие списки требований перечисляют отдельные требования абстрактно, оторванно друг от друга и от контекста использования

· Эта абстракция лишает возможности видеть, как требования связываются между собой или работают вместе.

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

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

· Эта абстракция означает, что чрезвычайно трудно убедиться, что у вас есть все необходимые требования.

Прототипы

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

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

Типы системных моделей, которые могут создаваться в процессе анализа систем:

· Модель обработки данных. Диаграммы потоков данных показывают последователь-ность обработки данных в системе.

· Композиционная модель. Диаграммы "сущность-связь" показывают, как системные сущности составляются из других сущностей.

· Архитектурная модель. Эти модели показывают основные подсистемы, из которых строится система.

· Классификационная модель. Диаграммы  наследования  классов показывают,  какие объекты имеют общие характеристики.

· Модель "стимул-ответ". Диаграммы изменения состояний показывают, как система реагирует на внутренние и внешние события.

обеспечение программный разработка

Размещено на Allbest.ru