What is the best way to prioritize functional requirements for testing?

I would not fixate on functions and deal with system requirements that are risk based. Enable all stakeholders to do this...Define the system… 1 Define the system needs 2 Define the system 3 Decompose the system 4 Perturb system 5 Develop and define risk criteria 6 Design adverse progressions 7 Define risks with minimal controls 8 Design controls to enable acceptable levels of risk 9 Rank risks and address high to low risks 10 Develop and design system monitoring: early detection, isolation, correction, contingency and recovery 11 Continually validate and verify risk controls 12 Monitor the system and revise analyses due to system dynamics....

Scope definition prevents "scope creep" as early as possible and answers the what. Objectives define the why, which are both essential questions to be answered before you spend any efforts and allow you to prioritize your capacities.

Of the many perspectives to view this from (requirement owner, test designer, requirement delivery), they all come back to the same answer. Prioritize the testing to meet the most important requirements first, following the critical chain down for any related requirements. Then the next important, and so on. This requires effective communication between the stakeholders of the system. If you don't have that, ask yourself if testing will be effective or end up costing more if the tests don't answer the objectives.

The most effective way to prioritize functional requirements testing involves analyzing critical functionalities for core system performance and user experience. Consider factors like business impact, user feedback, regulatory compliance, and technical dependencies. Implement risk-based testing to allocate resources efficiently, focusing on areas with the highest potential for failure or impact. Continuously reassess priorities throughout the development cycle to ensure alignment with evolving project needs and stakeholder expectations, fostering optimal testing effectiveness and resource utilization.

The project's scope dictates key functions, determining critical testing areas. For example, upgrading an existing car to have doors open automatically based on owner gestures requires prioritized testing. Focus should be on the core functionality of this new feature (auto door), as it serves as a performance benchmark for the project. In prioritizing testing requirements, the emphasis is on the essential functionality of the new feature. However, testing must address not only requirements directly linked to auto door but also those interacting with the new functions.

Early testing accelerates risk burndown. Emphasize testing on attributes that represent New, Unique or Different system technology and/or manufacturing method attributes. Have always found a pragmatic assessment of each subsystem and component Technology Readiness Level (TRL) and Manufacturing Readiness Level (MRL) to be meaningful. Standard Work for readiness levels are well defined in the defense industry. Low TRL/MRL subsystems/components become the best areas to emphasize early functional testing.

I don't agree that we should only look at the functional requirements as this point seems to suggest. Both functional AND non-functional requirements MUST be verified. There are well defined verification methods for each. And keep in mind that non-functional requirements may very easily get more important than functional ones. In examples those relating to regulatory compliance within the target market or customer hard constraints. Because the system you built (even if functionally perfect) is useless if it cannot be sold! As, at the end of the day, we build systems (products) to support the business to make a profit. The end product must satisfy business goals!

There are various tools available to assist in prioritizing and managing functional requirements for testing. Project management tools like Jira, Trello, or Asana can be employed to create boards or backlogs where you can categorize and prioritize requirements. Additionally, tools specifically designed for requirements management, such as IBM Engineering Requirements Management or Helix RM, can provide features for classification, ranking, and traceability of functional requirements throughout the testing process. The choice of tool depends on your project's specific needs, team preferences, and the level of integration required with other project management processes.

Para clasificarlos la mejor manera es poder usar una metodología ágil, que permita identificar la importancia, estimar los tiempos para luego evitar riesgos en tiempo de entrega y no poder cumplir los tiempos del cliente. Y una herramienta que recomiendo es Azure.

Sempre que inicio a fase de teste eu alinho com a equipe responsável pela manutenção do software que começarei os testes pelas funcionalidades de maior complexidade e as que possuem vínculo com outra funcionalidade já entregues, pois, caso encontre algo, eu coleto as evidências e já encaminho imediatamente para a equipe realizar os ajustes. É preciso verificar se uma nova entrada não causou danos, então, o teste regressão é fundamental a cada nova realese.

I found a requirements traceability matrix for testing invaluable. It validates that all the requirements are being tested and if the requirements changes (which happens frequently over the course of a program) you can identify the tests that need to change with it.

Para analizar las dependencias, es importante conocer como es la base de datos con respecto a las tablas que las compongan y que relación dependencia tiene una con otra. Por otro lado sirve mucho hacer diagramas de flujo que muestren caminos felices y no felices para evitar problemas a futuros. Recomiendo como herramienta Figma y Draw io.

This is a very important step in the process as it is easy to overlook or miss certain dependencies. Undertanding emergent behaviour is one way to comprehending all the interactions of the system and identify areas that will need testing. SYSML modeling is a good method to understand interations and emergent behavior

I think it's very important to have fully detailed functional block diagrams that highlight all the interfaces and for all the stakeholders to be able to contribute it. The function block diagram will remove any ambiguity with what each module or sub-system needs to provide for overall system to function.

Again, a building block approach has worked for me in my career. Starting with shared, basic functions and progressing to higher and higher level functions until the entire system has been tested and validated. Do I have power? Is that power stable? Does my GUI work as needed? Then move off into tier 2 functional areas and go up the pyramid from there until complete.

After all said, a given direction is necessary; Prior assessment to the test subject functionality is crucial per policy and given procedure for any system test but with expertise and long term use one should always consider the process flow and pin point the critical areas hassles to avoid legal factors of course and safety factors above all, not all test steps processing can be feasible at all time so a trained professional can better assess the before and after the fact possibilities with higher outcome rate...

The in real world, you can never get perfect values when testing. For example, if you have a requirement stating that the system shall provide 16v for power, but is 15.99v acceptable? Is 16.01v acceptable? It's much better to word the requirement for easy testing. A good requirement would be, the system shall provide 16v with a margin of +/- 0.5v. The margins have to be defined.

Oh, the places you'll go with requirements galore! To test them with ease, here's what's in store: Prioritize by risk, as the Grinch would agree, High-impact items first, let them run free! Next, consider complexity, like Horton's big feat, Break down the tricky ones, make testing a treat! User flows and frequency, oh my, oh my! Test common paths first, let no bug slip by! Regulatory needs, like the Cat in the Hat, Keep them in check, or face a legal spat! With Seuss-like wisdom, prioritize with care, And your testing will be successful, fair and square!

Se debe tener en cuenta si la prueba a realizar resulta factible realizar ya que aveces no se pueden tener los ambientes adecuados para su realización.

Well, use the unorthodoxy method successfully applied by the brilliant minds of genius in the field, the “ Oppenheimer-Feynman “ method to solve such adaptive hurdles they encountered.

Antes de realizar cada caso de prueba se debe tener en cuenta un plan de pruebas para que el equipo tenga el conocimiento de que se validara y el porque.

Systems Engineering is not just having the technical know how about how to design a system. You need to be able to communicate your design to many different team. Mastering cross functional communication is crucial to have a robust system with no hidden surprises that is the result of poor communication. A simple misunderstanding can set back a project for months. I highly recommend conducting design reviews after each milestone to make sure that any design changes are also communicated to all stakeholders as well.

Il est nécessaire d'enrichir les priorités avec les risques et les bonnes pratiques en la matière. Cela permet alors de définir un système plus résilient. Pour définir les priorités, cela nécessite de définir les priorités du système, la sécurité, la résilience, les fonctions métiers, etc

Identification of CTS and CTQ requirements helps in the prioritisation of functional requirement testing. Safety and quality of the product should be of utmost importance and this should reflect in verification activities. Once you know your CTS and CTQ’s, verification plan can be made, resources can be allocated according to priorities.

If it is truly a Functional Requirement, and it isn't tested, the job isn't complete. Alternatively, changing the requirements may be more feasible. If it isn't testable, then it should not be a requirement. The method of testing should be identified when the requirement is identified. While it may change, there is at least a starting point on what to address. The Requirements Traceability Matrix should list the requirement, why it is a requirement (the source), how it will be tested, and whether the requirement is met. Then the RTM can be used as a starting point for the testing program. Not every requirement must be tested, though I would argue that every Functional Requirement should be verified.

Also consider: What hurts the most if it is not realized, and how it affects the necessary fulfillment of stakeholder needs/requirements.

The steps are spot on but here are some more thoughts from experience. Experienced engineers will work with system engineers, and specially folks to consider the following in the test planning: mission needs, system safety mitigations, performance requirements of the functions, product structure, technology readiness, risk……and facilities and test rigs to test/qualify components and subassemblies, before complex and expensive integrated testing. Many times lessons, unknowns/uncertainty is used to test and confirm at a lower level. It is a balance of risk, cost, and waiting to home run a full up integrated test of all function nominal, contingency, failure performance. Many times an N2 matrix can also help.

To prioritize functional requirements for testing, various techniques can be employed. One method is Ranking, where requirements are assigned numerical values based on importance. Another technique is the MoSCoW method, categorizing requirements as MUST have, SHOULD have, COULD have, and WON'T have. The Bubble Sort technique involves comparing requirements and ranking them accordingly. The Hundred Dollar Method allows stakeholders to democratically vote on requirements by allocating points. The Analytic Hierarchy Process (AHP) decomposes goals into sub-problems for evaluation. Lastly, the Five Whys technique involves repeatedly asking why a requirement is necessary to determine its true importance.