Workshop Summary (part 2)

Part 2 of our workshop outcomes covered open research questions (part 1 looked at pros and cons of the just in time approach).

Open Research Questions

Based on the papers presented and ongoing discussions, the participants derived the following list:

1. If what’s important won’t be missed ⇒ What’s missed is not important. Does this relationship hold?
2. How do we do resource allocation (e.g., budget, $) in the face of JIT Reqs.
3. What’s a “small” (how much; how much is “big”) initial investment? (Principle #2)
4. Tradeoff between adaptability and building something that you don’t really need (YAGNI — you aren’t gonna need it)
5. How can you tell something is important without refining it? (e.g., slicing architecturally significant requirements; bucket architecture into 2-3 week period)
6. Don’t know the unknowns ([quality/NFRs]). Would a reqs taxonomy be useful here?
7. Can you do JIT RE on NFRs (e.g., security)?
8. Is traceability different in JITRE? Traceability assumes one has complete artifacts for both requirements and (code/design/arch) to trace between.
9. How consistently are the labels like “enhancement”, “major improvement”, “new feature”, “user story” used? (cultural variances, agile versus OSS). Can we rely on these for research data?
10. Metrics are rich for coding, testing, but not for reqs/RE. How significant is the lack of RE metrics?
11. Spikes as a way of advancing (experimenting) and deriving or eliciting new requirements.
    1. “fail early, fail often” branching/forking
12. Relationships between concepts at an abstract level: Agile, time-constrained, just-in-time RE?
    1. e.g., agile is not necessarily time-constrained

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.