Software Engineering

294
CHAPTER 17 
Software Requirements Definition
metrics
1
 , such as: interoperability, portability, scalability, security, maintainabil-
ity, complexity, and throughput. If the software product is expected to operate 
on more than one computing platform, then more than one computing environ-
ment specification may be prepared to account for the different characteristics 
of each platform.
5. 
Software interface requirements specifications
. The operational data exchange 
requirements should be documented to address all interfaces, including human–
machine interfaces. The software interface requirements specification should 
identify each interface among the product, other systems, applications, and ele-
ments of the computing environment. Each interface requirement must be speci-
fied in terms of the informational content of the exchange, as well as the means 
of transmitting data among the participating configuration items.
6. 
Software test and evaluation plan
. The software test and evaluation plan should 
be prepared to address the software acceptance testing strategy and how and 
when software quality assurance inspections will be conducted. The software test 
strategy should address the software qualification methods as they apply to each 
requirement specified by the SRS. Software quality assurance inspections should 
ensure that the software development tasks are being performed according to 
established procedures and that the product requirements, architecture, and imple-
mentation are converging toward a complete and consistent product solution.
7. 
Software post-development process concept documents
. The preliminary 
concepts for how the product will be replicated, distributed, and supported, and 
how training will be conducted should be prepared. These concept documents 
should be allowed to evolve as the product architecture is developed so that 
they will reflect the product architectural decisions made during the architecture 
definition. During software implementation, there should be a parallel effort to 
implement and test these post-development processes so that they are available 
when the product has successfully completed acceptance testing.
8. 
Software requirements traceability matrix
. The requirements traceability matrix 
should initially identify the source of each requirement and its dependencies to 
the computational environment requirements. The source of a software require-
ment may include, for example, a stakeholder, legal regulation, standard prac-
tice, company policies or guidelines, operational model, or derived by analysis. 
This matrix is intended to be evolved throughout the software post-development 
(distribution, training, and sustainment) efforts. During this requirements defini-
tion stage, the requirements specified for the software product and interfaces 
should be traced back to their source, for example, customer needs statements, 
statements of work, project authorization documents, market surveys, trade-
study results, recommendations, and decisions. This matrix can be maintained 
as a single product or separated into two or more individual matrices for each of 
the identified software configuration items.
1 
Distributed Computing Environment, Software Technology Roadmap, 
http://www.sei.cmu.edu/str/
descriptions/dce.html

---