1

Topic: Documenting of correspondences of business requirements to the code

Whether for a long time wanted to ask such question, generally speaking, I do not know there is such problem in development or it is decided by me, we in firm of developers have not enough and all becomes on storage. Namely: as storage of a binding of requirements and code pieces where these requirements are implemented is organized. If for the requirement the class, apparently, it is possible to conduct a label the requirement-class answers. And if the requirement is spread on triggers and a data access layer. Most likely it is a designing error (or I am not right), but such it is theoretically possible. How process of a coordination of such binding of requirements with the code is under construction? I.e. if I changed the code I should  go to correct the document. Whether There is such problem in the modern world of software development? How she dares? If not to conduct a binding in the document, it can be possible to write requirement number to comments in the code and any collector collects the referential documentation? Or when I in   in comments can write the requirement identifier. Then in the future I can look at what code is responsible for the requirement under this comment?

2

Re: Documenting of correspondences of business requirements to the code

Hello, hyp1k, you wrote: H> As storage of a binding of requirements and code pieces where these requirements are implemented is organized. If for the requirement the class, apparently, it is possible to conduct a label the requirement-class answers. And if the requirement is spread on triggers and a data access layer. Most likely it is a designing error (or I am not right), but such it is theoretically possible. How process of a coordination of such binding of requirements with the code is under construction? I.e. if I changed the code I should  go to correct the document. Whether There is such problem in the modern world of software development? How she dares? It not in all projects is really necessary. If the project small (we tell, to 500 to code lines) and with a distinct business model often happens faster to find dependence on the code and the specification, than to search for the separate document. It is necessary to understand that support of such document (by the way, for search, it normally is called traceability matrix) business troublesome enough. H> if not to conduct a binding in the document, it can be possible to write requirement number to comments in the code and any collector collects the referential documentation? H> or when I in   in comments can write the requirement identifier. Then in the future I can look at what code is responsible for the requirement under this comment? In practice, in small projects is better to connect requirements and the code through units-tests: to each test to write the attribute enumerating points of requirements. And all code which is fulfilled under this test to consider implementing the requirement. It allows to generate automatically dependences and to collect them in the document though everyone . And the document in this case is not especially necessary, it is possible to look directly under tests. After all the ultimate goal of such document normally just to clarify, change of the given piece of the code can influence what requirements. And search of the code in requirement number becomes simple.

3

Re: Documenting of correspondences of business requirements to the code

Hello, hyp1k, you wrote: H> If not to conduct a binding in the document, it can be possible to write requirement number to comments in the code and any collector collects the referential documentation? H> or when I in   in comments can write the requirement identifier. Then in the future I can look at what code is responsible for the requirement under this comment? If there is a post of an analyst - it already should organize all this business. If is not present  - to get and cross to yours  source codes. If is  - to mark all  with functional labels, further the necessary is banal search  and review . Well, or in the opposite direction: we find a problem file, we look, in what  the problem place exchanged. From  we get number , further all is simple.

4

Re: Documenting of correspondences of business requirements to the code

Hello, hyp1k, you wrote: H> If not to conduct a binding in the document, it can be possible to write requirement number to comments in the code and any collector collects the referential documentation? H> or when I in   in comments can write the requirement identifier. Then in the future I can look at what code is responsible for the requirement under this comment? https://en.wikipedia.org/wiki/Behavior- … evelopment

5

Re: Documenting of correspondences of business requirements to the code

Hello, hyp1k, you wrote: whether H> There is such problem in the modern world of software development? How she dares? Software Configuration Management

6

Re: Documenting of correspondences of business requirements to the code

H> As storage of a binding of requirements and code pieces where these requirements are implemented is organized. The elementary variant - through  in Jira/Bugzilla/etc. In  requirements are specified.  has type "feature" (or "user story", it where as is accepted). If at you is more than one level (for example, everyone feature consists of many user story), enter this level in a type in addition fields "the feature identifier". Everyone commit in SCM (git, SVN, whatever) contains number  where everything is described that should be made for this specific target. , opened on bugs, also can contain the reference on feature/UserStory that it was clear, to whom and that . H> i.e. if I changed the code I should  go to correct the document. Whether There is such problem in the modern world of software development? How she dares? The separate document is not necessary. If it is necessary to find all documentation on the given feature, it or is conducted by an analyst (at you that is not present), or gets banal search on Jira/Bugzilla.

7

Re: Documenting of correspondences of business requirements to the code

The automated acceptance tests for a feature will be a reliable method as it seems to me. Here they it is exact  coordinate the requirement to the code.