Forums for the Business Analyst

  Modern Analyst Forums  Business and Sy...  Business Proces...  Business Process and Documentation Types
Previous Previous
Next Next
New Post 6/16/2008 9:59 AM
User is offline Carl
4 posts
No Ranking

Business Process and Documentation Types 
I just started working for a small IT shop that now consists of the owner the developer and me. The current process is the owner talks with a potential client for 15 – 30 minutes and based on that conversation the owner and the developer sit down and come up with an estimate of hour many hours it will take and then present the estimate to the client. If accepted, then we may interview the client one more time before we create a Functional Specifications document. This is used to obtain client sign-off as well as used by the developer to build from. The Functional Spec is way too detailed for any client to be expected to read and understand, but isn’t quite detailed enough for the developer and certainly not formatted for easy use by the developer. Does anyone have any suggestions for improving the process and what types of documentation we should be using and at what point in time we should be using it?
Thanks so much for any input.
New Post 6/17/2008 5:37 AM
User is offline Craig Brown
560 posts
4th Level Poster

Re: Business Process and Documentation Types 
Modified By Craig Brown  on 6/17/2008 6:38:42 AM)

I think you should basically skip the FD and go for a high level (higher than that) solution architecture and then talk them through the complexity.  Forget the issues of requiremets before solution design.  You are a small and integrated team so should be continously talking.

You should also think about whether you can get sales using an Agile Modelling approach. (Google it of you don't know it.)

Lastly - try breaking your delivery into four (or however many) phases; discovery, planning, delivery, implemntation.  Try delivering in small iterations - that way the client gets to say when to stop spending her money and you get to prioritise high value features up front.

New Post 6/18/2008 6:33 AM
User is offline Tony Markos
493 posts
5th Level Poster

Re: Business Process and Documentation Types 

It sounds like you are tasked with process improvement before going into automation.     The UML does not specify any process improvement techniques.    I highly suggest data flow diagrams, espcially if the need is to come up with a comprehensive, integrated whole.  Use data flow diagrams to simplify and integrate.  

To spec for automation, many suggest the UML (use cases and, sometimes activity diagrams, for functional modeling).     But, it has always been my experience that, for larger scale efforts,  the UML techniques fail because they are based on the use of a forced, artificial partitioning and they lack a lithmus test of completedness.  I use a modified version of data flow diagrams for systems design diagrams.  One that substitues, for example, transaction type flows for logical business data flows, and allows for flow of control.



New Post 6/18/2008 6:46 AM
User is offline Nigelus
23 posts
9th Level Poster

Re: Business Process and Documentation Types 
Modified By Adrian M.  on 6/19/2008 1:08:48 AM)

I would suggest a proper business process discovery and documentation procedure and the best and easiest tool around for that use these days is Process Master There is a free download available and it really is the easiest tool to use. You can output the documents as PDF for collaborative use and then perform analysis to the "as-is" with a view to optimising and improving the business processes before automation.

In addition the output of this tool produces an XML file which has connectors for configuration of numerous BPM tools - give it a try

New Post 6/19/2008 12:26 AM
User is offline Adrian M.
734 posts
3rd Level Poster

Re: Business Process and Documentation Types 
Modified By Adrian M.  on 6/19/2008 1:28:03 AM)

 cnsdahl wrote

The Functional Spec is way too detailed for any client to be expected to read and understand, but isn’t quite detailed enough for the developer and certainly not formatted for easy use by the developer.

I'm not sure what "Functional Spec" means in your organization but it sounds like you have a real problem: you have an artifact (the Functional Spec) which is not good enough for either the client or the developer.

What I would suggest is that, if documentation is important to your organization, you split the documentation into two types:

  • artifacts to be consumed by the stakeholders/clients, and
  • artifacts to be consumed by the development/technical team.

Now these can be separate documents or separate sections in the same document.  Please note that I am not advocating that the dev team cannot read the stakeholder artifacts or that the stakeholders can't review the functional specs.  I'm just saying that you might consider having artifacts tailored for a particular audience.  It's sort of like having to give a speech about the scope of the project to the stakeholder and to the developers.  I bet that while the two messages may be similar and have many things in common, they would also be very different as to what is said, how it is said, and how much is said.

Of course, before you make a decision as to what type of artifacts to use you need to also identify the "why" of creating the artifact.  Why do you need the artifacts?

For example, your organization's process might require that a client sign-off is received on the requirements before proceeding with the functional design.  Or maybe the development team is not close to the client and BA and need to have clear functional specs.  Identifying the "why" is very important or else you won't know the reason behind why you are doing what you're doing.

So without knowing much about your project's needs, processes, or structure, here are some options. Note that in most cases you won't need all of them so look them up and decide what will work for you.

Artifacts for consumption by the clients/stakeholders:

  • Business Case
  • Vision Document
  • Project Charter
  • Business Requirements Document
  • Business Use Case Model
  • Business Use Case Briefs
  • User Stories
  • etc.

Artifacts for consumption by the development team:

  • System Use Case Model
  • Detailed Use Case Specifications
  • Functional Specification Document
  • Data Model
  • Data Flow Diagrams
  • etc.

- Adrian

Adrian Marchis
Business Analyst Community Blog - Post your thoughts!
 1 Reports
Previous Previous
Next Next
  Modern Analyst Forums  Business and Sy...  Business Proces...  Business Process and Documentation Types

Community Blog - Latest Posts

Different procedures are utilized for legitimate administration of IT administrations, yet ITIL is viewed as the best arrangement of practices for even administration of IT administrations. ITIL is the contraction for Information Technology Infrastructure Library.  In easier words, ITIL is many rules and arrangements for the effective admin...
10 Responses
What Everyone Must Know about AI in Testing Artificial Intelligence is the buzzword that we frequently keep hearing. Its widespread popularity and influence can be understood from the way industries adopting AI in their organization. Whether it’s Healthcare, Automobile, Banking & Financial Services, or Airlines, many industries have st...
3 Responses
Ashish Adike
Ashish Adike
As a Business Analyst, very often we get into a situation where the Project requires multiple IT Products to be evaluated before implementation and might seek Business Analyst’s recommendation for the same. With the ever-growing range of Products in the market and the marketing promotions associated with some of the products, it’s very ...
6 Responses

Latest Articles

How to Thrive as a Business Analyst in the New Normal
Jan 24, 2021
The Pandemic hit us suddenly and yes it came without any notice to our lives as a transient thing but became the new normal way of life. Some of ...
Copyright 2006-2021 by Modern Analyst Media LLC