Career Forums

 
  Modern Analyst Forums  Careers  Getting Started  How to aim or goal at High level requirements in documentation.
Previous Previous
 
Next Next
New Post 9/11/2008 9:51 AM
User is offline srikanth
33 posts
9th Level Poster


How to aim or goal at High level requirements in documentation. 

Hi everyone,

I am trying to document on a topic. They have introduced a system in 2003 as a trail ( online tests for candidates)so they got bit positive response so thay made changes in 2004 with the same system,so on 2005,2006, 2007(0.1% as live), 2008(0.3% as live). Now next year they are making it is live only 3% of whole. And there is big change of system internally how to manage and mark. and They have targeted for 2011(30%) and 2020(100%) to implement the whole system as Live.

Now I have to document in such a way where I have to show the existing system of 2008 and How it is Implimented in 2009 and  Point out to High level requirements(2020)

Note: I have to show the change in the process how that is going to change in 2008 and 2009.

In short document should consists of present 2008 system, and 2009 (how it is going to be ) and 2020 how we are targeting.

I NEED TO PRESENT IN SUCH A WAY WHERE S/H CAN EASILY UNDERSTAND  HOW WE DID IN 2008 , HOW WE ARE DOING IN 2009 AND HOW IT IS RELATED TO OUR FINAL GOAL.( On a document).

Please I would appreciate the ideas , samples or any suggestions.

Thank you ,

Regards,

Srikanth

 

 

 

 
New Post 9/11/2008 10:07 AM
User is offline Guy Beauchamp
257 posts
www.smart-ba.com
5th Level Poster




Re: How to aim or goal at High level requirements in documentation. 

Hi Srikanth,

If you have a CASE tool such as ProVision or CASEWise or Enterprise Architect then you can create goals, requirements, process models and data data models (link them as required) and then re-use them as needed in diagrams called 2008, 2009 and 2010. This will allow you to reuse all the components you need to and run reports off the daigrams defining the states for 2008, 2009 and 2010.

If you haven't got a CASE tool you are looking at doing this manually in Visio or Excel or even Powerpoint which can be done but has a higher maintenance overhead and is more prone to error as a result.

If you don't need diagrams then you could also create a repository of all these components and links in Access and then report of them that way. I think I have an Access schema that does that kind of thing but would need modification to fit with your requirements.

Guy

 
New Post 9/11/2008 8:38 PM
User is offline Jarett Hailes
155 posts
6th Level Poster




Re: How to aim or goal at High level requirements in documentation. 
Modified By Jarett Hailes  on 9/11/2008 10:22:20 PM)

Hi Srikanth,

Guy pointed you towards some good diagramming tools - this will be an important aspect of your deliverable.  However, you must also wrap any diagrams with appropriate dialogue that describes what's happening.  Even if you go with basic activity or flowchart diagrams that are easy to understand, it will be important for you to highlight the important aspects that will change (likely based on the level of impact and their importance to the overall system).

As a rough table of contents, I would recommend the following:

  1. Introduction
  2. Current state (diagram + narrative)
  3. Future state 2009 (diagram + narrative)
    1. Impact analysis - what must/could change and how
  4. Future state 2020 (diagram + narrative)
    1. Impact analysis - what must/could change and how
  5. Change management
    1. Steps that need to be taken in order to achieve 2009 vision
    2. High level steps that need to be taken in order to achieve 2020 vision (must more generic and should focus on the process of continually refining the target vision and making plans each year to achieve the next part of the system realization)
    3. Risks to achieve these states and mitigration strategies
 
New Post 9/12/2008 12:52 AM
User is offline Guy Beauchamp
257 posts
www.smart-ba.com
5th Level Poster




Re: How to aim or goal at High level requirements in documentation. 

Larimar,

I totally agree that diagrams with no descriptions and definitions and narratives are not much use and I agree with your table of contents (though I would suggest adding goals, requirements, process and data models and the linkages between each of the components on these daigrams for each of the 'state' sections).

The CASE tools I suggested would hold your proposed table of contents 1 thru 4 (and even 5 if it was defined as a documented process in the tool). The advantage of the CASE tool is that you document it once in the tool and the tool can use it in many reports such as the one you suggest and many diagrams if appropriate.

Not using one of the CASE tools I suggest means having separate diagrams and words which will be a maintence challenge though not impossible.

Guy

 

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Careers  Getting Started  How to aim or goal at High level requirements in documentation.

 






 

Copyright 2006-2024 by Modern Analyst Media LLC