This site uses cookies , both own and third parties , to collect statistical information about your browsing and show related advertising to your preferences , generated from your navigation patterns . If you go on surfing, we will consider you accepting its use.

Talks

Imagine that you are an analyst on a big project. You are working with analysts' team. Each analyst deals with a significant piece of the project, and he is the custodian of valuable insights. Suddenly, one of the custodians quit your team. You get a critical mission - to close his front of work.

A project gets into your hands. Most of the analytical work has been completed, the requirements have been written, and the technical specifications have been agreed, the development is undergoing, there is a list of questions on the requirements. And in a month, you need to conduct acceptance tests. And yes, the one who quit was a very valuable employee, he had three functional specifications in work. By the way, nobody has cancelled your work, and you are preparing to deliver the project at the same time as the three inheritedprojects.

When you hear the "review of requirements", the shudder and imagine a long list of comments to the document, the majority of which about spelling and punctuation? Do you think that your team is small and you do not need it? Or maybe you are one of those who believes that the only task of the review is to improve the quality requirements? Let's talk about this.
In his report, I will consider reviewing the requirements and answer the following questions:
1. Why is reviewed, it is not only about the quality requirements?
2. Why do more than 20% of teams refuse to review, and how it can be useful to them?
3. What types of review are?
4. Whom to involve and how to organize a peer review process with the team?
5. How to review and work with the result of the review?
The report will be based on experience - my and my colleagues, supported by the results of a survey among analysts and will be useful to anyone who is involved in reviewing the documents.

The purpose of the report - to form a picture of the main activity that should be paid attention to when documenting requirements in the project for integration:

1) How to start the formation of a job requirement?

2) How to describe the interaction of systems involved in the exchange?

3) How to describe the services that are implemented through the interaction of?

4) How to describe the requirements for the development of routing and logging modules.

The report generated from the point of view of the analyst responsible for the development on the developer side of the integration module, which is implemented by means of the interaction of systems involved in the exchange of data.

The report is aimed at beginners to analysts, who have an idea about the basic terms of analytics tasks in the project for integration.