28. Software Supplier Requirements – PRD/MRS/FRS
SDLC Requirements Phase Input: Product requirements from Sales; Product Management; Customers; Software Bugs List. Output: Product Requirements Document (PRD) or Market Requirements Specification (MRS). PRD/MRS then converted to Functional Requirements Specification (FRS). (p. 214)
The Software Development Life Cycle (SDLC) for regulated software can take various forms, but it always begins with development of an agreed set of requirements. For custom software projects, the URS and PRS provide important input for converting work process needs into software features and functions for a Functional Requirements Specification (FRS).
For configurable or Off the Shelf (OTS) commercial software, the supplier uses diverse sources to compile a Product Requirements Document (PRD) or Market Requirements Specification (MRS). With input from sales, product management, current and prospective customers, software bug lists and competitive products, supplier management agrees on a set of required deliverables in a PRD or MRS. Engineering then converts the PRD/MRS into an FRS that describers a more technical view of the software features and functions necessary to deliver on PRD/MRS requirements.
Suppliers use various Computer Assisted Software Engineering (CASE) tools to support and manage the development work process. One such tool type can manage uniquely identified requirements and trace them from FRS through design and formal testing. This is a huge and complex task for most commercial software suppliers and using automated tools is essential to get the job done. CASE tools are available both as high end commercial products and also as open source programs.
A standard approach to creating a PRD/MRS document is to organize related requirements in tables where each requirement has a unique identifier, a customer focused description, and a way to test for it as a purchased system. Having a column for Use Case Test Topics is essential to ensure that the PRD/MRS has only real testable requirements. If it can’t be tested, it is a wish and not a requirement.
| Unique ID | PRD/MRS Requirement Title & Description | Use Case Test Topics (PQ view) |
| 1. | ||
| 2. |
Creating the FRS requires mapping the PRD/MRS requirements to the respective technical features and functions needed to deliver the agreed requirements. Again, no “wishes” are allowed. There MUST be a way to verify that the software performs technically as expected.
| Unique FRS ID | PRD/MRS
ID(s) |
FRS Requirement Title & Description | Verification Test Topics (OQ view) |
| 1. | |||
| 2. |
Then one can record Test Script IDs in the last column. This will make an instant OQ Trace Matrix. The requirement ID trace between FRS and PRD/MRS may be one to one, one to many, or many to many.
Next Month: Validation Package Model – Human Control
There are three streams of validation work that must be controlled and documented within each package. The first workflow is control of human interaction with the system starting with approved requirements, system specifications, and service level agreements with suppliers. (p. 61)