Review of the book "Developing Software Requirements" by Karl Wigers and Joy Beattie

Published on September 24, 2018

Review of the book "Developing Software Requirements" by Karl Wigers and Joy Beattie

    In 2018, the book “Development of software requirements” was re-published. Colleagues sent me a link to the publication. The authors added techniques for working in agile-projects, defining the role of analyst and recommendations on automation. In the web go extremely controversial reviews . I ordered the book and figured out the question.



    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 according to the principle “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 phrases such 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 add to the list, I had to add 50 new phrases and page numbers by hand.

    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 provide 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: the 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 to better handle 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 is not yet created? 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 their 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.

    There is no culture of respect for the requirements.


    As the familiar developer said, “I do not read the TK, but I 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 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 the 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, and not 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. This is unreal. There are several dozens of TZ in the company, and their number is increasing. If you yourself finished making 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 due to the implementation of requirements management systems (CTS). 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 book version in Russian about 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 off. But if a specialist wants to be held as an analyst, he will have to understand by volition what the authors wanted to say. It is not easy, but the time spent is worth it, and you will respect yourself a little more.