Requirement Analysis

Anish M

Hey guys, I am new to "Requirement Analysis", usually i come in after design. There has been some structural change in our company and am now now doing "Requirement Analysis" for a project. Is there a tool/website/template available to ease the process... PLEASE PROVIDE ANY SUGGESTIONS OR BEST PRACTICES THAT YOU CAN THINK OF... thanks in advance -- modified at 1:00 Tuesday 9th May, 2006

El Corazon

Eurus wrote:

I am new to "Requirement Analysis", usually i come in after design. There has been some structural change in our company and am now now doing "Requirement Analysis" for a project.

Make sure it is adaptive. Agile programming[^] _________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)

peterchen

Requirements Analysis [dev, inf]: Make an appointment with the client where you discuss the proposed features. Everytime he requests something you think is not possible, pinch him in the cheeks. Hard. Lovely. New meanagers restructuring without taking care of the training. Oh wait, they SAVED training cost and got a bonus. Tell them you found above definition on the internet, and feel you need a raise because pinching is strenuous. OK, now for the serious part: "Requirements Analysis" is finding out what the client means when he says e.g. "We need new billing software", detailed enough to sign a contract about it. This typically includes: * understand how the client expects to use the software * which processes your software is involed in * what data is pushed around or stored where * standards and regulations your client must meet stuff like that. best practices: * spend some time with the client (talking, or even on his site) * Understand how they do it now, why they want to change it * Remmeber that the client often has all the facts but still doesn't know what he really needs

Some of us walk the memory lane, others plummet into a rabbit hole
Tree in C# || Fold With Us! || sighist

Joe Woodbury

Rule 1: Write a list of the requirements of the software. Sounds obvious, but you'd be surprised at how many such documents include implementation details and things that are "cool", but not required. Rule 2: Cite justifications for the requirements. A very frustrating thing is to find a really dumb requirement that has no supporting evidence. On the flip side, if you can show that so many users have a requirement, it really helps when designing the application (especially when you have contradictory requirements.) Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke -- modified at 0:16 Tuesday 9th May, 2006

code frog 0

There is a book Code Complete[^] it now also has a 2nd revision. Nobody should be doing requirements without understanding everything in this book. Once you have a foundation you can then embrace agile programming and other concepts but Code Complete is a must. This isn't just my opinion or at least it wasn't. Once upon a time Code Complete was the reverant response. Things change but I think I'm still right on this. - Rex

The enemy's gate is down.:cool:
Welcome to CP in your language. Post the unicode version in My CP Blog [ ^ ] now.

People who don't understand how awesome Firefox is have never used CPhog. The act of using CPhog alone doesn't make Firefox cool. It opens your eyes to the possibilities and then you start looking for other things like CPhog and your eyes are suddenly open to all sorts of useful things all through Firefox. - (Self Quote)

Dy

This book[^] doesn't cover requirements analysis directly, but it does give you a starting point from a programmers point of view. If you're totally new to it, it's a nice start (though you might need to follow it up with something more specific).

- Dy