Design, build, and test specifications are key outputs of this phase. These specifications can be service-specific or at the domain level. Test case scenarios and test cases are also important outputs of this phase which helps with the traceability of the non-functional requirements from gathering to realization. Non-functional requirements engineering, design, and build as well as testing help with the implementation of solutions that meet or exceed non-functional requirements. Non-functional requirements engineering includes:
- Non-functional requirements engineering, such as performance engineering
- Design for non-functional requirements, such as designing for availability
- Building with non-functional requirements building blocks
- Testing for each non-functional requirements test case
Standards-related specifications are a key part of this phase and the next phase. Several standards organizations provide documented specifications that are very relevant for re-use during the engineering and operating phases of the NFR life cycle.
When the NFRs are adequately refined, software architect will be able to identify possible solution for architecting these NFRs for the target state. The development techniques are the methodology for arriving at the target state. However, there may be a gap between NFR goals and solution methodology and one must bridge the gap to get to the destination. This involves extensive analysis and handling various factors. These include priorities, ambiguities, tradeoffs, and domain information including the workload of the organization. These factors will have to be addressed in the entire process chain.
An alternative to providing optimum response time is to leverage indexing. Indexing is a database design methodology for optimum response times. Indexing will helps meet the NFR goals for response time. Also leveraging uncompressed format will make a positive influence on establishing the response time. Indexing or uncompressed format are the best alternatives for achieving good response times.
Framework will aid the search and solutioning of NFRs. The progression from NFR goals to solutioning is a key step in the design process because NFRs needs to be converted into implementable entities. However, it may not be possible to convert initial requirements into a concrete solution definition in one step. There will be iterative refinements and expansions steps. Furthermore, software architect needs to carry-on identifying development techniques alternative and finalize them.
We need to emphasize on meeting the NFRs goals priority. Priorities may come up from attention of several factors. These include domains such as priorities and load capacity. In addition, requirements may be identified as priorities during different development steps. Few priorities will be designated as critical, as they are the key to the success of the business or organization goals. Others will be defined as prevailing, as they form a significant portion of the organization's workload.
After identifying the priorities, it will be analyzed and operationalized. For example, priorities may be leveraged to decide appropriate tradeoffs for NFR business goals. Information about the tradeoffs is documented, and made available for dealing with conflicts and collaboration. Thus throughout the development methodology, different tradeoffs considerations are made and rationales established.
During the analysis and solutioning process, choices are made to achieve a particular NFR, it is highly possible that some other NFR gets affected, either positively or negatively. These interactions are critical because they have a bearing on the decision process for achieving the overall NFRs. They may either have negative or positive impacts but will be managed in a variety of ways and documented in the design specifications.
An essential technique about the framework is that design decisions must be supported by well-justified rationale or decisions. Rationale will be established for making refinement or choosing an option. The solution process will continue till various options for the target state are sufficiently established, and no other options are conceivable. During the entire process, the architect will review the NFRs, domain, and will address ambiguities and trade-offs.
The architect then considers possible solution definition, design rationale, and dependencies, using knowledge from the past. Early decisions may need to be taken into account when making decisions. This information is documented and is available to help the architect decide among the alternatives. The architect will drive the decision making to finally arrive at the target system architecture. In order to produce a target state, the architect has to choose from the possible operationalizations or options. Additionally, correct design rationale should be determined and documented. There will be various choices for operationalizing NFR goals of those identified alternatives; some are chosen, while the others will be rejected.
All the architecture and design decisions are considered to establish the impact. The evaluation of design decisions emphasizes the fact that a chosen option is good for the target architecture. This methodology of reasoning will be correct for dealing with NFRs as meeting these NFRs is often a matter of degree.