Как да станете истински анализатор, част 2

Извличането на изисквания е най-трудната, важна, податлива на грешки и интензивна за комуникация фаза от разработването на софтуер. Извличането на изискване е творчески процес и всеки използва собствените си инструменти, за да получи резултата, т.е. изисквания. В моя багаж има такива методи, които наричам „Класически“, т.е. Това са триковете, които работят в 90% от случаите. Традиционните методи за идентифициране на изискванията включват използването на интервюта и въпросници, наблюдение и изучаване на бизнес документи. Това са прости и икономични методи. Надявам се, че опитните хабраузери ще добавят своите към списъка.

Разделяне на потребителите на групи

За да не се изпускат от поглед нуждите на отделните потребители, е необходимо:

Опитайте се да класифицирате потребителите според различни характеристики. Например по честотата на работа със софтуера, използваните функции, нивото на привилегии и работни умения.
Изберете активен потребител във всеки потребителски клас. Този човек ще представлява интересите на определен клас потребители и ще взема решения от тяхно име.

IMHO: Изберете не онези хора, които говорят много, а тези, които говорят по същество.

Работете с потребителите, за да изясните изискванията към продукта

1. Разпитване / интервюиране

2. Наблюдение

Наблюдавайте работата на потребителя. Не бъдете мързеливи, за да прекарате един работен ден за това! Използвайки този метод, можете да идентифицирате неявни системни изисквания, които потребителят не е изказал. Понякога дори се оказва, че потребителите изобщо не се нуждаят от нов софтуер, за да изпълняват задачи.

3. Провеждане на съвместни семинари

Проучване на доклади за проблеми на работещи системи или подобна система, за датърсене на нови идеи

За да идентифицирате изискванията, можете да използвате информация от услугата за поддръжка. Прегледайте отчетите на клиенти за проблеми и предложения за подобряване на функциите. Можете също така да изучавате подобни системи (системи на конкуренти), да идентифицирате техните силни и слаби страни. Това са страхотни източници на идеи, които могат да бъдат приложени в бъдещи версии или в нов продукт.

Изисквания за повторно използване в проекти

Ако функционалността, която клиентът иска, вече е внедрена в друг продукт, предложете на клиента гъвкавостта да преоцени своите изисквания за използване на съществуващите компоненти.

Как да разберем, че събирането на изисквания е завършено?

Няма конкретни индикации, че извличането на изисквания е завършено. Невъзможно е напълно да се идентифицират изискванията, но следните знаци ще ви кажат, че източниците на информация са почти изчерпани:

потребителите вече не могат да измислят нови случаи на употреба.
потребителите предлагат нови случаи на употреба, но вие вече сте извели съответните функционални изисквания от други случаи на употреба.
потребителите описват проблеми, които вече са били обсъждани;
предложените нови функции са извън обхвата на проекта;
потребителите предлагат функции, които има смисъл да бъдат приложени по-късно.

Въпреки най-добрите ви усилия, няма да можете да идентифицирате всички изисквания, така че бъдете готови да правите промени, докато работите по проекта. Не забравяйте, че вашата цел е да формулирате изисквания, които са достатъчни, за да позволят приемливо ниво на риск при разработката. В следващата статия ще споделя с вас опита от анализа на изискванията, ще разгледам различни графични модели и др. До следващата среща.

Литература:

Как да станете истински анализатор на изискванията. Част 1. Раждат ли се или стават великите анализатори?

Работа в Nordavind

Коментари 29

Очаквам с нетърпение следващата статия.

Когато изясняваме изисквания, когато вече имаме частична документация, ние се връщаме на потребителите с тази документация. На практика потребителите рядко разбират абстракциите, формулирани от изискванията. Ето случаите на използване по-близо, защото това са по същество техните действия стъпка по стъпка. Още по-добър начин е прототип и случай на използване. Прототипът не трябва да бъде написан от програмисти като част от бъдеща система. Може да бъде макет или чертеж на хартия. Вярно е, че най-често потребителят ще започне да обсъжда дизайна. Например този диалогов прозорец: Потребител: Ще изглежда ли този бутон по-добре отляво? Аналитик: Защо? Потребител: Добре тогава, след като щракнах върху него, изскачащият текст не скри тази информация, но за мен е по-удобно да виждам и двете едновременно.

Опитен анализатор веднага се вкопчва в думата „трябва“ и вече се чуди: „Това качествен атрибут ли е или функционално изискване?“

Възможно ли е да се свърже блок-схемата с цикъла на Деминг за управление на качеството:

- Подобряване - Планиране - Изпълнение - Анализ -

Според мен изглежда така.

Тази схема също съответства на функционалния цикъл на Петр Кузмич Анохин.

Едно от описанията на подхода е дадено на http://www.zooton.net/ind1026.html

Оттам - диаграма на реакцията на човешкото тяло:

Така че тази класика има и физиологична основа.

Факт е, че дейността на анализатора също може да бъде подложена на анализ. Моите предложения за анализ на човешката дейност - в http://integral-community.ru/forum/viewtopic.php?f=8&t=12#p68

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

Поздрави, Алексей.

Бих искал да чуя опит относно разрешаването на конфликти на интереси. Това се отнася за конфликт на интереси на потребителите (мениджмънтът на клиента също е потребител). Директен саботаж (кой трябва да въведе нещо ново, той също ще се намеси, по-добре е да объркате всичко) и други човешки фактори?

Бих искал статия по тази тема.

В крайна сметка баналният подход - слушайте този, който не отива по-високо - иска повече контрол, често неподходящ и т.н.

Докато работите с потребители, ще задавате въпроси, ще слушате за отговори и ще наблюдавате техните действия (извличане на изисквания).

За да не се изпускат от поглед нуждите на отделните потребители, е необходимо:

Попитайте потребителите какви задачи трябва да изпълнят с помощта на софтуера.

Правилно разбрах, че предлагате да се разработи система само въз основа на изискванията на потребителите? Какво ще кажете за бизнес изискванията? Как протича работата с различни заинтересовани страни – клиент, спонсор, собственик на системата, купувач, продавач, изпълнител?

Мисля, че е важно да подчертая, че първо трябва да получите проблемен модел на ключови заинтересовани страни и след това да отидете на проучване на потребителите.

Защото в противен случай можем да отидем да разследваме дейността, която няма нищо общо с проблемите на клиента и нейната промяна / автоматизация няма да ги засегне.

И ако трябва да обсъдите техните задачи с потребителите, и може бижелания за дизайна на системата, тогава с клиентите е необходимо да се обсъдят на първо място бизнес проблеми и бизнес ефекти, методи за измерването им и др.

Аз също го харесвам. Но защо не препоръчате по-мек запис - например от 60-100 страници? bagcheck.com/bag/1377

Запозната ли сте със статията на Химонин?

Защо да създаваме толкова висок праг за влизане? Полезен ли ви е този „елитаризъм“ на анализаторите? Не всеки, който мечтае да стане анализатор, ще лети до средата на Wigers?

„Нужда“ е от един идеален свят. В реалния свят 95% от изискванията са написани от ръководители на проекти, които нямат специализиран анализатор, защото това не е рентабилно за техните проекти.

И сега мениджърът има развитие на изискванията - това е

Основите могат и трябва да бъдат разбрани от по-прости и кратки книги. Защо да губите време в анализиране и търсене на полезна информация в голям текст, когато можете да прочетете кратък?

Защо да губите време в анализиране и търсене на полезна информация в голям текст, когато можете да прочетете кратък?

По принцип нямам нищо против дългите уроци. Против съм първият учебник по темата да е дълъг учебник.

Ами за смилаемостта при сърфиране на голямо вместо на кратко - не ми се вярва.

Абсорбцията не показва това.

Има различни задачи, режими и формати: Въведение - преглед на материала Дълбоко потапяне - изследване Изучаване на специфична методология - наръчник за обучение Преразглеждане на вашия опит - модел на процес, подход, карти на концепции и явления Помощ - справка

Настоявам кои точно Химонин и Лефингуел, а от май и Корнипаев, а след това Кон и Кобърн, ще бъдат по-добър вариант за ученика на анализи и изисквания от отвратително преведените на български многостранични Вигери.

Чели ли сте Vigers?

Против съм първия урок по темата да едълъг урок.

Не мога да споря с въпроса за отвратителността на превода, ако не съм го чел.

Въпросът за асимилацията не е толкова въпрос на размер, колкото на концентрация на нови знания.

Ако опитен инженер е напълно доволен от такъв запис

Колелото е устройство за намаляване на триенето при движение на предмети. Колелото е кръгло. Другата форма обикновено е неефективна, но има варианти. Технически колелата са сравнително малки устройства, прикрепени към основното превозно средство, така че да могат да се въртят свободно. Ефектът от намаляване на силата на триене се основава на факта, че силата на триене при търкаляне е по-малка. Недостатъци - сложността на дизайна, изисква по-добри материали и обработка Предимства - значително намаляване на силата на триене и в резултат на това икономия на енергия.

За да се намали броят на робите, необходими за транспортиране на товара, е необходимо да се намали усилието, необходимо за преместване на товара. Нека си представим, че трябва да преместим сто хиляди огромни камъка. Очевидно броят на робите, необходими за преместване на всеки камък, зависи от теглото на камъка. Не можем обаче да направим камъка по-малък - тогава ще имаме нужда от повече камъни, така че печалбата ще бъде под въпрос. Нека помислим - какво пречи на камъка да се движи? Оказва се, че това е така наречената сила на триене. Да, не се учудвайте - камъкът просто се трие в пътя и това му пречи да се движи по-бързо. Силата на триене зависи от много фактори - от теглото на камъка, от неговия размер, от площта на контакт с пътя, от качеството на пътя, от гладкостта на камъка и от много други фактори. Дори нашите предци са забелязали, че по-гладък камък е по-лесен за теглене, ами акополивайте пътя пред камъка, тогава ще бъде по-лесно да теглите, че можете да поставите меки кожи под камъка и много други трикове. Откритието обаче беше революционно, че силата на триенето при търкаляне е много по-малка - всъщност, ако натиснете дънер така, че да се търкаля, ще бъде много по-лесно да направите това, отколкото да го бутате перпендикулярно. Въпреки че изглежда, че зоната на контакт с пътя е същата, теглото е същото и т.н. Ще научим за причините за това невероятно явление в следващата глава. И сега ще научим как да го използваме. Нека поставим пет или шест цепеници под нашия камък. Така бутането на камъка става много по-лесно. Камъкът обаче се движи над трупите и те трябва постоянно да се пренареждат отзад напред. Как това може да се подобри допълнително? Представете си, че не поставяме цели трупи под камъка, а само къси парчета по ръбовете на камъка. Разточването на такава конструкция не е по-трудно от предишната, но е адски нестабилно, клиновете винаги се стремят да се разточат ... Нека свържем противоположните клинове с дълга пръчка. И ние ще свържем тези пръчки една с друга с други пръчки, но по такъв начин, че пръчките, свързващи клиновете, да могат да се въртят свободно в кръстовищата. Нашият дизайн стана малко по-малко бърз, поради силата на триене в кръстовищата, но много по-стабилен. И като бонус - можем да фиксираме настилката върху напречните пръчки, които няма да се въртят, което означава да сложим нашия камък върху него, няма да се налага да местим нещо и т.н. И така, скъпи читатели, тези клинове, върху които се търкаля нашата конструкция, се наричат колела.

Вие сте тези, които демонстрирате различни стилове на представяне. Вторият стил, по-обемен и описателен, не е това, което прави Wigers различни.

Моят опит показва, че среднопри същия стил на представяне, вероятността да прочетете книга е обратно пропорционална на квадрата на нейния обем.