How do you effectively decompose requirements for systems design?

When dealing with complex systems, or system-of-systems, the resulting requirements can run into the thousands. Attempting to achieve this at a singular, top-level is going to force errors. Not just simple errors such as ambiguous, conflicting or duplicated requirements, but potential complex issues including lack of requirement traceability, missing or wrong system allocations and even missing requirements. Induceing risk, cost and unnecessary change. Decomposing requirements is a critical practice as it enhances clarity, traceability, verification, allocation of responsibilities, risk management, modularity, iterative development, communication, cost estimation, and change management throughout the systems engineering process.

Some of the ways to decompose requirements is to ask the client more questions on what all functional and non functional requirements are, do the users of the system reside in specific geography, is there any response SLA for the users that needs to complied with?. Does the domain in consideration require any compliance like HIPAA/GDPR? What is the estimated usage of the system 6 months to 1 year down the line? How many users and transactions per second does the system need to fulfill? What are the availability requirements of the system? What are the RTO and RPO parameters? Do we need a phase wise release? What all features should be part of the MVP release? What are the other assumptions and constraints? Decomposing is absolutely critical

Decomposing requirements is crucial for: 1. Clarity-breaking down complexity, improving focus and organizing the system. 2. Development-enabling parallel work, modular design and risk mitigation. 3. Maintainability- facilitating updates, traceability and easier testing. 4. Documentation- leading to clear and concise documents. 5. Communication- enhancing communication between stakeholders.

When we were designing cloud integration solution for a partner, decomposing requirement helped us in defining the KPI's for both functional and non-functional requirements. such as canonical schema for message exchange to serve as reusable contract, turnaround time for processing financial information, logging for compliance, max message size & RPS to be supported. NFRs like consistency, high availability and scalability. Ability to reprocess messages. Decomposing requirements helped us define SLA for comprehensive solution, it provided clarity that foundation for the first customer will take significant efforts. Being able to create reusable and pluggable design is the most helpful aspect of decomposing requirements.

Decomposing requirements in system Design is a critical first step that lets you come down to the details to know important parts of what will guide the design. You need to know the number of users, how often they will use the system, potential size in bytes of each message they will send, how many times they will send the message and many other details depending on the system you want to design. This is to guide you on the potential traffic and data the system will consume which will help to design the system to handle it and for redundancy.

We have developed tools to enable this complex process to be more regularised avoiding many of the pitfalls for both system and software. Avoidance of ambiguity, ensuring completeness, accuracy and consistency are what’s needed and the D-RisQ tools System Kapture and Kapture help developers in these areas and more.

Essentually decomposing requirements means, identifying building blocks. Break the large requirement into pieces or logical functionalities that forms the final requirement. This requires good understanding of the requirement itself and then broad understand of "How" to reach that requriement. This thinking brings us to the "What" logical steps / building blocks required to reach the final step.

Principal Component Analysis. This is the first step in decomposing any system based on the KL method into an orthogonal set of features. Characteristic specification for these features can subsequently be defined based on an understanding of how these characteristics relate to the behavior of the system.

Erfahrungsgemäß ist es sinnvoll, die funktionale Zerlegung und die Definition nicht-funktionaler Anforderungen zu trennen. Bei der funktionalen Zerlegung beginnt man bei der Definition von System-Use-Cases, sprich, welcher Anwendungsfall vom Gesamtsystem umgesetzt werden soll. Hierbei werden verschiedene Prozessschritte herausgearbeitet, die unterschiedlichen Systemkomponenten zugeordnet werden können. Dadurch ergibt sich der Komponentenschnitt. Im zweiten Schritt werden die komponentenspezifischen Prozessschritte in Component-Use-Cases weiter ausdetailiert. Die relevanten nicht-funktionalen Anforderungen werden anschließend auf die identifizierten Prozessschritte gemappt.

Successful decomp starts by revisiting the past. Only a superhero can derive the system's intent without knowing the system's intent. So: > KNOW your users' dream of what's ENVISIONED fron ConOps > LOOK for synergy between Requirements & ConOps docs; if they disagree, SAY SO > MAKE BIG things into SMALL(er) things by successive approximation: 1 BIG function-> 3-5 small-functions-> 10-20 smaller-functions etc. > FIND METHODS/TOOLS to assist. Old School: Demarco; Newer School: Story Maps, Decomp diagrams > TALK -- get info (users) and help (experts) BEFORE a crisis Decomp will work IF you have: Users' description of what product should do SE description of what is specified Methods/Tools to break down functions Help when you scream for it

I am HUGE on visual diagrams, particularly in the early stages of decomposition. We are often dealing with extraordinarily complex processes that are not been well-documented. Visual diagrams ensure that all stakeholders can come to a common agreement more quickly, and reduce errors as compared to purely conceptual or written decompositions.

First of all, architecture design. It must be as simple as it can, as long as it meets the requirements of the system. After defining the architecture, the subsystems and their detailed specifications must be defined. After this, simulation, design verification and performance analysis are performed. Most times several toolboxes must be incorporated to verify the design and redefine the requirements of the subsystems from different perspectives, for example the functional specifications and the standardization specification.

Flowcharting, Flowcharting, Flowcharting. If you have to master one decomposition technique, it has to be flowcharting. As simple as it sounds, you can never go wrong with flowcharting. Flowcharting will enable you to: 1. Identify the levels of abstraction you can introduce in your system design; 2. Help your management and end-users appreciate that your system design addresses does indeed cater to their requirements in the most reasonable way possible; 3. Identify the functional and technical quality standards for not only your system as a whole, but also for each of your modular sub-systems.

Some of the decomposition techniques include: - system thinking - process charts - data flow diagrams - people, process, information, technology - use case diagrams

Here are few other decomposition techniques. Domain-Driven Design (DDD): This approach focuses on decomposing a system based on its business domain. Entities, value objects, aggregates, and bounded contexts are identified to create models that reflect the business domain closely. Service-Oriented Architecture (SOA): In SOA, the system is decomposed into services, each providing a set of related functionalities. These services communicate over a network and can be reused in different contexts. Microservices Architecture: Similar to SOA but with a focus on building small, independently deployable services that do one thing well. This approach is beneficial for large, complex systems that require high scalability and flexibility.

Personally, I would have decomposed the requirements as follows: 1) Global Understanding 2) Establishment of Hierarchies 3) Use of Structured Methods 4) Decomposition into Sub-Requirements 5) Identification of Relationships and Dependencies 6) Validation and Verification 7) Tracking and Change Management By effectively breaking down the requirements for system design, you establish a solid foundation for development, ensuring that all stakeholders have a clear and shared vision of the expected goals and functionalities.

1. Be certain of the position of boundaries between subsystems. 2. Be certain of the model of the subsystems absent from the total system. 3. Imagine how your final system will perform. This is where creativity plays a major role, one must imagine how the final system will behave, even if all of the underlying principles are unclear or unknown. There are modeling tools available to help with this, depending on what kind of system one is producing, however, there is no substitute for imagination.

Requirements decomposition criteria include measurability, traceability, completeness, consistency, independence, atomicity, relevance, feasibility, testability, user-centricity, prioritization, and evolutionary considerations. Adhering to these criteria ensures effective breakdown of high-level requirements into manageable and well-aligned components for system design.

The decomposition criteria depend at the stage of system design you are at. 1. If you have just been introduced to the end-user requirements, let those requirements be your guiding light as you flowchart them into "micro-requirements" which can be mapped to modular sub-systems later. 2. Once you've identified the "micro-requirements" that your system design needs to cater to, you should identify the technical standards you want your modular sub-systems to adhere to. This will help you identify which industry-proven sub-systems you can use use as-is, which ones need to be tweaked before being put into use, and which sub-system would need to be created from scratch.

Effective decomposition relies on specific criteria to ensure clarity and precision in systems design. Start by breaking down complex requirements into smaller, cohesive units. Prioritize based on business value and critical dependencies. Employ the MECE principle (Mutually Exclusive, Collectively Exhaustive) to prevent overlap and ensure completeness. Ensure each component adheres to the SMART criteria (Specific, Measurable, Achievable, Relevant, Time-bound). Consider cross-functional requirements and anticipate potential changes. Regularly review and refine the decomposition process to maintain alignment with evolving project needs. This criteria-driven approach enhances systematic decomposition, leading to a more robust and adaptability

Zur Überprüfung der Anforderungen können die einzelnen System-Use-Cases mental durchgespielt werden. Die Abläufe sollten sinnvoll sein und in der richtigen Reihenfolge ablaufen. Zu jedem System-Prozessschritt sollte es einen passende Component-Use-Case geben, der ebenso sinnvoll und in der richtigen Reihenfolge dokumentiert sein sollte. Sollte es Use-Cases geben, deren Ablauf nicht klar verständlich ist, dann ist dieser noch nicht fertig ausdetailiert und muss weiter bearbeitet werden. Anhand der System-Use-Cases und der Component-Use-Cases sollten die Entwickler:innen in der Lage sein, die Komponenten zu entwickeln und deren Interaktionen auszuimplementieren.

Validate decomposed requirements through verification, workshops, prototyping, user acceptance testing, simulations, traceability analysis, test case development, use case testing, feedback iteration, tool-assisted validation, compliance checks, and independent reviews. This ensures accurate, user-aligned, and robust requirements for system development.

Validating and reviewing decomposed requirements in systems design is critical for ensuring accuracy and completeness. Conduct thorough peer reviews involving cross-functional teams to bring diverse perspectives. Validate against the project's overall goals and stakeholder expectations. Employ verification techniques such as traceability matrices to confirm alignment with initial requirements. Prioritize user acceptance testing to validate functionality from an end-user perspective. Regularly update documentation and seek continuous feedback to refine and enhance the decomposition. This meticulous validation and review process ensures the reliability and effectiveness of the decomposed requirements

Validate and review decomposed requirements systematically to ensure accuracy and alignment with project goals. Involve stakeholders and conduct peer reviews using checklists to assess completeness and consistency. Verify traceability, dependencies, and compliance with industry standards. Seek clarifications, use prototypes for visual representation, and perform walkthroughs with the project team. Pay attention to non-functional requirements and evaluate testability. Review accompanying documentation and encourage feedback from diverse stakeholders. Iterate based on feedback to continuously improve the decomposed requirements, minimizing errors and ensuring project success

When you meet w/ the stakeholders to begin a req gathering/decomposition session - you can bet a large majority are not clear about what those 5 types of decomposition are - nor will they know how to best contribute to your fact-finding mission unless you guide them w/ clear, non-intimidating methods right out of the gate. Concise 'bucketization qualifiers' along w/ stellar process flow visuals coming to life in real-time will enable synchronization between the Client & IT team more expeditiously which will in turn provide the momentum needed to tackle the complex issues presenting themselves as the visual takes form. Bottlenecks, areas of cohesion or lack-thereof will begin to stand-out & provide those opportunities for your team shine.

People often dedicate considerable time to decomposing requirements, which is great. However, many forget to refer back to the requirements when needed. It's crucial to treat them as a source of truth during implementation and as reference during testing. Allocate your time effectively, ensuring sufficient focus on requirement gathering, implementation, and testing.

A key element of building complex systems is to agree on a common view of the data to be collected and used. Understanding the "meaning" of data across functional domains is key to understanding how it will flow from subsystem to subsystem and ensuring proper decomposition.