Hello everyone, I am tasked with collecting requirements from users on an existing software system. The requirements will be used to further develop and improve the tool folks are using.  Please suggest a document or method I could use to collect the input from users.  I'm starting from scratch.  My company took over a contract from a company who did not leave behind any initial requirements.

My job will be to collect input, enter the requirements into a tracking system (sort of like a task tracker) and then pass these request to the developers.  I'll be responsible for tracking and providing feedback to the requestor.

I also need to develop a process for what I will be doing.  Anyone already have an existing requirements gathering process I can look at and then create one for myself????  I really would appreciate your assistance.

Thanks in Advance.

Shirley

Hi Shirley,

Sounds like you need to do more than just collect requirements. You need to work out the future state they want (perhaps requirements gathering is the way to do this), where they are now (analyse the current system that you inherited) and do a gap analysis (difference between the current system and what their requirements are telling you) to determine what your company needs to do to finish the job.

Tricky job but loadsa fun if you get it right.

Good luck

Kimbo

Shirley,

The one challenge that you will face is that when you start gathering requirements now 'from scratch', you will likely get requirements given to you that will vary from what the current system actually does. People will tell what they want the system to do - even if that is not actually what it does right now. I agree with Kimbo that your best approach is to document both current-state (what the system actually does) and future-state (what people want it to do, i.e., requirements) and then do a gap analysis of the differences.

To accurately capture the current-state of the existing software system, my suggestion would be to document with screen shots and textual descriptions of associated data rules, business rules and functional operations (actions that users can take and what happens in each case). A good way to capture this information would be to use the system yourself in a test environment if possible, and to job-shadow existing users. In job-shadowing, you sit and observe someone who is using the system to perform typical tasks and note how they use the system to perform those tasks.  If you bring people into workshops and ask them to describe all the functionality provided, they will likely miss a number of required functions (just because most people do much of their jobs by habit, and simply don't recall every step or detail).

This will give you information on how the system is working today. Then you can review this collected information with your business stakeholders to collect any future-state requirements for things they would want changed or enhanced. These will be your future-state requirements.

Sandy