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
Advertisements

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.