You Tube Channel: https://www.youtube.com/@brrknowledgecenter

There are two types of requirements for  software projects: functional and non-functional requirements. Functional requirements are the requirements for what the solution must do (which  are usually expressed as use cases or stories). The functional requirements are what the users (or systems) that interact with the system do with the system (fill in an order, update customer details, authorize a loan etc.). Non-Functional requirements are attributes the system is expected to have or manifest. These usually include requirements in areas such as performance, security, availability etc. A better name for non-functional requirements is “Quality Attributes” . Below are some formal definitions from IEEE standad 1061 “Standard for a Software Quality Metrics Methodology”  for quality attributes and related terms Quality attribute: A characteristic of software, or a generic term applying to quality factors, quality sub factors, or metric values. Quality factor: A management-oriented at

The Architecture Tradeoff Analysis Method (ATAM) is a method for evaluating software architectures relative to quality attribute goals. ATAM evaluations expose architectural risks that potentially inhibit the achievement of an organization's business goals. The ATAM gets its name because it not only reveals how well an architecture satisfies particular quality goals, but it also provides insight into how those quality goals interact with each other—how they trade off against each other. ATAM Process Business drivers and the software architecture are elicited from project decision makers. These are refined into scenarios and the architectural decisions made in support of each one. Analysis of scenarios and decisions results in identification of risks, non-risks, sensitivity points, and tradeoff points in the architecture. Risks are synthesized into a set of risk themes, showing how each one threatens a business driver. The ATAM consists of nine steps : Present the ATAM . T

Never use the same ASPState database for two different web applications or sites. The stored procedure tempresettimeout is called on every request and this can be madness on a high volume/many pageviews per visit site.  There is a deleteexpiredtokens stored procedure that kills the performance under load.  Found that a DELETE statement was the main culprit in DeleteExpiredSessions stored procedure. Looking at it, it seems applying delete operation on same table CREATE PROCEDURE DeleteExpiredSessions AS   DECLARE @now DATETIME   SET @now = GETUTCDATE()   DELETE ASPState..ASPStateTempSessions   WHERE Expires < @now   RETURN 0 GO However, the problem is that as session size grows, each delete takes longer and as the number of sessions grows, this simple DELETE ends up causing substantial blocking. It was at the head of nearly every blocking chain. This proc is run every  minutes. There is no need for this proc to do all the deletes in a single ope

Running your ASPState database in a SQL Always On Availability Group provides redundancy in case there is a SQL server failure. Unfortunately the default process for setting up the ASPState database does not take this configuration into account and you may find that your ASPState database has an ever expanding data file that is using all of your disk space. When the ASPState database is created, there is also a SQL Agent job that is also created which deletes expired sessions to keep the database size at a reasonable level.  This job is usually called: ASPState_Job_DeleteExpiredSession In the usual setup, this job runs every minute and simply fires of a Store Procedure which lives in the ASPState database itself using the following T-SQL statement: Execute DeleteExpiredSessions Generally this all works well. The issue arises when the Availability Group is failed over to a secondary availability replica. Because the SQL Agent job is not present on this server, the expired

ASR (Architecturally significant requirements) are those requirements that play an important role in determining the architecture of the system.  Such requirements require special attention. Not all requirements have equal significance with regards to the architecture. Architecturally significant requirements are a subset of the requirements that need to be satisfied before the architecture can be considered "stable". Typically, these are requirements that are technically challenging, technically constraining, or central to the system's purpose. Furthermore, the system will generally be more sensitive to changes against architecturally significant requirements, so identifying and communicating this subset will help others understand the potential implications of change. Requirements can be explicitly or implicitly architecturally significant. Explicitly significant requirements are often overtly technical in nature, such as performance targets; the need to inter