The Community Blog for Business Analysts

Peter
Peter

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

COMMENTS

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.



Modern Analyst Blog Latests

Jarett Hailes
Jarett Hailes
As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
2 Responses
Howard Podeswa
Howard Podeswa
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
12 Responses
Adrian M.
Adrian M.
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN
1 Responses
Featured Digital Library Resources 
Copyright 2006-2015 by Modern Analyst Media LLC