How to cope in industry projects with poor requirements engineering awareness?
In quite many projects and companies, there is too little or even ostensibly no requirements engineering performed. That is, of course, bad, but usually not as bad as it looks. If there was really no requirements engineering at all, no knowledge about the intended IT product and project scope, then nothing could be done, no projects goals achieved.
This seeming incongruity is explained by the fact that requirements engineering is often hidden and performed under other role names, and other project activities.
The long-term solution is of course to improve the project process and put requirements engineering into it properly. However, this may require quite a revolution, mental and organisational. A short-term improvement may be more pragmatically achieved by improving real requirements engineering, however it is done, under the guise of whatever names apply.
This tutorial teaches and gives practical exercise in how to do this.
1. Requirements engineering as part of practical project management
Since project managers are responsible for project resources and deadlines, they must of course be responsible for its scope as well. Therefore, they must often take care of all requirements engineering activities. How can this be improved without changing processes too much? There are many good RE practices hidden in PMI and PRINCE 2, for example.
2. Requirements engineering in agile
Agile framework is very requirements-centred, and creates huge potential for extremely well-focused and disciplined development, but this fact is sometimes hidden behind the façade of little documentation, networking, self-organizing and funny terminology.
Agile can be made sharper still by more consciously following the best practices of “traditional” RE, and there is plenty of room in agile for great RE practices.
3. Requirements engineering in design and programming
Many great RE practices are already implemented in methods better known as programming practices such as DDD, BDD, FDD and TDD, and their full potential can be enhanced if we exploit their RE-related powers fully. But even without these methods, practical RE issues have always been, still are, and will always be solved by programmers, especially by great programmers, who seem to perform their RE-chores on the fly, on their way to great code. We’ll study how it works, and how it can work better still.
Then, of course, RE is to some extent done together with design modelling, and we’ll have a look at this option, too.
4. Requirements engineering in business analysis
Business analysis is an important part of RE, but I have seen many projects, where it seemed to replace complete RE altogether. In these cases, there was a huge yawning gap between business analysis and programming. We’ll try to bridge this gap.
5. Requirements engineering in testing
Testing and requirements engineering aresister (or brother) activities in many respects, but in this part of the tutorial we’ll focus on how test analysis and design are in essence very much requirements elicitation and analysis by other means. Seen this way, both RE and testing can be much improved, and projects can achieve much better results if they are aware of this. We’ll try to discover how.
6. Exploratory testing as ersatz requirements engineering
In many-a-project exploratory approach to testing has managed to find and help remove bugs that other test approaches have failed to identify. Apart from its other good practices, such as continuing test design during test execution, and still more apart from often hysterical and ideological (not to say “religious”) aspects of the popularity of exploratory testing, its real power is in being a very effective complement to, or even replacement for requirements elicitation and analysis, which could not have achieved the same.
Great results can be achieved if we learn how to put these two unwilling allies to co-operation.
7. Requirements management is in everything
Now it seems that the author of this tutorial has caught excessive proselyting fever, but it is actually true: even in most trivial, every-day misunderstandings and failures, the principles well known from RE are at work. We’ll study a number of communication, organizational, group dynamics and other psychological issues for the point of view of RE and discover, how it may help improve not only our IT projects, but virtually all projects, including daily lives.