In this article, I aim to give detailed information about the A-Spice SWE.2 Software Architectural Design process, but first I would like to start by thanking everyone for the extraordinary interest in my previous article.
I will explain clearly what needs to be done regarding the SWE.2 process, which I think is the most confusing issue for my clients, through base practices.
Software design is a process based on requirements. Therefore, a company that cannot carry out the SWE.1 Software Requirements Analysis process properly cannot be successful in design.
In order for the design process to be applicable, design tools must be used and the UMLs drawn must be simple to understand and consistent with the requirements.
SWE.2.BP1: Develop software architectural design:
To ensure this base practice, what needs to be done is to create a primary design.
While you can do detailed design and primary design in a single document, you can also create a software architectural design document. In addition to this document, the use case document and user interface document should also be written, these documents are primary design documents.
When creating these documents, the first thing to consider is to separate the software components and units at a hierarchical level and with respect to functional and non-functional software requirements.
Software Architectural Design Document content;
- Architectural overview
- System overview (Software components, relationships between systems to which system components are connected or communicate)
- Software unit component definition, relationship and dependencies (many to one..)
- Inter-task/inter-process communication
- Physical data storage model
- Code to be developed or supplied
- Dynamic behavior (Activity, Sequence, State Diagram) if any
In addition, the Use Case Document, which is another document that needs to be made, includes;
It is the drawing of use case diagrams in accordance with the software requirements. The thing that should not be forgotten in these drawings is that after explaining the general structure, the use cases should be drawn in such a way that no requirements on an actor basis are left open. It is definitely about establishing traceability. (I will explain this in detail in BP.7)
In the User Interface Design Report, which is another annex to the primary design document;
Mock ups must be drawn in accordance with the software requirements. It is important to draw mock ups on an actor basis, as well as to provide information about each field in each interface, including workflow information, business rules information, and pre- and post-condition information. In this section, it is necessary to establish traceability through interfaces. (I will explain the concept of traceability in detail in BP.7, and detailed information about the user interface in BP.3)
SWE.2.BP2: Allocate software requirements
In order to achieve this base practice, which requires us to allocate software requirements to the elements of the software architectural design, the design must be made in a way that no requirements are left open.
While doing this, in the design document;
- Is UML drawn to cover the entire requirement?
- Are Use Cases cover the entire requirement?
- Are Interfaces cover the entire requirement?
- Have the Component/Unit been defined so that the requirements are not left out?
In fact, this control is provided by traceability.
The design must be consistent with the requirement.
SWE.2.BP3: Define interfaces of software elements
In order to provide this base practice, an Interface Design Report must be created. I should point out here that not every software has to have an interface, in these cases this document does not need to be defined.
While preparing the Interface Design Report, the mock ups that will be created must be drawn based on the requirements and taking into account each element of the software to be created.
While drawing mock ups, screens should separate on an actor basis. As well as you should define field information about the screen (obligation status, type, field description), information about the functions on the screen, rules and restrictions.
MOCK UP EXAMPLE
Again, one of the most important issues that should be included in the Interface Design Report is traceability. This traceability must be between mock ups and requirements.
SWE.2.BP4: Describe dynamic behavior:
Here it is necessary to define the dynamic behavior (if any) of software elements in order to meet the required behavior of the system.
What needs to be done for this is to draw activity diagrams, sequence diagrams and state diagrams.
SWE.2.BP5: Define resource consumption objectives:
Specified in the Requirements Document; To determine the usage targets of hardware requirements (server and client (RAM, ROM external / internal EEPROM)), software requirements, ethernet requirements, CPU requirements and all resource usage requirements for the operation of the software product, and define them in the Design Document.
SWE.2.BP6: Evaluate alternative software architectures:
The Aspice standard requires proof of why the architectural design chosen was chosen. For this reason, we can use the Alternative checklist when making an architectural choice to answer the question of whether all alternatives were evaluated. Evaluation criteria for this alternative checklist to verify our choice may include quality attributes (modularity, maintainability, extensibility, scalability, reliability, security implementation and usability) and the results of the build-buy-reuse analysis.
SWE.2.BP7: Establish bidirectional traceability:
When establishing two-way traceability, we should use tools such as the ones I explained in the previous article, which will allow us to both do traceability correctly and ensure continuity. Tools can be Doors or Jira. If you use Confluence, using Jira is much more suitable for traceability. Being able to code traceability in Jirada will make your job easier in the future.
It means creating traceability between Software Requirements – Architectural Design;
- Software Requirements – Use Cases
- Software Requirements – User Interfaces
- Software Requirements – Component/Unit
- Software Requirements – Activity or Sequence It is the existence of traceability between diagrams.
In my previous article, I showed the traceability plug-in for Jira. In the image below, I show the matching of Use Cases and Mock Ups documented on Confluence with Epic. So, if you have written a use case document on Confluence and numbered the use cases uniquely, you can match it with the requirement in Jira, so that the team member assigned to the requirement can access the relevant title in the design document with one click.
Gamze Dağloğlu
