JITRE was held August 25, 2015 in Ottawa. Here are is part one of our outcomes. Part 2 will cover the open research questions we identified.
<h2>Evaluating Just in time RE Analysis</h2>
<span style="font-weight:400;">An early description of just in time RE comes from Lee's <a href="http://cf.agilealliance.org/articles/system/article/file/1007/file.pdf">JITRA Principles (pdf)</a>. In the afternoon, the participants split into groups and walked through each principle to capture pros and cons.</span>

<span style="font-weight:400;">(1) Req's aren’t analyzed or defined until they are needed.</span>
<table>
<tbody>
<tr>
<th>Pro</th>
<th>Con</th>
</tr>
<tr>
<td>Save time & money</td>
<td>What’s “needed” is not clear.</td>
</tr>
<tr>
<td>Easier to understand</td>
<td>Risk of missing sth. important.</td>
</tr>
<tr>
<td>Get the big picture</td>
<td>If it’s important, then you won’t miss it. If it’s missed, then it’s not important.</td>
</tr>
<tr>
<td>Avoid over-specifying</td>
<td>Missing dependency of req.s.</td>
</tr>
<tr>
<td></td>
<td>May need to do a lot of re-work.</td>
</tr>
<tr>
<td></td>
<td>Risk of wrong “architecture”/design choices.</td>
</tr>
<tr>
<td></td>
<td>No scope to budget on</td>
</tr>
</tbody>
</table>
<span style="font-weight:400;">(2) Only a small initial investment is required at the start.</span>
<table>
<tbody>
<tr>
<th>Pro</th>
<th>Con</th>
</tr>
<tr>
<td>Easier to approve</td>
<td></td>
</tr>
<tr>
<td>Easier when re-using a project (as opposed to building a project from scratch)</td>
<td></td>
</tr>
<tr>
<td>Initial investment is small… at some time, the investment will be added to the same as, say, waterfall</td>
<td></td>
</tr>
</tbody>
</table>
<span style="font-weight:400;">(3) Development is allowed to begin with incomplete requirements.</span>
<table>
<tbody>
<tr>
<th>Pro</th>
<th>Con</th>
</tr>
<tr>
<td>Fast prototype</td>
<td>Hard to distinguish between functional and nonfunctional req.s (if you have incomplete req.s)</td>
</tr>
<tr>
<td>Adaptability</td>
<td>Hard to know if it’s feasible (hard to design V&V activities)</td>
</tr>
<tr>
<td>Experienced developers don’t need complete requirements</td>
<td> Risk of wrong “architecture” / design choices</td>
</tr>
<tr>
<td>Experienced developers may need to use only the code to understand the requirements</td>
<td></td>
</tr>
<tr>
<td>Fits developers intuition (ego)</td>
<td></td>
</tr>
</tbody>
</table>
<span style="font-weight:400;">(4) Analysis and requirements definition is continuous throughout the project.</span>
<table>
<tbody>
<tr>
<th>Pro</th>
<th>Con</th>
</tr>
<tr>
<td> Tracing is easier</td>
<td>No certainty on deliverables</td>
</tr>
<tr>
<td>Flexible & adaptable</td>
<td>Difficult for contract</td>
</tr>
<tr>
<td>Quick feedback on the direction</td>
<td></td>
</tr>
</tbody>
</table>
<span style="font-weight:400;">(5) Requirements are continuously refined as the project moves forward.</span>
<table>
<tbody>
<tr>
<th>Pro</th>
<th>Con</th>
</tr>
<tr>
<td>It's clear what to do</td>
<td>Risk of duplications, therefore ambiguous & misunderstandable</td>
</tr>
<tr>
<td></td>
<td>Always need RE skills</td>
</tr>
<tr>
<td></td>
<td>Cross-functional software developers</td>
</tr>
<tr>
<td></td>
<td>Risk to “never” refine requirements (there’s always tomorrow)</td>
</tr>
</tbody>
</table>
<span style="font-weight:400;">(6) Change is expected and easy to incorporate into requirements.</span>
<table>
<tbody>
<tr>
<th>Pro</th>
<th>Con</th>
</tr>
<tr>
<td> Itself is a pro -- it’s not a principle</td>
<td> Not everyone needs (wants) change</td>
</tr>
<tr>
<td>Only applicable to agile process</td>
<td>False expectations (create a [false] sense of easier to change implementation; probably the fact is easier to change requirements)</td>
</tr>
<tr>
<td>Flexible, shorter cycles, lean</td>
<td></td>
</tr>
</tbody>
</table>
<span style="font-weight:400;">(7) Analysis tasks complement XP planning.</span>

This one we left off given the lack of time.