15 Areas to Think About When Writing Non-Functional Requirements

Non-functional requirements should be defined when you are also creating and writing functional requirements. These are requirements that detail the constraints and quality standards that the system you are building should adhere to. You can find out what these non-functional requirements should be by your experience, interviews, and industry standards. Also, you can use functional use cases to try and discover what non-functional requirements should be.

Here are some areas that you should have in your non-functional requirements document:

1. Reliability - Reliability is the chance that the system processes work correctly without being aborted. Some of the potential resulting losses that you should consider are:
   • Complete or partial loss of the ability to perform a mission-critical function
   • Loss or corruption of data Loss of user productivity
   • Time between failures
2. Recoverability - Recoverability is the ability to restore function and data in the event of a disaster, either natural or man-made. Recoverability ensures that if any kind of system failure occurs, regardless of the reason, the system will operate with minimal interruption. You should think about:
   • Where backup copies of the system and data held within it will be stored
   • Discuss plans to have a Continuity of Operations Plan (COOP) and procedures for the system
   • How soon after a failure is detected must function be restored
   • How soon after corruption is detected must function be restored
3. Data Backup/Restore – Data Backup/Restore is a measure of how frequently data is backed up and the speed of data restore from backup. You should think about:
   • If the hardware, data, and onsite backup are destroyed, how soon must the application be restored
   • Do you have another site that has a full backup of the data?
   • How many backups do you have?
   • If one server goes down, how many backup servers do you have?
4. Availability – System availability is the time when the application must be available for use. Required system availability is used in determining when maintenance may be performed. Definitely think about time zones, schedules, and user location.
5. System Maintenance – There should always be regular system maintenance.  You should think about how much time you need to do maintenance, and how and when you will notify users.
6. Performance – Performance details the way the system will perform for users. Think about:
   • What is the response time for reports, queries, and updates?
   • What is the total number of user sessions open for the entire application?
   • What is the total number of concurrent sessions that can be opened by a single user?
   • What is the total amount of idle time before the user session is forced to terminate?
7. Usability – Usability is the system support of the execution of user tasks (i.e., presentation of information and management of user interaction). Think about:
   • How easy it is for user to learn the system
   • How easy it is for user to memorize steps
   • How efficient is the system
8. Visibility – Visibility discusses how the system looks to user.  Is it easy for them to see the font, screens, reports, etc.
9. Data Retention - Data Retention details the length of time that various data will be retained in the system.
10. Fault Tolerance – Fault Tolerance is a measure of how well the system can maintain normal operations when defects are encountered. Think about:
    • How every threat will be identified
    • How will you warn the user
    • Will you disable the feature
    • Will you remove the feature
11. Maintainability – Maintainability is a measure of how easy it is to correct defects in the software.
12. Interoperability – Interoperability is a measure of how easy it is to integrate the software with other systems.
13. Error Handling – Error Handling will be in place to respond to reports of security flaws in the system. Reported vulnerabilities must be tracked throughout the process to ensure they are triaged, corrected, and tested. When a security flaw is discovered in an application deployed in a production environment, notification to users must take place as quickly as possible.
14. Threat Modeling – Threat Modeling is the process of identifying potential threats to the application, risk ranking these threats, and selecting appropriate countermeasures or mitigations for the threats. Threat modeling is a critical step in securing an application from attack. The threat model will be reviewed for each application release and updated as required to reflect the changes in application design and functionality. As potential threats are discovered and the implementation details of the application become known, the threat model will be updated.
15. Reusability – You should think about having a system that parts of it can be easily reused in other systems.  This will save the company them and money in future projects.

What are some of the non-functional requirements you think about when designing a system?

Questions to Ask Yourself When Collecting and Writing Security Requirements

Security is one of the most important things to consider when developing any type of system. There are numerous malicious attacks that could happen at any time that you have to ensure that your system is protected. The first step in doing this is thinking and developing the requirements that will drive the way your team and you handle anything that comes your way.

Security requirements are important because you will have sensitive data contained within that you need to protect. We have seen in the past how hackers have been able to collect users’ identities, financial records, Social Security numbers, and the list keeps going.

One thing that companies fail in doing is taking the time to research, analyze, and collect security requirements before developing a system. This is always an error because then you spend more time trying to patch up the things you didn’t foresee. I have been collecting requirements for years, and I have noticed that when done correctly, you usually build a good, stable system

Security Requirements are usually part of the overall Functional Requirements Document or Security Requirements Specifications. There are times that people will build a separate Security Plan, but usually it’s within one of the two documents named above.

The four major areas that you should consider when collecting and writing security requirements documents are:

1. User Management
2. Data Management
3. Access Control
4. Auditing

User Management

When developing a system, there are usually users who will be accessing the system. The main questions to answer are the following:

• Who are the people that will be accessing the system? Will they be frequent users? How do they relate with one another?
• Do these users have different levels of classification, if it applies?
• What will be the user roles used in the system?
• How will you authenticate these users? How are you going to manage passwords?
• Who will have manage these users? What are the security guidelines that these people have to follow?
• What kind of checks will have you in place to ensure that there is no security breach?

Data Management

Next, you should consider how you will protect the data maintained in the system.  You should think about these points when thinking about data management:

• Does the data have different classification levels?  How will you handle the difference in data sensitivity?
• How will you control access to data? What are the different ways that you will?  How do they relate with one another?
• How is data collected? What safeguards will be in place when users are entering data into the system?
• Will the system have encryption? If so, what kind of encryption will it have? When will encryption be used?
• What kind of data validation will be performed?

Access Control

Access Control is how users will interact with the data.  It is probably the most important section because usually issues with access control is why attacks are usually successful. Here are question to ask yourself when thinking about access control:

• Will there be remote access to the system? How is remote access handled?  How will you secure users remotely accessing the system?
• How will you secure different control points into the system?
• What kind of physical access controls will be in place? How will you manage it?
• Who can access what kind of data? What kind of rights will they have to that data?

Auditing

You should always be collecting, reviewing, and discussing how users are using the system, what they are accessing, errors, risks, and vulnerabilities.  You should be asking these questions when dealing with auditing.  Auditing could save you from a serious mishap because you are constantly monitoring the system.

• What kind of data will be collected in the audit trail? Frequency? When it will be reviewed by  security personnel?
• How will error, audit, and any security notifications be performed? Frequency?
• How long will audit trail and history be contained in the system? How long will they be in archives?
• How will audits be backed up? Frequency?
• Who will review these audit trails? Frequency?

Resources

These resources will help you in understanding what kind of detailed security questions you should be asking yourself:

1. Security Technical Implementation Guides
2. US Military and Government Security Guides and Information
3. Functional Requirements Document Sample
4. Writing Software Requirements Specifications
5. Functional Requirements Document Checklist

Final Thoughts

These are the basic four areas that you should be thinking about when thinking about security for your system. One thing that you should also remember is that security goes hand-in-hand with non-functional requirements that if ignored, can negatively affect your system. Best thing is to do things right from the beginning, so you won’t have any headaches later.

Three Don’ts When Taking Part in a Peer Review

I have participated in many peer reviews, be it for gap analysis, requirements, or proposals.  I have seen a few them go awry for numerous reasons.  Here are a few tips that I picked up while attending these peer reviews:

1. Leave the egos at home – There was one gap analysis that was four of us in one room for three months hashing out the best and worst of three complex financial management systems.  It was already a tedious and stressful job trying to figure out which features to place in the new system.  The process became ten times as hard because of two individuals who though his system was the best, and that he was the only expert.  Honestly, leave the egos at home.  When you are thinking about how great you are or the system you represent, you are not being open enough to take in other people’s suggestions, which can be detrimental to designing a new system.

2. Don’t continuously interrupt - Sometimes allowing people to ask questions during someone introducing a topic is the worst thing to do.  You usually get sidetracked with other conversations that you really don’t address the discussed topic.  I found it best to allow someone to say his/her part, and then ask any questions you have afterwards.  It gives them time to touch on everything that he/she wants to talk about, and you are able to have useful questions at the end.

3.  Don’t belittle others’ ideas or questions - I’ve been around some people who will smirk or say some sarcastic comment if a person says something that they deem “stupid.” Peer reviews are usually times to brainstorm ideas.  Therefore, this is one of the only times that I will agree that no question (or idea) is stupid.

How to Gather Requirements and the Documentation to Help You Do It

Requirements gathering can be tedious and frustrating, but if done successfully, you can ensure that the solution or product that you are building is a success.  Here is a video I created about the things I am learning while assisting a company gather requirements for a proposed system that they are going to build that will replace a system compiled of legacy systems (made out of Access..eeeek) and spreadsheets.