Подробная документация по вариантам использования [закрыто]

Question

Я прилагаю большие усилия, чтобы дисциплинировать свои проекты и с самого начала создать документ «Видение/Объем».Сюда входят диаграммы вариантов использования.Простое перечисление вариантов использования действительно помогло мне полностью увидеть все требования, которые запрашивает клиент, и открыло диалог.

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

Если нет, то когда мне следует документировать эти детали?

Answer 1

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

Столбцы отчета являются частью спецификации дизайна или требований (детали функции в терминах agile) и нет принадлежать к диаграмме вариантов использования

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

где?это не имеет значения, если это постоянное место и вы знаете, где его найти ;-)

напомнить людям, как выглядит диаграмма вариантов использования и почему в ней нет места ложным деталям.
_{(источник: agilemodeling.com)}

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

Описание варианта использования должно быть между:

• Низкая детализация:Так что пользователь понимает это и думает:"Как легко это делать"
• Высокая детализация:Нет открытых возможностей (подробное описание того, что происходит после каждого шага)

Answer 5

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

На самом деле вариант использования должен быть в письменном формате.Имеет три формата.

1. Краткий
2. Повседневный
3. Полностью одет

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

Подробности...Видеть «Применение UML и шаблонов:Введение в объектно-ориентированный анализ, проектирование и итеративную разработку Крейга Лармана»