Requirements in time critical projects

I read another interesting article, Requirements Engineering for Time-to-Market Projects (requires IEEE access) by Christopher McPhee and Dr. Armin Eberlein.



This article talks about what techniques work best for critical Time-to-Market (TTM) projects. We’ve all had projects that were “urgent”, in fact most projects we work on are, so I thought this would be an interesting read. I’ll share some of the highlights with you. This article suggests that standard requirements engineering practices for large-scale organizations is ineffective when applied to TTM projects.



First of all, to increase speed in the process, there are only a few things you can do. Either do less things, do them faster, or do them concurrently. So they looked at techniques against these choices. Based on these criteria and looking at what would produce quality requirements, they found the top 4 techniques were:

• JAD


• Modeling


• Scenarios


• Prototyping

It’s funny to think about JAD as being fast, but I suppose if you set it up correctly and execute it well, it can be fast relative to talking to people individually. That said, it’s so rare to see JAD done well. I completely agree with the listing of modeling, scenarios and prototyping (see another post on the value in prototypes).

Just below those on the list are some more interesting techniques:

• Requirements re-use


• Checklists

I am looking for ways we can reuse requirements. This makes sense both from the perspective of projects in the same organization likely have similar requirements they could share (ex – non-functional requirements are often consistent) and at a functional level, many functions are reused across applications (ex – login), so likely have similar requirements. The checklist idea is a personal favorite. I live by them in most areas of my life. They take the thinking out of the process.

We are all familiar with the common attributes of good requirements – unambiguous, complete, concise, etc. In TTM projects, it may feel natural to shortcut the unambiguous attribute, but it turns out, developers really think that this one is more important in TTM projects. So they look for techniques that will lead to unambiguous requirements.

What was interesting is that they surveyed development teams about the usefulness of the various techniques on TTM projects. The top techniques were:

• Prioritization


• Change management


• Scenarios, use cases
  

What I found very interesting was that the top TTM techniques varied in an interesting way from non-TTM projects. So to start, change management is near the top on both types of projects. But requirements prioritization wasn’t even on the non-TTM top 10 list. And requirements reviews dropped significantly in usefulness from 3 on non-TTM projects to 9 on TTM projects. This last one is pretty interesting. I think it implies that you are moving so fast, you are probably getting requirements, building them and iterating on them through things like prototyping, more so than getting them right up front.

Anyway, it was something interesting to think about. Nothing terribly earth shattering though.