1

Topic: The tool for control of requirements

Hello! In some projects for the registration of requirements of the customer any more there is no Excel th, Word. Advise any a software for development, the registration and control of requirements. What programs use? What advantages in them \lacks?

2

Re: The tool for control of requirements

E> What programs use? Marvelously - Outlook.

3

Re: The tool for control of requirements

Hello, Dym On, you wrote: DO> Marvellously - Outlook. And what there is in Outlook for control of requirements?

4

Re: The tool for control of requirements

Hello, es3000, you wrote: E> Hello! E> in some projects for the registration of requirements of the customer any more there is no Excel th, Word. E> Advise any a software for development, the registration and control of requirements. E> what programs use? E> what advantages in them \lacks? Good afternoon At us in the company use IBM Rational DOORS

5

Re: The tool for control of requirements

E> What programs use? Different. In this business the main thing - process, instead of the tool. In a tool role used (from old places of operation to new) 1. Excel (year so to 2005) 2. Bugzilla ( to impropriety) together with CVS, SVN, git 3. Eparxx Systems Enterprise Architect 4. Jira and as it is amusing, Trello 5. Targetprocess (this is ground under development process used now)

6

Re: The tool for control of requirements

E> And what there is in Outlook for control of requirements? What do you imply controls of requirements? Requirements are exposed by the customer, it does it normally on email', yes even if by phone or at personal meeting, all the same then everything that discussed, it is necessary to write down and send on the statement, besides on email'. That is the mail client becomes that node through which is mandatory transit all requirements and . It is enough means for their organization: both categories, and flags, both periods, and - all it it is possible to twist folders somehow. There is a search, it is possible to assign meetings, etc. If to use any other system, it is possible to lose, forget to import, forget to confirm something, and here all in one.

7

Re: The tool for control of requirements

You incorrectly put the problem: you need first of all not to select the tool, and to put development process. And already proceeding from process requirements it is necessary to select the tool. Concern it, as to the project on implementation: 1. Define business users is possibly there will be analysts, developers,  and management. 2. Formulate requirements from each business user. 3. Requirements to the tool allow you to formulate search was more specific and to select possible decisions... Etc. before start in prom. maintenance. In the market of decisions it is a lot of and following step after a Word and  there can be a dial-up of server products -  or the monitoring system of versions as documentation storage,  as the tool of control of performance of tasks (implementation of requirements). Plus  in simplicity for ultimate users, plus of the monitoring system of versions of type Git - in simplicity of tracing of correspondence of requirements to the code. Approximate variants (them much more in the market): 1. Free of charge - Git + MediaWiki+Bugzilla 2.  - Git + Atlassian JIRA + Atlassian Confluence More serious, but also more expensive variant - ALM CodeBeamer and analogs.

8

Re: The tool for control of requirements

DO> That you imply controls of requirements? Requirements are exposed by the customer, it does it normally on email', yes even if by phone or at personal meeting, all the same then everything that discussed, it is necessary to write down and send on the statement, besides on email'. That is the mail client becomes that node through which is mandatory transit all requirements and . It is enough means for their organization: both categories, and flags, both periods, and - all it it is possible to twist folders somehow. There is a search, it is possible to assign meetings, etc. If to use any other system, it is possible to lose, forget to import, forget to confirm something, and here all in one. It you describe a communication medium, so to say, for the coordination of requirements. Categories, flags, are installed not to requirements, and letters. So it not that system

9

Re: The tool for control of requirements

A> At us in the company use A> IBM Rational DOORS Heard that there is such system. Speak, abrupt. How impressions?

10

Re: The tool for control of requirements

11

Re: The tool for control of requirements

B> you incorrectly put the problem: you need first of all not to select the tool, and to put development process. And already proceeding from process requirements it is necessary to select the tool. The tool that all requirements of the customer which has been written down by chaotically separate sentences, somehow to group, classify, place correlations in between is to begin with necessary. As a result it is necessary to receive the intelligible grouping (classification) of requirements containing the logical serial description of these requirements, communications of business requirements and "technical" requirements. Then it is necessary to trace these requirements - can be any it is necessary to change, from any to refuse.

12

Re: The tool for control of requirements

13

Re: The tool for control of requirements

SD> Different. In this business the main thing - process, instead of the tool. SD> in a tool role used (from old places of operation to new) SD> 1. Excel (year so to 2005) SD> 2. Bugzilla ( to impropriety) together with CVS, SVN, git SD> 3. Eparxx Systems Enterprise Architect SD> 4. Jira and as it is amusing, Trello SD> 5. Targetprocess (this is ground under development process used now) Similar that any of them is not the tool, ground it is is specific on control of requirements.

14

Re: The tool for control of requirements

Hello, es3000, you wrote: E> the tool that all requirements of the customer which has been written down by chaotically separate sentences, somehow to group, classify, place correlations in between is To begin with necessary. E> as a result it is necessary to receive the intelligible grouping (classification) of requirements containing the logical serial description of these requirements, communications of business requirements and "technical" requirements. E> then it is necessary to trace these requirements - can be any it is necessary to change, from any to refuse. Here before "to begin with", it is necessary to define process. It is not necessary to overturn upside down, be defined with requirements to the tool on the basis of your development process, and then select.

15

Re: The tool for control of requirements

B> Here before "to begin with", it is necessary to define process. It is not necessary to overturn upside down, be defined with requirements to the tool on the basis of your development process, and then select. So it also is process: 1) we fix requirements of the customer 2) it is analysable, we classify, we install correlations between separate requirements 3) it is revealed , contradictions etc.

16

Re: The tool for control of requirements

At you any very simplified understanding of process of operation with requirements. In large-scale projects, it not only , consisting from mentioned by you interview to the customer ("we fix requirements") and its handlings ("it is analysable, ..." ). Before the customer still should formulate project business purposes with which all subsequent decisions should be commensurated. After that, in an amicable way, there should come a design stage of information architecture on which you coordinate conceptual basis (a project glossary) with the customer and construct Customer Journey Map. The information architecture defines requirements to an interface design stage on which you can implement CJM in a prototype of your application (wireframe or interactive) and to describe requirements to the interface. On the basis of the interface project, and also business requirements of the customer to application deployment (for desktops - recommended configurations and propagation methods, for server applications - loading/cost, etc.) You can pass to writing of the functional requirements from which there will be a technical specification of your product (architectural decisions and ). And only then you can pass to an implementation stage on which the developer solves the tasks on operation with requirements (what?). And then there will be a testing stage on which SQA the engineer should too somehow with requirements work (as?). And acceptance testing by business users will be then probable, and they too should somehow with requirements work (as?) . And probably still someone should write the user guide for what too it is necessary to work with requirements... And to the expert of technical support too not bad to know a product functional... And how about your colleagues from the adjacent command with which development you are integrated? How process of operation with requirements to integration will look? And then to you audit or the appraisers fulfilling due diligence comes, and they want to familiarize with how you provide quality of a product and its correspondence to requirements. They will need to show any documents... As you can see, not all so is simple. There are tools which allow to work with requirements at all mentioned stages, there are what close this functional partially. Your choice should depend on that, how you work, and it normally is not reduced to "wrote down-systematized", and includes also other business processes of development which too need to be recalled and fixed.

17

Re: The tool for control of requirements

E> it is similar that any of them is not the tool, ground is is specific on control of requirements. Because control of requirements is not the tool, and process. When you understand with process and (a recursion, yes) collect requirements to the tool - then it will be possible to consider the tool.

18

Re: The tool for control of requirements

E> So it also is process: To such "process" to you more than will enough apply Trello. However listen Baudolino, he writes the correct things.

19

Re: The tool for control of requirements

E> Hardly further in this subject I wrote the wishes to management system requirements: E> http://rsdn.ru/forum/management/6332931.1 the Author: es3000 Date: 02.02 18:28 you make a classical mistake: put a cart ahead of a horse. To you already correctly advised in adjacent branches - at first build process. Now at you how much I understood, a brothel in requirements, and you want to put it in order. But only it is necessary to consider that the system does not direct the order. I will tell banality, but attempt to automate a brothel leads to appearance of the automated brothel. No more. System it simply tool of automation of already built process. As I already wrote, in my case process of operation with requirements is built so that I have enough outlook'.

20

Re: The tool for control of requirements

Hello, es3000, E> the tool that all requirements of the customer which has been written down by chaotically separate sentences, somehow to group, classify, place correlations in between is To begin with necessary. E> as a result it is necessary to receive the intelligible grouping (classification) of requirements containing the logical serial description of these requirements, communications of business requirements and "technical" requirements. Such tool is, MS Word is called. Well and brain presence too is desirable As a result the document under a title "Technical project" turns out. E> Then it is necessary to trace these requirements - can be any it is necessary to change, from any to refuse. Aha, too it is enough MS Word. Addition to  "is written corresponding".