Hierarchical Quality Requirement Model for Software
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current methods fail to explicitly define and elicit non-functional quality requirements for software products, leading to difficulties in ensuring that software meets these requirements, resulting in redesigns and re-testing, which are resource-intensive and time-consuming.
Innovation Solution
A product quality requirement model with a taxonomy tree structured into primary, secondary, and tertiary levels is used to identify and document quality characteristics, sub-characteristics, and objectives, enabling clear documentation and customization of quality requirements for software products.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If non-functional quality requirements are not explicitly defined, then software development can proceed without detailed quality specifications, but software quality cannot be ensured leading to redesigns and re-testing
Solution Approach 1:
The patent segments quality requirements into a hierarchical taxonomy structure with quality characteristics at the top level, sub-characteristics at the second level, and quality objectives at the third level. This segmentation allows comprehensive quality coverage while organizing requirements in a manageable, structured manner that reduces documentation complexity.
Solution Approach 2:
The patent applies preliminary action by defining the complete quality requirement taxonomy and mapping software requirements to this structure before the actual software development begins. This upfront structuring ensures quality requirements are explicitly defined and integrated into the development process, preventing later redesigns and re-testing.
2Reliability
If a comprehensive quality requirement model is implemented, then software quality can be ensured, but the complexity of defining and documenting requirements increases
Solution Approach 1:
The patent creates a universal quality requirement taxonomy that can be applied across different software projects and domains. This multi-functional model serves as a reusable framework that reduces the time needed to define quality requirements for each new project, as the same structured approach can be consistently applied.
Solution Approach 2:
The patent enables copying and reusing quality requirement templates and mappings from previous projects. Once the taxonomy is established and populated with quality objectives, these can be replicated and adapted for similar software projects, significantly reducing the time required for requirement definition while maintaining comprehensive quality coverage.
3Productivity
If quality requirements are not clearly defined beforehand, then development can start quickly, but defects related to non-functional requirements are difficult to identify
Solution Approach 1:
The patent applies preliminary action by establishing the quality requirement taxonomy and mapping objectives before development begins. This upfront definition of quality characteristics, sub-characteristics, and objectives ensures that non-functional requirements are clearly specified in advance, enabling faster development without compromising defect detection capability.
Solution Approach 2:
The patent implements feedback mechanisms by structuring quality requirements in a hierarchical taxonomy that allows systematic verification and validation. The organized structure of quality characteristics, sub-characteristics, and objectives provides clear criteria for testing and measurement, making it easier to detect and measure defects related to non-functional requirements throughout the development process.
Data Source
AI summary
A method(s) and system(s) of identifying quality requirements for a software product to be developed is disclosed. The method includes receiving input data from a user. The input data is indicative of objectives to be met by the software product being developed. The method further includes mapping the input data with a pre-defined product quality requirement model (PQRM). The PQRM is retrieved from a database and includes a taxonomy tree configured to define a plurality of quality characteristics (QCs), a plurality of sub-QCs, a plurality of quality objectives (QOs), and a plurality of quality requirements (QRs) for the software product. Further, the method includes identifying at least one OR from the plurality of QRs applicable for the software product. The identification is based on the input data. The method also includes generating a product requirement report (PRR) for the software product based on the identification.