Software Architecture
Development of preconditions
The overall goal of preparation is to reduce risk: adequate planning eliminates the main aspects of trouble at the earliest stages of work so that the main part of the project can be carried out as efficiently as possible. Of course, the main risk factors in software development are bad requirements development and poor project planning, so the preparation is aimed primarily at optimizing these stages. Since design preparation is not an exact science, the specific approach to risk mitigation is largely determined by the nature of the project.
Requirements development
Requirements describe in detail what the software system should do, and developing them is the first step toward solving the problem. Explicit requirements help ensure that the system's functionality is defined by the user and not by the programmer. If the requirements are explicit, the user can review and approve them. Detailed requirements allow you not to guess what the user wants. Attention to the requirements allows you to minimize changes to the system after the start of development. If you find an error in the code while coding, you will change a few lines, and work will continue. If, however, you find an error in the requirements during coding, you will have to change the program's design to match the revised requirements.
- Business requirements describe why the organization needs such a system, that is, the goals it intends to achieve with its help. Their main content is the business goals of the organization or client ordering the system;
- User requirements describe the goals or tasks that users should be able to perform with the product, which in turn should benefit someone. The user requirements area also includes descriptions of product attributes or characteristics that are important to user satisfaction;
- Functional requirements define how a product should behave under certain conditions. They define what developers need to create so that users can complete their tasks (user requirements) within the business requirements. This relationship between the three levels of requirements is vital to the project's success.
Architecture design
Architecture is a high-level part of the program, a framework consisting of the details of the project. The architecture's quality determines the system's conceptual integrity, which in turn determines the system's overall quality. A well-thought-out architecture provides the structure needed to maintain system-wide conceptual integrity. Good architecture makes design easier. Bad architecture makes it nearly impossible.
Making changes to the architecture during design and subsequent stages is expensive. The time it takes to fix a bug in the software architecture is comparable to the time it takes to fix a bug in the requirements, i.e., exceeds the time spent on fixing a bug in the code. Architecture changes are similar to requirements changes in that seemingly minor changes can have far-reaching consequences. Whether architectural changes are due to bug fixes or improvements, the sooner you recognize the need for them, the better.
The result of our work
- Requirements for development, testing, and validation;
- A detailed description of the system that correctly solves the set business tasks;
- Scheme of the designed and implemented software architecture with a description of each microservice and infrastructure element;
- Optimally selected technologies for each microservice;
- Structured content of functional and non-functional requirements.