sd west 2008: call the requirements police, you've entered design!
TRANSCRIPT
Call the Requirements Police, You’ve Entered Design!
Alan Bustamante, PMP
Houston, TX
Objectives
1. Why are Requirements Important?2. What is the difference between Requirements and
Design?
3. What Design elements often creep into Requirements and Why?
4. What are some problems associated with including Design elements with Requirements artifacts?
5. What are some Best Practices for reducing the number of Design elements in Requirements artifacts?
6. What factors determine how much Design should be included in Requirements and when is it ok to compromise?
Why Focus on Requirements?
Requirements errors are the most expensive errors to fix if they are not caught early in the project lifecycle
IT Trends Impacting RequirementsGrowing Interest in IT/Business Alignment“The division between IT and business will diminish”CIO Insight,30 Most Important IT Trends for 2007
More Consistent IT Quality“Process improvement will be job No. 1”
CIO Insight, 30 Most Important IT Trends for 2007
Globalization & Offshore Outsourcing“Two-thirds of companies on the InformationWeek 500 list of business
technology innovators say they do offshore IT outsourcing, up from 43% in 2004”
InformationWeek, 2007
Increasing Number of Federal Compliance RegulationsSarbanes-Oxley Act, Basel II, Gramm Leach – Bliley Act, Patriot Act,
OSHA, FTC, FDA, DOD, SEC, Health & Human Services, etc…
Requirements
What is Requirements?• The part of the software development process “whose
purpose is to define what the system should do.”1
Common Outputs Produced during Requirements:• Use Case Model (Specifications and Diagrams)• User Stories• Backlog Items
• Test Cases• Software Requirements Specification (SRS)
1 Philippe Kruchten, The RUP an Introduction, 3rd Edition
Design
What is Design?• “The part of the software development process
whose primary purpose is to decide how the system will be implemented.”1
Common Outputs Produced during Design:• Design Model• Data Model
• Software Architecture Document (SAD)• UI Prototypes
• Builds and Releases for emerging architectures (i.e. Agile methods)
1 1 Philippe Kruchten, The RUP an Introduction, 3rd Edition
Design Elements Often Included in Requirements
User Interface Design
• Modified Screen Shots of Existing Applications
• Prototypes Built in a Development Environment
• Prototypes Built in a Diagramming Tool
Data Design
• Table and Field References
Constraints
• Programming Language
• Software
• Hardware
What’s the Connection?40 to 65 percent of Adults are Visual learners, while 10 to 30 percent
are Tactile (Kinesthetic) learners.1
Therefore, by nature we like to jump immediately to the solution Design without giving full consideration to correcting the business process, which is dealt with in Requirements.
Other contributing factors which encourage us to include Design activities with Requirements:
• Business Demands
• Tight Timelines
• Perceived Reduction in Documentation Effort
• Preferred Requirements Documentation Style
• Many Others…..
1 Suki Reed, Learning Your Way, July 02, 2007
Problems with Too Much Design in Requirements
• Increases likelihood of rework• Customer expectations are inappropriately set• Documentation effort increases due to redundancy of
information and the need to keep redundant documentation updated
• Wasting customer time with too much unnecessary information
• Requirements become tightly coupled to a specific type of technology
Any Others?
Case Study
Romania– Project Description
Digitize and store land records for citizen and
government retrieval
Primary Goal:
Entire Country of RomaniaEnd Users:
VB .NET integration with ESRI GIS ArcObjects,
Oracle 9i Database, Windows XP Clients and AIX
Unix Servers
Solution:
Land Management records (Deeds, Maps, etc) not
stored in a digital repository
Problem:
Highly ComplexApplication Complexity:
~ 50 people, globally dispersedSW Dev Team:
Public SectorIndustry:
Romania – Surveyor Information UI
UI Design in Requirements Delivered To Client
Romania – Add Control Point UI
Romania – Lessons Learned
• Static controls made the application look antiquated
• Prototypes could not be reused in the Visual Studio .NET environment
• Major user interface rework required
• The customer expected one thing, but got another
• Unreasonable and unnecessary design constraints were placed on the development team
Designing all application UI’s up front in Visio and including in the Requirements Specifications presented the following problems:
Traditional Software Requirements Specification (SRS)
Use Declarative Statements to Describe Requirements• System shall provide a function which allows the user to
manually initiate the upload
• System shall process all records in file which pass validation, withholding only those with validation errors
• System shall validate user credentials
Because the customer is focused on WHAT the system should do, they are less likely to be concerned with HOW the system should provide the functionality
Traditional Software Requirements Specification (Cont’d)
However, declarative statements make it difficult to understand:
• The user’s flow through the system, thereby complicating communications with key stakeholders.
• The state the system is in prior to the user using the functionality
• The state the system is in at the conclusion of the user’s interaction with the system
Use Case
• Communication improves among all stakeholders• A&D, Test, and End User Documentation teams have
actionable input for their work
• Reference to a common repository for terms such as “upload file” and “confirmation” reduces redundancy
Allows the key business stakeholder to reveal the required system behavior where it’s needed in the workflow, therefore :
However, flows encourage the User to think about the Design aspects of the system because they are essentially walking through a piece of functionality in the application.
Use Case (Cont’d)
Best Practice - Control Agnostic Use Cases
Words to Avoid
Click Drag
Open Close Button Field
Pop-up Scroll Record Window
Words to Use
Text is not good at describing visual things; therefore, words should be chosen carefully when building a Use Case.
Prompts Chooses
Initiates SubmitsLocates Specifies
Form
DropDrop-down
BrowseScreen
Selects
DisplaysInforms
What else?
What else?
Best Practice - Control Agnostic Use Cases (Cont’d)
What’s wrong with this flow step?
It could have been better written like this……
Case Study
Note: Names have been changed to protect the innocent!
Energy Company – Project Description
Replace existing system with web based system.
Improve Inventory tracking.
Primary Goal:
Energy Trading GroupEnd Users:
Custom J2EE integration with SAP, Oracle 10gSolution:
Current system did not meet needs. Need better
Inventory tracking throughout the Supply Chain.
Problem:
Highly ComplexApplication Complexity:
~ 75 people, globally dispersedSW Dev Team:
Private Sector – Top 3 Energy CompanyIndustry:
Energy Company – Data Design in Use Cases
Energy Company – Lessons Learned
• Anytime the data model was updated, the analyst had to look to see what changes were made and update
any Use Cases that were impacted.
• Key business stakeholders spent unnecessary time
reviewing data design elements.
• Analysts wasted time answering questions from business stakeholders regarding data design
elements.
Documenting Data Design Elements in Use Cases Presented the Following Problems:
Set the appropriate level of abstraction in order to understand what the requirements are!
Best Practice – GlossaryDefine Fields and Values in a common Glossary:
• Provides shared repository for all stakeholders
• No need to update individual use cases
• Focuses key business stakeholder (i.e. end user, product owner, customer) on the process rather than the technical solution when reviewing Use Cases
• Can initially be generated from the Business Domain Model, if created
Trace Data Design entities back to Requirements through A&D artifacts:
• Data Dictionary
• Data Model
• Design Model
Best Practice – Glossary (Cont’d)
What’s the Reality?
Requirements versus design activities must be iterative. Requirements discovery, definition, and design decisions are circular. The process is a continual give and take in
that:1
1 Leffingwell and Widrig, 2003
Requirements cause us to
consider certain design options
Design options cause us to
reconsider requirements
How much Design in Requirements is Too Much?
• Type of Development Effort
• Performing Organization Culture
• Stakeholder Product Knowledge
• Team Distribution (local, national, global)
• Language and Other Cultural Barriers
• Product lifecycle
• Product maintenance needs
Any Others?
Acceptable Design detail depends on:
Know Where Your Projects Fit In
Less complex systems
• Have fewer communication channels
• Have smaller budgets
• Require less time to build
• Create less risk or volatility in project portfolio
More complex systems
• Have exponentially larger numbers of communication channels
• Have larger budgets
• Require more time to build
• Create more risk or volatility in the project portfolio
Increasing need for separation of
Requirements and Design Elements
The overriding goal must be to move the project forward in a constructive way so that conflicts among stakeholders do not impact the delivery timeline and budget too severely.
How Do I Identify When Compromise Is Needed?
• Stakeholder is unable to round trip the solution
• UI is stable and snapshots are readily available
• High risk features that are critical to project success
Points of Compromise
Methods of Control
• Use Case Modeling Guidelines
• Requirements Management Plan
• Feature Team Approval
Japan
China
South
Korea
India
Mexico
Russia
Arab
countries
Sweden
France
Germany
Israel
United
States
Bargaining &
Decision-Making
time
(chart shows approximate comparison, not absolute duration)
Preparation
Relationship
Building
Information
Gathering
Agreement & Closure
Copyright Lothar Katz, 2008
Consider Your Audience When Negotiating
Best Practice – Use Case Guidelines
Use Case Guidelines
• Brings cohesiveness to Use Cases for the entire project
• Provides a common reference for the requirements analysts; thereby, minimizing confusion on what information a Use Case should contain
• Sets expectations for all stakeholders on what will be included with each Use Case specification.
• All primary stakeholders should sign off on a base lined Use Case Guidelines artifact before the first detailed specification is documented
Best Practice – Use Case Guidelines (Cont’d)
Supporting Tools
Requirements & Design• IBM Rational Software Modeler
(RSM)• Ravenflow
• iRise
Requirements Management• IBM Rational Requisite Pro• Telelogic Doors
• Serena Dimensions RM
Process Authoring and Publishing• IBM Rational Method Composer
(RMC)
Change Management
• IBM Rational Clear Quest• Serena Dimensions
Version Control• IBM Rational Clear Case• Visual SourceSafe• Perforce
Summary
• Defined Requirements and Design
• Looked at a couple of Case Studies to highlight some of the problems that can occur when too much Design is written into Requirements
• Identified a few Best Practices for preventing too much Design in Requirements
• Provided actionable evaluation criteria for determining how much Design in Requirements is too much
• Listed some tools that can help with traceability and process implementation
Questions & Answers
Thank You!!