< PreviousChapter 4: Requirements60Chapter Contents4.1 Requirements Context ...................................................... 614.1.1 Requirements Subject ............................................... 614.1.2 Requirements Significance ......................................... 614.2 Requirements Suite .......................................................... 614.2.1 Foundations Requirements ........................................ 614.2.2 Context Requirements .............................................. 624.2.3 Architecture Requirements ......................................... 634.2.4 Development Requirements ....................................... 644.2.5 Engineering Requirements ......................................... 654.3 Requirements Evaluation ................................................... 674.3.1 Requirements Evaluation Scale .................................... 674.3.2 Requirements Evaluation Matrix .................................. 67Requirements Context614.1 Requirements ContextDesign is based on requirements. There’s no justification for designing something one bit “better” than the requirements dictate. — Akin’s Laws of Spacecraft Design 4.1.1 Requirements SubjectAs introduced in the previous Chapters 1-3, this dissertation will find a suitable approach, architecture, and implementation for optimally developing User Inter-faces of HTML5 Single-Page-Applications. To be able to decide on this optimum, a particular suite of requirements has to be stated first (see section 4.2 on page 61) [Lamport 1978].The subject of those requirements is the to be developed solution of the ap-proach, the architecture, and the implementation. In each requirement, this solu-tion is simply referenced as “it.”4.1.2 Requirements SignificanceThe requirements in this Chapter are the basis for evaluating the State of the Art of related work in Chapter 5 (see page 69), developing the central Solution (the “Hierarchical User Interface Component Architecture (HUICA)”) in Chapter 6 (see page 111) and finally checking the achieved results in the Evaluation in Chapter 10 (see page 277).4.2 Requirements SuiteIf you don’t care about quality, you can meet any other requirement. — Gerald M. WeinbergAll requirements are stated in the fixed form “[<id>] <name>: IT SHALL <result/ac-tion/condition> BECAUSE <rationale>“, inspired by [Robertson & Robertson 2017]. The requirements are clustered into Foundations, Context, Architecture, Develop-ment and Engineering requirements.4.2.1 Foundations RequirementsThe following requirements are derived from the foundations of Chapter 2 (see page 33). They are specific to User Interfaces but are still not related to the Web Technologies context.The stated requirements are the basis for Chapters “State of the Art”, “Solu-tion” and “Evaluation”.Chapter 4: Requirements62 ■[REQ-F1] Complete User Interface Aspect Coverage: IT SHALL cover all im-portant User Interface Aspects BECAUSE it should be a complete solution for implementing arbitrary User Interfaces. ■[REQ-F2] Complete User Interface Ontology: IT SHALL provide a complete ontology of the User Interface domain, ranging from the specification, over architecture, to implementation BECAUSE it is important to have a clear terminology of concepts and documented relationships between the concepts. ■[REQ-F3] Separation of Mask, Style, and Behaviour: IT SHALL make a clear separation of the three distinct User Interface concepts Masks, Styles, and Behaviour, BECAUSE of the important architecture principle Separation of Concerns. ■[REQ-F4] Separation of Controls, Interactions, and Events: IT SHALL make a clear separation of the three distinct User Interface concepts Controls, Interactions, and Events BECAUSE of the important architecture principle Separation of Concerns. ■[REQ-F5] Dialog-Level Structuring: IT SHALL support and motivate the structuring of the User Interface at the level of individual Dialogs (instead of just User Interface Fragments) BECAUSE the Dialog is the primary design unit of User Interfaces. ■[REQ-F6] Dialog Life-Cycle and States: IT SHALL support a flexible custom life-cycle of Dialogs BECAUSE User Interface Dialogs are inherently stateful and are used in various states over an entire time range.4.2.2 Context RequirementsThe following requirements are derived from the specific Web Technologies context of Chapter 3 (see page 43). ■[REQ-C1] HTML5 Single-Page-Application Approach: IT SHALL support the Rich-Client Architecture and Web Technologies based HTML5 Single-Page-Applications approach BECAUSE this is currently the mainstream architec-ture approach for User Interfaces. ■[REQ-C2] Strict Language Separation: IT SHALL separate the involved indi-vidual configuration, markup, query, and programming languages of Web Technologies BECAUSE of the architecture principle Separation of Concerns and to better support the usual development tools, like linting tools, tran-spilation tools, text editors, and Integrated Developer Environments (IDE). ■[REQ-C3] Potential Offline Operation: IT SHALL support the potential of-fline operation of User Interface BECAUSE of physical roaming and location changes, the network connectivity of the devices the User Interface is run-ning on, can be regularly interrupted.Requirements Suite63 ■[REQ-C4] Near-Real-Time Updates: IT SHALL support near-real-time Back End communication and corresponding near-real-time User Interface up-dates BECAUSE the expected overall User Experience today demands near-real-time updates of information in modern User Interfaces.4.2.3 Architecture RequirementsThe following requirements are derived from a general Software Architecture point of view. ■[REQ-A1] Separation of Model, View, and Control: IT SHALL use a clear sep-aration of at least the four concepts Domain Model, Presentation Control, Presentation Model and Presentation View BECAUSE of the architecture principle Separation of Concerns and the fact that practical experience over three decades of User Interface architectures showed that this separation produces many major benefits in practice. ■[REQ-A2] Distinguished Presentation Model: IT SHALL distinguish between presentation and domain model BECAUSE the model of the Front End (User Interface) usually has a different granularity and aggregation than the model of the Back End. ■[REQ-A3] Dialog Instantiation and Reusability: IT SHALL allow multiple in-stantiations of Dialogs during run time BECAUSE Dialogs often occur mul-tiple times in parallel within a single User Interface. ■[REQ-A4] Dialog-Level Component-Orientation: IT SHALL support a rea-sonable Component-Orientation on a Dialog-basis (instead of User Inter-face Fragment basis) BECAUSE it is vital to master the overall complexity of a User Interface and the Dialog is the primary design unit of a User In-terface. ■[REQ-A5] Hierarchical Dialog Communication: IT SHALL provide an inter-Dialog communication directly along the Hierarchical Composition of the User Interface Dialogs BECAUSE this way the Dialog communication di-rectly follows the natural Dialog relationships. ■[REQ-A6] Transitive Dialog Communication: IT SHALL provide an inter-Di-alog communication which transitively extends from parent to ancestor and from child to descendant Dialogs BECAUSE in practice the Dialog rela-tionships are often transitive. ■[REQ-A7] Structure and Behaviour Patterns: IT SHALL provide a set of struc-ture and behavior patterns BECAUSE architects should be guided by docu-mented best practices. ■[REQ-A8] Microservice User Interface Integration: IT SHALL support the in-tegration of partial User Interfaces from multiple Microservices BECAUSE Chapter 4: Requirements64the usual stand-alone User Interface of each Microservice in a strict Micro-service Architecture conflicts with the expected overall User Experience. ■[REQ-A9] Run-Time Tracing and Architecture Constraints: IT SHALL allow the tracing and restriction of run-time communication between Dialogs BECAUSE from an architecture point of view, usually not all technically pos-sible communications between Dialogs should be allowed.4.2.4 Development RequirementsThe following requirements are derived from the Software Development and Soft-ware Craftmanship perspectives. ■[REQ-D1] Server-Side Component Model Alignment: IT SHALL use a Com-ponent Model which is at least similar to existing ones on the server-side BECAUSE a similar model potentially increases developer acceptance. ■[REQ-D2] Hierarchical Development-Time Dialog De-Composition: IT SHALL allow the hierarchical decomposition of the User Interface into Ob-ject-Oriented Components during development time BECAUSE the code structure should be easily derived from and naturally align to the inher-ently hierarchical structure of User Interfaces. ■[REQ-D3] Distributed Orchestration of Run-Time Dialog Re-Composition: IT SHALL use a distributed orchestration for the hierarchical re-composition of the User Interface during run time BECAUSE this way the Dialogs can be developed fully independently from each other. ■[REQ-D4] Event-Driven Architecture: IT SHALL use the direct mapping of user Dialog interactions onto corresponding programmatic events BE-CAUSE this approach of an Event-Driven Architecture most naturally maps onto the domain of User Interfaces. ■[REQ-D5] Adequate Technology Complexity: IT SHALL support both small and large User Interfaces by causing just an adequate extra technology complexity BECAUSE this increases developer acceptance in practice. ■[REQ-D6] Object-Oriented Programming Flavors: IT SHALL work with an arbitrary Object-Oriented Programming (OOP) model of classes implement-ing Components BECAUSE until ECMAScript 6 (aka ECMAScript 2015) there was no standardized way of implementing OOP classes in JavaScript and so many alternative approaches exist. ■[REQ-D7] Different Programming Models: IT SHALL support both the tra-ditional OOP-Class-Hierarchy-based programming model and the Web-na-tive HTML/DOM-based programming model BECAUSE in practice it should work both with products like, for instance, Sencha ExtJS and VueJS.Requirements Suite654.2.5 Engineering RequirementsThe following requirements are derived from the Software Engineering perspec-tive. ■[REQ-E1] Potential Web Technology Independence: IT SHALL at least po-tentially support non-Web-Technology contexts of Rich Client Architectures BECAUSE in practice there are also other Rich Client based approaches like Eclipse RCP, ORACLE JavaFX, or Adobe Flash/Flex. ■[REQ-E2] Third-Party Integration and Extensibility: IT SHALL be extensible to allow the easy integration of and compatibility to third-party libraries BECAUSE the requirements of at least complex industrial Business Informa-tion Systems always demand the usage of additional esoteric User Interface widget libraries in practice. ■[REQ-E3] Run-Time Debugging and Visualization: IT SHALL provide a run-time mechanism to debug and visualize the User Interface with the help of event traces and a graph of instantiated Dialog Components BECAUSE having an overview of the Components during run time in large User Inter-faces is a major challenge for developers. ■[REQ-E4] Head-Less Run-Time Testing: IT SHALL allow the “head-less” (aka DOM-less or Browser-less) testing of the User Interface during run time BE-CAUSE for Continuous Integration and Regression Testing it is vital to have the ability to test-drive the User Interface without any visual representa-tion at all. ■[REQ-E5] Massive Dialog Scalability: IT SHALL scale without problems to many hundreds of instantiated (but potentially not shown in parallel) Dia-logs BECAUSE large industrial Business Information Systems often have be-tween 200 and 600 instantiated Dialogs during run time. ■[REQ-E6] Team Delegation and Responsibilities: IT SHALL support the rea-sonable delegation of Dialog implementations and the corresponding responsibilities to different teams BECAUSE at least the User Interface of large industrial Business Information Systems have to be split across multi-ple teams or at least multiple developers.Chapter 4: Requirements66Figure 4.1: Requirements Evaluation Matrix Template0%1-19%20-39%40-59%60-79%80-99%100%NOT AT ALLVERY POOR POORACCEPTABLEGOODVERY GOODPERFECTNDNA0123456REQ-F1Complete User Interface Aspect CoverageREQ-F2Complete User Interface OntologyREQ-F3Separation of Mask, Style, and BehaviourREQ-F4Separation of Controls, Interactions, and EventsREQ-F5Dialog-Level StructuringREQ-F6Dialog Life-Cycle and StatesREQ-C1HTML5 Single-Page-Application ApproachREQ-C2Strict Language SeparationREQ-C3Potential Offline OperationREQ-C4Near-Real-Time UpdatesREQ-A1Separation of Model, View, and ControlREQ-A2Distinguished Presentation ModelREQ-A3Dialog Instantiation and ReusabilityREQ-A4Dialog-Level Component-OrientationREQ-A5Hierarchical Dialog CommunicationREQ-A6Transitive Dialog CommunicationREQ-A7Structure and Behaviour PatternsREQ-A8Microservice User Interface IntegrationREQ-A9Run-Time Tracing and Architecture ConstraintsREQ-D1Server-Side Component Model AlignmentREQ-D2Hierarchical Development-Time Dialog De-CompositionREQ-D3Distributed Orchestration of Run-Time Dialog Re-CompositionREQ-D4Event-Driven ArchitectureREQ-D5Adequate Technology ComplexityREQ-D6Object-Oriented Programming FlavorsREQ-D7Different Programming ModelsREQ-E1Potential Web Technology IndependenceREQ-E2Third-Party Integration and ExtensibilityREQ-E3Run-Time Debugging and VisualizationREQ-E4Head-Less Run-Time TestingREQ-E5Massive Dialog ScalabilityREQUIREMENT ATTAINMENTNOT DETERMINABLENOT APPLICABLERequirements Evaluation674.3 Requirements EvaluationExperience doesn’t make you wiser. It just makes you older. Evaluated experience makes you wiser. — Andy Stanley4.3.1 Requirements Evaluation ScaleIn the following Chapters, we evaluate the stated requirements on the following attainment scale: ■ND: NOT DETERMINABLE: The author or the evaluator, for arbitrary reasons, is not able to determine the attainment at all. ■NA: NOT APPLICABLE: The requirement is not applicable to the current evaluation context. ■0: NOT AT ALL (0%): The requirement is not attained by the evaluation con-text at all, i.e., the evaluation context meets no expected aspects. ■1: VERY POOR (1-19%): The requirement is attained very poorly, i.e., the evaluation context meets just very little of the expected aspects. ■2: POOR (20-39%): The requirement is attained poorly, i.e., the evaluation context meets just little of the expected aspects. ■3: ACCEPTABLE (40-59%): The requirement is attained in an acceptable way, i.e., the evaluation context meets about half of the expected aspects. ■4: GOOD (60-79%): The requirement is attained well, i.e., the evaluation context meets much of the expected aspects. ■5: VERY GOOD (80-99%): The requirement is attained very well, i.e., the evaluation context meets most of the expected aspects. ■6: PERFECT (100%): The requirement is attained perfectly, i.e., the evalua-tion context meets all of the expected aspects.4.3.2 Requirements Evaluation MatrixWhen evaluating the stated requirements, the results will be recorded in a clearly arranged evaluation matrix (see Figure 4.1 on page 66), directly based on and referencing the requirements of the Requirements Suite (see Section 4.2 on page 61).68Chapter 5State of the ArtNext >