Help!

I work for a government agency that buys vs build software solutions for its various agencies.  We are in the process of building a framework for eliciting requirements from our customers before we write our Requests for Proposals for the software solutions.  This will fix a huge broken in our organization.

My challenge is that as I research the vast number of ways to elicit / document processes and requirements, everything seems geared towards software development.

 I need a method that is simple yet through enough to elicit and document the essential business processes and have them validated by the users and then take those validated process (their As-Is) along with their defined business problems and turn them into functional requirements that will be used to write the RFPs. 

Another challenge is that our users are not IT folks and are not familiar with requirement elicitation, engineering or business analysis. 

My goal is to:

1)  Find a method that will help me learn and document / model the business processes for a department(s) as quickly as possible.

2) Find a method to translate the business processes into functional requirements for the RFPs.

I need a way to help the users think of their jobs as tasks or processes, help them tell me about the information (data) they use while performing those tasks and the rules(business rules) that constrain their tasks, the results / goals / outputs and the variations of the tasks.

The answer may be a hybrid of a use case I’m not sure how to get from a use case to a requirement that reads like:

“The system shall always notify the designated user (officer) when the predefined number of days is exceeded for an open fire records management case”. For example.  

I plan to start using Context diagrams to help us scope the area of study. But how do I elicit the information without being overly technical? (They hate that!! LOL)

TIA

Thank you , sorry it has taken so long for me to come back and respond.

That makes sense to me, I could start on both and fill in the Context diagram as I gather additonal information to completed while doing the lower level "workflow" diagram. They seem to perfer the word "workflow", they get confused when I talk to them about data flow diagrams.

Inputs are as important if not more to the process than outputs from the process.

TIA,

As an alternative to DFD's if you'd rather use a UML / Use case approach i'd suggest creating a process diagram e.g. activity diagram, BPMN; that shows your systems processes - this is likely to be muli-layered for anything but the most simple system. The important thing is to consider each node / activity on the process diagram to be a use case. Its also important to capture all activities, not just system based activities in your "As-is" as this can help you with determining opportunities for process and system improvement when creating your "To-be".

In your use case, specify not only the main course and alternates but also refer to the business rules and requirements covered in this use case. List your requirements and business rules separately - you can then ensure you've covered all the rules and requirements. Your functional specification starts with the process diagram with each activity specified after that in the document as a  use case. Your business rules and textual requirements can be appendices or separate documents. Your requirements list should also include non-functional requirements.

If you wish you can also include a basic business domain model as a class diagram with textual explanation of each class in your document.

I've used this approach for a number of years with great success.

Kimbo