Constraints, functional requirements, quality attributes. All of those are known as\narchitecturally significant requirements. Characterizing those is the final step\nin our initial “understand phase”.
\n--- excerpt ---
\nThey may be given as constraints, that is, predefined decisions that may not change.\nThey may be implied by user stories, making them functional requirements. They may be general\ndesirable qualities in connection with business goals of stakeholders.
\nAll of those are known as architecturally significant requirements. That is, requirements\nthat strongly influence architecture choices. Characterizing those is the final step\nin our initial “understand phase”.
\nMost come from stakeholders' goals. A few other ones are here to make my life as\na developer easier on this project.
\n| Origin | \nConstraint | \nDetail | \n
|---|---|---|
| Manager | \nInitial release must be ready by end of Q4 2018. | \n\n |
| Manager | \nMust use free tools only. | \nAs an illustrative project, it has no allocated budget. | \n
| Manager | \nMust be Open Source software | \nProject will be used to write articles on a website. | \n
| Manager | \nMust support at least two of Binance, Bitfinex, Bitstamp and Bittrex marketplaces. | \nThose are common and renowned marketplaces, good initial candidates to gain visibility. | \n
| Developer | \nMust run on Linux | \nEasier to develop and maintain, and no willingness to mess with Win32 oddities. | \n
| Developer | \nMust use only C/C++/Python/JavaScript for development | \nBest knowledge at this point in time, will make for more efficient development. | \n
| Developer | \nMust work in detached mode, as a background job with a controlling interface. | \nThis follows the tradition of Unix modular architecture. | \n
As the point of this article series is architecture and implementation, I\nintentionally skipped writing formal requirements.
\n\nAn influential functional requirement is a requirement that has an impact on system architecture.
\n
The point is not to recreate project's functional requirements. Rather, it is to identify\nkey requirements that could make our architecture fail badly should we omit them in our design.
\nUsually, interactions with people or with external system are good candidates.
\nCryptomate shall react to data updates in real time, according to a predefined strategy:
\nCryptomate shall allow strategies to trigger market orders on trading platforms.
\n\n\nA quality attribute describes visible properties of the solution and expectations of how\nwell it performs its role.
\n
As much as possible, we want to describe those quality attributes through scenarios,\nquantifying the characteristics of solution's response to specific stimuli.
\nThere are many possible quality attributes. This section only includes the ones identified\nwhile establishing stakeholder's business goals. All items in this section either are taken\nstraight from stakeholders' goals, or result from refining\none of those goals into multiple scenarios.
\nRepresents the cost of changing the product. In our case, it can be split into maintainability\nand testability.
\n\n\nMaintainability is the capacity of a system to be modified in order to fix defects,\nmeet new requirements and manage technical debt.
\n
Scenarios :
\n\n\nTestability is the capacity of a system to facilitate the establishment of tests and\ncheck that validation criteria are met.
\n
Scenarios :
\n\n\nPerformance is the ability of the system to achieve required functionality within\ntime, space and cost constraints.
\n
Scenarios :
\nThose assume consumer-grade hardware, with 100 active strategies. Current state examining at\nmost one Cryptomate-provided indicator, and no throttling restrictions coming into play.
\n\n\nReliability is the ability of the system to recognize the failure of an internal component\nand maintain its correctness (either by compensating the fault or reporting it).
\n
Scenarios :
\n\n\nAvailability characterizes system response to failures and the associated consequences.
\n
Scenarios :
\n\n\nScalability is the ability of the system to handle an increasing amount of work. This\nincludes the ability to accommodate additional resources.
\n
\n\nUsability is the ability of the system to enable users to accomplish desired tasks\nin the most efficient / comfortable / … way.
\n
I will leave this part out intentionally for now, we will come back to it when designing\nuser interactions. As we have a constraint that the system is detached from any user\ninterface, we should have a high level of decoupling, making the UX almost a separate project.
\n\n\nAuthenticity is the trust the system can have that data and messages are from the sender\nthey claim to be from.
\n
\n\nConfidentiality is the ability of the system to keep some information and services private.
\n
\n\nIntegrity is the ability of the system to ensure information has not been corrupted or tampered with.
\n
\n\nAudit-ability is the capacity of the system to keep adequate records to support audits\nand investigations.
\n
We now have a full view of what features and which quality attributes will have an impact\non the architecture of our solution. At that point, we should consolidate all the knowledge\ngathered so far into an architecture-significant requirement workbook. This is a living document\nthat we will update as we encounter new elements we missed in the initial design phase,\nhopefully as few as possible.
\nIn the next post, we will use that knowledge to create a high-level\narchitecture from common designs, possibly compositing them for our system.
","fields":{"isPage":false,"slug":"/2018/cryptomate/requirements"},"frontmatter":{"title":"Requirements and Quality Attributes","classname":null,"date":"2018-08-06T00:00:00.000Z","formattedDate":"August 06, 2018","isoDate":"2018-08-06T00:00:00+00:00"},"headings":[{"value":"Constraints","depth":1},{"value":"Influential functional requirements","depth":1},{"value":"Quality attributes","depth":1},{"value":"Modifiability","depth":2},{"value":"Maintainability","depth":3},{"value":"Testability","depth":3},{"value":"Run-time attributes","depth":2},{"value":"Performance","depth":3},{"value":"Reliability","depth":3},{"value":"Availability","depth":3},{"value":"Scalability","depth":3},{"value":"Usability","depth":2},{"value":"Security","depth":2},{"value":"Authenticity","depth":3},{"value":"Confidentiality","depth":3},{"value":"Integrity","depth":3},{"value":"Audit-ability","depth":3},{"value":"Conclusion","depth":1}],"image":null,"series":{"name":"cryptomate","fullName":null,"fields":{"slug":"/cryptomate"}},"tags":[{"name":"architecture","slug":"/tag/architecture"}]}},"pageContext":{"series":"cryptomate","slug":"/2018/cryptomate/requirements","previous":{"fields":{"slug":"/2018/cryptomate/stakeholders"},"frontmatter":{"title":"Stakeholders and Goals","series":"cryptomate"},"tags":[{"name":"architecture","slug":"/tag/architecture"}]},"next":{"fields":{"slug":"/2018/cryptomate/modules"},"frontmatter":{"title":"Modules and Components","series":"cryptomate"},"tags":[{"name":"architecture","slug":"/tag/architecture"}]},"seriesPrevious":{"fields":{"slug":"/2018/cryptomate/stakeholders"},"frontmatter":{"title":"Stakeholders and Goals","series":"cryptomate"},"tags":[{"name":"architecture","slug":"/tag/architecture"}]},"seriesNext":{"fields":{"slug":"/2018/cryptomate/modules"},"frontmatter":{"title":"Modules and Components","series":"cryptomate"},"tags":[{"name":"architecture","slug":"/tag/architecture"}]}}}, "staticQueryHashes": ["1733002695","4006707078"]}