Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Software for An...  Document requirements for existing software
Previous Previous
 
Next Next
New Post 11/11/2013 10:22 AM
User is offline ShadinDC
1 posts
No Ranking


Document requirements for existing software 

 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

 
New Post 11/13/2013 8:05 AM
User is offline dldelancey
61 posts
8th Level Poster


Re: Document requirements for existing software 

Hmm, that's a tall order to describe in this forum.  I would recommend the IIBA's Business Analysis Body of Knowledge (BABOK) for a comprehensive description of the tools and techniques you might employ in such an endeavor.  Good luck.

 
New Post 11/14/2013 2:17 AM
User is offline Kimbo
454 posts
5th Level Poster


Re: Document requirements for existing software 

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

 
New Post 11/14/2013 7:50 AM
User is offline Sandy
74 posts
8th Level Poster




Re: Document requirements for existing software 

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

 
New Post 11/14/2013 7:51 AM
User is offline Sandy
74 posts
8th Level Poster




Re: Document requirements for existing software 

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

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Software for An...  Document requirements for existing software

Community Blog - Latest Posts

A business analysis checklist helps you stay organized while you work through projects. It includes questions that will help you identify problems in your current processes, and suggest improvements for future projects. Understand the Problem Before you start writing code, you need to understand what problem you're solving. This means u...
I’ve heard “The End is Near!” for Business Analysts for almost 20 years.  Waterfall project management, with its need for formal requirements, is dead…a dinosaur…so 1990’s.  To be honest, that’s mostly true.  With the publishing of the Agile Manifesto in 2001 there was no need for a 2-inch-...
Business analysis is used to identify and articulate the need for change in how organizations work, and to facilitate that change. As business analysts, we identify and define the solutions that will maximize the value delivered by an organization to its stakeholders. We look for opportunities for new business models and new ways to work together. ...

 






 

Copyright 2006-2022 by Modern Analyst Media LLC