Unless the system parameters are carefully and meticulously articulated, you have a very costly task ahead of you. Let’s take the importance of the Software Require- ments Document, the SRD. Why have one? There are many projects that don’t bother with such things. The SRD is your contract with the customer. Who is your customer? Generally for a segment, it is the system implementation manager.
If you are the systems manager, it is the end user like the Army, Air Force, or NASA, depending who entrusted you with the funds to build the system. If it is incomplete, how do you know as a customer what you have coming to you? As a producer of software, how do you know what you have to deliver for the money you have been paid if you have an incomplete set of requirements?
4Cost estimates are usually very sloppy these days. They need to be broken down into hardware and software components, at a minimum. Regardless of whether the ‘‘host’’ is a flight system or ground system, all of it works because computer software makes it work. We are past the mechanical age and cannot exclude software from our estimates if we are sane, care about cost, and take professional pride in the work we do.
This is double jeopardy; I don’t like it. One of the techniques that some custo- mers use to get the last drop of blood out of the implementer is to say something to the effect of, ‘‘Gee, this application doesn’t work right.’’ This puts you on the spot and gives you feelings of guilt or makes you feel stupid for having forgotten it, when in fact the function might not have ever been a requirement. An SRD is an SRD only if, at a minimum, it has been signed by both parties. It helps if two management tiers above have reviewed it and concurred to make certain that some critical application was not left out accidentally.
The project Software Requirements Document is the contract between the cus- tomer and the client. It follows that it must be treated with due respect. Not having one would be equivalent to an individual saying to a contractor, ‘‘I want you to build me a house. There is the lot, and here is the money. Let me know when you are finished.’’ No honest person would accept a job like that; I certainly wouldn’t.
The Software Requirements Document is very complex. It contains all stated, implied, and derived requirements needed by the project and system. I would esti- mate the contents of the SRD are about 60% stated requirements, 25% implied requirements, and 15% derived requirements. Only the stated requirements origi- nate from the customer. The rest is originated through dialectical examination of the proposed objective design. This is not an easy thing to do. On GDSS, the entire system depended on implied and derived requirements, which represented a good two-thirds of the total cost.
Moreover, the project test plan is based on the SRD; all test cases and test pro- cedures are based on the SRD, so a project cannot test a system that does not have a completed, signed off Software Requirements Document (or System Requirements Document for system hardware, like spacecraft, aircraft, or missiles). Without an SRD, the customers don’t know what they are to get, and you don’t know what they want. Worse than just looking like a fool, you will take a lot of abuse—not name calling in today’s politically correct environment, but the kind of abuse that makes you feel like a fool, a novice, a greenhorn. The stress is awful: Your cholesterol climbs, you eat big burgers with everything on them to control your sto- mach acid, and you gain weight. Your best people leave and you have to hire new people who may or may not be good at their chosen professions. They need ‘‘break- in time’’ to familiarize themselves with the project, systems, and personnel; never- theless, your blood pressure goes through the roof, and it affects everything. Even this could be acceptable if the individuals who push you around were technically competent and serious individuals who understood the conditions. But they are not;
they are anything but experienced and knowledgeable computer scientists. They may have a B.S., M.S., or even a Ph.D. in computer science, but have never deliv- ered a significant system from start to finish. They are ‘‘professional managers’’
whose interest is in career before product. So, the SRD is very important to all con- cerned, and above all to the project and implementation managers.
If a fully agreed-to SRD does not exist, the project is not being managed cor- rectly. In fact, there is no way realistically to cost a system, hardware or software, unless the requirements are completed and signed. An expert manager can estimate
THE SRD: SOFTWARE REQUIREMENTS DOCUMENT 89
very closely what it will cost, but it is not the real thing. As far as ‘‘creeping requirements’’ are concerned, the meaning of this term is ‘‘we don’t know what we are doing; we are novices.’’ A customer always knows what functionality a system must provide. It is the project manager and his team whose job it is to figure out the detailed requirements, and based on those, the detailed design.
When going out on a competitive bid for implementation, if funds matter, the project design team writes the FRD and the SRD. Based on these two documents, the project manager prepares the Project Implementation Plan (PIP). The Request For Proposal, RFP, contains only the FRD and SRD, and is the package that needs to be sent out. When the proposals come back, the costs proposed can be compared to the PIP, and then you can see relatively clearly who is and who is not rational about cost and schedule, if the funding profile is important, of course. I am saying this because in my experience the funding was rarely important to most projects in the military. The rare exceptions were instances like GDSS and JTLS, because the acquisition of a new technology had priority and urgency.
The FRD is the project manager’s contract with the customer, while the SRD is the project manager’s contract with the implementing organization. No one would invest in building a house without a contract, yet projects do the equivalent of this all the time. All government agencies do it; it’s no small surprise, then, that our national budget is so overrun. We taxpayers are paying almost 100% percent more than we need to for our products. Only the private sector is anxious to get value for the money.
7 Software Management Standards
The software management standard is one of the most important tools at the dispo- sal of a manager-architect and systems engineer. In my point of view, it is the
‘‘Talmud’’ of computer software development. I don’t like to even think about developing a system without it. In my career in computer science, I have only once built a system without using an software management standard. It is certainly a great help in keeping cost down, the development on schedule, and the quality of the product at a professional level. When a decision is made to waive a standard, it must be made with great caution. Only those managers, architects, and systems engineers who understand software standards thoroughly should be permitted to forgo the use of one. In such cases, the manager and systems engineer already know it by heart and will substitute improvised methodologies that reflect the fun- damental approach of a specific standard, or a combination of several.
It is sad indeed that software management standards are not included as a required subject for a degree in computer science in the curriculum of our univer- sities. Not that a standard is a substitute for courses in management or systems design, but it forms a clearly articulated framework around the process of systems development, like the structure of the five-paragraph field order does to Army operations, planning, and implementation. If one uses a standard properly and con- sistently, it becomes second nature to one’s mental process, and ever easier to apply and use. In a definite sense it becomes a teacher to the users as well, as discussed in Chapter 10, ‘‘The Development Process Methodology.’’