The Community Blog for Business Analysts


When is Security not a Non Functional Requirement?

If you are building a reusable Security Product tool to specifically address Security Technical Implementation Guide (STIG)  Findings, should the requirements be considered Non Functional Requirements or Functional Requirements?

For example if there are a number of STIGs such as:

  1. The minimum password length shall be 15 characters
  2. The maximum password length shall be 30 characters
  3. The password shall contain at least one of each of the following types of characters
    1. Numeric Character
    2. Uppercase Alphabetic Character
    3. Lowercase Alphabetic Character
    4. Special Character (!,@,#, etc.)
  4. The password shall be changed a maximum of every 60 days

 should I add them to the Functional or Non Functional section of my Requirements Document.

Add your answers and thoughts in comments below:

This entry was published on Aug 22, 2017 / Peter. Posted in Functional Specifications, Business Analysis. Bookmark the Permalink or E-mail it to a friend.
Like this article:
  1 members liked this article

Related Articles


Karl Wiegers posted on Tuesday, October 10, 2017 4:52 PM
Peter, I think items 1 through 3 in your list are data definitions about the exact properties of the data element called 'password.' Those will lead to functionality needed to test whether a valid password is entered, what to do if it is not, etc.

Your item #4 is actually a business rule, a policy regarding security concerns on this system. That should lead to a number of derived functional requirements, such as what the system does if the user's password has not been changed in the past 60 days.

The BA's job is to derive all the necessary functionality descriptions needed for the system to comply with these data definition attributes and relevant business rules. If the specified requirements stopped with this sort of information, you're just asking someone else, like a developer, to figure out just how to handle those password validations and password change behavior. Someone needs to make those choices.
GregArkansas posted on Thursday, March 8, 2018 12:03 AM
Indeed. I agree with Karl. The example you served is largely an example of what does not constitute a functional requirement. Though in principle you question should be answered YES. If the main functionality of reusable product is providing security the functional requirements are a MUST.
In the requirements one needs to specify what the tool DOES.
Derived from the requirements Functional Designs might elaborate on implementation details.
GregArkansas posted on Thursday, March 8, 2018 12:16 AM
For example functional requirements would be:
- System must have a capacity of maintaining 26 billion active accounts.
-System must provide security 1, 2, 3 level logins..
where level 1 is...
level 2 is..
level 3 is
- system must support 12 million concurrent sessions

From the above requirements you derive first the Architectural Design, High Level Designs, and finally Detailed Functional Designs ( though some would say Architecture is a part of HLD ).
GregArkansas posted on Thursday, March 8, 2018 12:30 AM
In your question you brought an excellent point: what is and what is not functional depends on the context or scope of the project.
In your example 60 days is a policy . But the fact that the system must support expiring of accounts is a functional requirement.
Only registered users may post comments.

Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.

Copyright 2006-2019 by Modern Analyst Media LLC