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