Functional Requirements Part C
As Ron Foster, the CRM vendor, and Pat are reviewing the CRM project status before the project team meeting starts, “Pat, you have finished your business project document and functional specs in record time. You are good to go into your planning stage”.
“It seems the functional specs took a lot of time”, said Pat. “Is this true for all companies during a CRM application implementation?”
“Your time for drawing the business process charts was about normal”, explained Ron. “That’s because your team and users were always available for the scheduled meetings.”
“You mean that isn’t always true”, asked Pat.
“Afraid not”, explained Ron. “You would be surprised how some companies stall progress by: keep changing their minds about how things work and then have to research it and then schedule another meeting.”
“What about a small company with, say, 5 or 10 employees?”
“My advice goes along these lines. And it goes for almost any size company for that matter. On-premise CRM systems today are rich in function. Therefore, unless the detailed process charts indicate the need for lots of tailoring and/or integration, I say go with the out-of-the-box solution if 90% of the function is there.”
“What about the other 10%?” asked Pat.
“Chances are it will wait and you can create a phased plan. Realistically, some of that 10% will just go away as not really needed.”
“What about technical specifications? And what are they?
“Well Pat, technical specs are usually not needed for an out-of-the box solution. They are needed for a customized project. A functional specification describes how a product will work entirely from the user's perspective. It doesn't care how the thing is implemented. It talks about features. It specifies screens, menus, dialogs, and so on. On the other hand, a technical specification describes the internal implementation of the program:
It talks about data structures, relational database models, choice of programming languages and tools, algorithms, etc. For example a house construction project needs for technical and functional specifications.”
“This is good Ron. We still have a few minutes before the team starts arriving. Do you mind giving me a couple of real life examples?”
“ Pat, as you know, a typical functional specification might state the following: When the user clicks the OK button, the dialog is closed and the focus is returned to the main window in the state it was in before this dialog was displayed. It can be informal, in which case it can be considered as a blueprint or user manual from a developer point of view, or formal, in which case it has a definite meaning defined in mathematical or programmatic terms. When you design a product, inside and out, the most important thing is to nail down the user experience. What are the screens, how do they work, what do they do. Later, you worry about how to get from here to there. Fortunately a good out-of-the-box solution has already done this.”
“I like it. What about the technical specs?”
“A good example might be using . When the user clicks Log In, the following checks are performed on the server: and so forth.”
“Thanks Ron. That was very helpful. After our review this morning, what will be the next step?”
“We will get down to planning for installation and implementation.”
No comments:
Post a Comment