środa, 11 czerwca 2014

Praktisk kravhantering på enkelt sätt



 
Hur klarar man sig inom IT-industriprojekt med dålig eller ingen formell kravantering?

I många projekt och firmor, man bedriver mycket lite eller ingen alls kravhantering, i alla fall inte under dess eget namn. Det är inte bra, men ofta inte så illa som det ser ut. Om det verkligen inte fanns någon kravhantering alls, ingen kännedom om den planerade produkten eller om projektmål, då skulle man inte kunna uppnå något som helst resultat.

Sådant skenbart missförhållande beror på att kravhantering och dess aktiviteter ofta döljs under ytan och genomförs som en del av helt andra projektaktiviteter.

Den långsiktiga lösningen är så klart genomgående processförbättringar, vilka skulle placera kravhanteringen på dess rättfärdiga plats. Men detta kanske kräver en revolution, både mental och organisatorisk. En kortsiktig, men snabb och pragmatisk förändring kan effektivare uppnås kravhanteringen där den redan faktiskt bedrivs, oavsett vilken klädsel den använder och vad den kallas för.

Min endagskurs lär ut, utifrån min praktiska erfarenhet och vissa funderingar och generaliseringar, hur detta kan uppnås.

[artikeln fortsätter på engelska – kursen ska i alla fall hållas på engelska J]
 

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 are sister (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.

Specialrabatter till RE’14




Till 22 juni gäller följande specialrabatter till 22 IEEE kravkonferensen i Karlskrona 25-29 augusti:

*** 10% Tutorial Rebate for IEEE RE'14 Conference ***
*** expires June 20, 2104 ***

Academics
IEEE Member – Early Bird, 10% Rebate on TS
http://eventus.trippus.se/RE14-reg-A-TS

IEEE Non-member – Early Bird, 10% Rebate on TS
http://eventus.trippus.se/RE14-reg-C-TS

Student IEEE member – Early Bird, 10% Rebate on TS
http://eventus.trippus.se/RE14-reg-E-TS

Student Non-member – Early Bird, 10% Rebate on TS
http://eventus.trippus.se/RE14-reg-G-TS

Industry
IEEE Member – Early Bird, 10% Rebate on TS
http://eventus.trippus.se/RE14-reg-I-TS

Non-member – Early Bird, 10% Rebate on TS
http://eventus.trippus.se/RE14-reg-K-TS