Rationale:: We used _functional decomposition_ to separate responsibilities: * {xrefConceptCheckerCore} shall encapsulate checking logic and Html parsing/processing. * all kinds of outputs (console, html-file, graphical) shall be handled in a separate component (`Reporter`) * Implementation of Gradle specific stuff shall be encapsulated. Contained Blackboxes:: [cols="1,3" options=""] .HtmlSanityChecker building blocks |=== | <<sec:checker_blackbox, HSC Core>> | hsc core: html parsing and sanity checking, configuration, reporting. | HSC Gradle Plugin | integrates the Gradle build tool with HSC, enabling arbitrary gradle builds to use HSC functionality. | HSC Maven Plugin | integrates the Maven build tool with HSC, enabling arbitrary maven builds to use HSC functionality. | HSC Graphical Interface | (planned, not implemented) |=== Source: https://hsc.aim42.org/arc42/chapters/chap-05-BuildingBlocks.html
problem and found solution} ## Context and Problem Statement {Describe the context and problem statement, e.g., in free form using two to three sentences or in the form of an illustrative story. You may want to articulate the problem in form of a question and add links to collaboration boards or issue management systems.} ## Considered Options * {title of option 1} * {title of option 2} * {title of option 3} * … <!-- numbers of options can vary --> ## Decision Outcome Chosen option: "{title of option 1}", because {justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force {force} | … | comes out best (see below)}. <!-- This is an optional element. Feel free to remove. --> ### Consequences * Good, because {positive consequence, e.g., improvement of one or more desired qualities, …} * Bad, because {negative consequence, e.g., compromising one or more desired qualities, …} * … <!-- numbers of consequences can vary -->
when, by whom, and which data was changed. • Approaches: • Logging in services • Hibernate Envers for auditing • Fitness Function: classes() .that().areAnnotatedWith(Service.class) .should(log())
→ paper is in the printer within 3 seconds. • Fitness Function: • Collect end-to-end duration from test & production environments • Calculate average • Pass if <3s • Fail if consistently >3s
within a single sprint. • Fitness Functions: • Track lead time from In Progress → Done in Jira • Analyze cycle times across stories • Checks median story lead time ≤ sprint length
designed architecture Did we build the system right? 2. check if the implementation (and thus the architecture) fits the non-functional requirements Did we build the right system?
can we measure whether the requirement is fulfilled? • What is our solution strategy for fulfilling the requirement? • Automatically check whether the solution strategy is implemented consistently. • Automatically check whether the requirement is fulfilled.
https://www.workingsoftware.dev/the-ultimate-guide-to-write-non-functional-requirements/ [email protected] in/roland-weisleder @rweisleder.de arcNdev Need help with your Legacy System? Let´s connect!