Tips for Presenting Requirements and Deliverables

April 4th, 2011 2 comments

A few days ago I found an very interesting blog post on the presentation of requirements. The post gives 5 tips for presenting requirements which came from a business analyst point of view. The tips are:


1. Establish and Communicate the Purpose

2. Use Visual Artifacts to Display Requirements and Design

3. Understand your Audience

4. Understand the Business Context

5. No Surprises


When I read these tips the sound very logic and come back in my daily work.


1 in RUP we have an vision document this document describes the vision and it is one of the most important documents there is, and should be agreed opun.


A Vision Document is a software process document that describes the overall ‘vision’, or plan, for a particular piece of software


2 visualization is key, who reads and understands use-cases which are 50 pages thick and contain references to many other documentsAan-niemand-vertellen-emoticon. I practice I found out the showing screen impressions in walkthrough sessions (with different view points) gives the users an clear view on the requirements. and in that way the find the missing requirements. Off course the backend stuff such as error handling and interfacing with other systems can be written down with use-cases but the audience for those specifications id different then the user interaction.


3 This tip is a bit obvious because if you don’t know the audience how could you give the right information. If you are giving the CEO a detailed UML diagram he will probably nod and pretend he understands what you are saying, but he doesn’t and is afraid to tell you that. And when you show a financial overview a programmer doesn’t care.


4 This tip says know what you are telling and how this fits in with the business. When you present requirements but don’t know where they are for, is a bit silly. You usually get a question why is this necessary?? and i9f you don’t have an answer the requirement will be rejected by the sponsor, and you have to tell the users for whom the requirement was crucial.


5 tip 5 says be agile share and test the requirements ass early as possible. If you present you’re requirements when the document is finished you put 40 hours in it and the review on the document gives you usually tons of remarks. But when you shared the early versions of the document these bugs in the specs would have been found earlier.

TOGAF 9 certified

March 29th, 2011 No comments

Since this week I am officially TOGAF 9 certified. I passed the bridge exam with a 82% score Glimlach. Now I can use both my old TOGAF 8 and the new TOGAF 9 logo and say I’m certified.

Some nice tips for other people who are preparing for the exam:

Categories: TOGAF Tags: , ,

TOGAF 9: preliminary

March 22nd, 2011 No comments

Since I’m busy obtaining my TOGAF 9 certification I thought it would be handy for my self to produce some blog posts. By making this posts I  will learn the material better and hope to help others with this summary. For the formal and more detailed description of TOGAF the open group website can be referenced. In this blog post I will describe the preliminary phase of TOGAF. As you can see in the figure this is the first phase of TOGAF.



This phase establishes the Architecture team, project(scope), sets the first principles for architecture work and adjustment of TOGAF to match the organizational demands and links to existing frameworks.

The hardest to do is selling the architecture capability, and typical questions you will get from the business is

What’s in it for me?

How will it help me


In order to help answer these questions I found some tips on the following sites:

In short it helps with compliancy, gives insight and helps reusing of components and costs.


When you got a sponsor you need a team, a nice list of capabilities can be found at:



Reference Materials External to the Enterprise

  • Other architecture framework(s), if required

Non-Architectural Inputs

  • Board strategies and board business plans, business strategy, business principles, business goals, and business drivers, when pre-existing
  • Major frameworks operating in the business; e.g., portfolio/project management
    Governance and legal frameworks, including architecture governance strategy, when pre-existing
  • Budget for scoping project
  • Partnership and contract agreements
  • IT strategy

Architectural Inputs

Pre-existing models for operating an enterprise architecture capability can be used as a baseline for the Preliminary phase. Inputs would include:

  • Organizational Model for Enterprise Architecture (see Part IV, 36.2.16 Organizational Model for Enterprise Architecture), including:
    • Scope of organizations impacted
    • Maturity assessment, gaps, and resolution approach
    • Roles and responsibilities for architecture team(s)
    • Budget requirements
    • Governance and support strategy
    • Existing Architecture Framework, if any, including:
    • Architecture method
    • Architecture content (deliverables and artifacts)
    • Configured and deployed tools
    • Existing architecture principles, if any (see Part IV, 36.2.4 Architecture Principles)
    • Existing Architecture Repository (see Part IV, 36.2.5 Architecture Repository), if any (framework description, architectural descriptions, existing target descriptions, etc.)



  • Organizational Model for Enterprise Architecture (see Part IV, 36.2.16 Organizational Model for Enterprise Architecture), including:
      • Scope of organizations impacted
      • Maturity assessment, gaps, and resolution approach
      • Roles and responsibilities for architecture team(s)
      • Constraints on architecture work
      • Re-use requirements
      • Budget requirements
      • Requests for change
      • Governance and support strategy
  • Tailored Architecture Framework (see Part IV, 36.2.21 Tailored Architecture Framework), including:
      • Tailored architecture method
      • Tailored architecture content (deliverables and artifacts)
      • Architecture principles (see Part IV, 36.2.4 Architecture Principles)
      • Configured and deployed tools, including evaluation report if conducted
  • Initial Architecture Repository (see Part IV, 36.2.5 Architecture Repository), populated with framework content
  • Restatement of, or reference to, business principles, business goals, and business drivers (see Part IV, 36.2.9 Business Principles, Business Goals, and Business Drivers)
  • Request for Architecture Work (see Part IV, 36.2.17 Request for Architecture Work)
  • Governance Framework




  • Scope the Enterprise Organizations Impacted
  • Confirm Governance and Support Frameworks
  • Define and Establish Enterprise Architecture Team and Organization
  • Identify and Establish Architecture Principles
  • Select and Tailor Architecture Framework(s)
  • Implement Architecture Tools
Categories: TOGAF Tags: ,

A piece of history on the pc with Microsoft & apple

March 17th, 2011 No comments

Here you can find a nice (old) video on the history of the pc with Microsoft & Apple


March 13th, 2011 No comments

Last week I started with my TOGAF 8 – 9 bridge training, since I’m TOGAF 8 certified since 2007. The training consists of 2 days with lectures and 1 day the exam, which is based on the TOGAF 9 book. (900 pages Teleurgestelde emoticon)

What is TOGAF?

The Open Group Architecture Framework (TOGAF®) is a framework for enterprise architecture which provides a comprehensive approach to the design, planning, implementation, and governance of an enterprise information architecture. TOGAF is a registered trademark of The Open Group in the United States and Other countries [2].
TOGAF is a high level and holistic approach to design, which is typically modeled at four levels: Business, Application, Data, and Technology. It tries to give a well-tested overall starting model to information architects, which can then be built upon. It relies heavily on modularization, standardization and already existing, proven technologies and products. (

TOGAF topics

TOGAF is based on four pillars, called architecture domains:

  • Business architecture or business process architecture which defines the business strategy, governance, organization, and key business processes of the organization
  • Applications architecture which provides a blueprint for the individual application systems to be deployed, the interactions between the application systems, and their relationships to the core business processes of the organization with the frameworks for services to be exposed as business functions for integration.
  • Data architecture which describes the structure of an organization’s logical and physical data assets and the associated data management resources
  • Technical architecture or technology architecture which describes the hardware, software and network infrastructure needed to support the deployment of core, mission-critical applications

Architecture Development Method

The Architecture Development Method (ADM) is applied to develop an enterprise architecture which will meet the business and information technology needs of an organization. It may be tailored to the organization’s needs and is then employed to manage the execution of architecture planning activities.[7]

The process is iterative and cyclic. Each step checks with Requirements. Phase C involves some combination of both Data Architecture and Applications Architecture. Additional clarity can be added between steps B and C in order to provide a completeinformation architecture.

Performance engineering working practices are applied to the Requirements phase, and to the Business Architecture, Information System Architecture, and Technology architecture phases. Within Information System Architecture, it is applied to both the Data Architecture and Application Architecture.

Enterprise Continuum

The Enterprise Continuum may be viewed as a "virtual repository" (As of TOGAF 9 this not virtual any more) of all the architecture assets available to an organization. These include architectural models, architectural patterns, architecture descriptions, and other artifacts. These artifacts may exist within the enterprise and also in the IT industry at large.

The Enterprise Continuum consists of both the Architecture Continuum and the Solutions Continuum. The Architecture Continuum specifies the structuring of reusable architecture assets, and includes rules, representations and relationships of the information system(s) available to the enterprise. The Solutions Continuum describes the implementation of the Architecture Continuum by defining reusable solutions building blocks. (


To show the structure of TOGAF 9 I found the following presentation

Categories: Architecture, TOGAF Tags: