Comment lines: Botzum, Brown, Hambrick: Why do non-functional requirements matter?

Functionality is important, of course. But if you don't consider non-functional requirements, then your solution could very well be practically useless.

Share:

Keys Botzum, Senior Technical Staff Member , EMC

Keys Botzum is a Senior Technical Staff Member with IBM Software Services for WebSphere. Mr. Botzum has over 10 years of experience in large scale distributed system design and additionally specializes in security. Mr. Botzum has worked with a variety of distributed technologies, including Sun RPC, DCE, CORBA, AFS, and DFS. Recently, he has been focusing on J2EE and related technologies. He holds a Masters degree in Computer Science from Stanford University and a B.S. in Applied Mathematics/Computer Science from Carnegie Mellon University. Mr. Botzum has published numerous papers on WebSphere and WebSphere security. Additional articles and presentations by Keys Botzum can be found at http://www.keysbotzum.com, as well as on IBM developerWorks WebSphere. He is also co-author of IBM WebSphere: Deployment and Advanced Configuration.



Kyle Brown, Senior Technical Staff Member, EMC

Kyle Brown is a Senior Technical Staff Member with IBM Software Services for WebSphere. Kyle provides consulting services, education, and mentoring on object-oriented topics and J2EE technologies to Fortune 500 clients. He is a co-author of Enterprise Java Programming with IBM WebSphere, the WebSphere AEs 4.0 Workbook for Enterprise Java Beans, 3rd Edition , and The Design Patterns Smalltalk Companion . He is also a frequent conference speaker on the topics of Enterprise Java, OO design, and design patterns.



Geoff Hambrick, Distinguished Engineer, EMC

Geoff Hambrick is a lead consultant with the IBM Software Services for WebSphere Enablement Team and lives in Round Rock, Texas (near to Austin). The Enablement Team generally helps support the pre-sales process through deep technical briefings and short term Proof of Concept engagements. Geoff was appointed an IBM Distinguished Engineer in March of 2004 for his work in creating and disseminating best practices for developing J2EE applications hosted on IBM WebSphere Application Server.



18 January 2006

From the IBM WebSphere Developer Technical Journal.

Remember the real world

At one time or another, each of us has become absolutely spitting mad because we've read an article or a book or seen a presentation that we felt was incomplete. In each case, somebody discussed some aspects of a set of technologies, solutions, and options, but then ignored a crucial issue: non-functional requirements.

Granted, functionality is important. After all, if you can't show that the system you're building does what you want, then who cares? But while it's all well and good to come up with a new, clever, simpler, prettier, or more elegant approach to solve some problem, if you don't consider non-functional requirements, then your solution may actually be useless in practice.

We've all seen plenty of reasonable solutions that turned out to be absurd when you actually considered how to make them work in the real world of big systems being managed by real people who are very busy. The cause of these disasters is discounting or ignoring the system's non-functional requirements.

Non-functional requirements are those that don't necessarily address "I want my system to do this," but instead address "How do I make this system work in the real world". Some of these real world issues that you rarely hear people mention are:

  • High request volumes for online systems: Lots of users, all at once!

  • Overburdened administrators that have to deploy your applications: In the real world, an administrator will deploy each application more than once - and then have to monitor each one after deployment.

  • Administrators that make mistakes: Most of us are human, after all! While it's theoretically possible to perform 100 manual deployment steps perfectly, in the real world that just doesn't happen.

  • Annoying script kiddies and real, honest-to-goodness crackers that attack our systems: Security matters!

So, what are non-functional requirements? There are a number of good definitions available, but we'll start by looking at the ISO 9126 list of Software Characteristics; aside from (of course) functionality, these characteristics include:

  • Reliability

    It's not enough to show that your system can do something once. If a system does not work reliably (for instance, while under load, or when systems fail, and so on), then it's not going to serve the customer's needs.

    Some questions to ask yourself are:

    • Can this run reliably even when there are hardware failures?
    • What about replication and failover scenarios?
    • Is manual intervention needed, or can the system failover automatically?
    • Will implementing reliability negatively impact performance?
    • How much will implementing reliability cost?

    Some special aspects of reliability to consider are:

    • Security: Assume that attackers are out there. How do I know that the user of the system is who they say they are and only give them access to authorized functions? How do I protect my system from attack? Think about network attacks, machine attacks, and even attacks from within your own systems.

    • Transactionality: How is the system designed to preserve the ACID properties of a unit of work? This is especially important if multiple independent subsystems are involved in your design (as is the case with Web services and SOA). Do not assume that two phase commit is always possible.

  • Usability

    If your users cannot easily access your product from the channels they have available (like the Web), then what good is it? This is sometimes considered part and parcel with functionality (or should be in a perfect world), but is often ignored to the peril of the project as a whole. Some issues to consider here are:

    • Are you placing undue burdens on your users (for example, requiring special browser versions)?
    • Has the system been designed according to a Model-View-Controller architecture to make multiple user interfaces possible? If so, how are they bound together?
    • Is the interface inherently stateful while the functions are stateless (or vice versa)?
  • Efficiency

    The most functional, reliable, and usable system will ultimately fail if it does not make efficient use of its resources (like processors, memory, and disk space). We've often found it useful to split efficiency into two sub-areas, both of which deserve consideration:

    • Performance: How well will this system perform? Is it just plain slow? Can the system meet its response time goals? Is the application designed for performance? Do you take advantage of caching?

    • Scalability: If the system seems reasonably fast in the small, how well will it scale with thousands or hundreds of thousands of activities per second, minute, or hour? How is it designed to meet the throughput goals? Can I replicate the systems to achieve linear scaling? Are there bottlenecks (like a common database)?

  • Maintainability

    This is a vitally important requirement because if the developers, administrators, and operators cannot figure out how to manage the application, then it won't live past the first release. Let's assume you are an administrator tasked with having to run this thing. How do you configure it? How do you monitor it? What if you have to do things many times (for example, install dozens of applications)? Do you have a reproducible deployment process? Can you automate repetitive tasks to make it feasible in the large

  • Portability

    Although last on the list, it's certainly not the least important. For instance, how are standards employed to provide some form of platform neutrality? Do you have a plan for moving applications to the latest and greatest version of your application server? If not, what do you do when the vendor withdraws support for that version? Similar issues come up if your project is based on open source. If you have to rewrite the whole application every time somebody comes up with a better mousetrap, no one will beat a path to your door.

In a perfect world, we would hope that every article, paper, Redbook, slide presentation, and system design would address these important issues head on. They matter. Tradeoffs almost always have to be made that should be explicitly called out so that you can determine if a specific design will meet your needs. If you are reading something that doesn't address these issues, consider this our warning - something important has almost certainly been overlooked. If you are an author, consider this our plea: don't ignore these issues!

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere, Sample IT projects, Architecture
ArticleID=102079
ArticleTitle=Comment lines: Botzum, Brown, Hambrick: Why do non-functional requirements matter?
publish-date=01182006