При рассмотрении спецификации требований, что “смертельно грешит” потребность, которая будет обращена? [закрытый]

Вы могли бы рассмотреть чтение части управления Требованием и документов CMMI.

Также посетите Контрольный список Требования и Google для "Критериев Хорошего Требования".

Они специально предназначены для создания помощи процессов в разработке программного обеспечения.

• Разделение функциональных, архитектурных, интерфейсных, нефункциональных требований.
• Использование однозначной и последовательной нотации для описания объектов
• Ясные критерии входа и выхода вариантов использования
• Имейте блок-схемы (интеллект-карты служат той же цели как UML и легче потянуть),
• Определите объем ясно, что покрыто и что не и где найти оставленных неизведанными
• Имейте матрицу трассируемости

Все знание wikpedia имеет хорошее резюме для требований - http://en.wikipedia.org/wiki/Requirement#Good_requirements. Я сказал бы, что та из тех точек, отсутствия verifiability - то, что наиболее распространено. Понимание большое изображение важно в жизни, однако, необходимо обстоятельно объяснить вещи явно в Вас требования, напр. Система должна быть, отвечают быстро. Вместо этого система должна ответить на все запросы меньше чем через 2 секунды.

Моя рекомендация и что я всегда делаю перед новым проектом, является двойной проверкой контрольный список на Странице 42,43 Завершенного Кода Steve McConnell

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

Удостоверьтесь, что все абсолютно ясно: неопределенный == Плохая Вещь (TM)

По строгому - Если возможно указывают соответствующие допуски.

Неоднозначные требования плохи.

И неисчислимые требования неподдающиеся проверке удваиваются так.

Естественно, все это зависит от того, какое требование Вы получаете. Я привык к типичному Gui или веб-приложению, пакетным обработкам и

• Поднятые standars сначала, которые не должны быть определены в каждой спецификации, относятся к ним
• Сделайте его как можно меньше - редко можно прочитать документ на 200 страниц и иметь в виду все
• Будьте конкретны, mesurable, конкретны
• Сделайте примеры (рисунки, бухгалтерские записи)
• Объясните цель прежде, чем описать funtction
• включайте стандарты производительности, устойчивость standars, инструкции по развертыванию, документация для необходимых операций

У меня есть также один единственный совет для рецензента: знайте свой предмет

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

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

Требование не указывает, кто/какой делает вещь.

"The invoice is reconciled to the purchase order."

Это означает, что система делает что-то или пользователя?

Требования, которые не легко проверить столь же встречаемый - Изменение в форме, которая может быть более легко отмечена, как встречено или не при рассмотрении.

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

Функции, Время, Качество - выбирают любые два. удостоверьтесь, что требования не налагают все три на Вашу команду.

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

Попросите четкое установление приоритетов с начала.

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

Создание предположений - двойная проверка, чтобы что-либо, что похоже на предположение, было на самом деле проверено.

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

Недостающие требования - Намного тяжелее для ловли. Seperating требования в ясные разделы (например, безопасность, производительность, моделирование, и т.д.) может сделать это легче определить.

Худший я видел на проекте, что кодировал для:-

The system shall interface to SAP as required.

Во-первых, требование с "как требуется" в нем глупо. Та одна строка, должно быть, стоила $400 тысяч. Клиент продолжал указывать на него и говорить, что это говорит там, что Вы собираетесь сделать вздор, вздор, вздор.