Feeds:
Записи
Комментарии

Posts Tagged ‘Требования’

Если смотреть на мир из черепа обыкновенного заказчика ПО, требования — совершенно лишний артефакт, который отнимает очень много средств и ничуть не гарантирует получение качественного результата. Вам надо — вы их и прописывайте.

А загляните в череп опытного заказчика ПО — он требования прописывает сам. Всегда. Да, общепонятно, что через требования он хочет получить хотя бы именно, что было заказано, но засада не в том, что «без ТЗ результат ХЗ» (можно ваять ПО и без предварительного малевания ТЗ). Проблема в коммуникациях. Чем более опытным становится заказчик, тем сильнее он эту проблему осознает и начинает решать.

(далее…)

Read Full Post »

А почему мы, тестировщики, столько времени возимся с функциональными требованиями? А как же остальные требования, коих тоже много, и кои тоже важны?

А дело в том, что функциональное требование это ‘A description of a behavior that a system will exhibit under specific conditions‘.

Продумывать ситуации, в которых может оказаться программа, и предусмотреть, как она должна из этих ситуаций выкручиваться — это ли не задача тестировщика?

Это.

На очень высоко абстрактном уровне все требования делятся на четыре слоя:

  • бизнес-требования,
  • пользовательские требования,
  • функциональные требования,
  • всё, что угодно, что попадает под понятие «нефункциональные требования».

Дальше начинается преданье, дальше начинается ересь от «По-моему, под функциональными требованиями подразумевается, что…» до «Шо вы мине голову морочите вашими требованиями, возьмите и напишите их себе сами, если они вам так нужны…»

Конечно, можно нужно учесть, что требование и спецификация — не одно и то же. Но чего это учитывать — их писать надо.

В алфавитном порядке толкование самых толковаемых терминов:

Business requirement
A high-level business objective of the organization that builds a product or of a customer who procures it. Это «Хотелки», которую ещё нужно правильно отобразиться в функциональных требованиях (коих может быть больше, чем одно), которые в свою очередь должны превратиться в спецификации.

Неприятность в том, что хотелки дают ответ только на вопрос «Зачем нужно что-то делать?», а большинство считает, что «Чё там валандаться по одному порошку в день, ох, тьма египетская в глазах…», и подразумевают, что хотелки будут рассказывать и зачем, и как это надо реализовать. Как же, читай потом этих доку-монстров…

Business rule
A policy, guideline, standard, or regulation that defines or constrains some aspect of the business. Not a software requirement in itself, but the origin of several types of software requirements.

Constraint
A restriction that is imposed on the choices available to the developer for the design and construction of a product.

Feature
One or more logically related system capabilities that provide value to a user and are described by a set of functional requirements. И попробуй теперь пересказать это своими словами, слабак.

Functional requirement
A description of a behavior that a system will exhibit under specific conditions. Ключевое слово — «ситуация».

Nonfunctional requirement
A description of a property or characteristic that a system must exhibit or a constraint that it must respect. То есть, нужно учитывать.

То есть, дураком буду, если скажу, что нон-фанкшынал рекуайрментс — это же не требования, бо есть же слово «нон».

Quality attribute
A kind of nonfunctional requirement that describes a service or performance characteristic of a product. Кто это учитывает?

System requirement
A top-level requirement for a product that contains multiple subsystems, which could be all software or software and hardware. Как такие требования пишутся?

User requirement
A goal or task that specific classes of users must be able to perform with a system, or a desired product attribute. Не надо ждать, что пользователи придут, и предъявят свои требования. Будет очень плохо, если пользователи придут с требованиями.

© «Software Requirements» by Karl Wiegers and Joy Beatty, Third Edition, PUBLISHED BY Microsoft Press, ISBN: 978-0-7356-7966-5

Read Full Post »

Иногда бывает сложно начать работать с требованиями.

Мешают толстые книги, в которых в подробностях описано такое, что становится страшно вообще думать о документировании требований, а не…

Однако есть простейший способ для начала работы с требованиями. Вот пример issue:

Summary «Export product list to Excel (csv)»

Description [3:42:34 PM] Маркетинг: а на счет экпортировать репортик?
будет такая возможность?
[3:42:56 PM] Программист: tebe nado exportirovati vse dannie ili postrani4no?
ili konkretnuiu stroku?
[3:44:20 PM] Маркетинг: одной строки не достаточно. мне надо чтоб то что я выберу фильтром (все отфильтрованные продукты) можно было скачать и потом работать с эксель файлом.

Status: Resolved.

И все отлично 🙂

А главный секрет в том, чтобы требования хотя бы как-нибудь хотя бы где-нибудь были записаны в виде БУКВ, а не в виде «Мы созванивались и это дело обсудили«.

Оформлять все это дело можно потом как угодно по какой угодно схеме и методике.

Read Full Post »

Вовлеченным в процесс все понятно сразу и безусловно:

Read Full Post »

%d такие блоггеры, как: