as title

Hi 888-ga,

  First, I assume that SRS stands for
  Software Requirements Specification.
  If so, it should be done before creating
  the project budget.

  An SRS is how a customer and developer
  agree on what the product will do.  It
  is not a design document.  It only describes
  what the project will accomplish, not how
  the developer will accomplish it.

  Accordingly, it is not possible to create
  a good budget without knowing what you are
  budgeting for.

  Finally, I thought this PowerPoint presentation 
  from Buffalo University was a nice presenation
  on what an SRS should accomplish:
  
http://www.cs.buffalo.edu/~kershner/cse4-542/5B.Customers.SRS.ppt

  To read more about the SRS, try googling
  for "SRS software project" or "SRS project
  budget."

  I hope that helps you.

                dogbite-ga

---

Request for Answer Clarification by 888-ga on 08 May 2003 23:28 PDT

But If the SRS would be modified by customer's request again and
again, then how's that ? Do we need to update our project budget
correspond to the changes that customer has made.

---

Clarification of Answer by dogbite-ga on 09 May 2003 08:42 PDT

Hi 888-ga,

  You raise a good point, and maniac made a nice 
  comment to this question.  From those perspectives,
  I would say the tasks could come in either order.

  I believe the key is how you define "budget."  I
  understand that a project cannot get rolling until
  there is some discussion of what resources (financial,
  people, etc) the customer and developer have.  To
  that end, one could argue that a budget is put in
  place as the first step of the process.

  The development process described on the Program-Ace
  corporation's website supports that view:

http://www.program-ace.com/advantages/project-definition.htm

  I define a budget as a fairly detailed document where
  money is clearly divided among tasks.  I like to know
  how much money will be needed, for each project component,
  for software developers, system testers, equipment, etc.
  The budgets that I see usually speak directly to the
  requirements document.  That way the customer can see
  exactly how much money is put toward achieving particular
  requirements.

  The IT Solvers corporation presents a development process
  where the budget follows the requirements here:

http://66.123.188.50/itsolvers/documents/projdev.PDF

  Also, EPRI discusses their "software contract
  package," where the budget follows the SRS:

http://www.epri.com/eprisoftware/processguide/swdrf.html

  The search terms I used were "software development 
  steps budget".

  I hope that helps you.

               dogbite-ga

Hello 888,

I am a little concerned that the answer from dogbite is incorrect or
misleading. I agree that it is best to have good, solid software
requirements prior to setting up a budget. However, in a number of US
government procurements, the Software Requirements Specification is
written long after the contract is approved (and the project budget is
done).

For reference, see
   http://www.stsc.hill.af.mil/resources/tech_docs/
the guides (Guidelines for Successful Acquisition and Management of 
Software Intensive Systems) go into a lot of detail of the overall 
procurement and development process. What a contractor typically gets
from the government includes:
  - the contract materials
  - the statement of work (how to do the task)
  - the procurement specification (what to do)
These documents have requirements on what the contractor must do, but
not to the detail of what the software must do vs. the hardware,
people, etc. That detail is going to be developed after contract award
(and thus after the budget is established).

  --Maniac

Hello maniac-ga,
So are you saying that large project usually have the project budget
before SRS be done? then how about a project like ERP?
Pls advise! Thank you for your comment!

 -- 888

In response to your request for clarification...
But If the SRS would be modified by customer's request again and
again, then how's that? Do we need to update our project budget
correspond to the changes that customer has made.

This is an *excellent* question. The short answer is - yes - you need
to update the project budget. Note however, that some changes don't
affect cost and I'll mention that briefly below.

The government's solution to this general problem area is called an
"Engineering Change Proposal" (ECP) or some other form of contract
change order. I will use a project done about 10 years ago as an
example. The company I worked for had won a contract with the US Air
Force to develop a set of flight simulators. Within a year to 18
months, we had contract changes for
 - replacing a 19" CRT display with a large rear projection display
for the "out the window" visual system
 - replacing LCD's that would have simulated the altimeter, mach /
airspeed indicator, horizontal situation indicator, and attitude /
direction indicator with more realistic instruments
 - added a digital radar landmass simulation
 - stopped work / started work / stopped work on one set of simulators
 - options exercised to produce another 10-20 simulators (up from the
original 5)
and so on.

Each of these required a change in the budget, schedule, statement of
work, and procurement specification. There was a replanning activity
as part of implementing each of these change orders. All of these
changes happened to cost money, but some changes are called "class 2"
ECP's which change the requirements but not the cost or schedule. A
class 2 change may be a trade of some kind - the contractor will do X
and in exchange, the government will remove requirement Y.

Changes occur with almost every large government program and the
government (and contractors) have well established procedures to do
them.

  --Maniac