Requirements Driven Development and Delphi
Draft version 1
Daniel Polistchuck
Agenda
Background Info/Concepts
CMMI
People, Process and Technology
Requirements Development & Management
Feature Driven Development
Delphi CaliberRM Integration
Implementation example: Requirements Management +
FDD
Purpose
The purpose of this session is to emphasize that it is
possible to combine formal processes (such as CMMI’s
Requirements Process Areas) and a full-blown Agile
Methodlogy such as Feature Driven Development (FDD)
Especially if you’re using Delphi
(Can I hear ECO? Integrated CaliberRM Client? That’s AGILE!)
CMMI
We’re really serious about “process improvement”
The Teraquest acquisition was about this
To get an official CMMI Appraisal is just the tip of the
iceberg… Real Process Improvement (with capital
letters) is the actual goal
We already had the tools like StarTeam, CaliberRM,
Together, Delphi…
Now we have it all: people + process + tools
But What’s CMMI?
CMMI stands for Capability Maturity Model Integrated
Provides several process areas, with specific and
generic goals that will drive process improvement in your
organization.
Two representations:
Continuous – Each Process Area is evolved individually by
capability level. More flexible, lets you plan specific areas for
improvement, aligned with your organization’s strategic business
goals.
Staged – Provides a proven path for improvement of your
organization’s processes. Easily lets you compare your
organizations maturity level with other players in the market.
CMMI - Staged
CMMI - Continuous
What’s in it for me?
CMMI is a model for improvement than can be used,
independent of formal appraisals and reports, to help
you organization become:
Organized
Focused
Continuously and systematically growing
It’s not a process, but lets you select a process that
complies with the model.
RD & REQM Process Areas in CMMI
Requirements Development – elliciting, developing,
analyzing and validating customer and product
requirements
Requirements Management – manage the
inconsistencies to other work products (tasks, for
example), change and traceability of the previously
developed requirements
Requirements Good Practices
Categorization of requirement types
Business Requirements: Business Opportunity, Business
Objectives, Market Requirements, Major Features, Project
Success Factors
Project Constraints: Schedule, Budget, Staffing, Technical,
Location
Functional Requirements
Prioritizing
Trade-off analysis (using the Requirements Grid)
FDD
What is FDD?
It’s an Agile Process that focus on repeatable, measurable
delivery of WORKING software
Why?
To enable and enforce the repeatable delivery of working
software in a timely manner with highly accurate and meaningful
information to all key roles inside and outside a project.
The Agile Manifesto
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
FDD Context
Requirements Management
Configuration Management
Requirements Development
Feature Driven Development
Resource Testing
Develop an Overall Model Programming Language
Build a Features List
Project Staffing Prototyping
Plan By Feature
Design By Feature
Budget Preparation
Build By Feature
Testing
Project Overall Planning
Testing
FDD 5 Processes
1.Develop 2. Build a 4. Design
3. Plan by 5. Build By
an Overall Features By
Feature Feature
Model List Feature
Shape and core A categorized A development A design package Completed
methods list of features plan (sequences) client-valued
function
An object model Detailed how-to
(more shape than content) content
+ informal features list
+ notes on alternatives
FDD 5 Processes + RDD
Requirements Development Requirements Management
1.Develop 2. Build a 4. Design
3. Plan by 5. Build By
an Overall Features By
Feature Feature
Model List Feature
Shape and core A categorized A development A design package Completed
methods list of features plan (sequences) client-valued
function
An object model Detailed how-to
(more shape than content) content
+ informal features list
+ notes on alternatives
FDD Context (again)
Requirements Management
Configuration Management
Requirements Development
Feature Driven Development
Resource Testing
Develop an Overall Model Programming Language
Build a Features List
Project Staffing Prototyping
Plan By Feature
Design By Feature
Budget Preparation
Build By Feature
Testing
Project Overall Planning
Testing
FDD Context + RDD
Requirements Management
Requirements Development
Feature Driven Development
Develop an Overall Model
Build a Features List
Plan By Feature
Design By Feature
Build By Feature
FDD and Functional Requirements
FDD has a specific context: to model, ellicit, plan, design
and build functional (working) software.
Actually Feature Areas, Feature Sets and Features could
be seen as a hierarchy of Functional Requirements
Remember “Requirements Good Practices?”
Requirements Good Practices (again)
Categorization of requirement types
Business Requirements: Business Opportunity, Business
Objectives, Market Requirements, Major Features, Project
Success Factors
Project Constraints: Schedule, Budget, Staffing, Technical,
Location
Functional Requirements
Prioritizing
Trade-off analysis (using the Requirements Grid)
CaliberRM
CaliberRM is the tool that will help you as part of the
PPT tripod of your company
Process – aligned to your business goals
Tools – supports your process
People- must be trained in the tools and processes
Requirements Types
CaliberRM supports the creation of Requirement Types
These are high level groups of requirements that follow a
specific standard. For example
Business Requirements – Vision and Scope/Project Charter (WHY)
User Requirements – Use Case/user interaction (WHAT)
Functional Requirements – Implementation (HOW)
Non-Functional Requirements – Performance, Deployment, etc.
CaliberRM in Delphi
Toolbar
The Integration UI is divided in 3 major parts
Requirements
Treeview
Contents
CaliberRM Req TreeView
The requirements treeview
Has the project itself as the root node
In the first level lists the requirement
types set for the current project by the
admin
In the other levels (req types children)
are the requirements themselves
organized hierarchically. (can be
dragged/dropped)
You can change/set the name of the
currently selected requirement either in
the TreeView or in the Details Tab
CaliberRM Toolbar
Available Functionalities
Select the current project and baseline
Create a new child or sibling requirement
Move the requirement up and down
Delete the selected requirement
Save or cancel changes
Refresh
Log off
Launch Estimate Pro
Format the description
Manage Code Traceabilities
CaliberRM Content Pane
In BDS 2006 it’s a first-
class IDE window
The content pane shows
information for the
currently selected
project/requirement
type/requirement
You can edit the any
requirement info you want
in the content pane.
Let’s take a look at the
different tabs
Content Pane Tabs
Details – Shows the “system fields” for the Requirement. They are
all required.
Traceability – Lets you create To/From traces between your
requirements and Delphi/C# code. Just ALT+Drag code to either the
“Traces From” or “Traces To” listboxes
Validation – Validation procedure, so you can help testers with
certifying that the requirement was correctly implemented/followed
Content Pane Tabs
Discussion – Lets you collaborate with other team
members by creating a “forum-like” discussion for a
specific requirement
References – Here you can create references to web
sites and external documents
History – Shows the history info (who, what, when, why
the requirment changed)
Content Pane Tabs
Responsibilities – The team members that participate in
the management, implementation and definition (for
example) of the selected requirement. It’s currently read-
only.
User-Defined Tabs – Contains any Admin –created
Custom Attributes set for the current requirement type.
FDD and CaliberRM
Next slide will show an example implementation of the
“Features” Requirement Type in CaliberRM
Build a Feature List Plan By Feature, Build by Feature
All Together Now!
Well, so we’ve taken a look at:
CMMI Requirements Management and Requirements
Development PAs
Requirements Good Practices
Feature Driven Development
CaliberRM Integartion in Delphi
Lets wrap it all together in a…
DEMO – Sales Force Automation
The demo will focus on a specific deliverable of a Sales
Force Automation Project: Order Entry
Delphi-specific features that will be used:
CaliberRM Integration
ECO III
DUnit Unit Testing Wizards
StarTeam Integration
Step 1: Requirements
Let’s gather the requirements
Business Requirements
Project Constraints
Step 1: Requirements
Step 2: FDD #1 – Develop an Overall Model
Form the modelling team: domain experts, developers
and architects
Domain walk-through: the domain expert will provide an
overview of the domain
Develop and Refine the Model: got ECO?
Write Model Notes: any detailed or complex strutctures
must be clarified using notes
Internal and External Assesment
Step 2: FDD #1 – Develop an Overall Model
Step 3: FDD #2 – Build a Features List
Form the Features List Team: Gather your Chief
Programmers from FDD Process #1
Organize the Features List in CaliberRM under the
CaliberRM “Features” Requirement Type:
Subject Areas/Feature Areas
Business Activities/Feature Sets
Business Activities Steps/Features
The Business Activity Step/Feature format is
E.g.: Associate a responsible Salesperson to
an order
Step 3: FDD #2 – Build a Features List
Step 4: FDD #3 – Plan By Feature
Determine the development sequence: Enter the
Planned Dates for all Features in your CaliberRM
Project.
Assign Business Activities/Features Sets to Chief
Programmers: Set the Chief Programmer Responsibility
for each Feature Set (2nd level) in your CaliberRM
Project.
Step 4: FDD #3 – Plan By Feature
Step 5: FDD #4 – Design By Feature
Form the feature team
Develop Sequence Diagram: besides Sequence
Diagrams, you can also define State Machines for the
classes involved in the work package/Feature Set.
Refine Object Model: add methods/attributes to the
Object Model based on the Sequence Diagram and
State Machines.
Write Class and Method Prologues: Add XMLDoc tags to
document classes, methods and parameters for the
classes
Design Inspection
Step 5: FDD #4 – Design By Feature
Step 6: FDD #5 – Build By Feature
Implement Classes and Methods: Implement specific
methods for the feature classes
Code Inspection: Peer review the code
Unit Test: Create unit tests to verify if the requirements
related to the features were attended
Promote to Build: Add/Check in class to StarTeam using
Delphi’s Integration.
Monitoring and Reporting Progress
Monitoring and Reporting Progress
Monitoring and Reporting Progress
Conclusion
Wheew!! Lot’s of new information, eh?
We managed to align seemingly “disparate visions”
CMMI
Agile Methodologies
Delphi
Questions
Thank you
Daniel Polistchuck
dpolistchuck@borland.com
http://blogs.borland.com/danielp