One says while developing software, an analyst suffers once, a developers few times or a user all his life. It’s true for developing any document also, if we did not think about its target audience, document reading will either become a pain for colleagues or it will be ignored. From this perspective, saving time during the creation of documents of requirements and other artefacts it is a good desire from an engineering point of view, but not from the perspective of working with people around you.

In the talk, we will refer to different target audiences of documents in software development, its goals and objectives when reading documents and working with other methods of presenting information.

We describe the actions: in the processes, Use Cases, instructions. We want to write shortly and so as not to cause questions. And there is always not enough information, time for a detailed and intelligible description. We model more sophisticated and our descriptions are more and more incomprehensible. There is a solution: we can treat the description of the process, Use Case, as creating a tool. When you explain to a person what you need to do, you give a tool for solving some problem and must explain why it is needed, how and in what conditions it can be used. In the workshop, I will offer a template for describing such a tool-method. Let's practice describing different tasks - processes, user scenarios - for which we usually use familiar notations, and try to find “white spots” in the usual use of our favorite tools.

Requirements structure is a base for futher analysts work in project. It should be clear for all project participants. People talk much about requirements classification but not about arranging requirements inside one class. How would we split functional requirements to help developers design architecture according to real world domain? Report include this issues and other about how to agree the structure with stakeholders within and outside of project.