Defining Requirements – The TOGAF Way
How is it different?
Feb. 10, 2011 05:15 AM
If you are new to TOGAF, you may be wondering how this process is different from what you do in a typical “Requirement Analysis” phase of software development. Once I tell you that the many of the techniques recommended in TOGAF are what you are already using, like UML modeling techniques like Activity Models, Use-Case Models and Class Models, you may think why bother with TOGAF?
What you really do differently in TOGAF is that you take a much wider perspective of the requirement. There are three important things that you need to do:
- Explicitly document the current state, the expected future state and identify the gap
- Assess impact of the change on other projects and other organizational initiatives
- State the change from the perspective (viewpoint) of different stakeholders and get their buy in
While doing this, you need to keep in mind the following:
- Are you adhering to all the relevant organizational standards & guidelines?
- Have you made an explicit attempt of reuse?
Steps for Defining the Requirement
We had discussed the following lists (without the 3 steps in “Define Requirement”) in my earlier posts –
What is TOGAF? & Planning a project.
- Tailor TOGAF to suit your need
Define scope of work and prepare plan for rollout
- Define the scope and get approval from the sponsor
Define requirement in terms of how the business process will change, what data, application and technical infrastructure is required for accomplishing the work
- What should the new business process be?
- What application & data do we need to support the changed process?
- What technology infrastructure do we require to implement the change?
- Select a suitable solution and make the implementation plan
- Oversee development and implementation
- Manage post-implementation change
What about defining Services? The SOA approach? TOGAF has some recommendations but it looks more like a force fit - we will cover it later.
Here are some of the terminologies used in TOGAF and their meaning as used in TOGAF.
View & Viewpoint
- View = What you see or what a stakeholder sees
- Viewpoint = Model or description of the information contained in a view
Baseline, Target & Gap
- Baseline = Where you are now
- Target = Where you want to be
- Gap = What needs to change
Deliverable & Artifact
- Deliverable = Contractually specified document – formally reviewed, agreed, and signed off by the stakeholders
- Artifact = Architecture from a specific viewpoint – can be a Catalog, a Matrix or a Diagram
What artifacts do you may produce?
For Business Architecture:
- Organization/Actor catalog
- Driver/Goal/Objective catalog
- Role catalog
- Business Service/Function catalog
- Location catalog
- Process/Event/Control/Product catalog
- Contract/Measure catalog
- Business Interaction matrix
- Actor/Role matrix
- Business Footprint diagram
- Business Service/Information diagram
- Functional Decomposition diagram
- Product Lifecycle diagram
- Goal/Objective/Service diagram
- Use-Case diagram
- Organization Decomposition diagram
- Process Flow diagram
- Event diagram
For Data Architecture:
- Data Entity/Data Component catalog
- Data Entity/Business Function matrix
- System/Data matrix
- Class diagram
- Data Dissemination diagram
- Data Lifecycle diagram
- Data Security diagram
- Data Migration diagram
- Class Hierarchy diagram
For Application Architecture:
- Application Portfolio catalog
- Interface catalog
- System/Organization matrix
- Role/System matrix
- Application Interaction matrix
- System/Function matrix
- Application Communication diagram
- Application and User Location diagram
- System Use-Case diagram
- Enterprise Manageability diagram
- Process/System Realization diagram
- Software Engineering diagram
- Application Migration diagram
- Software Distribution diagram
For Technology Architecture:
- Technology Standards catalog
- Technology Portfolio catalog
- Environments and Locations diagram
- Platform Decomposition diagram
- Processing diagram
- Networked Computing/Hardware diagram
- Communications Engineering diagram
Read the original blog entry...