log inhelp

  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

View
 

Beyond The System Shall- A Journey From Good To Great Requirements

This version was saved 15 years, 9 months ago View current version     Page history
Saved by PBworks
on June 16, 2008 at 7:35:28 am
 

Standish Chaos Report

  • 71% of IT projects underperform or fail outright
  • 4 of the top 5 reasons for failure have to do with requirments
    • lack of user input
    • incomplete requirements
    • unclear objectives
    • changing requirements

 

Seilevel

  • Structured hiring process
    • Resumes
    • Complex problem solving
    • Practical
    • Formal assessment
  • model based methodology
    • identify project type
    • capture business objectives
    • complete models
    • derive requirements
    • map to objectives
    • transition to dev/test
    • validate ROI (did app meet requirements & business objectives)
  • Process tools
    • Team collaboration
    • Issue tracking
    • Requirements management
    • requiements collection
    • document management

 

SHALL is a good way to capture information but not a good way to work with requirements.

Models help us categorize, group, and organize requirements.

 

Models

  • People (who)
    • org chart
    • use cases
    • decision trees
  • systems (interaction between systems
    • context diagrams
    • display action response
    • cross-functional process flows (swim lanes)
  • Data
    • entity relationship diagrams
    • data dictionaries
    • data flow diagrams
    • state tables

 

Can build org charts around external roles (like cdustomer) as well as internal.

Steps and alternate paths in use cases can alert us to process and areas that need further definition.

 

Decision trees useful for capturing complex decision pathways.

 

Discussion of when to do current/future state state of a process modle.

 

  • Context diagrams capture relationships between systems
  • Display action response capture complex UI behavior (time consuming)
  • Cross functional process flows (swimlanes)
    • rows need to be a user/actor or a system but not both
  • Entity relationship diagrams capture relationships between objects
  • Data dictionaries capture rules for interfaces (cross into design)
  • data flow diagrams capture connections between processes
  • state tables capture states and transitions
  • Lots more models and requirements types.

 

Good vs. Great Requirements

Stay with the business objective

The requirements must define success

Printable version