Trick brings up some an interesting point for those of you not completely aware of Software Engineering practices. In fact there are a whole gamut of SE documents that help control the entire process. In this discussion, I am focusing on the SRS and SDD, since the SRS as it focuses directly on requirements (which EA seems to want to support properly) and the SDD as it focuses on design.
These two documents, as well as the other, can be developed by an organization to provide a useful, orderly process to developing complex systems. Here is an outline of the core documents:
Vision and Scope - Software Vision and Scope
SCMP - Software Configuration Management Plan
SPMP - Software Project Management Plan
SQAP - Software Quality Assurance Plan
SVVP - Software Verification and Validation Plan
SRS - Software Requirements Specification
SDD - Software Design Description
STD - Software Test Documentation
Other include the User's Manual and Maintenance Plan in this list. Variations and other documents also exist.
All of these can be applied to the hardware side, or systems, as well. Substitute "System" for "Software" if you like.
The "Vision and Scope" document is basically a project kickoff document.
The first 4 documents are project managements documents:
----------
The SCMP documents the management of all configuration items in the project, i.e., everything: personnel organization and responsibilities, policies and procedures, tracking project artifacts (tools, documents, code, etc.), schedules, resources, and maintenance.
The SPMP documents the management of the project's processes, such as an overview, deliverables, reference material, project organization (model, structure, boundaries, responsibilities, management process, technical process, and work packages (their content, dependencies, scheduling, resource requirements, and budget).
The SQAP documents the quality assurance objectives for the project. It covers quality assurance management, tasks, responsibilities, documentation (referencing all the documents), standards, practices, conventions, metrics, reviews and audits (peer review process, reviewing other documents and processes), testing process, handling problems, securing tools, code, media, and suppliers, recording process, training, and risk management.
The SVVP document documents the verification and validation process. It covers the V&V team, its members, their responsibilities, and process.
----------
The next 3 documents are the project development documents:
----------
The SRS covers all thing related to the projects requirements such as overview, C-requirements (project description, UI concepts, system interfaces, use cases, assumptions, constraints, dependencies, priorities), D-Requirements (a detailing of the C-reqs: detailed interface requirements, functional requirements as features including a sequence diagram, its specification of feature process requirements, and, if an OO process, detailing the specified class requirements (their attributes, methods, instances, and related events), non-functinal requirements including performance, design constraints, and quality attributes, and any other support materials.
The SDD covers all things related to the projects design. It is driven directly from the SDD and includes an overview of the project, its architectural considerations(with reviewed alternatives), strategies, and design as a high-level design of the architecture dividing the project into its related systems, modules, packages, etc., and detailing their relationships, any policies and tactics for the design, a detailed design specifying all the processes, functions, files, formats, etc. at the lowest granular level (for an OO process, the classes with their attributes and methods including documentation and pseudo-code to direct the implementation process), and the UI detailed design. Any additional supporting materials are also included.
The STD covers all thing related to the testing of the design and is driven by the SQAP, SRS, and SDD. It includes documentation of the testing policy and procedures, test cases for the project including validation and verification of all project requirements present within the implementation, and design flaw documentation and remediation.
----------
The following standards can serve as a reference for most of the documentation presented in this discussion:
IEEE Std. 829-1998 IEEE Standard for Software Test Documentation
IEEE Std. 830-1998 IEEE Recommended Practice for Software Requirements Specifications
IEEE Std. 1008-1997 IEEE Standard for Software Unit Testing
IEEE Std. 1012-1998 IEEE Standard for Software Verification and Validation
IEEE Std. 1016-1998 IEEE Recommended Practice for Software Design Descriptions
IEEE Std 1058-1998 IEEE Standard for Software Project Management Plans
IEEE Std 1540-2001 IEEE Standard for Software Life Cycle Processes – Risk Management
IEEE 12207.2-1997 Industry Implementation of International Standard ISO/IEC 12207: 1995 (ISO/IEC 12207) Standard for Information Technology - Software Life Cycle Processes - Implementation Considerations
MIL-STD-498 Military Standard, Software Development and Documentation, US Department of Defense, 5 December, 1994
The Process Impact site is a good resource:
http://www.processimpact.com/Also, the book "Writing Effective Use Cases" is suggested.