1. Управление требованиями

   1. Анализ и выявление требований

Определение

Анализ требований — это процесс сбора требований к программному обеспечению (ПО), их систематизации, документирования, анализа, выявления противоречий, неполноты, разрешения конфликтов в процессе разработки программного обеспечения. В англоязычной среде также говорят о дисциплине «инженерия требований» (англ. Requirements Engineering). В процессе сбора требований важно принимать во внимание возможные противоречия требований различных заинтересованных лиц, таких как заказчики, разработчики или пользователи.

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

Анализ требований включает три типа деятельности:

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

• Анализ требований: определение, являются ли собранные требования неясными, неполными, неоднозначными, или противоречащими, и затем решение этих проблем.

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

Включает следующие фазы:[1]

• Разработки требований

  • Формирование видения

  • Выявление

  • Анализ

  • Спецификация

  • Проверка

• Управления требованиями

1. Define business requirements

Business requirements specify business goals or values that should be achieved with considered software.

Examples:

• Capture market share in X

• Achieve profit on X

• Save costs on X.

• Process at least X transactions per day.

Business requirements should be SMART (specific, measurable, attainable (not impossible), relevant, time-based (not open-ended) )

2. Define stakeholders

Business users involved into product.

3. Identify project constraints

There are five major constraints:

• Features

• Staff

• Quality

• Costs

• Schedule

Diagram:

4. Table of freedom

Constraint	Driver	Degree of freedom

5. Define project success criteria

Business Stakeholder, Measurable, priority

6. Define Project Vision and project Scope

Project vision should be divided in terms of the following words:

• For

• Who

• The

• Is

• Unlike

• Our Product

7. Context Diagram

TBD

8. Способы получения требований

• Интервью

• Анкетирование

• Наблюдение

• Самостоятельное описание требований

• Совместные семинары

• Прототипирование

2. Proposal development

Proposal content:

• Company overview and benefits.

• Project description.

• High level technical proposition.

• List of features.

• Estimate.

• Schedule (Feature levels).

• Product release criteria.

• Collaboration vision (Determine collaboration & communication types).

• Commitments.

• Final price.

3. Feature levels

Table example

Feature No	Release 1.	Release 2.	Release 3.
Feature 1	13.01.13	11.02.13	13.04.13

1. Product Release Criteria

Release criteria should be SMART

Features	Release criteria for the area
Quality Assurance	...
Certification	...
Bugs	...
Documentation	...
Performance Certification	...

ID	Description	Measurement method	Target value	Implications if not satisfied.

2. Commitments

Commitments should be represented as table:

Commitment	Person who made commitment	Commitment date
Commitment 1	Vasiliy Pertrov	11.02.13

4. Software Requirements Specification (SRS)

STS is the document being developed at the beginning of the project. It consists of the following sections:

• Functional Requirements

• Nonfunctional requirements

• Acceptance Criteria