Проектирование программных систем. Занятие 2

SOFTWARE REQUIREMENTS DEVELOPMENT

МАИ, каф 806, ППС

Что такое требования?

Согласно IEEE Standard Glossary of Software Engineering Terminology это

1. Условия или возможности необходимые пользователю для решения задачи или достижения цели

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

3. Документальное представление условий или возможностей как в пункте 1 или 2

2

ТРЕБОВАНИЯ – ЭТО ОБЩЕЕ ПОНИМАНИЕ РЕШАЕМЫХ ЗАДАЧ


Зачем нужны требования?

• Консолидация общего понимания требований заказчика.

• Разбиение сложных требований на группы, для лучшего понимания проекта.

• Служит основой для планирования проекта.

• Служит соглашением между командой разработки и заказчиком.

3

ТРЕБОВАНИЯ ДОЛЖНЫ БЫТЬ ДОКУМЕНТИРОВАННЫ


Почему этим важно заниматься?

4

СОЗДАНИЕ ТРЕБОВАНИЙ ПОЗВОЛЯЕТ ПРОТЕСТИРОВАТЬ ПОНИМАНИЕ ЗАДАЧИ


Из чего они состоят?

5


Какими должны быть хорошие требования?

• Полные

• Нацеленные на решение поставленной задачи

• Осуществимые

• Нужные

• Приоритезированные

• Исключающие двоякого толкования

6


Какие этапы есть в создании требований к программному обеспечению?

Определение классов пользователей

Определение потребностей каждого класса пользователя

Понимание задач и бизнес целей пользователей

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

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

Понимание важности атрибутов качеств системы

Выяснение приоритетов в реализации (функциональных и нефункциональных)

Создание документа с требованиями и модели системы

Рецензирование документа для достижения общего понимания между заказчиком и исполнителем

7


СБОР ИНФОРМАЦИИ

8


Методы сбора информации

Существуют несколько основных методов сбора информации:

наблюдение за действиями пользователя (shadowing);

интервьюирование (inteviewing);

опросы (surveys);

обучение, проводимое пользователями (user instruction);

создание прототипов (prototyping);

Точка зрения

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

9


Наблюдение за действиями пользователя

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

Наблюдение бывает пассивным или активным.

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

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

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

10


Примеры вопросов, задаваемых при наблюдении за пользователями

Как пользователь структурирует свою работу?

Какие решения он принимает в начале и при завершении задачи?

Как пользователи выполняют свою работу в текущей реализации?

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

Как воздействуют на пользователей перерывы в работе? В состоянии ли онипродолжить работу с того же места, на котором их прервали?

Со сколькими сотрудниками взаимодействует пользователь при выполнении той или иной операции?

Какие усовершенствования внес пользователь, чтобы упростить выполнениезадачи?

Возможна ли модификация тех или иных стадий выполнения задачи? Каковы возможности и от каких условий они зависят?

11


Во время наблюдения на некоторые вопросы постарайтесь найти ответы самостоятельно.

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

Как повысить эффективность процессов? Обязательно ли все выполняемыевручную задачи должны возлагаться на автоматизированное решение?

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

Каковы критерии производительности?

Какие функции используются часто, а какие реже?

Что пользователям нравится в существующей системе, а что нет?

Как снизить затраты на обучение и поддержку?

Каковы характеристики и предпочтения пользователей?

12


Интервьюирование

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

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

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

13


Что нужно помнить при интервью

Начинайте с общих (не специализированных) вопросов и стройте беседу так, чтоб интервьюируемый думал обо всех выполняемых им задачах и информации, которую он способен вам сообщить;

На основании ответов на вопросы попросите интервьюируемого изложить наиболее общие задачи и разбить их на более мелкие;

Особо попросите выделить информацию, которая обычно отсутствует, а так же возможные альтернативные пути решения задач;

Пройдитесь по заданным вопросам несколько раз, повторно спрашивая интервьюируемого, не упустили ли вы что-то важное;

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

Примеры вопросов

С какими проблемами вы сталкиваетесь при выполнении своих задач?

В какой помощи вы нуждаетесь, работая удаленно?

Есть ли у вас какие-либо потребности кроме задокументированных?

Какие бизнес-политики помогают (или, наоборот, мешают) вам выполнять свои обязанности?

Какие люди или документы снабжают вас информацией, необходимой для выполнения работы?

Какие ешё пользователи или системы влияют на вашу работу (например, сторонние поставщики или специалисты службы поддержки)?

14


Правила Глеба Жиглова

1. Разговаривая с людьми всегда улыбайся. Люди это любят

2. Будь к человеку внимателен и страйся подвинуть к разговору о нем самом

3. Найди тему, которая ему интересна

4. Проявляй к человеку искренний интерес...

15


Опросы [1/2]метод

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

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

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

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

16


Опросы [2/2]Примеры информации, которую можно собрать путем опросов

Организационные структуры, политики или правила, которые содействуют или препятствуют выполнению задач;

Неудовлетворенность технической поддержкой или политикой;

Особые требования к аппаратному или программному обеспечению;

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

17


Обучение, проводимое пользователями

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

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

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

дизайн пользовательского интерфейса;

необходимость в обучении для поддержки существующих и будущих процессов;

критерии производительности системы;

воздействие, которое оказывает на выполнение задачи физическая среда.

18


СОЗДАНИЕ ПРОТОТИПОВ

19


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

Сбор информации выполняется путем моделирования производственной среды.

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

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

требования клиента к качеству;

требования к времени отклика:

простоту использования;

интеграцию существующих технологий и приложений;

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

проверку цепочек технологических процессов.

20


Стратегия сбора информации

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

Определяя стратегию сбора информации, руководствуйтесь следующими вопросами:

какие источники необходимо использовать для добывания информации;

какую информацию необходимо собрать;

какие методы сбора информации вы планируете использовать и к каким источникам тот или иной метод применим;

как предполагается хранить собираемую информацию;

сколько времени вы планируете собирать информацию?

Используйте несколько методов сбора информации. Если вы положитесь лишьна один-единственный метод сбора, полученная картина бизнеса может оказаться неполной. Комбинируя различные методы, удается преодолеть недостатки, присущие каждому в отдельности

21

МАИ, каф 806, ППС22

Какие проблемы могут возникать?

Различное толкование терминов в требованиях.

Словари терминов.

Отсутствие нефункциональных требований.

Надежность. Заказчик всегда хочет получть 100% надежную программу. В большинстве случаев это невозможно (сбои аппаратуры, зависимость от внешних систем).

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

Безопасность. В случае если у программы более одного пользователя, то должны быть требования к безопасности (кстати, если пользователь один - это то же требование к безопасности).

Usability. Квалификация персонала заказчика сильно накладывает ограничение на Usability. Возможно персонал уже привык работать с определенным типом пользовательского интерфейса и даже более простой интерфейс будет непонятен.

Модифицируемость. Следует сразу понять в какую сторону система будет развиваться, как часто будут приходить запросы на изменение системы. Какие эти запросы будут?

Тестируемость. Будет ли заключаться договор о тех. поддержке? С какой скоростью нужно обнаруживать и исправлять сбои?


А еще какие проблемы могут быть?

Отсутствие бизнес-целей Какую выгоду принесет разрабатываемый функционал?

Описание деталей реализации. Нельзя смешивать требования и реализацию.

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

быть универсальных правил.

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

быть документирована.

Недостаточные требования.

Требования нужно постоянно дополнять и актуализировать.

Дублирующие требования

Одно требование – только в одном месте.

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

Одно требование не должно противоречить с другим.

Зависимые требования

Если одно требование вытекает из другого, эта связь должна быть документирована


REQUIREMENT MANAGEMENT

24


Требования – это живое существо, меняющееся в течении проекта

25


Разработка концептуальных требований. Стабилизация.

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

Ведение версий требований и историй изменения требований.

Ведение матрицы зависимости требований (одно требование может порождать другое).

Свободный доступ к единой (сетевой) версии требований.

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

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

Выделение главных требований и бизнес-целей проекта (определение приоритета требований). Разбор сценариев и выяснение их приоритетов (голосование).

Принятие решения о реализации или отклонении требований.

В какой версии продукта данное требование будет внесено.

Этапы согласования требований.

Внутреннее согласование внутри проектной команды.

Согласование с заказчиком.


ПРИМЕР ДОКУМЕНТА С ТРЕБОВАНИЯМИ

27


Пример документа с требованиями [1/20]Цель создания системы

Содержание: Данный раздел содержит описание цели создания системы.

• Бизнес цели (сконцентрировано на функционале). Может быть короткое описание запрашиваемого функционала, например реализация интернет-магазина по продаже книг.

• Цели дизайна (сконцентрированы на атрибутах решения). Уменьшение ошибок операторов, повышение производительности.

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


Пример документа с требованиями [2/20]Описание текущего состояния системы

Содержание:Описывается то как запрашиваемый функционал реализуется в данный момент. Если реализация отсутствует, то указывается что разрабатываемый функционал является новым.

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

СпособUML модели, SADT модели, пользовательские истории ...

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


Пример документа с требованиями [3/20]Описание границ проекта

Содержание:

В данном разделе указывается что попадает в рамки данного проекта, а что остается за рамками. Например, система автоматизации завода может автоматизировать бухгалтерию и отдел кадров и не затрагивать работу со станками с ЧПУ. Возможно применение UseCase диаграмм с указанием границ.

Обоснование:

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

Подсказка:

проще писать то что не входит в проект


Пример документа с требованиями [4/20]Описание зависимостей и предположений


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

Обоснование: Данные зависимости оказывают существенное влияние на дизайн разрабатываемой системы.

Подсказка: Пишите только то, что является за границами вашего проекта.


Пример документа с требованиями [5/20]Описание ролей пользователей системы


Дается таблица, в которой указываются названия ролей. Указывается описание ролей пользователей.

Обоснование: Для простоты описания системы удобно пользователей разделить на группы и строить описание работы пользователя применительно к группе. В большинстве случаев ролей больше чем одна (как минимум пользователь и администратор).

Подсказка: Давайте ролям человеческие имена, это упрощает описание сценариев.


Пример документа с требованиями [6/20]Борьба со сложностью

Структурированное изложение информации

Если есть возможность разбить функционал на блоки – это лучше сделать.

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

Для каждого блока нужно определить его инварианты (условия, выполняющиеся всегда).

Инварианты помогают мыслить категориями.

Хороший инвариант описывает правило с минимумом условие (например, солнце встает на востоке).

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

33


Пример документа с требованиями [7/20]Сценарии работы

Описание сценариев работы системы Преценденты как механизм упрощения этапа формулировки требований для всех

заинтересованных лиц.

Идея описания функциональных требований с помощью прецендентов была сформулирована Айваром Якобсоном в 1986 году.

Сценарий – это специальная последовательность действий или взаимодействий между исполнителем и системой.

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

Описания прецендентов – это текстовые документы а не диаграммы. Соответственно, моделирование прецендентов это процесс написания текста.

Для иллюстрации имен прецендентов и исполнителей, а так же их взаимоотношений используются диаграммы UML Use Case.

Преценденты бывают двух видов: Функциональные, описывающие реализацию той или иной функции.

Инфраструктурные, описывающие работу системы в целом (например процессы авторизации и т.д.)


Пример документа с требованиями [8/20]Прецедент

Содержание сценария прецендента: Обычно описывается в виде последовательности шагов, с коротким словесным описанием шага и кем

он выполняется. Если в процессе работы допускается ветвление (например, при одни обстоятельствах выполняется

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

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

Описание прецедента состоит Описание ролей; Описание предусловий; Описание основных сценариев; Описание дополнительных (альтернативных) сценариев;

• Состоят– Описание точки расширения в базовом прецеденте;– Описания условия старта альтернативного потока;– Описания сценария потока;

• Используются для– Обозначения ветвления в сценариях (например, описание реакции системы на ошибочную авторизацию);– Создания сценариев- наследников (например, авторизация и авторизация с аудитом);

Описание постусловий:


Пример документа с требованиями [9/20]Плохое описание прецендента

Роли:

• Оператор – сотрудник организации.

Предусловие:

• Компьютер выключен.

Сценарий:

Постусловие:

• Программа запущена и готова к работе.


Пример документа с требованиями [10/20]Хорошое описание прецендента

Роли:

• Оператор – сотрудник организации имеющий права на работу с системой.


• Система ожидает авторизации (Компьютер выключен.)

Сценарий:


• Оператор успешно аутентифицирован и авторизован на работу с системой. (Программа запущена и готова к работе.)


Пример документа с требованиями [11/20]Расширяющий сценарий

Роли:

• Оператор – сотрудник организации имеющий права на работу с системой.


• В сценарии авторизации на шаге 3 система определила, что оператор имеет роль - Директор

Сценарий:


• Выполнение переходит на 4 шаг базового сценария

38

Описание Роль/Модуль

1 Отправляется e-mail на почту оператора. В e-mail пишется время входа в систему.

Система

2 В системе сохраняется информация о времени входа в систему и об усппешностиотправки e-mail.

Система


Пример документа с требованиями [12/20]Правила формирования описания прецендентов

Определите рамки системы: что включает в себя система? Программный это комплекс или программно-аппаратный?

Идентифицируйте основных исполнителей системы (роли). Для каждого исполнителя определите его задачи.

Определите преценденты, удовлетворяющие потребности каждого исполнителя.

Отсутствие внешних компьютерных систем среди основных исполнителей – достаточно редкий случай.

Имя прценедента начинается с существительного, описывающего действия.

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


Пример документа с требованиями [13/20]Требования к программным интерфейсам


Данный раздел содержит спецификацию программных интерфейсов системы и описание потоков данных между системами. Могут применяться UML диаграммы Activity, Sequence, Collaboration.

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

В качестве иллюстраций хорошо использовать Activity диаграммы или Взаимодействия.


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


Пример документа с требованиями [14/20]Требования к отчетности

Содержание

В данном разделе описываются отчеты, построенные системой. Описание включает:

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

Периодичность построения отчета. Создание сложных отчетов может создать большую нагрузку на систему.

Параметры отчета. Нужно понимать достаточно ли вводимых данных для построения отчета. Возможно данные будут избыточны.

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

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

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


Пример документа с требованиями [15/20]Нефункциональные требования

Требования описываются в виде измеримых сценариев (всегда должна быть цифра, описывающая данную характеристику качества!);

Сценарий состоит из следующих частей:

• Источник события (внешняя система, оператор ...)

• Событие (некоторый факт, повлиявший на систему)

• Артефакт (то на что конкретно повлияло событие)

• Условия, при которых происходит событие

• Реакция на событие (то что хотим достичь для нормальной работы системы)

• Измеримая величина характеризующая реакцию.

Сценарии должны иметь сквозной приоритет (все показатели качества сделать максимальными не удастся).


Пример документа с требованиями [16/20]Требования к надежности


Описываются сценарии сбоя в работе системы и временные требования к восстановлению системы.

Сценарии строятся по принципу: сбой, реакция на сбой, сбой устранен.


Абсолютно надежных систем не бывает, даже если все ПО функционирует безотказно сбой может произойти в аппаратной части.

Например:


Пример документа с требованиями [17/20]Требования к производительности


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

Сценарии строятся по принципу: элементарный сценарий или прецендент, скорость работы сценария или прецендента.


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

Например:


Пример документа с требованиями [18/]

Требования к безопасности


Описываются сценарии проверки прав безопасности. Описываются требования к наличию прав у ролей на те или иные функции системы.

Сценарии строятся по принципу: описание атаки, время восстановления после атаки


В случае, если в системе должно работать более одного человека - разделение прав безопасности единственный способ организации нормальной коллективной работы с системой.

Например:


Пример документа с требованиями [19/20]Требования к удобству использования


Описываются требования к взаимодействию системы с оператором. Указываются бизнес приоритеты и специфика работы операторов.

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


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

Например:


Пример документа с требованиями [20/20]Требования к модифицируемости


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


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

Например:


Что почитать для углубленного понимания?

Software Requirements, Second Edition

by Karl E. WiegersISBN:0735618798

Microsoft Press © 2003 (516 pages)

48

Проектирование программных систем. Занятие 2

Education

Transcript of Проектирование программных систем. Занятие 2