1 / 18

Visualization an alternative approach to developing requirements

Visualization an alternative approach to developing requirements. Bo Lora bo.lora@bearingpoint.com 210-259-3020 February 2008. The Importance of Requirements. Requirements… Communicate the needs of the end user. Assure that business objectives are stated.

macon
Download Presentation

Visualization an alternative approach to developing requirements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Visualizationan alternative approach to developing requirements Bo Lorabo.lora@bearingpoint.com210-259-3020February 2008

  2. The Importance of Requirements Requirements… • Communicate the needs of the end user. • Assure that business objectives are stated. • Provide developers with specifications. • Detail validation rules which can be tested. Developing solid business requirements is at the heart of any project and it’s success.

  3. The Challenges Requirements development involves multiple stakeholders working together to define and design business solutions through a standard documentation framework. Today, organizations routinely tap the global talent pool for low-cost, high-quality system and software development. Effectively leveraging these resources requires a robust requirements development process and sound project management oversight. Technical teams must be clear on the project objectives and development approach. They then must apply templates and code consistently, whether they’re in Boston, Bangalore or Beijing.

  4. Problems With Requirements Often, however, organizations stumble in developing business requirements. The problems can occur in three areas: • Poor requirements definition: Incomplete or missed requirements during requirements elicitation and validation by business analysts and end users reduces the quality of system features and often results in new technologies that do not meet business needs. • Lack of requirements program management: Misused, unapproved or delayed business requirements can occur due to the lack of a strong program management framework, which increases system development risks. • Inadequate requirements knowledge transfer: Technologists design flawed systems because of misconstrued business requirements.

  5. Time or Cost Overruns are the Norm The average project cost overrun was 56 percent, and the average time overrun was 84 percent. Source: “Overdue and Over Budget, Over and Over Again,” The Economist, June 9, 2005.

  6. The Need for Visualization Leonardo da Vinci understood the power of visualization. How could he possibly describe many of his innovations without drawings?

  7. An Incomplete Picture Static forms of requirements documentation offered by business analysts, such as word processing documents, screen shots and process flows, often provide an incomplete or foreign view of the system during technology development. Because static documents are focused on giving technologists a view of business needs, they can be misinterpreted when translated into technology specifications or developer code. Static formats also may not provide business users with a full or easily understood summary of the system. Moreover, such forms can be long and difficult to maintain as requirements evolve.

  8. The “Normal” Requirements Process Visualization Is this really normal? When you buy a car, would you know that it is right for you just by looking at a list of it’s features or would you want to test drive it first?

  9. A Visual Approach Visualization stimulates scope and requirements v.s. Scope and requirements drive visualization

  10. The Benefits of a Visual Approach Agility – The team will be able to more easily respond to changes. Efficiency – More effective requirements communication will reduce post development rework. Speed – Development teams can get involved sooner and work faster. Accuracy – A greater level of accuracy reduces overall cost. Collaboration – Visualization allows everyone to have more input.

  11. Integration of Visualization Scope Requirements Visualization Content Technical Design Test Scripts Visualization can be the driver of common objectives

  12. The Anatomy of a Visualized Process SCOPE Problem: Over 50% 0f customers who order service by phone say they started online but could not finish. Identify Problem Cause and Effect Identify Audience Voice of Customer

  13. The Anatomy of a Visualized Process REQUIREMENTS Flow Diagrams Rapid User Model Prototype Technical Specs

  14. The Anatomy of a Visualized Process CENTRALIZATION Access to related documents Status tracking Access to all prototype pages Access to all technical design documents

  15. The Anatomy of a Visualized Process TRACEABILITY Functional requirement reference Developer notes

  16. The Anatomy of a Visualized Process REUSE Prototypes are in HTML and 40-60% of code is reusable in development phase

  17. Conclusion Visualization supports better systems A strong requirements development process can help mitigate the risks associated with large-scale system implementations. Visualization is emerging as a powerful tool for increasing the quality and efficiency of a firm’s requirements development program. Before adopting visualization, organizations must understand the key considerations in using visualization and determine how to best integrate it into their existing requirements program to capitalize on this promising new solution.

More Related