Call the Requirements Police, You’ve Entered Design!

Alan Bustamante, PMP

Houston, TX

alan_bustamante@yahoo.com

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!!