In 201? the year was reissued the book "Developing Requirements for Software." Colleagues sent me a link to the publication. The authors added techniques for working in agile-projects, defining the role of the analyst and recommendations for automation. The web is extremely conflicting reviews . I ordered the book and understood the question.
 
 
 
 

Pros

 

It is painted all

 
Beginners will get a full picture of the analyst's work. Pros will remember what they faced themselves. All stages of creating specifications have been disassembled. In Appendix B there is a manual composed on the basis of the "problem-solution" principle. The table of contents acts as a hint. Almost every chapter contains detailed checklists. For example, the specification template includes 8 items, 24 sub-paragraphs and two annexes. Comprehensive guidance.
 
 

It is easy to find information

 
The information is clearly structured, and this makes it easier to search the book. The table of contents is written on 9 pages. It quickly finds the right stage and explanations. In each chapter there are references to other chapters, if any issue there is described in more detail. At the end of the manual is a glossary of terms, so you can not be afraid of phrases such as "UML", "waterfall life cycle of the project" or "CRUD-matrix." For a couple of minutes there is a PDF-version of past editions, you can use the search for a document if you need specific data.
 
 

For all who are in IT

 
Analysts come into contact with everyone who participates in the project: customers, designers, developers, testers, salespeople, support and users of the product. And each group should know how to adequately relate the technical assignment to what they are doing. An inexperienced employee may ask something like: "And where is it written that when clicking on this element should not anything happen?" If he read the book, he himself will answer this question and leave a valid commentary to the document.
 
 

Explanations of the terms

 
It's difficult to read the manual with unaccustomedness, but after the 700th page it becomes easier :) In the course of the presentation, each concept is shown in parentheses in 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 there is a dictionary of terms with explanations. True, there are not all the concepts that are found in the leadership. To add to the list, I had to add 50 new phrases and page numbers by hand.
 
 

Cons

 

Verbosity

 
The authors abuse long sentences and unnecessary information. Because of this, the meaning is more difficult to grasp.
 
 
"Requirements management helps to track requirements, enabling you to determine the 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, you?
 
 
" communication methods can ensure efficient synchronization of in time and space inside the team. "
 
And on the flyleaf it is written that this manual, and not a philosophical treatise.
 
 
"A state diagram for the status of food orders."
 
The authors do not repeat twice, do not repeat.
 
 
"Stephen Withall (2007) describes many schemes for accurately documenting data (also called information)."
 
Data = information. And in this there is something!
 
 
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, I counted more than 160 of them. All mistakes in the school curriculum. For example: words are skipped, "-yats" are used instead of "-yats", sentences are repeated in one paragraph, commonplace typos are encountered, commas are omitted, concepts that are written in a similar way are confused.
 
 
The first error occurs as soon as you open the book. Chris does not have any megalomania, she was just confused with Karl, who dedicated a book to her. They are married.
 
 
 
 
And how do you like this phrase?
 
"Redesign the system for better handling of volatile business rules that have been complex project support."
 
 

Product placement

 
In the course of the presentation, the authors repeatedly mention Microsoft products. They are so famous that it makes no sense to write about them. And when it is necessary to call the requirements management system (CMS), the authors keep silent about them. I just read this chapter for them. The book was published by Microsoft Press, and the "soft" does not have a full-fledged CTA. Loyalty of the company outweighed professional debt.
 
 

Incomprehensibility

 
For example, in Appendix B, the authors give an example of requirements documentation. They write that customers should be able to change subscriptions. But it is not said about the creation of subscriptions. How can I change what has not yet been created? Missed the initial stage.
 
 
Or it is indicated that the system should allow the customer to specify the method of payment. But it is not written about the confirmation of payment. What is the point of indicating how you want to pay if payment can not be confirmed? Missed the final stage.
 
 
The remaining stages are spelled out in the appendix in some detail. Against this background, the missing links in the chain of options leave a feeling of discord. It is clear that the applications are given for an 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 digital, and there are no problems. " It turned out that the problems are approximately the same.
 
 

There is no culture of respect for the requirements of

 
As the familiar developer said, "I do not read TK, but I immediately write the code." This is not a balanced approach. Implementation is not coordinated with stakeholders, additional options are not studied, links with other elements are overlooked. The risk of error and its price increases. If the user finds an error after the release, then its price increases by 21 times. At the TZ stage, it is much cheaper to eliminate. But while the companies seriously do not relate to the specification, will "like how best, but it turned out, as always."
 
 

Business requirements

are not developed.
 
Business requirements describe why an 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, then a strange impression is created. Some do not understand why they produce, while others do not understand why they are buying. But ambition is inflated and betting on seals in Instagram is being made. Sometimes, you communicate with another genius from Skolkovo, and he passionately imposes his clients on fictitious needs. As a result, the company looks like a vegetable, and the budget is like a leaky bucket.
 
 

"Bind" to the design of

 
So it is impossible, because after the redesign you have to edit the TK. It's an unnecessary waste of time. It is not necessary that the specification depends on the design. Let the designers have a choice how to implement this or that requirement. For example, the control element "Delete" can be represented as a button, icon, link, whispering, context menu item. It is better to describe this 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 work of the analyst

 
For example, in one company, analysts have expanded their responsibilities. They were instructed to inform the authorities about when this or that demand is being implemented and by whom. If there was a delay, then they figured out why. Translated the task into stages and appointed the responsible from other departments. As a result, the substantive part suffered. All described - the responsibilities of the project manager. The manager is responsible for the exchange of information about the project, the analyst - for exchanging information about the product. These are two different areas of activity.
 
 

The toolkit

is not used.
 
One boss wanted those working with TK to know them close to the text. This is unrealistic. The company has several dozen TK, and their number is increasing. If you yourself finished compiling TK a month ago, you still forget it, because then you sink into 2-3 new ones. The problem is solved not at the expense of memory, but due to the implementation of requirements management systems (CMS). They support the identification, management, tracking and withdrawal of requirements. But they have to be paid for, and employers prefer to work in the old fashion, as in the saying:
 
 
Two soldiers from the construction battalion replace the excavator.
 
And one of the Airborne Forces replaces them doubly.
 
 
Post Scriptum
 
I wrote to the publishers a version of the book in Russian about the mistakes and suggested that they be corrected together. The request was read, but the staff did not respond. Hence, they consider illiteracy as the norm. This is sad, because the original is good.
 
 

Conclusion

 
The book leaves a contradictory impression due to its lack of familiarity. The content is high, but the form is not. This frightens off. But if the expert wants to take place as an analyst, he will have to effortlessly understand what the authors wanted to say. It's not easy, but the time spent is worth it, and you will respect yourself a little more.