What’s My Function… or Is It Non-Function?

January 27, 2017 | , ,

One of the substantial differences between an architect and a software developer is regarding requirements. In general, a developer is concerned with functional requirements while an architect is concerned with non-functional requirements. Of course, there is some overlap between each requirement type and the type of person focusing on each, but that is generally how it’s divided.

In general, functional requirements describe what the system or application should do. For example: a particular application may need to:

  • Send data to another system once per day
  • Collect name and address from users
  • Display an error on the screen when all data fields are not filled in

We’ve all seen requirements like this and a software developer would write the code to perform those functions. Very often, what we don’t see is many (or any) nonfunctional requirements documented. It’s up to us as architects to help flush those out. Not taking them into account will often have an adverse effect on the project as they are not usually seen as missing until very late in the project or ever after the project has been implemented, since almost everyone else is concerned with an application’s functionality.
Non-functional requirements describe what the system should be not what it should do. Some well-known examples can be shown like this:  “The system shall be:”

  • Scalable
  • Extensible
  • Resilient
  • Maintainable
  • ….

An application would have its own specific needs for each nonfunctional requirement. For example, the scalablility design needed for a once-a-day batch application is different than a financial company’s web-hosted front-end used by its customers. As an architect you need to have an understanding of both to design the correct solution for each. For example, the number of transactions in a web-based investing application can vary widely based on external events such as major fluctuations in the stock market or time of year.  Related to that, the spike in online transactions means that the application may face processing issues with its nightly batch job.  Design considerations to make sure each can scale to meet the processing needs are different for each but nonetheless required and must be thought through by you, the architect.

So on your next project, make sure you:

  • Have a list of non-functional requirement handy.
  • Do the proper digging to understand which ones should be in scope.
  • Work to get the proper design for for each.
  • Make sure they are documented and tested.

Being on top of the non-functional needs of your project will give you the peace of mind knowing that the application(s) in scope will be able to withstand external influences and continue to perform its “function”.

If you could use some assistance eliciting non-functional requirements or designing for them, contact us!

The following two tabs change content below.
Jim Sweeney
My LinkedIn profile

Jim Sweeney

is a consultant with Systems Flow, Inc. Over his 25-year IT career, he has worked with some of the largest companies in the financial services and insurance areas. His experience runs from hands-on (Java, C++ and C#) to application and solution architecture. He has led many small and large projects to successful completion, and enjoys working with his business partners to achieve their goals. Jim has a BS from Northeastern University in Management Information Systems and a MS in Computer Science from Boston University. Jim's LinkedIn profile has the whole scoop on who he is and what he's done.


Comments

Comments are closed.