What is the best way to go about gathering requirements for a project?

Question

How to collect system engineering or product requirements? For example, if we want to make a car, how should we collect the requirements? Kindly guide me.

Answer 1

It's called systems analysis - you go and talk to the would-be users of your product.

Answer 2

I would probably start off by readying Gathering Requirements I would then checkout Joel On Software and 37Signals. They have decent information regarding creating requirements documents. The Joel on Software site has an example of one.

Answer 3

Use an SRS document to record the requirements you elicit from the client.

Answer 4

1. Talk to people - project stakeholders and users in particular.
2. Ask questions. Lots of them.
3. Document your discussions and conclusions.
4. Use prototypes to validate the conclusions.

Answer 5

This is actually a really big question. The answer I would pose is "it depends." Collecting requirements is a very difficult thing. The best way to gather requirements depends on your project methodology. First are you going to use an iterative approach or a waterfall approach? You also need to determine who your project stakeholders are (e.g. project manager, developers, business analyst, customers, project sponsor...) Then you need to have your project stakeholders talk about what they want.

When you have everyone talking about what you want the business analyst should help guide the customers describe what they want. Your analyst needs to dig for the requirements. A lot of times the customer does not know what they really want or how to describe the system in a way that will make sense to developers.

The first step of this phase is to describe project scope. Once a good scope has been identified you will be able to determine which requirements are in scope or out of scope. After that the best way to identify requirements are to discuss the problem and what they would like to solve. Try not to build a solution during the requirements phase, just a description of what the end product ought to do.

Becareful not too spend too little time gathering requirements. The more changes you have later in the project lifecycle the more expensive it is to make those modifications. Also, don't spend too much time perfecting the requirements or you will find yourself in what is called "analysis paralysis." Keep in mind these points are just scratching the surface. Here are a few decent books where I read some of this information:

Software Requirements 2nd Edition by Karl E. Wiegers

More About Software Requirements by Karl E. Wiegers

These are decent books and they talk about all of the topics from preparing an SRS for multiple viewers to "Requirement Elicitation."

Answer 6

Normally it is helpful to remember that you are serving several masters all at once:

1. The end user
2. Management
3. Your design environment and whatever limits it imposes

The best thing is to spend time with all of the above

for instance: I recently was hired to program a system from ground up for a package delivery company - I had to please the end user (drivers - make it simple and fast) management (we want to know what everybody did and when/how) as well as working in a restrictive environment (a mobile scanner)

I spent a lot of time with management then turned around and went out on deliveries with the drivers. Only after that was I able to really get a handle on it.

An important thing to remember is to NOT simply come up with a solution that you like but one that actually solves the issues the client faces every day. The only way you will ever do this is to spend some quality time with them, preferaly while they are doing their jobs.

It is also worth clairify that last point - while they are doing their jobs...if you just ask them you will almost certainly get incomplete answers. Most people do many things on their job that they do not even think about anymore, it has just become habit. It is these little job quirks that are hard to pick up and include in a new system without first hand experience.

I apologize if you were asking for tools instead of methods.

Answer 7

• regular discussions with Customers and especially the future users and key-users
• Take small notes during the talks
• After each CONVERSATION write an official requirement list and present it for approving. Later on it would be difficult to argue against all agreed documentation
• make sure your Customers know approximately what are the approximate expenses in time and money for implementing "nice to have" requirements
• make sure you label the requirements as "must have" , "should have" and "nice to have" from the very beginning, ensure Customers understand the differences between those types also
• integrate all documents into the latest and final requirements analysis (or the current one for the iteration or whatever agile programming cycle you are using ... )
• remember that requirements do change over the software life cycle , so gathering is one thing but managing and implementing another
• KISS - keep it as simple as possible
• read the agile manifesto - working software is the only measurement for the success of a software project
• study also the environment where the future system will reside - there are more and more technological restraints from legacy or surrounding systems , since the companies do not prefer to throw to the garbage the money they have invested for decades even if in our modern minds 20 years old code is garbage ...