Review of the book "Developing Software Requirements" by Karl Wigers and Joy Beattie
In 2018, the book “Development of requirements for software” was republished. Colleagues sent me a link to the publication. The authors added techniques for working in agile projects, defining the role of an analyst, and recommendations on automation. In the web go extremely controversial reviews . I ordered the book and figured out the question.
Beginners will get a complete picture of the work of the analyst. Pros remember what they faced themselves. Disassembled all the stages of creating specifications. Appendix B contains a manual compiled on the principle of “problem - solution”. The table of contents itself acts as a hint. Detailed checklists are contained in almost every chapter. For example, the specification pattern includes 8 items, 24 subitems and two appendices. A comprehensive guide.
Information is clearly structured, and it makes it easy to search by book. The table of contents is written on 9 pages. It quickly finds the necessary stage and explanation. In each chapter there are references to other chapters, if any question is described there in more detail. At the end of the manual provides a glossary of terms, so you can not be afraid of such phrases as "UML", "waterfall life cycle of the project" or "CRUD-matrix". For a couple of minutes there is a PDF version of previous editions, you can use the search on the document, if you need specific data.
')
Analysts come into contact with all who participate in the project: customers, designers, developers, testers, sales people, support and users of the product. And each group should know how to adequately relate the technical task to what they are doing. An inexperienced employee may ask something like: “Where is it written that when you click on this element nothing should happen?” If he reads a book, he will answer this question and leave reasonable comments to the document.
It’s difficult to read the manual without using it, but after the 700th page it becomes easier :) In the course of the presentation, each concept is given in brackets its original in English. This is convenient because the translator is not always accurate and you can open Wikipedia in English. At the end of the book is a glossary of terms with explanations. True, there are not all the concepts that occur in the manual. To supplement the list, I had to finish writing 50 new phrases and page numbers.
Authors abuse long sentences and unnecessary information. Because of this, the meaning is harder to grasp.
Leo Tolstoy, are you?
And on the flyleaf it is written that this is a guide, not a philosophical treatise.
The authors do not repeat twice, do not repeat.
Data = information. And there is something in it!
And such a semantic noise throughout the book. There is a suspicion that the authors were paid for the lines.
In the course of reading counted them more than 160. All errors in the school program. For example: words are omitted, “-hya” is used instead of “-hya”, sentences are repeated in one paragraph, there are commonplace typos, commas are missed, concepts that are written in a similar way are confused.
The first error occurs as soon as you open the book. Chris has no delusions of grandeur, just confused her with Carl, who dedicated a book to her. They are spouses.
How do you like this phrase?
In the course of the presentation, the authors repeatedly mention the products of Microsoft. They are so famous that it makes no sense to write about them. And when it is necessary to call the requirements management system (SUT), the authors are silent about them. I only read this chapter for their sake. Just the book was released by Microsoft Press, while the “small-scale” one does not have a full-fledged system. The company's loyalty outweighed professional debt.
For example, in Appendix B, the authors provide an example of requirements documentation. They write that customers should be able to change subscriptions. But it does not say about the creation of subscriptions. How can you change something that has not been created yet? Missing initial stage.
Or it is stated that the system should allow the client to specify the method of payment. But it is not written about the confirmation of payment. What is the point to indicate how you want to pay if the payment cannot be confirmed? Missing final stage.
The remaining steps are spelled out in the application in some detail. Against this background, missing links in the chain of options leave a feeling of lack of agreement. It is clear that applications are given for example, but still.
Before reading, I thought something like this: “What can an American advise us? They have everything in the figure, and there are no problems. ” It turned out that the problems are about the same.
As the familiar developer said, “I don’t read the TK, but immediately write the code.” This is not a balanced approach. The implementation is not coordinated with interested parties, additional options are not explored, overlooked links with other elements. Increases the risk of error and its price. If the user finds an error after the release, then its price increases by 21 times. At the stage of TK to eliminate it is much cheaper. But as long as the companies do not seriously refer to the specification, they will “like the best, but it turned out, as always.”
Business requirements (business requirements) describe why the organization needs a system, that is, the goals that the company intends to achieve with its help. But if you look at the average Russian companies, it creates a strange impression. Some do not understand why they produce, while others do not understand why they buy. But ambitions swell and bet on seals on Instagram. It happens, you communicate with another genius from Skolkovo, and he passionately imposes invented needs on clients. As a result, the company looks like a vegetable, and the budget looks like a leaky bucket.
This is not possible, because after redesign you have to edit the TK. This is a waste of time. It is not necessary for the specification to depend on the design. Let the designers have the choice of how to implement this or that requirement. For example, the “Delete” control element can be represented as a button, icon, link, swipe, context menu item. It is better to describe it through functions and circuits, rather than interfaces. Not "the system displays a drop-down list", but "the system provides a choice."
For example, in one company, analysts have expanded responsibilities. They were instructed to inform the authorities about when this or that requirement is realized and by whom. If there was a delay, then find out why. Translated the task in stages and appointed responsible from other departments. As a result, the content part suffered. Everything described is the responsibility of a project manager. The manager is responsible for the exchange of information about the project, the analyst is responsible for the exchange of information about the product. These are two different areas of activity.
One boss wanted those working with the TK to know them closely to the text. It is unreal. There are several dozens of TZ in the company, and their number is increasing. If you yourself finished drawing up a TZ a month ago, you still forget it, because then you plunge into 2-3 new ones. The problem is not solved at the expense of memory, but at the expense of the implementation of requirements management systems (DCS). They support the identification, management, tracking and withdrawal of requirements. But you have to pay for them, and employers prefer to work in the old manner, as in the saying:
Post Scriptum
I wrote to the publishers of a version of the book in Russian about the errors and offered to correct them together. The request was read, but the staff did not respond. So they consider illiteracy the norm. This is sad because the original is fit.
The book leaves a controversial impression because of its unfoundedness. Content is high and form is not. It scares. But if a specialist wants to be held as an analyst, he will have to understand by volition what the authors wanted to say. This is not easy, but the time spent is worth it, and you will respect yourself a little more.
pros
Everything is painted
Beginners will get a complete picture of the work of the analyst. Pros remember what they faced themselves. Disassembled all the stages of creating specifications. Appendix B contains a manual compiled on the principle of “problem - solution”. The table of contents itself acts as a hint. Detailed checklists are contained in almost every chapter. For example, the specification pattern includes 8 items, 24 subitems and two appendices. A comprehensive guide.
Easy to find information
Information is clearly structured, and it makes it easy to search by book. The table of contents is written on 9 pages. It quickly finds the necessary stage and explanation. In each chapter there are references to other chapters, if any question is described there in more detail. At the end of the manual provides a glossary of terms, so you can not be afraid of such phrases as "UML", "waterfall life cycle of the project" or "CRUD-matrix". For a couple of minutes there is a PDF version of previous editions, you can use the search on the document, if you need specific data.
')
For everyone in IT
Analysts come into contact with all who participate in the project: customers, designers, developers, testers, sales people, support and users of the product. And each group should know how to adequately relate the technical task to what they are doing. An inexperienced employee may ask something like: “Where is it written that when you click on this element nothing should happen?” If he reads a book, he will answer this question and leave reasonable comments to the document.
Explanation of terms
It’s difficult to read the manual without using it, but after the 700th page it becomes easier :) In the course of the presentation, each concept is given in brackets its original in English. This is convenient because the translator is not always accurate and you can open Wikipedia in English. At the end of the book is a glossary of terms with explanations. True, there are not all the concepts that occur in the manual. To supplement the list, I had to finish writing 50 new phrases and page numbers.
Minuses
Verbosity
Authors abuse long sentences and unnecessary information. Because of this, the meaning is harder to grasp.
“Requirements management tools help keep track of requirements by making it possible to define relationships between different types of requirements, between requirements in different subsystems, and between individual requirements and related system components (for example, design, code modules, tests, and user documentation).”
Leo Tolstoy, are you?
"... communication methods can ensure effective synchronization in time and space within a team."
And on the flyleaf it is written that this is a guide, not a philosophical treatise.
"State diagram for the state of orders of dishes".
The authors do not repeat twice, do not repeat.
"Stephen Withthall (Stephen Withall, 2007) describes many schemes for accurately documenting data (also called information)."
Data = information. And there is something in it!
And such a semantic noise throughout the book. There is a suspicion that the authors were paid for the lines.
Grammatical errors
In the course of reading counted them more than 160. All errors in the school program. For example: words are omitted, “-hya” is used instead of “-hya”, sentences are repeated in one paragraph, there are commonplace typos, commas are missed, concepts that are written in a similar way are confused.
The first error occurs as soon as you open the book. Chris has no delusions of grandeur, just confused her with Carl, who dedicated a book to her. They are spouses.
How do you like this phrase?
"Redesign the system for better processing of changeable business rules that were difficult to project support."
Product placement
In the course of the presentation, the authors repeatedly mention the products of Microsoft. They are so famous that it makes no sense to write about them. And when it is necessary to call the requirements management system (SUT), the authors are silent about them. I only read this chapter for their sake. Just the book was released by Microsoft Press, while the “small-scale” one does not have a full-fledged system. The company's loyalty outweighed professional debt.
Understatement
For example, in Appendix B, the authors provide an example of requirements documentation. They write that customers should be able to change subscriptions. But it does not say about the creation of subscriptions. How can you change something that has not been created yet? Missing initial stage.
Or it is stated that the system should allow the client to specify the method of payment. But it is not written about the confirmation of payment. What is the point to indicate how you want to pay if the payment cannot be confirmed? Missing final stage.
The remaining steps are spelled out in the application in some detail. Against this background, missing links in the chain of options leave a feeling of lack of agreement. It is clear that applications are given for example, but still.
What is relevant for Russia?
Before reading, I thought something like this: “What can an American advise us? They have everything in the figure, and there are no problems. ” It turned out that the problems are about the same.
No culture of respect for requirements
As the familiar developer said, “I don’t read the TK, but immediately write the code.” This is not a balanced approach. The implementation is not coordinated with interested parties, additional options are not explored, overlooked links with other elements. Increases the risk of error and its price. If the user finds an error after the release, then its price increases by 21 times. At the stage of TK to eliminate it is much cheaper. But as long as the companies do not seriously refer to the specification, they will “like the best, but it turned out, as always.”
No business requirements are generated.
Business requirements (business requirements) describe why the organization needs a system, that is, the goals that the company intends to achieve with its help. But if you look at the average Russian companies, it creates a strange impression. Some do not understand why they produce, while others do not understand why they buy. But ambitions swell and bet on seals on Instagram. It happens, you communicate with another genius from Skolkovo, and he passionately imposes invented needs on clients. As a result, the company looks like a vegetable, and the budget looks like a leaky bucket.
"Tied" to the design
This is not possible, because after redesign you have to edit the TK. This is a waste of time. It is not necessary for the specification to depend on the design. Let the designers have the choice of how to implement this or that requirement. For example, the “Delete” control element can be represented as a button, icon, link, swipe, context menu item. It is better to describe it through functions and circuits, rather than interfaces. Not "the system displays a drop-down list", but "the system provides a choice."
There is no understanding of the specifics of the analyst
For example, in one company, analysts have expanded responsibilities. They were instructed to inform the authorities about when this or that requirement is realized and by whom. If there was a delay, then find out why. Translated the task in stages and appointed responsible from other departments. As a result, the content part suffered. Everything described is the responsibility of a project manager. The manager is responsible for the exchange of information about the project, the analyst is responsible for the exchange of information about the product. These are two different areas of activity.
Not used toolkit
One boss wanted those working with the TK to know them closely to the text. It is unreal. There are several dozens of TZ in the company, and their number is increasing. If you yourself finished drawing up a TZ a month ago, you still forget it, because then you plunge into 2-3 new ones. The problem is not solved at the expense of memory, but at the expense of the implementation of requirements management systems (DCS). They support the identification, management, tracking and withdrawal of requirements. But you have to pay for them, and employers prefer to work in the old manner, as in the saying:
Two soldiers from the construction battalion replace the excavator.
And one of the Airborne Forces doubly replaces them.
Post Scriptum
I wrote to the publishers of a version of the book in Russian about the errors and offered to correct them together. The request was read, but the staff did not respond. So they consider illiteracy the norm. This is sad because the original is fit.
Conclusion
The book leaves a controversial impression because of its unfoundedness. Content is high and form is not. It scares. But if a specialist wants to be held as an analyst, he will have to understand by volition what the authors wanted to say. This is not easy, but the time spent is worth it, and you will respect yourself a little more.
Source: https://habr.com/ru/post/419235/
All Articles