Zebranie i opracowanie wymaga? dotycz?cych tworzonego oprogramowania to jeden z fundamentow udanego projektu. Znajomo zakresu prac jest kluczow? informacj? dla wszystkich osob prowadz?cych projekt oraz bezcennym ?rod?em wiedzy dla deweloperow tworz?cych kod. Brzmi prosto, ale wcale tak nie jest! Identyfikacja interesariuszy, dokumentacja wymaga?, okre?lanie ich warto?ci biznesowej to tylko niektore z wyzwa? stoj?cych przed analitykami i ich zespo?ami!
Si?gnij po t? ksi k?, by unikn typowych problemow i pu?apek. W kolejnych rozdzia?ach znajdziesz kluczowe informacje na temat wymaga? dotycz?cych oprogramowania, roli analityka biznesowego oraz dobrych praktyk w in?ynierii wymaga?. Cz II tej ksi ki zosta?a po?wi?cona opracowywaniu wymaga?. Dowiedz si?, jak okre?la? wymagania biznesowe, rozmawia? z u?ytkownikami oraz dokumentowa? i walidowa? wymagania. W prawdziwym ?wiecie spotkasz si? z ro?nymi typami projektow. W zale?no?ci od ich charakteru trzeba b?dzie na bie co dostosowywa? poznane techniki. Projekty zwinne, projekty systemow wbudowanych, automatyzacja procesow biznesowych to tylko cz z omawianych obszarow. Ksi ka ta jest klasycznym podr?cznikiem, obowi?zkow? lektur? ka?dego analityka oraz osob odpowiedzialnych za wymagania.
Dzi?ki tej ksi ce:
- nauczysz si? identyfikowa? interesariuszy oraz rozmawia? z klientami- poznasz dobre praktyki w in?ynierii wymaga?- zrozumiesz zadania analityka biznesowego- ograniczysz ryzyko dzi?ki prototypowaniu- poznasz projekty ro?nego typu- zrozumiesz proces zarz?dzania wymaganiami
Lektura obowi?zkowa ka?dego analityka i osob odpowiedzialnych za wymagania!"
Karl Wiegers is Principal Consultant with Process Impact, a software development consulting and training company in Portland, Oregon. He has a PhD in organic chemistry. Karl is the author of 14 books, including Software Requirements Essentials (with Candase Hokanson), Software Development Pearls, The Thoughtless Design of Everyday Things, Software Requirements (with Joy Beatty), More About Software Requirements, Successful Business Analysis Consulting, and a forensic mystery novel titled The Reconstruction.
Karl has also written many articles on software development, design, project management, chemistry, military history, consulting, and self-help, as well as 18 songs. He has delivered hundreds of training courses, webinars, and conference presentations worldwide. When he's not at the keyboard, Karl enjoys wine tasting, volunteering (library and Meals on Wheels), playing guitar, recording songs (hear them at https://www.karlwiegers.com/songs.html), military history, and traveling.
Although The Business Analysis Body of Knowledge (a.k.a BABoK) is now considered the bible of business analysis worldwide, I can argue that Karl Wiegers’ “Software Requirements v3” should be dubbed as the survival guide for earnest IT Business Analysts. The BABoK has been written by different authors to be a comprehensive and horizontal framework on the subject, and I can say that its third version is much handy than the older one in terms of the logical soundness of the BA practice. However, Wiegers’ “Software Requirements” is the real practical and actionable book on “The Art of Requirements Engineering”. It is not a UML course or how-to, but rather a notation-agnostic complete trove of tips and advice that we need –as business analysts- to master in order to promote the BA profession beyond the mere current activities of hasty requirements collection and -then- mindless superficial dull documentation. Karl brought back deliberation and profoundness into this craft.
Been a BA for about 20 years. Best book on this topic I have read. If I was teaching a class on the documentation artifacts that a BA uses in a typical waterfall style SDLC this would be THE book. If you are not looking for that topic in particular this book might be a 4(or possibly even 3) stars.
First the good things. - Excellent discussion and overview of all the major requiremetns documentation artifacts that are used today. - Covers not only the documents but tries to also cover the "why" behind you should do these documents. (requirements management and traceability for example. Too often BAs tend to fall into the "follow the template and churn out a document" trap, it is alwas good to step back and think a bit about why we do what we do.) - Gives sample templates to illustrate what he is saying. - Covers the SDLC from the start for things like vision statement and scope.
Now the not quite so good things. - I found the "preaching" about the need for good requirements misplaced. While valuable and important I would assume anybody who plunks down money for this book and then wades through the 500+ pages is already motivated on this topic. - The style is a bit academic and theoretical. This is not a good "how to" book, it is a valuable reference. - I did not find the book that helpful for understanding when something is "not so good" as a tool. For example you will read things like "Don't try to force every requirement you encounter into a use case." And lots of descriptions of what a use case does well but I think some examples of where it does not work well would be helpful. - This pretty much assumes a standard waterfall style SDLC approach. It is a bit dated and not helpful for, say, an agile methodology using "stories". - If you are looking for a nice quick easy to read summary this is not the book you want. - The book is trying to cover a lot and so it does not adequately cover everything in detail. If you are looking for specific information to get better on a particular topic, like a use case, get a book on use cases.
تحلیلگران کسبوکار و همچنین مهندسان نرمافزار مخاطب اصلی این کتاب اند.
محتوا
هدف اصلی تحلیلگر کسب و کار (که با نام مهندس نیازمندیها هم شناخته میشود) این است که نیازمندیهای کسبوکار را توسعه و مدیریت کند. هدف از توسعه نیازمندیها استخراج، تحلیل، مستندسازی و اعتبارسنجی آن است تا در نهایت تیم ایجاد بتواند محصول مورد نظر را بسازد. هدف از مدیریت نیازمندیها بررسی و مدیریت تغییرات در نیازمندیهای موجود است.
تحلیلگر کسبوکار برای استخراج نیازمندیها باید از انواع روشها و فنون شناخته شده مانند برگزاری مصاحبه، ورکشاپ، تحلیل اسناد موجود و ... استفاده کند.
در بخش تحلیل نیازمندیهای استخراج شده، نیازمندیها با استفاده از مدلهای مختلف مانند نمودار زمینه، مورد کاربرد و ... مدلسازی میشود.
سپس تحلیلگر کسبوکار باید نیازمندیهای کسبوکار را در سه بخش نیازمندیهای سطح کسب و کار، نیازمندیهای سطح کاربر و نیازمندیهای سطح کارکردی مستند کند.
در بخش اعتبارسنجی تحلیلگر باید مطمئن شود که آیا نیازمندیهای ثبت شده همان نیازمندیهای مدنظر ذینفعان بوده است یا خیر.
جمعبندی
کتاب به بهترین شکل و به صورت جامع تمام مباحث مورد نیاز برای تبدیل شدن یک فرد به تحلیلگر کسبوکار را آموزش میدهد. به همراه کتاب و در بخش پیوست، قالبهای آماده تهیه شده است که تحلیلگر میتواند از آن قالبها استفاده کند. اگر مهندس نرمافزار هستید یا در حوزه تحلیل کسبوکار فعالیت میکنید قطعا خواندن این کتاب را توصیه میکنم.
Definitely a must-read for any beginner Business Analyst. The book well structured and informative, and very practical. Improved a lot in my BA processes after reading it!
Great introduction to the software requirements process. Would recommend to anyone who is working on software development in any capacity - development, project management, testing, etc.
Книга дает хорошее понимание о том, что делает аналитик и как он связан с другими проектными ролями. Не могу сказать, что можно узнать что-то кардинально новое, если опыт в индустрии уже есть, но суммирует знания отлично. Из минусов - отвратительное, ужасное, абсолютно нечеловеческое качество редакторской и переводческой работы. Так много ошибок, опечаток, несогласованностей я не видела, пожалуй, еще никогда.
This article does a solid job of explaining how clinic management software supports doctors—cutting back paperwork, simplifying appointments, and letting professionals focus more on care and less on admin. For teams developing such solutions, it might be worth exploring devops automation of testing reduces the holding cost for insights on how continuous-automation frameworks can keep that backend strong and scalable.
The only reason to read this book is for people who want to get impression of what Business Analysts do. But, first two chapters would be enough. The rest of the book is devoted to making rocket science out of simplest concepts. If a junior BA is not an idiot with below avg IQ, he/she would find it all out in the heat of the battle without much risk.
This book explains the discipline of requirements engineering in a very structured and detailed way. It's good for any kind of reader from a beginner to an experienced professional.
The first two parts of the book about requirements essentals and requirements development are really interesting - they define the main concepts and describe the ways how to elicit and document requirements.
The other parts of the book seemed less interesting to me, primarily because they are discussing some tools and activities that have limited if any application in ordinary commonplace projects. It was a bit boring to read about them.
It's definitely interesting in the sense that every developer ought to know this material, but it's hard to put into practice. It involves getting people to think about and express what they want. That can easily turn into a confrontation as people don't like to think too much!
I'm new to requirements analysis/business analysis, but not new to tech - I'm a career tech writer who was hired to write documentation and requirements, the only person in either role at a small company. I needed something more than the Pragmatic Institute training I was sent to and something more than the agile party line on requirements (document requirements as you go and just enough, not too much - less is more unless it's not enough). After reading this cover to cover, it's geared mainly at new RAs/BAs and has pretty much everything you need to know to start writing traditional software requirements or agile requirements, or reqs that fall somewhere in the middle. Later chapters also deal with process improvement (analysis & improvement strategies) so I imagine it would also be helpful to experienced RAs/BAs. With lots of scenarios and example projects (each ch starts with an anecdote for an example project) it is a bit inflated but I skimmed or skipped some of that stuff. The book comes with sample documents & supplemental material available online from the publisher, which is incredibly handy.
Voor mij het compleetste en beste boek dat ik al gelezen heb over "requirements analysis": van het houden van workshops tot het analyseren, documentatietechnieken en zowel interview- als beschrijfmethodes om - nog voor een project begint - met fantastische en op elkaar afgestemde requirements uit je pijp te komen.
Grote minpunt: doordat dit boek zo compleet en goed is, is het ook een waanzinnige klepper van een boek. Een resumé of één of andere "cheatsheet" was zeker welkom geweest als toevoeging. Nu voel ik mij verplicht dit boek nog een paar keer te doorploeteren om alles door mijn hoofd te laten malen en er alles uit te halen dat er in zit...
I started with an actual book and traded up for a kindle copy - knowing it would be such a valuable resource, I wanted a digital copy...turns out the digital copy was better to read!
I think it can add value to any BA/SA...newb to super experienced [I fall somewhere in the middle and love to learn like a newb]. It also shows where the current process/etc you're using has blatant room for improvement [how changing requirements are managed! #mgmtSaysYesTOOmuch]...and that improvement can always be made even if you're doing well.
Still a good guide for situations where greater rigour in requirements development and management is merited. The tone of the second edition felt noticeably better. This book is good to have on the shelf when I need to write a SRS. This book coupled with Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise cover most requirements challenges on the projects in which I generally end up.
Actually I'm not a SA and can rate this book just from developer's position. This book fully covers the topic of requirements analysis and helped me to delve into this step of software development lifecycle. The books is very easy and interesting to read, most of chapters starts with real life story that helps you to understand a problem and than author gives you a possible solutions. Of course applicability of given solutions, approaches and patterns depends on your project size and developments methodology, but as developer or system analyst you have to know about most of them.
I loved this book, even considering the fact that it took me precisely a year to read it. It encompasses a wide range of topics, all described in a very clear and concise way. This book feels like coming home - I finally clarified all the small gaps that were scattered through different chapters. Of course, it does not provide in-depth knowledge on any particular subject - it merely gives you the background from which you can go in any direction. I wish I had read this book 6 years ago when I was just starting as a Business Analyst. :)
От книги ожидал большего. Тяжеловато читается. Профессия аналитика позиционирована как сложная и ответственная.
На самом деле суть аналитика - в особой форме мышления. Плюс ответственность. Этого достаточно. По опыту. Всё просто и это далеко не самая сложная профессия, к тому же интересная.
В конце книги приведены примеры документов Vision и SRS - довольно полезные. Нашёл несколько фишек для себя.