Анализ требований: различия между версиями
[отпатрулированная версия] | [отпатрулированная версия] |
Содержимое удалено Содержимое добавлено
РоманСузи (обсуждение | вклад) м автовикификация |
|||
Строка 10:
* Документирование требований: требования могут быть задокументированы в различных формах, таких как простое описание, [[сценарий использования|сценарии использования]], [[пользовательские истории]], или спецификации процессов.
Анализ требований может быть длинным и трудным процессом, во время которого вовлечены много тонких психологических навыков. Новые системы изменяют окружающую среду и отношения между людьми, поэтому важно определить все заинтересованные лица, принять во внимание все их потребности и гарантировать, что они понимают значения новых систем. [[Аналитик программного обеспечения|
== Фазы ==
Строка 25:
=== Идентификация стейкхолдеров ===
{{main|Стейкхолдер}}
Стейкхолдер
=== Опрос стейкхолдеров
Опрос стейкхолдеров является широко используемой техникой при сборе требований. Эти опросы могут выявлять требования, не попавшие в рамки проекта либо противоречащие ранее собранным. Однако каждый стейкхолдер будет иметь собственные требования, ожидания и видение системы.
=== Сеансы совместного развития требований (СРТ) ===
Требования часто имеют сложное пересекающееся функциональное назначение, не известное отдельным стейкхолдерам. Такие требования часто упускаются или не полностью определяются во время их опросов. Такие требования могут быть выявлены при проведении сеансов СРТ. Такие сеансы проводятся под надзором подготовленного специалиста. Стейкхолдеры
== Спецификация требований ==
=== Списки требований ===
Традиционный способ документировать требования
Соответствующей метафорой может быть чрезвычайно длинный список покупок в магазине. Такие списки крайне неэффективны в современном анализе, хотя используются и по сей день.
Строка 62:
=== Прототипы (опытные образцы) ===
В середине 1980-х прототипирование ({{lang-en|prototyping}}) рассматривалось как решение проблемы анализа требований. Прототипы — макеты системы. Макеты дают возможность пользователям представить систему, которая ещё не построена. Опытные образцы помогают пользователям представить,
Однако за следующее десятилетие прототипирование хоть и было признано эффективной техникой, но не решило проблему анализа требований:
|