Explain how an architect can determine qualitative requirements.
Architecture and Qualitative Requirements
An architect translates the concerns of stakeholders into requirements by identifying the "quality factors" valued by each constituency. You have probably experienced quality factors yourself when using a system.
Is the system reliable?
Is it fast?
How many concurrent users can the system handle before response time drops off?
What makes a system good or good enough?
Who is asking?
Software quality is improved by separating concerns into tiers.
Fourth-generation Web Application
Most of the software has been moved to the application server. Large websites implement the application server as a collection of application servers that operate in parallel. Likewise, web servers are often clusters of computers that work together to serve requests from large numbers of users.
Application servers interact with one or more database servers, often running a commercial database such as Oracle or DB2. The client–server interaction uses the Internet. The Web servers and application servers are connected by middleware
(such as Corba), which are packages obtained from software vendors to handle functions such as communication, data translation, and process distribution. Middleware is sometimes as simple as (JDBC) Java Data Base Connectivity, whereas other middleware packages are large and solve complicated problems. Likewise, the application-database servers often interact through middleware.
Figure 2 -6 illustrates a typical configuration for a fourth-generation Web application.
Web Software Engineering Quality Factors
Although software engineering researchers, educators, and practitioners have spent years focusing on developing processes and technologies to improve software quality attributes, much of the software industry has had little motivation to improve the quality of their software.
Software is often sold with relatively low-quality requirements.
The combination of 1) user expectations and 2) market realities has been such that increasing quality usually has not increased profits.
A combination of time-to-market and marketing strategies has almost always determined whether traditional software products succeed competitively.
As an example, software contractors for government agencies are often paid the same regardless of the quality of the delivered software. Despite the positive impacts of the capability maturity model, many contractors are still given additional resources to correct problems of their own making.
Commercial software companies are usually driven almost entirely by time-to-market.
It is almost invariably more lucrative to deliver poor-quality products sooner than high-quality products later.
It is a well-known truism that companies can often sell poor-quality first versions of software applications and then make more money by charging for upgrades that contain more bug fixes than new features. For most applications, there has traditionally been little economic motivation for producing high quality software. In fact, there have often been economic disincentives for creating high-quality software products.
These quality factors ultimately translate into quantitative requirements. They are the performance metrics by which the solution is evaluated.
The architect must manage trade-offs between ideal quality requirements and other factors such as schedule, cost, or feasibility.
For example, high availability is a quality factor often sacrificed to cost and schedule considerations. Achievement of 99.99 percent availability usually presents a cost burden few organizations are willing to bear. But 99.5 percent availability may be good enough. Architects can explain the impact of these alternatives on the business. They can also determine whether the investment to achieve the higher availability is cost-justified.
As mentioned earlier, "The extra effort and expense associated with architecture almost always results in lower downstream operation costs."
By identifying quality factors up front, the architect prevents conflicts later on conflicts which often result in re-design, delays, and a potentially unhappy client/customer. It is often difficult to determine quality factors, for the following reasons:
Quality is a moving target. In e-Business the bar is raised weekly, sometimes daily.
Are we adding new products and services as quickly as we can?
Some quality factors are unique to e-Business. How secure does it need to be? What is the penetration risk?
Some quality factors are not very intuitive. Is your portal site similar to Yahoo, AOL, MSNBC?
The architect articulates a common vision based on the quality factors important to each stakeholder.
In so doing, she provides some insurance against the evolutionary nature of the e-Business world.