Workshop Summary (part 1)

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.

Pro Con
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.

Pro Con
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.

Pro Con
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.

Pro Con
 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.

Pro Con
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.

Pro Con
 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.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s