What do I want from requirements development tools. Gags, crutches and rake SUT
We publish the report of Pechenkina Grigory from the previous conference Analyst Days 2013.
In terms of providing professional tools, analysts are the most oppressed class compared to other software development participants. Analysts are used to this and often do not even think about how often they have to use uncomfortable and ineffective “crutches” in their work. In addition, analytics usually have to completely change their tools when changing jobs, because systems built on these crutches are almost always unique and not portable.
The report will look at some typical crutches and rakes of requirements management systems, as well as suggestions on what should be an analyst’s dream tool.
www.slideshare.net/VLDCORP/ss-21934097
')
We will look at the gags, crutches, and requirements management system (RMS) rakes in order to understand what I want from requirements management systems. In the beginning I will make 2 ads.
In one of the announcements of the report, which was previously sent out, it was said that a fundamental review of the PMS would be made. Review will not. In fact, there was such an idea: to miss several real-world tasks of the SUT through several systems, but when I took it, I realized that I greatly overestimated my strength (later I will say why). The good news is that I have where to send you :).
Last year, the REQ Labs conference was held in Kiev, where the idea was perfectly realized: analytical fights. The conference was attended by three experts who, unlike me, know SUT well, because they constantly use them and conduct training. In the course of the conference, the experts put the real task of working with the requirements, and they demonstrated how this is done in different systems. Work was proposed with three systems: RequisitePro, Enterprise Architect, Sybase PowerDesigner. If someone is interested in this question, the video is on the website of the company REQ Labs (http://www.req-labs.ru/conf2012/agenda/530/).
The second announcement (see screenshot 2 of the presentation) already refers to the announcement that I typed in the program.
Namely, I wrote that analysts are the most oppressed class among IT specialists, because they do not have good tools. But in the process of writing the report, I realized that analysts, on the contrary, have too many good toys that no one else wants to play. The problem is this, and it will be discussed now. I will tell why the idea of ​​the report arose, and what problem arose before analysts.
I am not a professional analyst. I was a programmer, then a manager, now my position is called an analyst - and, it turns out, I can say with a clear conscience that I became an analyst. But there was a period when I changed jobs once a year. He worked in three different places. In one company I worked as a technical director. The company was small, only five people. In another company - it was bigger and consisted of thirty people - I was in charge of the direction. Now I am working on a project to develop a banking system. And each time the customer (employer) confronted me with the problem of implementing a requirements management system (CTS) and I had to choose which tools to use. The article is devoted specifically to the topic, what problems I had to face, and the conclusions I reached in the process of this work.
Mostly on projects use such a system: Excel Word, Polarion, Enterprise Architect, TFS, Wiki, Caliber, Jira.
Many companies still use the MS Office suite to develop and manage requirements. In addition, Sharepoint is spreading more and more, since it allows you to bring some order into the chaos of Office documents, plus there is an opportunity to conduct version control and comparison. This system makes it possible to organize something similar to the CMS on the basis of existing practices of the company, which they conducted before in Word and Excel. And plus add to this web interface in which you can program (now, I know, Sharepoint programmers are the most popular and highest paid, and if you did not know, I recommend to study this program just in case). Consider other systems.
Everyone has heard the Sparx Enterprise Architect program, which allows you to simulate anything. Specialized development tools - IBM Rational RequisitePro, there are others. These tools are designed specifically for the development of requirements.
There are also teamwork tools - ALM (Application Lifecycle Management). Now MS TFS (Team Foundation Server) is gaining popularity very actively. I myself love him very much and work with him constantly. This is Microsoft’s development - a management system for “everyone” in a team, in other words, a team collaboration tool.
Wiki tools are also gaining popularity. Wiki is usually integrated with task trackers, the most common of which is the Jira system. I work in a company that uses the Confluence Wiki tool in conjunction with TrackStudio. There are more options, such as MediaWiki with Bugzilla.
In fact, what of this list is designed to manage the requirements? To answer this question, you need to answer one more question: what is the difference between development and requirements management.
You've probably heard about CMMI (Capability Maturity Model Integration). In this model, requirements management refers to the second level, and requirements development - to the third level, i.e. requirements development is a higher level process corresponding to a more mature process in a company.
In fact, these are generally different processes. Development is what analysts do (or people who are commonly referred to as analysts). And management is what managers usually do: the interrelation of requirements with different working artifacts: test cases, tasks, code, etc. In the end, they link everything that the team develops with the requirements. On their basis, statuses, traces, etc. are tracked.
From my point of view, all these processes are inseparable (although this is not quite so in CMMI). The problem is that tools are created for analysts to develop requirements, and for the rest of the team - tools for managing requirements. In an attempt to dock them and problems occur. Before we move on to analytics, let's define the terms: rake, crutches, gags.
Definitions
What is a rake? Rakes, I call some elements inherited from other industries, the use of which creates problems. For example (this example is not very relevant now, but 10 years ago, when all the development was carried out in Word, it was very relevant), some identifier is assigned to the requirements (by means of Word in the text), to which we refer elsewhere, then we change the source text, as a result of which the number changes, and then the whole structure of relations breaks down. I hope that you do not have such problems.
To date, the databases have coped with this problem: more or less. We all know that an identifier is assigned differently now. This case I gave as an example of a rake. In fact, in other industries such identification is used now: lawyers, accountants, when they draw up an agreement, then an additional agreement to it, which refers to some clause of the agreement. Or, for example, there is a Law or amendments to the Law, referring to a specific clause to the Law. It works in the real world, but an attempt to apply it in IT is a transfer of old experience or a rake, on which someone stepped on and stepped on again.
What are crutches? This is a very common term in IT - backups or temporary solutions. As an example, any integration of one system with another is a crutch: one system is not capable of solving something, another system cannot do something either, and in order to integrate them, it is necessary to build crutches.
What are “gags”? Gags arise in cases where the program must perform certain actions itself, but shifts these actions to you. A very common phenomenon. All usability consists of gags. There is even an anecdote about the "Uzbek virus."
Many programs behave this way, but we are just used to it and do not even pay attention to it. So, I gave the definitions of terms, we continue on the subject.
I propose to consider an example of a project that I am working on at the moment - this is an internal development project. I am developing requirements in the Confluence Wiki (after having failed to select a normal tool as part of my research).
For example, I chose a rather primitive old version. For the developer, I give this page: context as part of the tool use case diagram (so that they understand why this project is being created). Then the text describes some specific requirements.
In this project, a visual panel is developed, with which users can perform certain operations (I indicate those operations that must be implemented). And further, an interface layout is given - an idea of ​​how it all should look.
Experience has shown that such a page for developers is normal. They understand that they are making a panel that will look something like this (in the example, not a real interface, but a prototype), the actual requirements, what they should do, and some contextual representations in the form of a diagram are listed.
Of course, the question arises: “In which program, other than Wiki, can such a presentation be made?” Word is not much different. But later you will understand why I chose the Wiki.
I drew your attention to the fact that requirements management is a process that affects the interests of the whole team. You, as an analyst, develop requirements, then these requirements are used by different people. Depending on the size of the company, the scale of the project, the technology, some of these people may be, some may not, for example, lawyers may appear. The point is that in the center of the requirements management process are the requirements that the analyst is developing.
Below I will present some wishes on behalf of these people.
I want to note that not all analysts want to develop requirements in the form of text - in this case, this is my personal preference. Most text analysts do not like working with text and prefer to work with visual models, especially those who work in Enterprise Architect. I explain why it is more convenient for me to work in the form of text: in this form it is more convenient for me to work with the team - they understand the context.
All my experience in IT shows that the main problem of programmers is that they do not understand the context of what they are developing. They sometimes program without regaining consciousness. For example, there are many programmers in the banking system development project. They absolutely do not understand what processes are behind this: what’s the point of accounting, why do we need reports. They get the installation that you want to add such a code in such a folder and in such a function. And people work like that for years.
This naturally leads to problems: a lack of understanding of the context of what they are developing leads to a large number of problems, which are rather expensive. And in order for people to be immersed in this context, they need to be given demands in a form that is understandable to them. We are kindergarten and schools are taught to work with the text - for all this is the natural way of presenting information.
Text or database?
There is an unnatural way of presenting information - this is a database. It should be noted that SUT appeared only when databases appeared, where you can sort everything out and monitor the life of each element. But here is a contradiction: people work with texts, and they need to be stored in a database, leading many to mild schizophrenia.
Therefore, for the most part, the SUTs tend to the textual representation of the SUT, as it is organized in Wiki and Word, since they work with texts, and professional systems tend to database more often.
What does this lead to? Suppose I need to add a requirement. What I’ll tell you now is perceived by many of the listeners as something natural, because they don’t know any other ways. When you create a new requirement, you are asked to enter it in the dialog box. The slide shows a dialog box from Enterprise Architect because it is not text-oriented and can be justified there.
The following screenshot from TFS, is different here. I had a friend who was accustomed to working in Word, who categorically refused to work in the TFS system. This system allows you to use different design patterns (Scrum, MSF): requirements appear, bugs, change request, etc. In each case, its life cycle.
What's the point? When a default template is set, there every newly created artifact has the status of proposed. I don’t know why it was done, probably from the CMMI point of view, it was necessary. The bottom line is that when a person adds a new requirement, he needs to re-enter the dialog box and change the status again. Thus, he comes into a dialogue twice (of course, the template is customized and it can be removed). The bottom line is that each new element needs to be entered into the dialog box, and some systems still force all attributes to be set with pens - this is a kind of barrier to the introduction of the CMS.
3. The analyst does not want to do anything extra
I do not want to enter each paragraph in a separate window (much less repeat the same actions for each of them). I do not want to manually set all statuses and constantly switch between the mouse and the keyboard (everyone knows the carpal tunnel syndrome). This all knocks the analyst out of the stream.
I hope that the listeners understand what I am talking about. When you sit and generate a stream from the requirements text, and then: create a window, move it with a mouse, then again, etc. This is very difficult to work and very tiring. Therefore, I consider the dialog box system to be one of the examples of plugs when the system transfers its internal device to you: I have a database and save each record separately.
4. The analyst wants to include visual models and images in the requirements.
One more example. I consider visual diagrams to be the most powerful means of presenting requirements. Without this, it simply does not work.
In this case, the example that was given above in my requirements is the mockup user interface layout (developed in the Pencil program).
The point is that in order to insert a picture with requirements into the Wiki, I have to first export it to some jpg-png-bpm file, etc., and only then insert it there. And I always still (suddenly someone will have a desire to change something without me) I insert a link to the used tool and a link to the file. In my experience, no one ever wants to install a program to change a picture. In fact, such programs are surprisingly many.
5. Analyst: I do not want to export models to jpg-png-bmp-etc
He does not want to run his editors with his hands and store the models in separate files.
And if you work with the Wiki, then you have to insert images in this form. This is a huge problem. I do not want as an analyst to do this. I do not want to run other editors. I do not understand why this is not implemented in the requirements development environment. This is perfectly implemented in MS Office, when you draw a diagram in Visio, and then paste it into MS Office, after which you can edit it right there without leaving Word.
In other words, it is a crutch.
6. The analyst is not a programmer and does not want to describe pictures in the form of code.
Another option is interesting for those who develop requirements in the Wiki (Media Wiki, etc.). For them, the following screenshot will be clear. These are wiki plugins that allow you to create diagrams as text or as a picture: PlantUML is a simpler plugin and allows you to draw regular diagrams, and GraphViz has a wider purpose, it is possible to draw any diagrams, but the programming language is more complex (similar to assembler). In fact, it is a very convenient program in terms of presenting information. You can change your charts without using any external means, moreover, you can track changes (this is theoretically, because practically I have never seen this done).
But I do not want to code, although programmers love this program. In fact, if the user suddenly wants to change the arrows or move the figures of the users, and others, it will take a lot of time to figure out how to do it. If you are doing it in the Enterprise Architect program, it’s easier there, you’ve connected what you need with the arrows and everything, the difference is clear.
In general, it can be viewed in different ways. It can be considered as a gag, because I do not see any problems, why it is impossible to make an editor directly on the web. It can also be viewed as a crutch, because I want to include images and diagrams in the Wiki, but I have no other means, and I have to use it.
When Windows 3.0 or Windows 95 appeared and OLE was promoted by Microsoft precisely as an opportunity to embed one document into another: as I said, we create a diagram in Visio, then paste it into Word and then edit it in Word. I still do not understand why WEB does not have such a standard. There is something in Word, something in Flash, but there is no single way. Do you understand what I am talking about? You go to a web page and directly on it edit and draw something. I have high hopes for HTML5, because something has already appeared there before, but again I don’t understand why it hasn’t yet become mainstream.
There is a draw.io service that allows you to do this very conveniently and beautifully, but at the same time the diagrams are stored on their server, you can paste them into your pages, but not in your own. Perhaps this will change soon. That is why now Microsoft Office is so popular - there all these integration problems have been solved for a long time and are convenient, and, in addition, there are many developments.
We have learned to compare texts more or less. The programmers have already mastered the source control systems, there are many means of comparing texts, however, the comparison of the models is still in place while the pipe is being used, although I am told that in the tenth Enterprise Architect there is already an opportunity to compare the two versions, but I thought it was originally .
I do not want to run third-party programs, and it makes no sense to compare binary files. What do the requirements management systems that I mentioned at the beginning offer to us? All those who present the system, consider exporting to Word their advantage. There are several reasons for this, it is very much in demand, including because Word allows you to compare texts.
With pictures, everything is bad. If you need to compare two pictures, then you need to solve the problem “Find 10 differences” - i.e. compare visually. There are no other ways.
The analyst has to discuss the requirements. The most common ways - in Word and by mail. You can also hold a meeting or print out on paper and go to visit him with a stack of papers.
This all gets it. I do not want to carry packs. I don't want to go anywhere. And besides, I want to make changes during the discussion.
This feature provides a Wiki.
9. The analyst does not want to carry a pack of paper and does not want to go anywhere.
He wants to make changes to the requirements right during the discussion.
At our summer analytical festival (www.lafest.ru), which I advertise all the time, Elena Zhuravleva, technical director of Human Factor Labs, performed. She told how they lead the demands in Confluence. They have very different customers, including state ones, including large banks. And when I tried to elicit from her, how did they export all of this into Word to coordinate with them. She said that they do not export anything, but they take the page and they (the customers) work with it themselves.
People get used to good things very quickly. The main thing is for someone to show this good, but, unfortunately, our requirements management system, except Word and Wiki, which is specially tuned, does not know how to do this. What do we use? The only way is by mail.
I took a picture from the Internet, because I couldn’t have one — there’s too much confidential information. What we see: begin to make comments to every word, in every line. All this quickly grows into multi-colored "noodles". One paragraph and fifty comments to it from different experts. Then what does the analyst do? Rereads all this, throws it out and somehow rewrites it. Those.All these discussions are a crutch.
Or the second option, which is even worse. Goes to the customer, where everything discusses, crosses out on paper. And then it returns to the office with it, processes it and throws it away, because it is impossible to work with what was the result of the discussion.
10. The analyst wants to link requirements with each other.
I will not talk about tracing: the requirements need to be linked to each other, different components, the requirements have to be linked by levels (see the report by Irina Surova ). Again, we have to use crutches for this.
Hierarchy in models
I show not very good examples. In this case, this is a modified example from TrackStudio, where we tried to drive requirements. And in order to establish links between them, they tried to invent a hierarchy. The hierarchy itself is a good crutch. Now this is not a topic for conversation, because there are so many features: we try to think in advance which connections will appear in the requirements, and when we get into the subject area and begin to model it, it turns out that the hierarchy does not work. In general, hierarchy is a gag!
Look at the following screenshot. Does anyone work with this? Yes, for planning testing, tracking changes.
As I said, I'm not the kind of person who likes working with tables. There are people, unfortunately, who are zombie tables. For example, my boss: he discovered the “magic” matrix in Excel and then required all documents to be developed in Excel, including meeting minutes, requirements, and reports. I call this interface: guts out, because if you want to find out what requirements you have covered with test cases, it’s easier for you to list the works that are being tested. But some like it. But, nevertheless, it is a crutch.
11. The developer wants to know what requirements he needs to implement, and the project manager - what requirements have not yet been implemented.
We talked about requirements management, namely, tying requirements together. This is one moment. But all the power of a command management system is that it allows you to link different artifacts. The developer sees what he needs to implement depending on the tasks. The project manager wants to know what is left in the project unfulfilled and wants to know (this is especially true when there are a lot of customers), which is already installed at the customer. First you send him versions from different branches, and then requests come in, and you try to understand what he already has. In particular, in the banking sector, I constantly came across this: you need to determine which requirements in the current version are already implemented for the client and which are not. SUT allows you to answer this question.
12. The tester wants to know which requirements have not been tested.
And the tester needs to know the test cases that he has left to perform.
This is the task of the PMS: all processes are built around requirements management, when you need to track the very connections between artifacts.
This is best done in TFS, which allows you to connect anything, with anything, in any way, but the interface looks like this.
Links between artifacts
Those.If you want to associate one entity with another, you need to enter its number. And 2 color blocks in the lower part of the window, they are mockingly called visualization. Those.TFS, as it were, says: we have, you know, a relational database, therefore, describe all the relations with pens. This not normal.
For example, in the Enterprise Architect program this is implemented visually: you have two small squares and you draw an arrow between them.
These are plugs, and the ones that behave like the "Uzbek virus." On the one hand, there is a rich possibility of installing derived links, and on the other hand, a weak interface for creating such connections.
13. The customer wants his requirements understood correctly.
He wants to know what is done with his requirements.
We have already talked about the harmonization of requirements.
I repeat it all the time.
In order to communicate with the customer, we constantly use export to MS Office, because we think that the customer is a fool (although sometimes this is true), but in general, this leads to problems. This is a signal that it’s enough to use gags.
In general, I presented all of the above as a diagram of options for using SUT to summarize the topic of conversation. In fact, the options can be much more.
There is another problem that I mentioned at the very beginning. I am an analyst. I come to a new company, I want to implement a requirements management process, get involved in the work and want to use my tool, and what do I get?
Look at the options.
Do you know what it is? This is a Rational product (IBM Rational RequisitePro requirements management tool, a picture taken from the Internet) designed for everything: for testing, for requirements. Simply put, as in the saying: the claw is stuck - the whole bird is a precipice. All of them are integrated with each other, something integrates with something else (but this, in our case, is a rake).
There is another option - Confluence (Atlassian Confluence program) - a plugin store: take the cubes and collect what you need.
Summarize the problem.
The team does NOT want to use analytics toys
I wonder if someone managed to drive programmers in Enterprise Architect with models to work? How did it all end? Of course, programmers are different.
But what I want to say: teaching the whole team the tools intended for analysts is not the right approach. On the other hand, if we try to drive the analyst into TFS - as you remember, it can only work with texts. This means that the entire connection with the visual diagrams disappears and the problem of connections arises, which I mentioned.
Although there is an experience from the Kaspersky Lab - they connected TFS with Enterprise Architect, but this is actually not enough anyone can afford, because in this case it turns out a very expensive project.
It is known that integration always turns out to be unique and the analyst cannot transfer his toolkit to a new project. In our company, for example, a special team works on supporting Confluence with Track Studio, which is called the Corporate Portal Support Team, where there are five people and they are the most qualified specialists. Those. it is expensive.
As a result, I want to dream. It would be nice to take all the best of all the tools and put it all in one tool.
I tried to create an optimal system of requirements for documents. More precisely, these system requirements were born in the system analysis club.
• Generation of documents in different formats
• Joint remote work
• Consideration of influence and tracing
• Version control
• Integration with modeling tools
• External add-ins
However, in the process of working on my report I corrected these requirements.
Requirements fordocumenting the development and management of requirements
•Generation of documents in various formats Convenient presentation for all requirements
• Joint remote work, including with customers
•Impact accounting and tracing Model and artifact connectivity
•Version control Track changes
•Integration with modeling tools Built-in modeling tools
•External add-ins Ready for use out of the box
I want to show that happened.
1. Entering requirements
Here I enter the text in Confluence. Why should I enter data in some form? You can do this car.
Based on the formats of the requirements entered, the machine itself should list the records in the database. Let there be a possibility of correction, if I believe that she did something wrong, I will press Backspace and she will remove the record. There are similar systems: Rational RequisitePro (it uses MS Word as the text input tool) - here the requirements are typed in the form of text, which fall into the database with rakes and jambs, which can be seen even at the demonstration. I don’t see any technical problems.
2. Establishing hierarchy and relationships
After entering the text, the system itself must build connections based on the structure. It is clear that you will need to create a link layout, template. I use the template in Confluence to enter the requirements, and the record gets into the database at once with all the links, as shown in the screenshot diagram. I do not see any problems. Of course, this must be programmed.
3. Building diagrams
I want the connections to be set up like this. I want to change the diagram, make it to me on the web.
Why the web?
4. Display changes
If we already store diagrams as a record in the database, as a rule, the record is stored in XML. XML is the text from which we can always isolate all changes. Why this cannot be shown on the diagram I do not understand. Example: the screenshot shows two versions of the diagram, where I can immediately show what has changed in the latest model, compared with previous versions.
5. Coordination with the customer The
question is, why do we need the text? But the idea is that we leave the text as the main way of keeping the requirements. Let's work with this text and give such an opportunity to the customer: let him look at the requirements and put in points where he agrees: like (let him "like").
In fact, it is very convenient. Instead of going to him with a printout of requirements in the Word, you give him this Wiki page. He has his own interface for working with text and he notes: agreed - did not agree. If you need to discuss - please, note that you need to discuss and immediately discuss. What does this look like in modern TFS requirements management tools? Long and boring discussions.
With the text you can do anything. It is clear that you can customize the presentation depending on who is watching. For example, for project managers.
First, he assigns which release this requirement will go to, and then he monitors the change of statuses. There are many such examples.
7. Making connections.
What is link building? In this case, I tried to demonstrate how to create requirements with test scenarios. Those. The tester works with the context of the requirements (in text form) and can immediately create the necessary links (they immediately go to the database).
It is clear that this requires a well-developed model initially. Sometimes you need to associate something with something so that in the end your project does not suffer.
8. Visualization of communications
I took this picture from the Internet. Its meaning is as follows: instead of, as in TFS, all communications are hammered by hand, communications are shown visually.
9. Conclusions
And finally, the most important thing. I have presented all of the above about rakes, crutches and plugs from the point of view of analysts, but from my point of view, you need to take the tools of teamwork and attach a human interface for analysts to them. Then the problem would be solved.
Those. I want a tool for the whole team, but everything is so that everything that has been gained in other toys of analysts is convenient for him. From my point of view, all the prerequisites for creating such a tool are. As soon as such a tool appears, he immediately, in my opinion, will receive high popularity. Maybe they have already appeared, then tell me about them. (This hut in the screenshot symbolizes the web turned to face the analysts).
That's all. Thank you all.
You can meet Gregory at the next Analyst Days conference in Moscow on May 24.
Annotation:
In terms of providing professional tools, analysts are the most oppressed class compared to other software development participants. Analysts are used to this and often do not even think about how often they have to use uncomfortable and ineffective “crutches” in their work. In addition, analytics usually have to completely change their tools when changing jobs, because systems built on these crutches are almost always unique and not portable.
The report will look at some typical crutches and rakes of requirements management systems, as well as suggestions on what should be an analyst’s dream tool.
Video report:
Presentation:
www.slideshare.net/VLDCORP/ss-21934097
')
Introduction
We will look at the gags, crutches, and requirements management system (RMS) rakes in order to understand what I want from requirements management systems. In the beginning I will make 2 ads.
In one of the announcements of the report, which was previously sent out, it was said that a fundamental review of the PMS would be made. Review will not. In fact, there was such an idea: to miss several real-world tasks of the SUT through several systems, but when I took it, I realized that I greatly overestimated my strength (later I will say why). The good news is that I have where to send you :).
Last year, the REQ Labs conference was held in Kiev, where the idea was perfectly realized: analytical fights. The conference was attended by three experts who, unlike me, know SUT well, because they constantly use them and conduct training. In the course of the conference, the experts put the real task of working with the requirements, and they demonstrated how this is done in different systems. Work was proposed with three systems: RequisitePro, Enterprise Architect, Sybase PowerDesigner. If someone is interested in this question, the video is on the website of the company REQ Labs (http://www.req-labs.ru/conf2012/agenda/530/).
The second announcement (see screenshot 2 of the presentation) already refers to the announcement that I typed in the program.
Namely, I wrote that analysts are the most oppressed class among IT specialists, because they do not have good tools. But in the process of writing the report, I realized that analysts, on the contrary, have too many good toys that no one else wants to play. The problem is this, and it will be discussed now. I will tell why the idea of ​​the report arose, and what problem arose before analysts.
I am not a professional analyst. I was a programmer, then a manager, now my position is called an analyst - and, it turns out, I can say with a clear conscience that I became an analyst. But there was a period when I changed jobs once a year. He worked in three different places. In one company I worked as a technical director. The company was small, only five people. In another company - it was bigger and consisted of thirty people - I was in charge of the direction. Now I am working on a project to develop a banking system. And each time the customer (employer) confronted me with the problem of implementing a requirements management system (CTS) and I had to choose which tools to use. The article is devoted specifically to the topic, what problems I had to face, and the conclusions I reached in the process of this work.
Mostly on projects use such a system: Excel Word, Polarion, Enterprise Architect, TFS, Wiki, Caliber, Jira.
Many companies still use the MS Office suite to develop and manage requirements. In addition, Sharepoint is spreading more and more, since it allows you to bring some order into the chaos of Office documents, plus there is an opportunity to conduct version control and comparison. This system makes it possible to organize something similar to the CMS on the basis of existing practices of the company, which they conducted before in Word and Excel. And plus add to this web interface in which you can program (now, I know, Sharepoint programmers are the most popular and highest paid, and if you did not know, I recommend to study this program just in case). Consider other systems.
Visual modeling tools
Everyone has heard the Sparx Enterprise Architect program, which allows you to simulate anything. Specialized development tools - IBM Rational RequisitePro, there are others. These tools are designed specifically for the development of requirements.
There are also teamwork tools - ALM (Application Lifecycle Management). Now MS TFS (Team Foundation Server) is gaining popularity very actively. I myself love him very much and work with him constantly. This is Microsoft’s development - a management system for “everyone” in a team, in other words, a team collaboration tool.
Wiki tools are also gaining popularity. Wiki is usually integrated with task trackers, the most common of which is the Jira system. I work in a company that uses the Confluence Wiki tool in conjunction with TrackStudio. There are more options, such as MediaWiki with Bugzilla.
In fact, what of this list is designed to manage the requirements? To answer this question, you need to answer one more question: what is the difference between development and requirements management.
Development or management
You've probably heard about CMMI (Capability Maturity Model Integration). In this model, requirements management refers to the second level, and requirements development - to the third level, i.e. requirements development is a higher level process corresponding to a more mature process in a company.
In fact, these are generally different processes. Development is what analysts do (or people who are commonly referred to as analysts). And management is what managers usually do: the interrelation of requirements with different working artifacts: test cases, tasks, code, etc. In the end, they link everything that the team develops with the requirements. On their basis, statuses, traces, etc. are tracked.
From my point of view, all these processes are inseparable (although this is not quite so in CMMI). The problem is that tools are created for analysts to develop requirements, and for the rest of the team - tools for managing requirements. In an attempt to dock them and problems occur. Before we move on to analytics, let's define the terms: rake, crutches, gags.
Definitions
What is a rake? Rakes, I call some elements inherited from other industries, the use of which creates problems. For example (this example is not very relevant now, but 10 years ago, when all the development was carried out in Word, it was very relevant), some identifier is assigned to the requirements (by means of Word in the text), to which we refer elsewhere, then we change the source text, as a result of which the number changes, and then the whole structure of relations breaks down. I hope that you do not have such problems.To date, the databases have coped with this problem: more or less. We all know that an identifier is assigned differently now. This case I gave as an example of a rake. In fact, in other industries such identification is used now: lawyers, accountants, when they draw up an agreement, then an additional agreement to it, which refers to some clause of the agreement. Or, for example, there is a Law or amendments to the Law, referring to a specific clause to the Law. It works in the real world, but an attempt to apply it in IT is a transfer of old experience or a rake, on which someone stepped on and stepped on again.
What are crutches? This is a very common term in IT - backups or temporary solutions. As an example, any integration of one system with another is a crutch: one system is not capable of solving something, another system cannot do something either, and in order to integrate them, it is necessary to build crutches.
What are “gags”? Gags arise in cases where the program must perform certain actions itself, but shifts these actions to you. A very common phenomenon. All usability consists of gags. There is even an anecdote about the "Uzbek virus."
Joke. By e-mail you receive a letter in which it is written: “Hello, I am an“ Uzbek virus ”. My developer did not have time to finish writing me, so please send me to the entire address book and format the C drive. Thank you. "
Many programs behave this way, but we are just used to it and do not even pay attention to it. So, I gave the definitions of terms, we continue on the subject.
How requirements are developed now
I propose to consider an example of a project that I am working on at the moment - this is an internal development project. I am developing requirements in the Confluence Wiki (after having failed to select a normal tool as part of my research).
For example, I chose a rather primitive old version. For the developer, I give this page: context as part of the tool use case diagram (so that they understand why this project is being created). Then the text describes some specific requirements.
In this project, a visual panel is developed, with which users can perform certain operations (I indicate those operations that must be implemented). And further, an interface layout is given - an idea of ​​how it all should look.
Experience has shown that such a page for developers is normal. They understand that they are making a panel that will look something like this (in the example, not a real interface, but a prototype), the actual requirements, what they should do, and some contextual representations in the form of a diagram are listed.
Of course, the question arises: “In which program, other than Wiki, can such a presentation be made?” Word is not much different. But later you will understand why I chose the Wiki.
Participants in requirements management processes
I drew your attention to the fact that requirements management is a process that affects the interests of the whole team. You, as an analyst, develop requirements, then these requirements are used by different people. Depending on the size of the company, the scale of the project, the technology, some of these people may be, some may not, for example, lawyers may appear. The point is that in the center of the requirements management process are the requirements that the analyst is developing.
Below I will present some wishes on behalf of these people.
1. The analyst wants to enter requirements in the form of text.
I want to note that not all analysts want to develop requirements in the form of text - in this case, this is my personal preference. Most text analysts do not like working with text and prefer to work with visual models, especially those who work in Enterprise Architect. I explain why it is more convenient for me to work in the form of text: in this form it is more convenient for me to work with the team - they understand the context.
2. The developer wants to understand the context.
All my experience in IT shows that the main problem of programmers is that they do not understand the context of what they are developing. They sometimes program without regaining consciousness. For example, there are many programmers in the banking system development project. They absolutely do not understand what processes are behind this: what’s the point of accounting, why do we need reports. They get the installation that you want to add such a code in such a folder and in such a function. And people work like that for years.
This naturally leads to problems: a lack of understanding of the context of what they are developing leads to a large number of problems, which are rather expensive. And in order for people to be immersed in this context, they need to be given demands in a form that is understandable to them. We are kindergarten and schools are taught to work with the text - for all this is the natural way of presenting information.
Text or database?
There is an unnatural way of presenting information - this is a database. It should be noted that SUT appeared only when databases appeared, where you can sort everything out and monitor the life of each element. But here is a contradiction: people work with texts, and they need to be stored in a database, leading many to mild schizophrenia.Therefore, for the most part, the SUTs tend to the textual representation of the SUT, as it is organized in Wiki and Word, since they work with texts, and professional systems tend to database more often.
What does this lead to? Suppose I need to add a requirement. What I’ll tell you now is perceived by many of the listeners as something natural, because they don’t know any other ways. When you create a new requirement, you are asked to enter it in the dialog box. The slide shows a dialog box from Enterprise Architect because it is not text-oriented and can be justified there.
Dialog boxes
The following screenshot from TFS, is different here. I had a friend who was accustomed to working in Word, who categorically refused to work in the TFS system. This system allows you to use different design patterns (Scrum, MSF): requirements appear, bugs, change request, etc. In each case, its life cycle.
What's the point? When a default template is set, there every newly created artifact has the status of proposed. I don’t know why it was done, probably from the CMMI point of view, it was necessary. The bottom line is that when a person adds a new requirement, he needs to re-enter the dialog box and change the status again. Thus, he comes into a dialogue twice (of course, the template is customized and it can be removed). The bottom line is that each new element needs to be entered into the dialog box, and some systems still force all attributes to be set with pens - this is a kind of barrier to the introduction of the CMS.
3. The analyst does not want to do anything extra
I do not want to enter each paragraph in a separate window (much less repeat the same actions for each of them). I do not want to manually set all statuses and constantly switch between the mouse and the keyboard (everyone knows the carpal tunnel syndrome). This all knocks the analyst out of the stream.I hope that the listeners understand what I am talking about. When you sit and generate a stream from the requirements text, and then: create a window, move it with a mouse, then again, etc. This is very difficult to work and very tiring. Therefore, I consider the dialog box system to be one of the examples of plugs when the system transfers its internal device to you: I have a database and save each record separately.
4. The analyst wants to include visual models and images in the requirements.
One more example. I consider visual diagrams to be the most powerful means of presenting requirements. Without this, it simply does not work.In this case, the example that was given above in my requirements is the mockup user interface layout (developed in the Pencil program).
The point is that in order to insert a picture with requirements into the Wiki, I have to first export it to some jpg-png-bpm file, etc., and only then insert it there. And I always still (suddenly someone will have a desire to change something without me) I insert a link to the used tool and a link to the file. In my experience, no one ever wants to install a program to change a picture. In fact, such programs are surprisingly many.
5. Analyst: I do not want to export models to jpg-png-bmp-etc
He does not want to run his editors with his hands and store the models in separate files.And if you work with the Wiki, then you have to insert images in this form. This is a huge problem. I do not want as an analyst to do this. I do not want to run other editors. I do not understand why this is not implemented in the requirements development environment. This is perfectly implemented in MS Office, when you draw a diagram in Visio, and then paste it into MS Office, after which you can edit it right there without leaving Word.
In other words, it is a crutch.
6. The analyst is not a programmer and does not want to describe pictures in the form of code.
Another option is interesting for those who develop requirements in the Wiki (Media Wiki, etc.). For them, the following screenshot will be clear. These are wiki plugins that allow you to create diagrams as text or as a picture: PlantUML is a simpler plugin and allows you to draw regular diagrams, and GraphViz has a wider purpose, it is possible to draw any diagrams, but the programming language is more complex (similar to assembler). In fact, it is a very convenient program in terms of presenting information. You can change your charts without using any external means, moreover, you can track changes (this is theoretically, because practically I have never seen this done).But I do not want to code, although programmers love this program. In fact, if the user suddenly wants to change the arrows or move the figures of the users, and others, it will take a lot of time to figure out how to do it. If you are doing it in the Enterprise Architect program, it’s easier there, you’ve connected what you need with the arrows and everything, the difference is clear.
In general, it can be viewed in different ways. It can be considered as a gag, because I do not see any problems, why it is impossible to make an editor directly on the web. It can also be viewed as a crutch, because I want to include images and diagrams in the Wiki, but I have no other means, and I have to use it.
Does anyone remember what OLE is?
When Windows 3.0 or Windows 95 appeared and OLE was promoted by Microsoft precisely as an opportunity to embed one document into another: as I said, we create a diagram in Visio, then paste it into Word and then edit it in Word. I still do not understand why WEB does not have such a standard. There is something in Word, something in Flash, but there is no single way. Do you understand what I am talking about? You go to a web page and directly on it edit and draw something. I have high hopes for HTML5, because something has already appeared there before, but again I don’t understand why it hasn’t yet become mainstream.
There is a draw.io service that allows you to do this very conveniently and beautifully, but at the same time the diagrams are stored on their server, you can paste them into your pages, but not in your own. Perhaps this will change soon. That is why now Microsoft Office is so popular - there all these integration problems have been solved for a long time and are convenient, and, in addition, there are many developments.
7. The analyst wants to know what has changed in the requirements and models.
We have learned to compare texts more or less. The programmers have already mastered the source control systems, there are many means of comparing texts, however, the comparison of the models is still in place while the pipe is being used, although I am told that in the tenth Enterprise Architect there is already an opportunity to compare the two versions, but I thought it was originally .
I do not want to run third-party programs, and it makes no sense to compare binary files. What do the requirements management systems that I mentioned at the beginning offer to us? All those who present the system, consider exporting to Word their advantage. There are several reasons for this, it is very much in demand, including because Word allows you to compare texts.
With pictures, everything is bad. If you need to compare two pictures, then you need to solve the problem “Find 10 differences” - i.e. compare visually. There are no other ways.
8. The analyst wants to discuss the requirements so that the results of the discussions are always at hand.
The analyst has to discuss the requirements. The most common ways - in Word and by mail. You can also hold a meeting or print out on paper and go to visit him with a stack of papers.
This all gets it. I do not want to carry packs. I don't want to go anywhere. And besides, I want to make changes during the discussion.
This feature provides a Wiki.
9. The analyst does not want to carry a pack of paper and does not want to go anywhere.
He wants to make changes to the requirements right during the discussion.At our summer analytical festival (www.lafest.ru), which I advertise all the time, Elena Zhuravleva, technical director of Human Factor Labs, performed. She told how they lead the demands in Confluence. They have very different customers, including state ones, including large banks. And when I tried to elicit from her, how did they export all of this into Word to coordinate with them. She said that they do not export anything, but they take the page and they (the customers) work with it themselves.
People get used to good things very quickly. The main thing is for someone to show this good, but, unfortunately, our requirements management system, except Word and Wiki, which is specially tuned, does not know how to do this. What do we use? The only way is by mail.
I took a picture from the Internet, because I couldn’t have one — there’s too much confidential information. What we see: begin to make comments to every word, in every line. All this quickly grows into multi-colored "noodles". One paragraph and fifty comments to it from different experts. Then what does the analyst do? Rereads all this, throws it out and somehow rewrites it. Those.All these discussions are a crutch.
Or the second option, which is even worse. Goes to the customer, where everything discusses, crosses out on paper. And then it returns to the office with it, processes it and throws it away, because it is impossible to work with what was the result of the discussion.
10. The analyst wants to link requirements with each other.
I will not talk about tracing: the requirements need to be linked to each other, different components, the requirements have to be linked by levels (see the report by Irina Surova ). Again, we have to use crutches for this.
Hierarchy in models
I show not very good examples. In this case, this is a modified example from TrackStudio, where we tried to drive requirements. And in order to establish links between them, they tried to invent a hierarchy. The hierarchy itself is a good crutch. Now this is not a topic for conversation, because there are so many features: we try to think in advance which connections will appear in the requirements, and when we get into the subject area and begin to model it, it turns out that the hierarchy does not work. In general, hierarchy is a gag!Trace Matrix
Look at the following screenshot. Does anyone work with this? Yes, for planning testing, tracking changes.
As I said, I'm not the kind of person who likes working with tables. There are people, unfortunately, who are zombie tables. For example, my boss: he discovered the “magic” matrix in Excel and then required all documents to be developed in Excel, including meeting minutes, requirements, and reports. I call this interface: guts out, because if you want to find out what requirements you have covered with test cases, it’s easier for you to list the works that are being tested. But some like it. But, nevertheless, it is a crutch.
11. The developer wants to know what requirements he needs to implement, and the project manager - what requirements have not yet been implemented.
We talked about requirements management, namely, tying requirements together. This is one moment. But all the power of a command management system is that it allows you to link different artifacts. The developer sees what he needs to implement depending on the tasks. The project manager wants to know what is left in the project unfulfilled and wants to know (this is especially true when there are a lot of customers), which is already installed at the customer. First you send him versions from different branches, and then requests come in, and you try to understand what he already has. In particular, in the banking sector, I constantly came across this: you need to determine which requirements in the current version are already implemented for the client and which are not. SUT allows you to answer this question.
12. The tester wants to know which requirements have not been tested.
And the tester needs to know the test cases that he has left to perform.This is the task of the PMS: all processes are built around requirements management, when you need to track the very connections between artifacts.
This is best done in TFS, which allows you to connect anything, with anything, in any way, but the interface looks like this.
Links between artifacts
Those.If you want to associate one entity with another, you need to enter its number. And 2 color blocks in the lower part of the window, they are mockingly called visualization. Those.TFS, as it were, says: we have, you know, a relational database, therefore, describe all the relations with pens. This not normal.
For example, in the Enterprise Architect program this is implemented visually: you have two small squares and you draw an arrow between them.
These are plugs, and the ones that behave like the "Uzbek virus." On the one hand, there is a rich possibility of installing derived links, and on the other hand, a weak interface for creating such connections.
13. The customer wants his requirements understood correctly.
He wants to know what is done with his requirements.
We have already talked about the harmonization of requirements.
I repeat it all the time.
In order to communicate with the customer, we constantly use export to MS Office, because we think that the customer is a fool (although sometimes this is true), but in general, this leads to problems. This is a signal that it’s enough to use gags.
The bottom line: what tool to use?
In general, I presented all of the above as a diagram of options for using SUT to summarize the topic of conversation. In fact, the options can be much more.
There is another problem that I mentioned at the very beginning. I am an analyst. I come to a new company, I want to implement a requirements management process, get involved in the work and want to use my tool, and what do I get?
Look at the options.
Do you know what it is? This is a Rational product (IBM Rational RequisitePro requirements management tool, a picture taken from the Internet) designed for everything: for testing, for requirements. Simply put, as in the saying: the claw is stuck - the whole bird is a precipice. All of them are integrated with each other, something integrates with something else (but this, in our case, is a rake).
There is another option - Confluence (Atlassian Confluence program) - a plugin store: take the cubes and collect what you need.
Summarize the problem.
The team does NOT want to use analytics toys
I wonder if someone managed to drive programmers in Enterprise Architect with models to work? How did it all end? Of course, programmers are different.
But what I want to say: teaching the whole team the tools intended for analysts is not the right approach. On the other hand, if we try to drive the analyst into TFS - as you remember, it can only work with texts. This means that the entire connection with the visual diagrams disappears and the problem of connections arises, which I mentioned.
Although there is an experience from the Kaspersky Lab - they connected TFS with Enterprise Architect, but this is actually not enough anyone can afford, because in this case it turns out a very expensive project.
It is known that integration always turns out to be unique and the analyst cannot transfer his toolkit to a new project. In our company, for example, a special team works on supporting Confluence with Track Studio, which is called the Corporate Portal Support Team, where there are five people and they are the most qualified specialists. Those. it is expensive.
Dreams
As a result, I want to dream. It would be nice to take all the best of all the tools and put it all in one tool.
I tried to create an optimal system of requirements for documents. More precisely, these system requirements were born in the system analysis club.
• Generation of documents in different formats
• Joint remote work
• Consideration of influence and tracing
• Version control
• Integration with modeling tools
• External add-ins
However, in the process of working on my report I corrected these requirements.
Requirements for
•
• Joint remote work, including with customers
•
•
•
•
I want to show that happened.
1. Entering requirements
Here I enter the text in Confluence. Why should I enter data in some form? You can do this car.
Based on the formats of the requirements entered, the machine itself should list the records in the database. Let there be a possibility of correction, if I believe that she did something wrong, I will press Backspace and she will remove the record. There are similar systems: Rational RequisitePro (it uses MS Word as the text input tool) - here the requirements are typed in the form of text, which fall into the database with rakes and jambs, which can be seen even at the demonstration. I don’t see any technical problems.
2. Establishing hierarchy and relationships
After entering the text, the system itself must build connections based on the structure. It is clear that you will need to create a link layout, template. I use the template in Confluence to enter the requirements, and the record gets into the database at once with all the links, as shown in the screenshot diagram. I do not see any problems. Of course, this must be programmed.
3. Building diagrams
I want the connections to be set up like this. I want to change the diagram, make it to me on the web.
Why the web?
4. Display changes
If we already store diagrams as a record in the database, as a rule, the record is stored in XML. XML is the text from which we can always isolate all changes. Why this cannot be shown on the diagram I do not understand. Example: the screenshot shows two versions of the diagram, where I can immediately show what has changed in the latest model, compared with previous versions.
5. Coordination with the customer The
question is, why do we need the text? But the idea is that we leave the text as the main way of keeping the requirements. Let's work with this text and give such an opportunity to the customer: let him look at the requirements and put in points where he agrees: like (let him "like").
In fact, it is very convenient. Instead of going to him with a printout of requirements in the Word, you give him this Wiki page. He has his own interface for working with text and he notes: agreed - did not agree. If you need to discuss - please, note that you need to discuss and immediately discuss. What does this look like in modern TFS requirements management tools? Long and boring discussions.
6. Tool for managers
With the text you can do anything. It is clear that you can customize the presentation depending on who is watching. For example, for project managers.
First, he assigns which release this requirement will go to, and then he monitors the change of statuses. There are many such examples.
7. Making connections.
What is link building? In this case, I tried to demonstrate how to create requirements with test scenarios. Those. The tester works with the context of the requirements (in text form) and can immediately create the necessary links (they immediately go to the database).
It is clear that this requires a well-developed model initially. Sometimes you need to associate something with something so that in the end your project does not suffer.
8. Visualization of communications
I took this picture from the Internet. Its meaning is as follows: instead of, as in TFS, all communications are hammered by hand, communications are shown visually.
9. Conclusions
And finally, the most important thing. I have presented all of the above about rakes, crutches and plugs from the point of view of analysts, but from my point of view, you need to take the tools of teamwork and attach a human interface for analysts to them. Then the problem would be solved.
Those. I want a tool for the whole team, but everything is so that everything that has been gained in other toys of analysts is convenient for him. From my point of view, all the prerequisites for creating such a tool are. As soon as such a tool appears, he immediately, in my opinion, will receive high popularity. Maybe they have already appeared, then tell me about them. (This hut in the screenshot symbolizes the web turned to face the analysts).
That's all. Thank you all.
You can meet Gregory at the next Analyst Days conference in Moscow on May 24.
Source: https://habr.com/ru/post/217737/
All Articles