SPE Nonfunctional Requirements

Nonfunctional requirements define the performance and scalability goals for the business that are needed by the Architecture and Development teams.

Nonfunctional requirements define the performance and scalability goals of your application. They include a defined response time goal for key business transactions.  These transactions are what your customers will do on your web site, their user profile, or behavior.  The system must respond quickly and not slowdown the workflow or user experience. For instance, transactions types are; account history (what have I purchased this year), place product in shopping cart, and of course the check-out process. The actually numbers for the response time can vary by application and transaction. Each transaction must have a number assigned to it from a sliding scale of user experience (from the industry group Application Index or ApDex);

1)      Satisfied

2)      Tolerating

3)      Frustrated

4)      Abandonment

The user business transactions are important, however, we cannot forget about batch type business transactions.  These are programs supporting the application that run without user interaction.  These can run in real-time or many are still scheduled in a nightly batch window of processing. For example, your may have to match all the health insurance claims to the payors.  The NFR must be defined in terms of transactions per section to support the business goals.  How soon must the information be made available to the application? Is there a real-time component where the claim must be processed as soon as it arrives? How many arrive in a given minute? Or does 500,000 claims arrive at 8:00 PM EST and must be available for the business by 2:00 AM for further processing?

Requirements phase

The key business transactions must be defined and assigned a response time goal for the expected number of users for average load, peak loads, and the extreme.

The application volumetrics should be defined;

1)      User population goals – What is the total expected user population and how does it change over time (quarter to quarter)?

2)      User behavior and profile: The application must support 2,000 concurrent users with a satisfied response time of 2 seconds or less.

  • How many people will be on the web site during an average day or average hour?
  • What is your expected peak number of concurrent users?
  • Is there an extreme peaking factor? Does the business support flash marketing events?
  • Are there weekly, monthly, quarterly, year-end or seasonality that impact the user concurrency?
  • How is a processing day defined? (24, 12, 8 hours?)

3)      Workflow processing – How soon must information be available for the next step in the workflow for a business process? This is directed towards real-time messaging systems or batch processing. For instance, once a prescription is entered, how soon should it be available for filling and adjudication steps?

  • Real time message processing – Are there messages or work, arriving from other applications, how quickly must they be processed? Instantaneously, seconds, minutes or next business day? These should be rated in messages or transactions per second.
  • Batch processing – Batch can be run during the business day or during a nightly processing window. The overall batch process must have transaction per second goal and the individual programs must have a TPS rating. For instance, we must convert orders into invoices at a rate of at least 15 per second.
  • Movement to other systems – Many operational system move records into a Data Warehouse for analytics or retention. Is there a requirement on how quickly the records must be replicated into the Data Warehouse?

4)      Historical information – How long must key business information be retained? Many industries are regulated for records retention or have policies on retention.

5)      Key business transactions – These must be identified with performance requirements.

  • The business can establish general guidelines that apply to most transactions.
  • Specific business transactions must be identified, especially if there is an SLA’s in place with a contract.  Penalties can be incurred if the SLA’s are not met for some period of time.

This information must be communicated to the architecture and design team.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: