What is wrong with Wiegers’ classification of requirements?
The classification of requirements given by Karl Wiegers in his book “Software Requirements” is well known to most analysts. This book, thanks to its popularity, has become a kind of Bible for the analyst, and the classification of requirements has entered most courses on business analysis.
But when analysts try to use this classification in practice of different types of projects, they often face difficulties. I propose to dive into the analysis of these difficulties to get understood what is wrong with the Wiegers’ classification of requirements, and how it can be improved.
Worth a thousand words. Drawing diagrams with a customer
A variety of diagrams is a powerful tool in the arsenal of an analyst. They are widely used within development teams for analysis, transmission and storage of information in a compact visual form. It would be great to use their advantages when communicating with customers. But such attempts usually come up against the difficulty of not understanding diagram concepts and notations by untrained people.
In my talk, I will share the experience of using visual schemes when communicating with customers during the pre-project survey and analysis sessions. I’ll tell you about the basic elements, types of diagrams used, techniques for their use, emerging problems and how to solve them.
Human in Software Development: Factor or Actor?
Developers never read specifications, and users never read the documentation.
A customer never knows what he wants.
An ingenious user will always find a way to bypass fool-proof.
You're undoubtedly familiar with this IT folklore. And, of course, you have met such situations more than once. But do you know how to manage them because you always consider the human factor in your work?
But is it correct to call the factor just everyday human interaction?
There are two rules a business analyst should always keep in mind:
1. Software products are created for people.
2. Software products are created by people.
Despite the obviousness of these rules, their understanding dramatically facilitates the work of the analyst. They directly affect the choice of effective approaches, design methods and formats of requirements and other results of the analyst’s work.
We will examine in detail this influence and how it helps analysts in their work.
Go and draw! Modeling in the analyst work
All analysts know: the best way to exchange information is drawing models together on a white board. Everyone knows, but almost no one uses.
This is surprising, because visual modeling is applicable almost everywhere in the analyst's work. At each stage of identifying, analyzing, documenting requirements and transferring them to development, drawing the models gives unquestionable benefit.
We'll consider some examples of visual models suitable for basic cases in the analyst's work. We'll also discuss a set of simple modeling principles that allow creating intuitive and effective models.
Modelling is the Simplest Thing
In the talk it will be presented a list of simple principles and a minimum set of elements for visual modeling, that can be used for teaching entry-level analysts, and for practical purposes in the identification and description of requirements.
The talk is a development of the topics raised in my speech at the Analyst Days - 2015 "Why does the UML a bad choice for teaching of entry-level analysts": https://vimeo.com/127806626
Why UML is a bad choice for beginners
Most visual modelling courses for BA are based on UML. The author's experience shows that using UML to teach beginners is not a good idea.
Some reasons of that will be presented and analized in the speech, illustrated by real cases collected from BA site forum.
A possible solution will be proposed: a simple set of elements which may be used to learn visual modelling.