FOSS Requirements Gathering

From Wiki

Derek Keats:

Requirements gathering exists on a gradient

At the low end is the “scratch your own itch” requirements: you're developing for yourself, and you define your own requirements as you go

At the high end is thorough, formalized process for defining requirements. This is usually the case when you are doing large projects for paying customers and large organizations.

Sometimes the client gives you the requirements when they first engage you. This greatly lowers your risk in delivering what the customer wants; you simply work to their requirements.

There are number of different approaches for defining requirements. One is business process modeling where you model the business processes, and map that to capabilities of your existing code, do gap analysis, and estimate how much work is required.

In the mid-range of requirements gatherings are a range of processes and techniques.

Xtreme programming and Agile methodologies are two mid-range approaches. These don't scale to the high end, but they definitely have their place. These are sometimes referred to as rapid prototyping.

There is also the Rational Unified Process, which is another formal methodology. What I've found is if it's a development where agile approaches are appropriate, RUP really slows things down.

One of the mistake that folks who do “waterfall” processes make in their thinking about agile methods is that agile is “cowboy methodology”. But agile has its formal process.

Rapid prototyping works well when you don't understand your use cases. But your users must understand that it is an iterative process. If they just want a finished product.

What's most important is having a requirements process. And people have to accept that software will be developed iteratively.

Gunner: I've learned that requirements gathering is more a political process than a technical process. Understand your users' needs and tease out the mandate of how you are expected to solve their problems and meet their needs.

Mark Davies: I learned that you always learn things from user testing.

Justin: It's so painful to see folks try to figure out how to use your software when you not allowed to intervene.

Mark D: Just put people in front of the screen with no explanation and let them have at it.

Chris: how do you separate design from building, the way builders separate architecture from the act of building?

Derek: there are several levels:

• At the highest level is enterprise architecture, which is like town planning
• At the next level is application architecture, where you get your actual functionality. You have to decide whether it's a standard architecture, services-oriented architecture, how the application interacts with the “outside world”
• At the next level is technical architecture where you

Spanning all three levels is information architecture, which is your data structures and how users interact with the information structure.

Also, a lot of software projects happen without thinking about operationalization. You need to think about what actually happens in data centers. Stuff comes out of development, and it has to get into operations, and there is always a tension. We should revisit this topic tomorrow.