Практика выполнения: Разработка черновой Спецификации системных требований

Основные назначения этой практики:

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

Стремление этой практики -- проанализировать исходную информацию процесса процесса: преобразовать требования заинтересованных лиц в системные требования, которые определяют то, что должна делать система (функциональные требования) и как хорошо она должна работать (требования качества сервисов). Это начинается с анализа и, если требуется, уточнения требований заинтересованных лица; результатом является Спецификация требований заинтересованных лиц. По существу, требования заинтересованных лиц фокусируются на необходимых возможностях. Они преобразуются в необходимые системные функции (в формулировке "будут"), и документируются в черновой Спецификации системных требований. Для трассируемости идентифицированные системные требования связываются с ассоциированными требованиями заинтересованных лиц. Затем выполняется главный шаг - определение системных прецедентов. Прецедент описывает определенный операционный аспект системы (поток операций). Он указывает на поведение с точки зрения субъекта (пользователя) и на поток сообщений между субъектами и прецедентом. Субъект может быть человеком, другой системой или частью аппаратных средств, внешних к системе, разрабатываемой в проекте (SuD). Прецедент не показывает и не подразумевает внутреннюю структуру системы (представление черного ящика).

Use cases may be structured hierarchically – but care should be taken not to functionally decompose the use cases. Use cases are not functions, they use functions. There is no "golden rule" with regard to the number of use cases needed to describe a system. Experience shows that for large systems, typically 6 to 24 use cases may be defined at the top level. At the lowest level a use case should be described by at least 5, with a maximum of 25 essential use case scenarios. At this stage, emphasis is put on the identification of "sunny day" use cases, assuming an error/fail free system behavior. Exception scenarios will be identified at a later stage through model execution. If more than 5 error/fail scenarios are found for a use case, they should be grouped in a separate exception use case, which are then linked to the "sunny day" use case via an include or extend dependency.

In order to assure that all functional and associated performance requirements are covered by the use cases, respective traceability links need to be established. If functional system requirements are traced to multiple use cases, it is an indication that the use cases are not independent. Ideally, use cases should be independent of one another.

Once the system-level use cases are defined and the complete coverage of the functional and associated performance requirements is assured, the requirements analysis phase ends.