pdfcoffee.com-systems… q G
Figure 5-14 Agile versus plan-driven assumptions regarding the value of BRUF 5.6.2 Non-functional Requirements: The Key Determinant of BDUF Non-functional requirements pertain to the qualities of the system that are not specific to a business or industry. For example, let’s say we determine that a system needs the following:
• Supports up to one thousand users simultaneously, with the ability to scale to five thousand users without major technical changes. • Avenges response times under two seconds under full load during normal business hours. • Needs 99.9 percent uptime during normal business hours.
• • Designed so that it can communicate via standard internet interfaces called “web services” to twelve other systems. • • Implements security mechanisms to protect confidential customer data, including web applications exposed to the public intemet. • • Integrates a new workflow component enabling automated routing of items between users and business locations via software-driven business rules.
This seems clear enough. But what industry or company are we talking about? From these points alone, there is no way to know—they could pertain to retail, manufacturing, financial services, energy, education, and so forth. That is what makes these non-functional requirements: they don’t speak to functionality that is specific to a particular industry or business.
As noted previously, while the BA needs to assess non-functional requirements, addressing many of these in detail may involve working with a technical specialist. This could include involving an architect, senior development lead, security specialist, data communications network engineer, and so on. As such, here we briefly explain these items and their impacts.
As each of the following factors increase, so does the need to perform architectural planning via big design up front (BDUF):
• Performance: This defines how much work the system must be able to effectively support. This can be expressed in terms of users, transactions, data volumes, and more. This is often coupled with speed metrics, such as average response times or transactions processed per hour. Importantly, performance requirements are often stated in terms of an initial expectation and the ability to scale to higher levels without major changes in technical architecture. A relatively simple example of this is a database application built using a single-user tool such as Microsoft Access. This application might have complete and effective features for one (or a few) users. But there is no way we could scale this to, say, one hundred users without moving to a different technical environment. A meatier example would be a website that can support one hundred users simultaneously in a single country but needs a significantly different architecture to enable scaling to tens of thousands of users on multiple continents.
Performance
The amount of work a system must perform in terms of volumes of users or transactions. Typically includes speed and reliability metrics.
• Supportability: This involves designing the system to ensure that changes such as reconfiguring tables of values and adding new software features can be implemented easily over time. The former is called maintainability and the latter is called ertensibiliry. The degree to which this is necessary depends on where the system fits in the overall set of applications in an organization (which is called the application portfolio). For example, consider a system that will be used far into the future and that will likely need significant investments to extend its capabilities over time. Supportability requirements f h ‘II h