Requirements andSoftware Development

Charles CalkinsPrincipal Software Engineer

Object Computing, Inc.calkinsc@ociweb.com

2

OCI’s Business Model

• Training– Offer over 60 1- to 4-day classes

• OO design, languages, middleware, web tech• SETT, Middleware News Brief articles

• Custom software development– Build proprietary applications for customers

• What I do

• Support of Open Source software– TAO, OpenDDS, QuickFIX/FAST, Boost, etc.

3

What I Do

• Have written training articles– http://www.ociweb.com/mnb– http://www.ociweb.com/sett

• Flowlink project for Teledyne Isco– Windows-based interface to water

management sensors– ~700,000 lines of C++/C#– http://www.isco.com/products/products3.asp?

PL=2024010

4

2150 and Signature

5

Flowlink

6

Requirements Development

• Nearly daily phone calls to discuss– Lincoln, NE over 400 miles from St. Louis, MO– Isco must balance customer desires, internal product

direction, what is implementable in time

• Compose a Software Requirements Specification (SRS) with initial requirements– Document based on IEEE standard

• http://www.csc.villanova.edu/~tway/courses/csc4181/s2010/srs_template-1.doc

• Schedule proposed based on SRS– Month or more of testing included

7

Requirements Sections

• Introduction

• Overall Description– operating environment, dependencies

• External Interface Requirements– user, hardware, software, communications

• System Features

• Other Nonfunctional Requirements– performance, safety, security

8

Be Agile…

• Tech prototypes for various features– Can drive requirements, to show what is

possible

• No formal design document– Process docs, such as module connection

• Small development team– 1 to 4 developers at OCI, project

management/testing at Isco– No longer offshore development

9

…Be Agile…

• Constant feedback during development– Frequent conference calls– Code in Subversion so can be built by Isco

any time• Not just a code delivery at the end of the project

– Live demos via screen sharing using Teamviewer

• http://www.teamviewer.com

10

…Be Agile…

• Requirements added during the project– Requests via conference call, or ticket filed

via Request Tracker• http://www.bestpractical.com/rt/• RT used for bug tracking, too• Good to have written, prioritized requests, and

once implemented/fixed ticket can be resolved– Post ChangeLog info to ticket to track with codebase

– Balanced against schedule, may be “negotiated” to something simpler based on time constraints

11

…Be Agile

• Changes even made during testing phase– Want stable code to test against, but

stakeholders don’t always know what they want until they see something running

– Automated tests help, but UI requires human testing, too

• “Does this graph look correct?”

– Testers and customer support can even request changes

• Very flexible when everyone is a stakeholder