Как управлять требованиями

Методы анализа требований

Бизнес-аналитик проекта как правило, несет основную ответственность за управление требованиями. Он выбирает механизм хранения требований, определяет атрибуты требований, координирует обновление данных о состоянии и отслеживает обновление данных, а также следит за изменениями в операциях, если это необходимо.

Возможные атрибуты требований:

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

Отслеживание состояний

Часто возникают проблемы с требованиями(Отсутствующее требование, неправильное требование, вопрос по реализации, ненужное требование) и эти проблемы приводят к изменениям.

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

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

Незапланированный рост рост объема и управление им:
документирование бизнес-целей, концепции, границ и ограничений новой систе-
мы. Оценивайте каждое предложенное требование или функцию, соотносясь с бизнес-требованиями. Если задействовать клиентов в сборе информации, то снижается количество требований, упущенных из внимания. Составление прототипов — это еще один эффективный прием управления незапланированным ростом объема. Прототип помогает разработчикам и пользователям выработать общее понимание нужд пользователей и необходимых решений.
Либо сказать "нет".

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

Трассировка - это возможность отслеживания связи между артефактами.

причины для трассировки:
1. Позволяет управлять скоупом и бэклогом. Когда мы работаем с требованиями постепенно от бизнес целей к функциональным требованиям. Но когда заказчик начинает набрасывать требования, тогда путем трассировки можно определить является ли новое требование частью нашего скоупа и несет ценность.

2. Анализ изменений. Если меняется верхнее уровневое требования путем трассировки мы можем понять в какие декомпозированные требования следует внести изменения.

3. Управление приоритетами. 3 бизнес цели, у каждой бизнес цели 4 бизнес требования, у каждого бизнес требования 8 пользовательских историй. Суммарно это 96 требований. Если есть трассировка, то можно проследить связь между артефактами нижнего уровня с требованиями верхнего уровня. т.е. поймем какие сторис относятся к бизнес целям.

Трассировка требований

Change request

Change always happens. No matter what project you are on, no matter how well a requirement is documented, many situations arise where the requirements must change. Client Business logic has changed, new regulatory requirements arise, internal teams have discovered a need to update the solution; no matter the situation, signed-off requirements may need to be updated, changed, or removed.

Depending on the project methodology your organization uses, be it Waterfall, RUP, Agile, Hybrid-Agile, an effective way to track project requirement changes is via the use of Change Requests. This blog post will delve into the creation of the Change Request, but not the approval process behind it, as various development methodologies have different ways of approving the Change Request.

A Change Request document, in itself, is a formal document that allows you to capture how a simple or complex business or technical change impacts the existing implementation of a project.

Below are some key components of an effective Change Request:

• The project name;
• The request number;
• The requestor;
• Description of the change;
• The reason for the change;
• The impact of the change;
• The proposed action to be taken;
• The business priority of the change;
• The status of the change (approval block).

The Project Name

• This should contain the unique project name or identifier that your organization uses to identify projects, initiatives, or solutions.
• Additionally, if a solution is in production, it would be good practice to identify which release version is impacted.
• This element ensures that the Change Request is applied to the correct area of the solution.

The Request Number

• This should be a unique identifier for the Change Request.
• Having a unique identifier makes it easier for stakeholders to reference specific Change Requests, and helps when capturingChange Requests within the Project Change Log.

The Requestor

This section identifies who requested the change -

• Internal Stakeholder & team;
• Client Stakeholder.

Description of the Change

This section should contain meaningful information that allows those who pick up the Change Request to understand, at a glance, what the Change Request pertains to.

• A concise but clear description of the change that is being requested.
• Avoid being overly verbose or adding detailed business logic/requirements into this section, as that information can be captured elsewhere in the Change Request.

The Reason for the Change

This section allows you to document the reason(s) behind the Change Request. This section also provides the readers of the Change Request with further context into the drivers behind the change.

• Changes to client business logic;
• Changes to technology;
• Regulatory change requirements, etc.

The Impact of the Change

This section should identify the areas of the solution or document artefacts that will be impacted by the Change Request:

• Changes to specific (signed-off) Business Requirements;
• Changes to specific(published) Business Documentation (manuals, specification documents, etc.);
• Changes to Product Specifications;
• Changes to application modules;
• Changes to Business Rules/Logic;

The Proposed Action to be Taken

This section provides the details of the action(s) that will be taken to address the change requirement

• This section should include some or all of the following:
• Details of Application modules or functionality to be changed;
• Details of Business requirements to be modified (detailed text);
• Details of Business Rules/Logic to be updated (detailed update with any logic examples);
• Details of the updated solution configuration or development work;
• Details of updates to Business Documentation;
• Details of updates to Product Specifications
• This section may be completed by multiple contributors, including (but not limited to):
• Business Analysts
• Data Analysts
• Solution Architects
• Enterprise Architects

The Business Priority of the Change

This section would provide the context to the importance of the change to the Requestor making the request.

• You can use the priority hierarchy that your organization uses, which may be a variant of:
• Critical
• High
• Medium
• Low
• Defining the Business Priority allows Development Leads, QA Leads and Project Managers to allocate the correct resources to the change initiative.

The Status of the Change (Approval Block)

The Status of the Change allows readers to identify where, along the approval process the Change Request lies.

• Use the status hierarchy that your organization uses, which could be a variant of:
• New
• In Review
• Approved
• Rejected
• The Change Request Approval is typically provided by the Project Sponsor, and may not necessarily be the Change Request requestor.
• As a matter of ensuring accuracy, the Change Request should be reviewed by the requestor to ensure that the Change Request accurately captures the changes required.

Author — Francis Roque, DLT Labs™

About the Author: Francis Roque is a seasoned Senior Business Analyst with vast experience and extensive knowledge. His experiences span Fintech, Financial Regulation, Human Resources, Telecom, Consulting, Managed Services, and now Freighttech and Distributed Ledger technology.

Оглавление