<The business requirements provide the foundation and reference for all detailed requirements development. You may gather business requirements from the customer or development organization’s senior management, an executive sponsor, a project visionary, product management, the marketing department, or other individuals who have a clear sense of why the project is being undertaken and the ultimate value it will provide, both to the business and to customers.>
## Business Opportunity ## Business Objectives and Success Criteria ## Customer or Market Needs # Vision Statement ## Major Features ## Assumptions and Dependencies<The project scope defines the concept and range of the proposed solution. It’s also important to define what will not be included in the product. Clarifying the scope and limitations helps to establish realistic expectations of the many stakeholders. It also provides a reference frame against which proposed features and requirements changes can be evaluated. Proposed requirements that are out of scope for the envisioned product must be rejected, unless they are so beneficial that the scope should be enlarged to accommodate them (with accompanying changes in budget, schedule, and/or resources).>
<Describe the intended major features that will be included in the initial release of the product. Consider the benefits the product is intended to bring to the various customer communities, and generally describe the product features and quality characteristics that will enable it to provide those benefits. Avoid the temptation to include every possible feature that any potential customer category might conceivably want some day. Focus on those features and product characteristics that will provide the most value, at the most acceptable development cost, to the broadest community.>
<If a staged evolution of the product is envisioned over time, indicate which major features will be deferred to later releases.>
<Identify any product features or characteristics that a stakeholder might anticipate, but which are not planned to be included in the new product.>
<Define the architecture of the solution, from a 10k feet view to defining the inputs and consumption of the distributed system>
<Declare an architecture diagram for the project. A good rule of thumb is to keep the number of components under 10. For each component, consider having a follow-up paragraph explaining what each component does.>
<Define diagrams representing the lifecycle of the system, usually with sequence diagrams.>
<Define a diagram representing how data enters into the system. What data enters the system, when, who pushes the data?.>
<Define a diagram representing how data will be consumed from the system. Is data pushed to participants, or requested?>
<Define how trust will be managed in the system. It may be that the system will require a shared secret or a registration to a central system. It's also possible that the system requires presets in place prior to deployment to allow participation. If the system is an open peer to peer system, please indicate it here.>
<Define how the identity of the participants will be managed in the system. It can be a third party database, wallets, key pairs...>
<Define a representation explaining how participants to the system may receive payment for their involvement with the system. Usually this representation is first a sequence diagram showing the happy path by which incentives are introduced to participants in the system, if applicable.>
<List each mitigation measure in place making sure the distributed system is able to defend itself against bad incentives, bad actors>
<List each attack pattern the system is drilling against, explaining how it will perform under a variety of network conditions or in the presence of attackers. Think of attacks such as denial of service attacks, amplification attacks, discouragement attacks...>