Project: Modern Analyst Knowledge Appraiser

Hi Perry,

1. In-Scope

• HEY … IDEA ….. if this is good enough we can align to IIBA main site!!!!! Add to BC
  • AM: Can you elaborate on this?
• Alignment with the Zachman Enterprise Architecture Framework
• Alignment with the PMI® PMBOK® - second edition
• Alignment with the IIBA® BABOK® - V1.6
• An effective schema for each knowledge area's appraisal questions
  • AM: I see this project as having two distinct parts, the appraisal framework and the content.  The things that deal with PMBOK vs. BABOK vs. Zachman are content.  We should focus on both however we should clearly separate the two.  My vision is that this module is fully configurable so and will be maintained by an administrator via a UI.  So we should create the buiness entity model.  Here are some of the entities that I see will be there: Role, Competency, Knowledge Area, Question, User (to keep user profile), Keyword, Assesment Result (the result and dates of the test), etc.  Let's define these first.
• Links to documents, essays, forms, blogs, or any other learning tool for each knowledge area
  • AM: I'm assuming these are resources for a given knowledge area that user can utilize to increase their skills.  Let's do this in the "future release" as oposed to v1. 
• A personal assessment of the user's strengths and weakness for each knowledge area (topic suggestions are not limited to these suggestions alone)
  • Technical Appraisal – an assessment of the user's ability to understand general IT concepts and technologies
  • Project Lifecycles – an assessment of the user's ability to understand the major different types of project lifecycles (SDLC), their strengths and weaknesses (such as but not limited to object oriented analysis, structured analysis, business process modeling notation, rational unified process, base agile process principles, diagnostic modeling and joint application development)
  • Business Analysis – an assessment of the user's ability to understand the general concepts behind the profession of business analysis. What it is and what it is not.
  • Systems Analysis – an assessment of the user's ability to understand the general concepts behind the profession of systems analysis. In particular the delineation between business and systems analysis
  • Enterprise Architecture - an assessment of the user's ability to understand the planning framework of enterprise architecture and how it reflects on the overall analysis process
  • Requirements Planning and Management – an assessment of the user's ability to understand both product and project planning, how change is managed, how requirements are traced and tracked, how requirements are prioritized and allocated within the project lifecycle
  • Requirements Elicitation – an assessment of the user's ability to understand the process of effectively gathering stakeholder needs, approaches such as diagnostic modeling, verbal protocols, surveys, open and closed ended questioning and observation, object oriented and structured analysis approaches – then grouping those needs into regulatory, business (strategic, tactical, operational), user (functional, non-functional) and specification subject groups
  • Requirements Analysis – an assessment of the user's ability to understand the process of effectively analyzing the data gathered during elicitation, ability to define methods, tools and techniques and to structure the raw data into requirements (and gaps) that are visible, accountable, measurable and specific
  • Requirements Communication – an assessment of the user's ability to understand how to present and communicate requirements to all stakeholders and implementers of the project, to bring the group to consensus and approval, present the requirements in a format and structure that is appropriate such as a BRD or SRS
  • Requirements Assessment and Validation – an assessment of the user's ability to understand and develop alternate solutions, ensure quality, support the development and testing process, ensure buy-in and ensure traceability back to the stakeholder objectives
  • AM: Again, all these above ones are good but let's design the system/module to be flexible.  As you probably know already there is much debate in the BA community as to which is the exact list of roles, competencies, etc.  If we build a flexible tool we can simply change the data via and admin interface and we are ready to go.  This way this can also be used for assessing all kinds of sorts of things.

2. Not-in-Scope
   1. AM: Let's call this "future release"/nice to have features

• Comparative analysis between 2 appraisals from the same user taken at different times
• Any type of percentile analysis of community's performance, as a whole
• Any type of analytics of community's performance, as a whole
• Group or team appraisals
• A weighted scale between knowledge areas, as this will make any assessment calculations more difficult
• Fks;ldgk;lasdkgskl;df