Developers Club geek daily blog

2 years ago
Than unfinished construction in development threatens and what difficulties it is necessary to face on this way? As the business analyst of the company who 15 years are engaged in development and support of one product (EDMS), I has decided to share the thoughts and examples from practice. Perspective of management of requirements in any software products with the long period of implementation – topical issue for analysts, project managers and owners of products. And, perhaps, for direct partners and customers of Docsvision expecting output of the new versions and interested in emergence of new functionality.

Unfinished construction in software development: about problems of management of requirements

To what lead races behind terms and when flexible methodologies do not approach

Why among the companies vendors the tendency to refuse short-term projects (in our understanding it is products from the release period to 1 year) and politicians of frequent releases, and also flexible methodologies is widespread in development?
Visually the picture on which it is possible to select only one intersection gives the answer to question:

Unfinished construction in software development: about problems of management of requirements

As a rule, in the short-term project there is no opportunity to implement large volume of new functionality at temporary use of the due quality level therefore often customers do not see for themselves benefit in transition to the new version (any updating contains certain share of risk, and they reflect, whether it is worth it?). And for vendor any release — expensive pleasure as the full version is set of installation, documentation, carrying out performance tests, regression testing, testing of updating and compatibility and still the whole package of measures which it is necessary to be in time in rather small terms. Returning to the picture above, we get on intersections Qualitative Quickly or Fast is cheap. As resources are not boundless, it will be the second intersection (read, it is curve). The output arises: frequent updating of the version of product is unprofitable to both parties.

Having analyzed these factors, we have come in due time to the decision to replace policy of release of product: to pay attention, first of all, to quality, but not pursuit of terms. As a result at the same resources we receive unfinished construction (however instead of full-fledged releases we began to let out packets of accumulative updatings to fill up wait time of upcoming version).

Anyway, many vendors which are in the market not the first year come to similar solutions: this approach is used and in the companies of such scale, as Microsoft or Adobe. But at stage of development or in view of small scales, in a number of products you should not refuse policy of frequent releases.

Development methodologies

Let's pass to development methodologies now. The flexible methodologies popular today known to all Scrum/Kanban by the principles, for example, have not suited us since are not expected the volumes and terms necessary for carrying out all stages of implementation of features. Besides, they do not consider specifics of distribution of works in our team. Completely in the company we did not refuse these methodologies, in other Docsvision projects application was found for them.

I will not peddle old stuff if I tell that in pure form nobody uses this or that methodology. As for the project of development of the Platform, I can tell that recently we use the own, mixed methodology. It can become subject for separate article, within this It should be noted that it to some extent Waterfall with the Agile elements (yes, happens also such!): on the one hand, project stages in the long term are accurately defined, there is detailed project documentation for each stage, quality has pervoocheryodny priority in comparison with resources and time, and they are the integral lines of cascade model of development. It allows us to arrange production and to make it more controlled. On the other hand, there is mobile list of requirements, change management that is peculiar to flexible methodology.

The policy of accumulative updatings gives the chance to provide ready functionality until release of major version. Involvement of final customers in process allows to make changes to the version on the basis of data retrieveds. We could not afford it, using classical Waterfall, after all in it requirements are rigidly set and the ultimate user receives the working product only after version release. At first sight, we used advantages of each of approaches, on closer examination – have received also problems.

Unfinished construction problems

1. Large number of requirements which final list is initially not approved
On the one hand, having increased implementation terms, it is possible to increase also number of the requirements included in the version. It is a little digits: in short-term (on average, semi-annual cycle) release we let out about 35 features in the version, in the latest version with the long-term period is still declared about 100. Thus in 10 years in base of requirements almost 1600 potential features which customers expect have been recorded to see in product, and the list planned for the next version gradually grows. Natural question: till what time it will proceed?

2. Definition of priorities and assessment
Solution of the question sounded in the previous point – in arrangement of priorities among the requirements selected by the owner of product taking into account the received estimates (development, testing, documentation and risks) which become on the basis of the specification provided by the analyst. In each company the approaches to arrangement of priorities. It can be studying of statistics of request about implementations of this or that feature, results of the competitive analysis, partner obligations and nobody cancelled common sense. We regularly conduct surveys among customers and partners, we try to receive information maximum from the outside (for example, at us the Ideas and Sentences portal where everyone can leave the request is open or vote for already existing sentences). Ways of obtaining information are also seminars, webinars and other public actions. On the basis of all data retrieveds priorities are established, but they can change, it is necessary to monitor it in real time. In our practice in the list of requirements criticality it for projects and the general demand has the greatest impact on feature position: before necessary, then the already desirable. Increase of priority can be promoted by cumulative effect from functionality implementation – the speech about wow/killer features.
For example, in one of Docsvision versions functionality on management of the status in system (it is active / on issue / in business trip) the employee with the indication of the period of absence and the deputy has been declared. I.e. the employee, going on leave on Monday next week, can specify on Friday time of the absence and the employee, it substituting. The last during the work in system, since Monday, receives the notification that it in specified period is assigned by the deputy. This feature as a result has received higher priority, than functionality necessary for many users on control of uniqueness of the documents registered in system.

3. The general and private

Unfinished construction in software development: about problems of management of requirements

This problem for the first time arises in any product at the time of forming of the list of requirements, irrespective of the period of its implementation. Unlike design solution where the movement goes from the general to the particular, in product all on the contrary. We receive from the outside separate wishes, thus customers describe often everyone the specific task, and wishes on similar subject can be a little. Key task — to reduce and consider them all in the specific requirement. But the problem can arise and repeatedly, and for that period that the version is developed (hi, unfinished construction), interested parties can propose new solutions or specify nuances. Occasionally it is necessary to introduce amendments taking into account these sentences in the form of requests for change that can cause as a result shift of point of Stop Development. Not always it turns out to reduce it simply to record of "the 1601st wish to development of system".

I as to the business analyst of product in each such case should look for compromise — universal solution which would suit all.
I will give example: the scenario on processing of negative solutions (failures) at approval of documents. Initially in system the simple logic when when receiving negative solution from one of participants approval simply went further, to other coordinating persons has been implemented. Then have implemented opportunity when receiving failure to return approval in preparation status that the employee-initiator had opportunity to introduce amendments in the document and to begin approval again. After sentences on completions have come: "make so that approval thus proceeded, but it was possible to make changes to the document, having started at failure consolidation", "and to us it is necessary that only at failure of gen. director approval was cancelled". As a result there was setup switch of the different modes of processing of negative solution, thus this setup can be used differently for each separate stage.

4. Problem of icebergs

Unfinished construction in software development: about problems of management of requirements

The speech in this case at all not about unfortunate passengers and team of the legendary "Titanic" which has disappeared in Atlantic. Icebergs I call simple, at first sight, requirements ("to add tick/button/line") which as it becomes clear on closer examination, influence other components of system and demand additional completions. True scales, as a rule, come to light at the time of design, but happens, as when developing. Therefore it is better to select at once such requirements and to consider more attentively that it is necessary to make, what impact will be had by completion on the existing functionality, to correct estimates. After all the earlier the iceberg will be noticed, the it is more than chances to avoid collision, and in long-term projects with large number of the interconnected requirements the probability of emergence of such situation increases many times.

Not so long ago I worked on the specification according to the requirement estimated only at development couple of hours. The requirement was consolidated to that it is necessary to display search string in the reference book opened on choice. This line and search functionality has been already implemented, simply was not displayed when the reference book opened for value choice. At first sight, anything difficult. However the requirement allowing to limit search area of values from kontrol in the cards working with this reference book has been in parallel made. Have implemented some modes limiting choice. But search string in the reference book always worked on all values and knew nothing about the new modes which as it has become clear, it is necessary to support too. It was necessary to increase functionality, estimates, certainly, have increased.
But it is not always possible to find the requirement iceberg at early stages.
It happened in our practice to face with similar already in stage of active development. Then the requirement for localization completion (value choice depending on interface language) the general properties of kontrol has come to implementation: tags, alignment, etc. By our primary estimates, work was reduced to implementation of the general algorithm for all kontrol, but in reality it has appeared so that each of controls has features, and to do for some it was necessary separately. Total the difference of costs of implementation in comparison with initial assessment has made about 45 hours.

5. "Heavy" features: to divide or not to divide?
In the long-term project we are able to afford to implement not only rather simple requirements, but also more difficult features which one development demands of 80 o'clock. As a rule, each such completion requires detailed and volume TZ, set of test cases, etc. Here also there is need of division of the requirement of some parts, after all simpler to perceive smaller information volume. But, first, at division of the requirement the picture in general" is lost ". Secondly, the total quantity of requirements to the version that affects efficiency of control, assessment and change management increases. In our case if to separate the sounded higher than 100 features, we will receive approximately triple increase in number of requirements. Certainly, it not reason for failure from division of certain requirements of components. It is worth dividing but where it is really necessary: for example, in the presence of independent completions within one feature, say, in situation when the scenario the general, but for its implementation is required implementation of new functionality in different parts of system.

Or in case of simplification of option of implementation: if it is necessary to make for a start necessary minimum, and to plan the rest for the future.
Example when the requirement can be separated.
Initial requirement: "To support integration with Microsoft Lync 2013 in kontrola of cards with possibility of history logging of dialogs".
After division: "To support integration with Microsoft Lync 2013 in kontrola of cards" and "To implement possibility of history logging of the Microsoft Lync 2013 dialogs in card".

Example when it is better not to divide the requirement in spite of the fact that different objects are finished.
"It is necessary to make display on discharges in kontrola Number and Whole. For example, instead of 1230000 to show 1 230 000. Whenever possible to make the same completions and for the Table".

Release close

Let's provide that all requirements are implemented, the last errors are corrected, documentation will be just about ready, and all with impatience expect the termination of the project and release. At this stage we can take view of results of the works and sum up the results. The main objective of the final stage – to identify introduced errors of design and defects "without delay", to view repeatedly implementation of all requirements in particular – interconnected, and also implemented at the very beginning of the project. For long-term projects it is better to break this volume task into iterations. It will also be preliminary acceptance of product. Our works on preliminary acceptance are performed by the analyst and the owner of product. Developers correct part of defects as error (before the main acceptance of product and release), and essential defects and errors of design can be recorded as the requirement of upcoming versions (with perspective of inclusion in accumulative updatings). Thus, as approaching date of release and the beginning of official acceptance of product the manual and technical support we receive complex assessment of results and partly the list of requirements of upcoming version.

Thanks for attention, dear readers! In this article I have sounded the main problems which we face at management of requirements in long-term projects, but it is not the complete list. And with what problems you had to deal?

Anna Kurmanova, business analyst of Docsvision.

This article is a translation of the original post at
If you have any questions regarding the material covered in the article above, please, contact the original author of the post.
If you have any complaints about this article or you want this article to be deleted, please, drop an email here:

We believe that the knowledge, which is available at the most popular Russian IT blog, should be accessed by everyone, even though it is poorly translated.
Shared knowledge makes the world better.
Best wishes.

comments powered by Disqus