Site icon IT World Canada

Getting to FRs, part 3 – it’s the process, dammit

People expect a lot from their information systems, but it usually it comes down to one thing: the system has to do stuff. When you talk about systems, the verbs are active: the system is running, it is executing a function, the system is responding, ….
 
And what do you want it to do? You want it to do as much of your business process as it can, and then keep adding to it over time. So, you have to know your process, define it down to the steps and sub-steps that get you from input to desired output, from trigger to goal. And not just what you do now, you have to define the future state you want your process to be in, and with flexibility to accept change as well…. because each step in that future process is a Functional Requirement,  “the system must have the ability to do this…and … and this.” ….
 
And if you focus on identifying a candidate process, like Sell a Pizza, you can define all the steps necessary for a major process in 5 to 10 days.
 
Hah, you say… so I must tell you It takes focus and commitment. Give me 5 to 7 business people  — some managers, some staff  who work the process — six hours a day in facilitated sessions (with me plus a real-time documenter) and you will have all the functional requirements you need in days, not weeks or months. And it is something that your people can learn to do as well.
 
I don't want to use IT World to make a sales pitch; I just want people to know that getting to Functional Requirements does not have to be a long, drawn-out effort.
 
 
Comments? Thoughts? Counter-arguments?
Exit mobile version