This chapter defines the nonfunctional requirements. For example, with the advent of cybersecurity in the last several years, security is a very important section of any system. This chapter will cover reliability, availability, maintainability, extensibility (scalability), and security. Security is not technically spelled with “ility,” yet it is lumped in here. It is justified if the term became securibility, to coin a term. However, in interest of shorter and more understandable works, the text will use security, and you know it belongs in this chapter.
The government makes up a lot of words that are longer than they need to be, like “it has utility” rather than “use” or “prioritization” rather than “assign priority,” and the list goes on. You might keep to the KISS principle . This was something from the Army: Keep It Simple, Stupid. This is not to say you are stupid; it was targeted for those who made things a lot more complex than they needed to be so they could sound impressive.
The Types of Nonfunctional Requirements
Some sources may call these behavioral requirements, but they are everything that does not fall into the functional requirements. Nonfunctional requirements define how the system should do it. Nonfunctional requirements do not specify implementation. Look at the following list of types, and you will see what is covered.
Architectural
Capacity, current, and forecast
Documentation
Efficiency
Effectiveness
Environmental
Fault tolerance
Privacy
Performance
Resilience
Robustness
Accessibility
Availability
Data integrity
Extensibility
Interoperability
Manageability
Maintainability
Portability
Quality
Reliability
Recoverability
Scalability
Security
Serviceability
Stability
Supportability
Testability
Usability
Starting with the previous elements from the Stack Overflow web site (“What is functional and non-functional requirement.” Stack Overflow. Feb. 2015. http://stackoverflow.com/questions/16475979/what-is-functional-and-nonfunctional-requirement ), most other sources use many of this list, but others are appropriate.
Architectural
Your organization may mandate some architecture standards that your system must follow. Here’s an example:
5-1 The FBI BOSS Records Management shall be designed with a Service Oriented Architecture (SOA ).
As you learned in Chapter 2, requirement 5-1 could be an implementation if taken on its face value. However, given that an architectural study by the organization in question decided this was the best architecture approach for the system being considered, you will have to capture it. Alternatively, you might have something like the following (or both):
5-2 The FBI BOSS Records Management shall follow Representational State Transfer (REST ).
REST is an architectural style of the World Wide Web. Are there architectural requirements for hardware? Of course, there can be, so it depends on your organization and what you are trying to build. Here’s an example:
5-3 The DoD BOSS Records Management Computer system shall follow Common Operating Platform Environments (COPEs ) Architecture.
Even small items like the dosimetry system may have architectural requirements that may need to be applied. You will have to investigate your organization.
Capacity
In this section, you will examine the storage capacity you need for your system. In the FBI record system, you need to investigate how much capacity you need for these records. Are these just text documents? If the answer is no (which is very likely), then what resolution of images do you need to store? Will there be color images? Will you have video? Black and white or color? What about sound files? How many of these types of records will you need to store, and how many years’ worth? Once you know all the answers to this type of information, you can come up with a requirement like the following:
5-4 The FBI BOSS Records Management shall have a capacity of 12 Terabytes of data.
You should also write requirements to answer the questions in the previous paragraph. This will define how many text documents of what size you will have, how many other file types will you have, how many years of data, and how long before it goes to archive, if at all. You will address storage growth in the next chapter in the scalability section.
What about hardware that is not a computer system? Will you need some storage capacity for the individual dosimeter? Here’s an example:
5-5 The BOSS Individual Radiation Dosimeter shall store 1000 bytes of data.
5-6 The BOSS Unit Radiation Dosimeter shall store 1,000,000 bytes of data.
The previous example does not have the ability to expand these two different dosimeters. However, they could be updated in the future. That is not always the case for every system. Consider a deep-space probe where there is no way to upgrade the capacity of the system. There may be more efficient coding, but the hardware itself will not change. You have to ask the same kinds of questions as you did for the computer system earlier. There could be some alphanumeric data. Chances are, however, these probes travel the solar system to gather images among other types of data. Is color important for images (probably)? If so, what resolution do you need? How many do you want to store at a time before you transmit back? There are factors to consider in answering this last question. What is the transmission rate of the probe? If you can only transmit 1 kilobit per second of data, it makes no sense of store terabytes of data to transmit every hour. Therefore, you might come up with a requirement like this:
5-7 The BOSS Oort Cloud Space Probe shall store 1 gigabyte of data.
Then you will need to answer all the questions in the previous paragraph in requirements as well.
Constraints
There can be many constraints to your system that you need to address. These statements are restrictions on what you can do. Some you will learn about separately, like environmental or privacy constraints. Others might be architectural constraints, which you examined earlier.
For example, the individual dosimeter cannot be a large and cumbersome device that the individual soldier must wear. It might be similar to a wristwatch, such as the following:
5-8 The BOSS Individual Radiation Dosimeter shall weigh no more than 4 ounces.
For the records management project, you might have the following:
5-9 The FBI BOSS Records Management shall require all records to be in one of the following formats only:
DOC,
DOCX,
XLS,
XLSX,
PPT,
PPTX,
JPG, or
TIFF.
Notice that some constraints may be harder than others, such as a device that has to be moved from a naval ship to a Zodiac inflatable, by a 120-pound sailor. Thus, you have a carrying constraint and the specification of the minimum size of the person involved. You will see other types of constraints in this chapter like peak load, availability, capacity, daily and hourly loads, life spans, and size limitati ons. No doubt, you will encounter others in your career. Capture them, but highlight them as constraints.
Documentation
Documentation is the documents that already exist related to a project. Documentation is different from a document that captures all your requirements. Are there specific requirements for documentation that is part of the system? Here’s an example for the dosimetry project:
5-10 The BOSS Unit Radiation Dosimeter shall have a hardcopy user guide that explains all the functions of the BOSS Unit Radiation Dosimeter.
For the records management project , you should consider a similar requirement:
5-11 The FBI BOSS Records Management System shall have an online user guide that explains all the functions of the BOSS Records Management System.
Your organization may require documents, say, a system administrator’s manual or a frequently asked question guide for a help desk that supports a system. You will need to find all these needs during the elicitation phase.
Efficiency
According to Merriam-Webster’s Collegiate Dictionary, efficiency is
the ability to do something or produce something without wasting materials, time, or energy 1
For hardware, this could be energy efficiency, say the efficiency that solar power is converted to energy used by a consumer, either a person or hardware. For computer systems, it can be the efficiency of certain functions and resources. Take a formatting of the hard drive on your laptop. If a particular operating system consumed 75 percent of the disc capacity, would that be considered very efficient? Probably not.
Therefore, you may want the following requirement:
5-12 The FBI BOSS Records Management System Operating System shall make 99.5% of the data hard drive available for storage.
For the dosimetry project, you can have this:
5-13 The BOSS Individual Radiation Dosimeter shall alert the user when the battery drops below 90% power so that the batteries can be changed.
At first blush, you might consider 90 percent to be a very high threshold. However, knowing how logistics system operate, usually slowly, and especially during a combat situation, the replacement parts for low-priority items may be long. There are factors like that you may need to consider.
Effectiveness
You need to define how good certain functions are within your system.
For the dosimetry project, you might have this:
5-14 The BOSS Individual Radiation Dosimeter shall capture 99% of the radiation the individual soldier is exposed to.
For the records management project, you might have the following:
5-15 The FBI BOSS Records Management System Operating System shall ingest 100% of records submitted.
One hundred percent may seem impossible, but from a legal perspective, it is a necessity. In addition, you will have statements elsewhere that address the fixing of records that are submitted but do not meet the proper format or fail ingestion into the database for some other reason.
Fault Tolerance
What happens when a portion of the system, but not the entire system, fails? Think of a flat tire on your car. You can still drive, even though it is in a degraded mode. You will need to consider whether such conditions will happen with your system and specify how effectively it can operate. For example, if a jet fighter has lost one engine of two, would the pilot be able to land?
You will have determined what fault tolerance is required for your project. For the records management project, you should have a similar requirement:
5-16 The FBI BOSS Records Management System shall have all functions implemented as services within a service oriented architecture to allow the system to operate in the event of one or more services failing.
For the example of the fighter, you would have the following requirement:
5-17 The XF-36 jet fighter shall be able to land with only one of its two engines operating.
You will need to determine fault tolerances needed for your project. Your organization may have guidelines on this, so research it.
Privacy
There are several situations where you need to consider privacy issues . People are rightfully concerned about their personal information. This is a critical business consideration given consumer concerns about their person information. Also, in the medical field, HIPAA receives a significant emphasis. The Health Insurance Portability and Accountability Act of 1996 defines what the medical field must follow to protect an individual’s privacy relating to his or her medical information. Therefore, in the dosimetry project, you might have the following requirement:
5-18 The BOSS Unit Radiation Dosimeter shall store ensure individual radiation dosages are protected in accordance with HIPAA compliance.
In addition, even for the records management, the system must protect privacy. Here’s an example:
5-19 The FBI BOSS Records Management shall have protect the privacy of individuals identified in a record in accordance with Federal Government Privacy policies.
Check the application of privacy rules for your project and capture them appropriately.
Quality
For our purposes, qualityis a degree of goodnesss. There are two levels of quality you want to consider. First, if you take all these nonfunctional requirements together, it should define quality for the system. That means you then look at goodness at the individual requirement level, which we will do now.
Now examine the records management project. For argument’s sake, assume not all their documents have been converted to digital format yet. Therefore, they are working on documents that are 25 to 30 years old. Now you need to address the goodness of the documents to be converted. Back in that era, people were still using an antique called a typewriter. In addition, not all the paper was as good—think multiple-page forms. Also, documents were copied multiple times. The quality of documents to be scanned can degrade with age and the fragileness of the paper. Since you are going to scan this, you need to come up with a quality of the scan.
5-20 The FBI BOSS Records Management scanning shall capture 75% of the characters per page to be considered a quality scan.
Now the default scan will be 300 dots per inch (DPI). If the scan does not meet the 75 percent, the process will be repeated at the 600 DPI, 1200 DPI, and finally 2400 DPI. If the 75 percent cannot be achieved at 2400 DPI, the quality achieved there will be the default.
Are there quality requirements that would apply to hardware type systems? Yes. You will examine a simple example for the radiation dosimetry project.
5-21 DRAFT The BOSS Unit Radiation Dosimeter shall capture gamma ray exposure between 200KeV and 1.00 MeV with a 99% accuracy.
By the way, this requirement is not correct, so don’t reuse it (but it verifies the importance of experts). (KeV = Kilo-electron Volts and MeV = Mega-electron Volts.)
Resilience
Resiliency requirements define what must be preserved when an outage of the system occurs. Here’s an example for the records management system:
5-22 The FBI BOSS Records Management shall maintain all records during an outage until such time as the system is restored.
For the dosimetry project, consider the following:
5-23 The BOSS Individual Radiation Dosimeter shall maintain the individual exposure record during the loss of battery power until such time as the power is restored to the system.
For both projects, there of course will be other needs, and you will need to define them all.
Robustness
Robustness means that the system does not crash easily and is able to withstand changes that might weaken it.
Real-World Note
I worked on a system where a very complex query that spanned multiple tables would cause the user’s connection to it to fail. That is unacceptable. This is somewhat related to fault tolerance.
Therefore, you might have a requirement like this:
5-24 The FBI BOSS Records Management Search Function shall not cause the system to fail.
In the radiation dosimetry project, you could have the following:
5-25 If the energy exposure exceeds 1.00 MeV, the BOSS Unit Radiation Dosimeter shall ignore the energy rather than overload the sensor.
As usual, you will need assistance in capturing such expertise-loaded subject areas.
Environmental
What are the external environments that your system will need to operate in? Will this be a 24-hour, seven-day-a-week computer system? Will this be the same environment your dosimetry project must operate in? You will need to address temperature ranges, rain, wind, snow, humidity, and any other such factors. Will a sensitive probe need to be dropped or banged about (think of a watch on a soldier in a combat zone)? Therefore, you can have examples like the following:
5-26 The BOSS Unit Radiation Dosimeter shall be exposed to temperatures ranging from -40 to 140 degrees Fahrenheit.
Remember, these devices must operate anywhere in the world.
For the records management project, you should have the following:
5-27 The FBI BOSS Records Management shall operate from 6 a.m. to 11 p.m. daily Monday through Friday.
If it is a job done during the day, why would you not just base it on 8 to 5 in Washington, D.C.? If you have lived in that area, you will know people will come to work early to avoid the horrendous traffic. Plus, the FBI is in all four time zones. What about Hawaii and Alaska? Is 11 p.m. sufficient? Maybe not. For this exercise, you assumed records management took place in the continental United States. You will need to confirm that is correct.
Data Integrity
Data integrity refers to maintaining and assuring the accuracy and consistency of data over its entire lifecycle. This could be the corruption or loss of data because of a hardware failure, such as a spot on a hard drive that goes bad. Alternatively, data integrity is corrupted when a record cannot be found because the pointer within a database loses its link.
5-28 To prevent malicious corruption of the BOSS Unit Radiation Dosimeter, the system shall retain its data for 90 days after a designated user authorizes deletion of a record on the Unit Dosimeter.
For the records management project:
5-29 The FBI BOSS Records Management System shall maintain data integrity by keeping backups of all updates to the database for every record transaction.
Standards
There may be many and varied standards that are regulated on your project or even that your organization levies on you because of company policy. There could be programming standards for your developers. HR has standards of conduct for employees and ethical standards. The DoD has a whole series called military standards, or MIL-STD for short. The EPA has environmental standards. There are company architectural standards; even Microsoft has standards for its software development. Those are only a few. You learned about one kind of standard in the previous chapter that might apply to your project, such as the following:
5-30 The BOSS shall follow this company’s Organizational User Interface Standard.
The DoD has many standards for its hardware development such as DoD Manual 4120.24-M, Defense Standardization Program (DSP ) Policy and Procedures. This can drive you to requirements such as the following:
5-31 (5-26) The BOSS Unit Radiation Dosimeter shall be exposed to temperatures ranging from -40 to 140 degrees Fahrenheit.
You will need to find all standards that will apply. They should not be difficult to find as people will let you know what they must follow.
Performance
Chapter 4 began with arguably the biggest and most important group of requirements (business rules), and this topic probably has the second biggest and most important group of requirements: performance.
Merriam-Webster’s Collegiate Dictionary defines performance this way:
1 a: the execution of an action
b: something accomplished: deed, feat
2 the fulfillment of a claim, promise, or request: implementation
3 the manner in which a mechanism performs, e.g., engine performance 2
How something performs, whether it is hardware or software, is what is important to us. System performance affects almost every section in this chapter and the preceding one. In fact, reliability, availability, and maintainability requirements are almost exclusively performance requirements, as you will soon see. In this section, you will learn about how many, how often, frequency, confidence levels, and so on—anything you can quantify. Other than maybe a definition of something, there is a number associated with a performance requirement.
Where do you put these requirements? While you could place performance requirements in their own section, it may work best to do this with the particular function you are talking about. That helps to reinforce the point that most every function should have performance requirements, or you should at least spend some time thinking about if performance requirements are necessary for that function.
I want to look at the following:
Performance response time
Workload performance
Platform performance
These are good types of performance values, but only as a start. You have seen many values in this chapter that define performance values such as the number of users, response times, throughput, concurrency, resources, and many of the nonfunctional requirements like scalability that you have already examined in this chapter.
Check out that web site as some explanations of details related to various performance values. It gives guidance of user reactions to how quickly they receive feedback.
Now, examine example performance values.
Performance Response Time
How quickly do you want your request to be completed, whatever it is? Think of the records management project . You have received a request to find a particular set of documents from 1998. How fast should you get your results?
5-32 The FBI BOSS Records Management Search Function shall return the results within 4 seconds, 80% of the time.
The value “80% of the time” is important. It is the confidence level of your requirement. The results should meet four seconds in four out of five queries. Does that sound slow when you compare it to Google? However, think of a database that may have millions or tens of millions of records that could be megabytes of data each. That is a very good result.
What about the other 20 percent of queries? Excellent question. You need to address them in some way. You can increase the confidence level and the response time appropriately. Here’s an example:
5-33 The FBI BOSS Records Management Search Function shall return the results within 10 seconds, 90% of the time.
And here’s another:
5-34 The FBI BOSS Records Management Search Function shall return the results within one minute, 99% of the time.
There is more than one way to address the last one percent. One way is parallel to the requirements you already have, like so:
5-35 The FBI BOSS Records Management Search Function shall return the results within ten minute, 100% of the time.
Or like this:
5-36 The FBI BOSS Records Management Search Function shall return all query results in less than ten minutes.
Workload Performance
Another factor you need to consider is the workload on the system. Another name for this you may see in some text is concurrency. How many users will there be for your system? That is a capacity value (see the “Capacity” section in this chapter). You might have the following:
5-37 The FBI BOSS Records Management Search Function shall have 500 users.
However, those are not concurrent users. If you spread that over 24 hours a day, if it was a 24/7 system, you would have about 21 per hour. Is this system likely to be used that way? Probably not. Maybe about 10 hours a day, from the East Coast to the West Coast, so that would be 13 hours a day, or about 40 an hour.
5-38 The FBI BOSS Records Management Search Function shall have 40 average concurrent users.
However, assume in this case that you have learned that about 40 percent of the people use it in the first two hours of work and 300 users are in the Eastern Time zone, 50 users in each of the Central and Mountain Time zone, and 100 in the Western Time zone. You are left with a 120-user peak in the first two hours.
5-39 The FBI BOSS Records Management Search Function shall have 120 peak concurrent users.
Does the same apply for searches? If there are that many people querying the database, does it affect the response time? That is a question you need to address. Maybe if each person is doing only one search in those two hours, that is 120 searches in two hours, or an average of one a minute, so in that case, if that is representative, you may not need to address your search response time.
However, if each of the 120 users in the peak two hours is doing ten search each, they may not be evenly spaced apart, so you may need to specify something like the following:
5-40 The FBI BOSS Records Management Search Function shall return the results within 10 seconds, 80% of the time during the peak two hours of the day.
Or, you might have to say it this way:
5-41 The FBI BOSS Records Management Search Function shall return the results within 10 seconds, 80% of the time when there are 100 searches initiated within 10 minutes.
You may need to address each confidence level during the peak times. This is an important aspect for any performance requirement. Not only should you address normal activities, but also you need to address peak loads.
Here you have a relatively low workload for the example system. Think of Google or Amazon; they would have a much higher set of numbers, probably the high end of the spectrum of the number of users, frequency of queries, and so on. You may have situations that are in the thousands or even tens of thousands of users like a Google, Amazon, or eBay. In those cases, you will have to craft the same type of requirements, but the values will be significantly different. Analysis and discussion with the experts may be required to address these situations.
Platform Performance
Here you will learn about items like computers, printers, scanner, servers, type of network, operating system, and any other peripherals you could consider for a computer system. Naturally, performance applies to other hardware as well. For example, you should have the following:
5-42 The BOSS Individual Radiation Dosimeter shall capture exposure to radiation within one second of exposure.
Some responses are not driven by the user needing something within a certain time but driven by other needs like the previous requirement where exposure needs to be collected quickly in the event of other radiation exposure.
You need to consider transfer rates. Therefore, you might have the following:
5-43 The BOSS Unit Radiation Dosimeter shall capture the readings from the BOSS Individual Radiation Dosimeter within two seconds once the Individual Dosimeter is locked into the reader.
You will need to do the same for all the items within the computer system. Here’s an example:
5-44 The BOSS Network Printer shall print at least one hundred pages a minute.
Here’s another example:
5-45 The BOSS Network Scanner shall scan at least twenty pages a minute at 2400 dots per inch.
You will need to examine every possible performance value to determine what needs a requirement. The guiding rule should be, if you find a number associated with a piece of hardware, consider a requirement for it.
You may become involved with a piece of hardware that you do not have a strong background with. For example, many of you may not have had significant experience with radiation detection. As you have seen from the analysis so far and with more to come, the challenges will be subdivided sufficiently enough that many aspects are understandable after the analysis here that then you can work with the experts to harness their knowledge to translate the needs into good requirements.
Performance Profiles
Sometimes you may need to consider performance profiles that are different from one another. For example, you are looking at a local area network (LAN) for sales offices in company dispersed around the country. Some offices are larger than others. After some research, you find that your company has offices with the following sizes:
Small offices range from 3 to 6 people.
Medium offices range from 10 to 26 people.
Large offices range from 30 to 56 people.
Note
You will need to add these definitions to your glossary.
You will need to provide performance requirements that may vary based on this. Here are some examples:
5-46 The BOSS Network Sales Server for a Small Sales Office shall store 10 megabytes of sales records.
5-47 The BOSS Network Sales Server for a Medium Sales Office shall store 40 megabytes of sales records.
5-48 The BOSS Network Sales Server for a Large Sales Office shall store 100 megabytes of sales records.
There may be many values that you have to consider differently depending on different profiles. Why? First, you would not want to spend the money and resources for a large office when you are installing a small office. You need to focus the performance to suit the needs.
Throughput
Merriam-Webster’s Collegiate Dictionary defines throughputlike this:
the amount of material, data, etc., that enters and goes through something (such as a machine or system) 3
Now examine an example for the dosimetry project. In the archive section, you might consider the following requirement:
5-49 DRAFT The BOSS Unit Radiation Dosimeter shall have the ability to download up to 1000 transactions to the BOSS Dosimetry Archive Laptop.
This specifies how many transactions, but there is no time element. Therefore, you should have something like this:
5-50 The BOSS Unit Radiation Dosimeter shall have the ability to download up to 1000 transactions to the BOSS Dosimetry Archive Laptop in 5 minutes.
Given that you know each record can be 1,000 bytes of data, that gives you 1 megabyte of data in 60 seconds, or 166,667 bytes per second throughput requirement. That is quite doable by most systems.
What about the records management project? Do the same kind of analysis. Consider the backup capability. You know you should have 10 gigabytes of data each year. Now assume that will be the maximum you need to back up. You have determined you should perform a complete backup each week. Does that mean you have an entire week to accomplish this? Maybe, if it ran in the background yet it did not affect the operation of the system. That is probably not the case. Could you be updating the database while a backup is running? Operationally, that is not a good practice. So, what time do you have to do it?
The same process is applied to the database storage of a computer system. Think of an FBI records management system. Assume that 10 gigabytes of electronic information is generated per year. Now assume that the backup can run overnight. Then since you have the system operational from 6 a.m. Eastern time to 11 p.m., that means you have 7 hours to do the transfer. Then you would have a requirement as follows:
5-51 The BOSS Weekly Backup shall be completed between 6 a.m. to 11 p.m. on Thursday night, with a throughput of 400 kilobytes/second.
Then during your analysis, one manager says that the backup can happen on the weekends. That yields an additional 48 hours. What does that do to the calculation?
5-52 The BOSS Weekly Backup shall be completed between 11 p.m. starting on Friday night and 6 a.m. on Monday, with a throughput of 51 kilobytes/second.
That is a significant improvement, if that is needed. That gives you the idea of what performance is like.
Reliability, Availability, and Maintainability (RAM )
This is probably the one area within this book that will exploit mathematics to any significant degree. Network throughput calculations are probably the only other mathematical area, and that is relatively simple compared to RAM .
Reliability, availability, and maintainability are values that are related to each other, which is why they are usually studied as a group. Reliability is how reliable the system. Reliability is how reliable the system is. Availability is how available the system is. Maintainability is how maintainable the system is. To understand them better, there are specific terms and associated values associated with those terms. We will spend some time gaining an understanding of them.
Definitions
You are going to see many new terms and concepts for RAM. You need these terms to lay the foundation for RAM calculations.
Mean Time to Repair (MTTR )
This describes the average time to repair a failure. If a card dies in your network server or in a desktop, it could be very quick. Say 15 or 30 minutes. However, what if the entire server fails? Do you wait for someone to repair it, when it could be several hours or more than one working day to fix it? Probably not. If it is just the matter of having a hot spare that switches automatically, you do not even lose any time. Now what if the spare is not connected and all it requires is connecting the system and it is functional? Then maybe it takes 30 to 60 minutes to fix it. However, what if all you have is a machine without fully configured operating system for your use and without the applications installed on your machine? That will be a significant wait time, at least hours and probably days. Moreover, what if the people who fix it are not even part of your department? Then you have put in a repair request, and you have to wait for them to show up before any work begins.
That brings up a very important question relating to MTTR . Does this include wait time? If the answer is yes, then you are covered. If, in your organization, the answer is No, then you need to include wait time. That definition comes next.
Wait Time
Wait time is the time from the onset of the failure until the work begins on the failure.
Some people like to keep the wait time separate to track it. In many cases where a different organization is responsible for the service of hardware and software, the wait times create significant impacts on an organization. My experience shows most federal organizations I have worked with separate the hardware maintenance and software maintenance so that tracking wait time for that maintenance is very important. This is not a criticism of how this is done, just that some organizations can use wait time. In addition, it is not clear that they track how much time they lose in critical functions. This is something to be aware of in your organization. What good is it to have a small MTTR if no one looks at how much time is lost to wait time?
Mean Time Between Failures (MTBF )
This is the average operational time between failures. If you have three system failures every 30,000 hours, then your MTBF is 10,000 hours. That is straightforward enough. Of course, achieving it is another matter, not to mention verifying that kind of requirement. That is not the responsibility of this text—another course or volume will discuss that. What you need to define is what the value should be. In this era with so much computing power and equipment, this value should be quite high.
As you can see, these MTTR, wait times, and MTBF values seem to be related, which they are. You will continue to look at them and how they interrelate.
Availability
Availability defines how much of the time the system is operational. More precisely, availability is the percentage of time that the system is up and running. The two most important types of availability are operational availability and inherent availability.
Operational availability includes the time to repair a fault, the time spent waiting to repair the fault, and the time between faults. The formula for it is as follows:
Operational Availability = MTBF / (MTTR + Wait Time + MTBF) * 100% EQUATION 1
Note
The more general definition for operational availability is uptime divided by the sum of the uptime and downtime. This includes the MTTR and logistics downtime or wait time. In addition, periodic maintenance would come into the calculation, as well as any unscheduled maintenance. For the examples here, we will not look at the maintenance downtime.
Inherent availability includes the time to repair a fault and the time between faults. Since Wait Time is not included, the formula for inherent availability becomes the following:
Inherent Availability = MTBF / (MTTR + MTBF) * 100%EQUATION 2
Let’s look at some examples. You must use wait times as that reflects where problems can be hidden if not shown.
Plugging these values:
MTBF = 1000 hours
MTTR = 10 hours
Wait Time = 100 hours
into this equation 1:
Operational Availability = MTBF / (MTTR + Wait Time + MTBF) * 100%
yields the following:
Operational Availability = 1000 / (10 + 100 + 1000) * 100% = 90.09%
The CEO sees this wait time of 100 hours and says that number is totally unacceptable. He tells his maintenance manager that number must be reduced to 10 hours. What does that do to the availability?
Now plug these values:
MTBF = 1000 hours
MTTR = 10 hours
Wait Time = 10 hours
into equation 1:
Operational Availability = MTBF / (MTTR + Wait Time + MTBF) * 100%
which yields the following:
Operational Availability = 1000 / (10 + 10 + 1000) * 100% = 98.04%
As you can see, that made a significant improvement in the availability. Why was inherent availability never calculated? It was included as you will see some discussion elsewhere that uses it. However, it is my opinion that inherent av ailability does not reflect the reality of a system because it ignores the time spent waiting for something to be repaired. Look at the examples you have seen, and as an exercise for yourself, what would be the availability without wait time? You will see it is higher than when wait time is included. When wait time went from 10 hours to 100 hours, the operational availability dropped significantly. However, it does not reflect the real work. That is why we do not use it here.
Wait, you say, shouldn’t maintenance be included in this calculation? Good catch. In this case, no maintenance downtime is assumed.
You have to include the time that the system is not in service for maintenance in the total time calculation.
Maintainability
The Department of Defense defines maintainability as a measure of the ease and rapidity with which a system or equipment can be restored to operational status following a failure. Now we will analyze the primary calculated values within maintainability.
Mean Time to Maintain (MTTM )
This describes the average time the system is down for maintenance.
Mean Time Between Maintenance (MTBM )
This is the average operational time between maintenance.
MTBM defines how much of the time the system is operational. More precisely, availability is the percentage of time that the system is up and running. The formula for it is as follows:
Maintainability = MTBM / (MTTM + Wait Time + MTBM) * 100% EQUATION 3
When wait time is included in the MTTR, this formula becomes the following:
Maintainability = MTBM / (MTTM + MTBM) * 100% EQUATION 4
Again, let’s consider some examples.
Plugging the following values:
MTBM = 1000 hours
MTTM = 10 hours
Wait Time = 10 hours
into equation 3:
Maintainability = MTBM / (MTTM + Wait Time + MTBM) * 100%
yields the following result:
Maintainability = 1000 / (10 + 10 + 1000) * 100% = 98.04 %
So, how do you include maintenance with inherent availability (which is called operational availability)?
You must average the two values. If they both are 99 percent, it averages to 99 percent.
Now, look at some more examples.
In this first example, plug the following values:
MTTM = 10 hours
MTBM = 1000 hours
into equation 4:
Maintainability = 1000 / (10 + 1000) * 100% = 99.0099%
And, plug the following values:
MTTR = 1 hour
MTBF = 1000 hours
into equation 1:
Inherent Availability = 1000 / (1 + 1000) * 100% = 99.9001%
In this second example, plug the following values:
MTTM = 10 hours
MTBM = 5000 hours
into equation 4:
Maintainability = 5000 / (10 + 5000) * 100% = 99.8004%
And, plug the following values:
MTTR = 1 hour
MTBF = 1000 hours
into equation 1:
Inherent Availability = 1000 / (1 + 1000) * 100% = 99.9001%
In this third example, plug the following values:
MTTM = 10 hours
MTBM = 1000 hours
into equation 4:
Maintainability = 1000 / (10 + 1000) * 100% = 99.0099%
And, plug the following values:
MTTR = 1 hour
MTBF = 5000 hours
into equation 1:
Inherent Availability = 5000 / (1 + 5000) * 100% = 99.9800%
In this fourth example, plug the following values:
MTTM = 10 hours
MTBM = 5000 hours
into equation 4:
Maintainability = 5000 / (10 + 5000) * 100% = 99.8004%
And, plug the following values:
MTTR = 1 hour
MTBF = 5000 hours
into equation 1:
Inherent Availability = 5000 / (1 + 5000) * 100% = 99.9800%
Reliability
Basically, reliability of the system, component, or whatever the item is means it does not fail. To be more explicit, for hardware, reliability is the probability a component fails, whereas for software, reliability is the probability software will produce an incorrect output or not provide a result at all.
For the purposes here, you will only define reliability for the entire system and major functional areas (services and/or subsystems). For a system’s requirements, breaking down the hardware or functionality further is beyond the scope of this text and should be done more by a reliability engineer in conjunction with a requirements engineer.
The reliability, R, function over time, t, is defined in the following equation where the value lambda, λ, is the failure rate, which is defined as 1/MTBF:
R(t) = e –λt EQUATION 5
When you have two items in series (say the computer and the operating system), the reliability for both is as follows:
R (system) = R (computer) * R (OS) EQUATION 6
Then this series continues for the application on the top so it would be as follows:
R (system) = R (computer) * R (OS) * R (app) EQUATION 7
If you have both R(computer) and R(OS) = 0.90, substituting these values into equation 6, you get .9 * 0.9 or 0.81. If R(App) = 0.90, with R(computer) and R(OS) = 0.90, and you substitute that into equation 7, you have 0.9 * 0.9 * 0.9 = 0.729.
If you had ten services in one suite of services, it would be as follows:
R (total) = R1 * R2 * R3 * R4 * R5 * R6 * R7 * R8 * R9 * R10 EQUATION 8
If R1 through R10 all equaled 0.9, then substituting that into equation 8 would yield 0.348678. This would not be a very reliable system.
However, when things run in parallel, how does the formula work?
Rtotal(t) = 1 – [1 – R1(t)] [1 – R2(t)]
= R1(t) + R2(t) - R1(t) R2(t) EQUATION 9
So if you have both R1 and R2 = 0.90, substituting these values into equation 9, you get the following:
Rtotal = 0.90 + 0.90 - 0.81 = 0.99
Now you see the benefit of putting items in parallel.
And if a third one with R = 0.9 is added to equation 9, you get the following:
Rtotal = 0.990 + 0.900 - 0.891 = 0.999
This clearly demonstrates why items, whether they are hardware or software, should work in parallel whenever practical.
This is as much as you will see here about reliability. Usually, you will define availability and maintainability for systems. Only if you get very specific hardware would you get into very sophisticated reliability calculations.
At most, for your purposes here, you would write the following:
5-53 The BOSS shall have an overall reliability of 0.999.
This would allow the designers to identify the proper configuration to meet that. If you need more detail, you now have the tools to do some breakdown for subsystems and services.
Failure Definition
The requirements must provide a clear definition of a project failure. At a minimum, if the hardware that software resides on fails, that is a system failure.
Therefore, a requirement would look like this:
5-54 The BOSS system shall be available 99.99% of the time.
5-55 A failure of the BOSS system shall occur when any of the following critical functions are not working:
Security access to the system
Searching the mission database
Adding records to the mission database
Updating records within the mission database
Deleting records from the mission database
Notice that this did not list reporting or auditing. Remember there can be more functions depending on your system. In addition, stakeholders, not designers, define these critical functions. Also, special users like administrators do need representation in this special case but have only limited items that they can demand be included.
What is crucial to this requirement is that the unavailability is independent of the cause. Users are not properly reflected in availability. Please keep this approach included in all projects you work on. Do not let developers and designers whine that it is too hard. In addition, some say that you cannot define availability on software.
Real-World Note
I did bring an innovation, even early in my career. Up to that point in time for this organization, computer system operational availability was defined only by determining whether the mainframe was up. This type of definition may have had a much broader definition, but I did not research it at that time. If other hardware or even software would not operate, that was not considered. Therefore, if the mainframe was operating, but your terminal, the operating system, the line connecting you to the mainframe, or the application was not working, that made no difference. The system was still considered “operationally available.” From a user standpoint, clearly it is not. I defined operational availability by users being able to perform mission-critical functions. If any of the mission-critical functions could not be accomplished for any reason, hardware, software, operating system, etc., the system was not available. Not only have I brought that definition to every project I have worked on, but also, when I returned 25 years later to that original organization, they were still using that definition. As for defining availability for software, I could define it and I did. Believe me, it was embraced by the stakeholders, which was why 25 years later, it is still being used.
Tip
The study of RAM is the topic of many books, and you could spend entire courses in this effort. In fact, the U.S. Army course was 120 hours long. There are very detailed and very complex theories presented at symposia. What is interesting is that the value of these very sophisticated approaches compared to more simple theories (e.g., the normal distribution of failure, where electronic failures are random) may be very insignificant. In fact, rarely do you see validation of the initial assumptions to justify why the new theory is significantly better. This is not to say they are not better, but someone needs to validate why the more complex theory is better than tried-and-true, more simple approaches. If the difference is only 1 or 2 percent, go with the simple theory.
Security
One of Merriam-Webster’s Collegiate Dictionary definitions for security is
measures taken to guard against espionage or sabotage, crime, attack, or escape4
Wait a minute, you say, “Why do I need security since this will be a stand-alone system? I will not connect it to the Internet or any other servers.” First, you still will need to control who can access the system. Will you allow the office cleaners to access your billing system that specifies what you charge people? Will every employee have access to all functions in the payroll system (e.g., allow them to see everyone’s salary)? No. Second, you will need to decide whether data will be imported to this stand-alone system. If so, then you will need additional requirements to ensure security is maintained. Third, if you project will be connected to other systems, then further protections are needed, especially if it will connect outside the organization to include the Internet.
Realize in your work as an RE, you will generally be collecting the requirements as specified by the stakeholders. That said, there is some value added that you can provide to these same stakeholders. Every person will not know everything that is needed to collect the requirements for the entire system. You will work with as broad a spectrum of stakeholders as you can to ensure everything is covered. In Chapter 10, you will learn about doing gap analysis to find those areas that may not have been covered at all or covered sufficiently. By having a list of candidate topics like these, you may help ensure that the stakeholders do cover all their requirements.
These three aspects will be examined in the following sections. In addition, I had added a fourth section in security called reuse. Why reusing requirements is not the sole area where you will likely reuse requirements, in my experience, it is the one area where previous security requirements can be reused the most. So, it is introduced here. Just realize that any requirement or groups of requirements can be reused.
Access Control
Here you specify how people get access to the system. Usually you have some sort of unique user identification (e.g., user ID) and password. If there is more than one area within the system, or system of systems, where there are different groups within system, you may need to select from those areas.
You should consider some requirements like these:
5-56 The BOSS system shall maintain unique user identification for every person who will use the system.
5-57 The BOSS system shall maintain a password for every unique user identification on the system.
Note
You will need to decide whether the users themselves create their own password, whether the system creates them, or whether a system administrator creates them. Usually, this is defined by the organizational policy.
You will need more:
5-58 The BOSS system shall allow a user three attempts to enter their user ID and password (and select the domain, where appropriate) before that session is ended.
You will need to know what your organization’s policy is regarding how a failed login attempt is handled.
5-59 When the user has failed to enter their user ID and password correctly, the BOSS system shall allow the user three attempts to log in after one hour.
Or it might be as follows:
5-60 When the user has failed to enter their user ID and password correctly, the BOSS system shall only allow the user three attempts to log in again after a system administrator has authorized it.
Once a person has access to the system, you will need to define the roles and responsibilities that various users can have on your system. Some of what is discussed here will be standards, but there will be additional roles depending on the nature of the system. For example, an HR system will have significantly different roles than will a hospital system or an online auction system. Nevertheless, you should consider some of these:
5-61 The BOSS system shall allow roles that allow people to read the database.
5-62 The BOSS system shall allow roles that allow people to add to the database.
5-63 The BOSS system shall allow roles that allow people to change the database.
5-64 The BOSS system shall allow roles that allow people to delete from the database.
5-65 The BOSS system shall allow for system administrator roles.
Keep in mind, that one user can have multiple roles.
5-66 The BOSS system shall allow users to have multiple roles.
5-67 The BOSS system shall allow for system administrator roles.
5-68 The BOSS system shall allow for system monitoring roles.
5-69 The BOSS system shall allow for system auditing roles.
Note
You will need to define what functions are associated with system administrator, auditor, and monitoring roles.
This clearly is not a comprehensive list, but it will get you started.
Import From and Export to Outside the System
As mentioned earlier, you have to protect information coming to your application. You will address the formatting of the data in the interface in Chapter 8.
5-70 The BOSS shall ensure all data to be imported into the system has no viruses.
Will users of other system that exchange data with your system be able to access your data? In most cases, you would think not, but if you don’t specify so, you run the risk of someone controlling your data without you controlling what they can access.
5-71 The BOSS shall ensure all users external to the system do not have access to the BOSS data.
Clearly, there are more aspects to consider, but they depend significantly on whether you have systems connected to your system. Now what about exporting data? You will specify what applications you will export to and what formats are supported.
5-72 The BOSS shall provide users with the capability to export data to Microsoft Excel in .xlsx format.
5-73 The BOSS shall provide users with the capability to export data to Microsoft Excel in .csv format.
5-74 The BOSS shall provide users with the capability to export data to Microsoft Word in .csv format.
5-75 The BOSS shall provide users with the capability to export data to Microsoft Word in .docx format.
When defining formats, you need to decide whether you will provide backward compatibility, like .xls for Excel and .doc for Word, as well as other typical formats for these types of applications.
You must address if there is data within your system that cannot be exported or if it must be controlled in some manner. Why would you need to do that? There are various reasons, such as was mentioned, say payroll information or even proprietary information. Therefore, you might have requirements such as these:
5-76 The BOSS shall prohibit payroll data from being exported from the System.
5-77 The BOSS shall prohibit company proprietary information from being exported from the System.
Naturally, you will need to have identified what constitutes this kind of information, with requirement like the following somewhere in your list:
5-78 The BOSS shall identify all payroll data within the System.
5-79 The BOSS shall identify all company proprietary information within the System.
You may have a restriction that no data may be exported, so you have the following:
5-80 The BOSS shall prohibit any data from being exported from the System.
Once you understand the flow of data to and from your system and any associated restrictions, you will be able to apply import and export security requirements.
Connections to Outside the System
You will learn about interfaces with other systems elsewhere. This subsection addresses protection of the data. First, you must address the authorization of users to move data to and from your systems, as in these examples, including the appropriate data format:
5-81 The BOSS shall provide users with the capability to export data to ANY System in .csv format.
5-82 The BOSS shall provide users with the capability to import data from ANY System in .csv format.
Next, you should address the authorization system to move data automatically to and from your systems, as in these examples:
5-83 The BOSS shall provide ANY System to import data in .csv format.
5-84 The BOSS shall provide ANY System to export data in .csv format.
If you have specified a format different from any industry-standard formats, you will need to use that either in addition to the industry-standard formats or in lieu of those formats.
5-85 The BOSS shall provide ANY System to import data in the format specified in ANY System Interface Format.
5-86 The BOSS shall provide ANY System to export data in the format specified in ANY System Interface Format.
This brings up another point that people say is a limitation of good requirements engineering—requirements referencing other requirements or other documents. Purists say that you should never reference requirements or other documents. Our approach is this rule is like the Pirate’s Code mentioned previously. By that, you will run into situations where following rules so absolutely makes it such that you have to work inordinately hard to work around them. Otherwise, you might have to duplicate the interface specification again, and that adds nothing to the requirements.
There is another rule that requirement purists insist on—you should never write a requirement with a negative in it. For example, consider the following requirement:
5-87 The BOSS shall prohibit payroll data from being exported from the System.
That was instead of writing it as follows:
5-88 The BOSS shall not allow payroll data from being exported from the System.
Clearly, the first way is better. That said, there might be instances where it is nearly impossible to write any other way. For example, if you had a system that needed to have a specific query like this:
5-89 The system shall query for books about Vikings but not the Minnesota Vikings football team.
Chances are you would not write something that specific. This was an example of a “negative” in a requirement statement.
If you are going to connect to the Internet, you are going to need additional protection, such as firewalls. Here you will need to talk with an engineer who specializes in this. Here is a start:
5-90 The BOSS shall have a firewall to protect itself from Internet intrusion.
5-91 The BOSS shall have virus protection.
5-92 The BOSS shall prevent keystroke capture.
5-93 The BOSS shall protect against denial of service (DOS).
Reuse
Once you have defined certain security requirements, particularly access control, you should be able to reuse them throughout your career. Perform requirements reuse whenever you can.
Real-World Note
One day, I associated almost 700 requirements to one project. That sounds quite impressive, until you realize that I was reusing 700 requirements I had written before. It still is not as easy as just copying 700 statements. I had to search more than 1,000 statements and decide for each one if it belonged to the new project. I did reject more than 300 statements and had to modify dozens to make it appropriate to the new project.
This reuse is an exercise to consider for every project. People have been doing code reuse for decades. However, my experience in some federal government organization shows not enough have been doing it for requirements; although this could be happening anywhere in the industry, I cannot speak to it first-hand.
Reuse can come in two variants: completely copying existing requirements and copying some existing requirements but modifying the statements to reflect the new system.
Here is an example of copying.
The previous system is called PSS.
5-94 The PSS system shall require a customer to enter his name as a first name and last name.
5-95 The PSS system shall require a customer to enter an email address.
For our reuse, we will use our system BOSS.
5-96 The BOSS system shall require a customer to enter his name as a first name and last name.
5-97 The BOSS system shall require a customer to enter an email address.
Notice that only the names of the system changed, nothing else. The PSS could be a current system or even a predecessor to BOSS. If the requirement has not changed, there is no reason to modify the text.
Now, examine an example where the text of the requirement will be modified somewhat. This could be caused by changes to the environment or the requirement does not fit the original exactly.
Again, the previous system is called PSS.
5-98 The PSS system shall require a customer’s company name.
5-99 The PSS system shall require a customer’s company address.
For our reuse, the new system is BOSS. The difference for this new system is that the companies in question are online, so some modification to the requirements is in order.
5-100 The PSS system shall require a customer’s company online name (e.g., OnLineCompany.com).
5-101 The PSS system shall require a customer’s company URL (e.g., http://onlinecompany.com/sites ).
These are just simple examples; you will likely have many more that you would reuse, as in the previous Real-World Note, where 700 were reused.
Real-World Note
Part of the challenge I have encountered results from working in a classified environment. For reasons of security, people did not talk between different projects. One example of this problem was discovered in the first Gulf War, where people within the government were not sharing information that should have been shared, because security did not allow them to share within the U.S. government. Because people were accustomed to working in what was unaffectionately called a stove-piped environment, people did not share code and certainly not requirements, and in some cases the data itself. This was a tough culture to change as it had gone on for many decades. However, you should see less resistance to it now as you move into the workforce.
Cybersecurity is a growing field. Unless you have a degree in this or extensive experience in that field, you will need to work with an expert to get this defined properly.
Tip
There are very consistent areas that you should consider for reuse. The hardware configuration probably will not change much in your organization, along with related functional areas such as systems administration, auditing, printing, and monitoring. Of course, searching, system access and related roles and responsibilities, and report generation will have many of the same requirements for every application. What will be different is the data that is accessed. There will be others, but the number of reused requirements will be less and subject to your organizational needs.
Scalability
This “ility” refers to a system’s ability to scale up (or down) either to additional capabilities or to allow for growth. Some organizations may call it extensibility, but it is essentially the same thing. For this text, we will use scalability.
Tip
As you learned in Chapter 3, however, different organizations may use them slightly differently, and this will not be elucidated here. You must read the concepts in this and the next section and use them as you need in accordance with your organizational direction.
Now, examine some of these capabilities you want to address here.
You want to be able to scale up the system as more data is added. Say you anticipate your healthcare benefit application will grow 20 percent a year. You need to capture that growth once you have estimated the size of the original database.
For example, the requirements could be as follows:
5-102 The BOSS system shall be able to store 6 terabytes of data when deployed.
5-103 The BOSS system data shall be able to grow by 24% per year.
In addition, as new features are added to a system of services, you need to add a feature/function/service without having to completely redo the entire suite of services or a significant portion of them. Of course, this is supposed to be the benefit of SOA, but that does not mean you have a true SOA implementation, if at all.
Refer to a statement like the following:
5-104 DRAFT The BOSS system shall be extensible/scalable.
The previous statement is not a good one, based on what you learned in Chapter 2. So, how should you do it?
5-105 The BOSS system data shall be able to add five services per year without impacting the system performance requirements.
As you can see, this statement captures a quantifiable value for the number of services added while ensuring that performance. That may require the designers to add hardware to support the new capabilities, but they know what the need is.
You might need to address throughput scalability. Do a little research on the Affordable Care Act standup of their web site in 2013. It had real throughput scalability issue, which created quite a brouhaha. It causes one to wonder just what requirements they had for the Alternative Care Act (ACA ), aka the Obamacare system. That is another area you might want to consider writing requirements for if you will have significant throughput fluctuations in your system. Look at an actual example when the U.S. government stood up their ACA. They had determined an average number of enrollees per unit of time.
How do you address that?
5-106 The BOSS system data shall permit 30,000 people to enroll onto the system per day.
However, what is likely to happen both early when the system goes operational and near the end of the enrollment period? That is when a significant number of people are likely to use the system. As history showed, there were significant issues with the system being unable to handle the demands. Therefore, the normal value shown previously would be insufficient to address the needs.
How would be fix it? You should add a requirement like the following:
5-107 The BOSS system data shall permit a peak of 300,000 people to enroll onto the system per day.
This is an important aspect to any performance requirement. Not only should you address normal activities, but also you need to address peak loads, especially in the extensible/scalable aspect.
Some sources say you might examine platform considerations, contractual considerations, software, and response time. The first one will examined last. You saw response time in detail in the “Performance” section of Chapter 4. Scalability requirements are a natural extension of those requirements, like when you look at performance for simple queries versus performance at peak times. Contractual considerations are something that clearly are not part of the requirement phase, more the design and development phase, and sometimes the operations and maintenance phase. This brings you to the platform and software considerations. Again, they belong in the design phase, rather than the requirements phase. In the traditional waterfall method, these factors were captured in the design specifications presented at the end of the design phase. The main reason for not specifying the topics in requirements is because these topics are implementation, which you know requirements engineers are not supposed to define.
You could consider the following scalability topics:
How to accommodate increasing numbers of users.
The number of SQL statements that can run and provide results simultaneously (assuming SQL will be the query statement of choice in your database—a big “if”).
How to accommodate increasing numbers of transactions per second.
Not only should you address the total number of users, but also you need to address total number of concurrent users.
Think back to the peak user requirement you saw:
5-108 The BOSS system data shall permit a peak of 300,000 people to enroll onto the system per day.
That works out to an average usage of 2,083 people per minute. Think about it, if this was enrollment for the ACA website, would everyone take a turn throughout the day? With Americans only having four different time zones in the continental United States, that is highly unlikely. You are more likely to see it in an eight-hour time period, spread over the four time zones. So, how can you accommodate that? Consider something like the following requirements:
5-109 The BOSS system data shall permit a peak of 30,000 people to enroll onto the system in one hour.
That works out to 8.33 people per second—on average. Again, you have to consider peak numbers and figure people will be on the system for say 5, 10, or even 20 minutes per person. You must write a requirement that takes into account that the peak time on for people is roughly 10 minutes. That drives up to a number of concurrent users like this:
5-110 The BOSS system data shall permit 10,000 concurrent people to enroll onto the system in one hour.
Note
Concurrent users are people on the system at the same time.
There are some things many people have not always thought about when scaling their systems—pull-down or pop-up menus. Assume you are writing an airline system and you want to add or delete specific flight numbers. You want this to be done quickly and with the least effort.
Traditionally, software had that information hard-coded into the system. That meant that to get the change, the code needed to be rewritten, tested, and then deployed. That process could take up to six months, depending on how quickly the turnaround time was. For this type of system, that is totally unacceptable. How do you fix it? Make it so the items on such lists are in files that can be easily rewritten and then just called by the application, without putting the list internal to the code. The update to the list is made and then sent to every customer location for replacement and can be available immediately.
Are you affecting the implementation? You could argue yes, but think of it more of an architectural constraint because of responsiveness to the customers’ needs. The requirements to consider are as follows (notice the “negative” statement):
5-111 The BOSS system lists shall entered in files external to the code so updates do not require a recompilation of the code.
You may need more requirements than this, but you will know your environment better than most.
Real-World Note
You need to learn about the system as much as you can. With that information, you will prevent potential misunderstanding about the system. I had a situation similar to creating lists where the discussion dealt with modification to a pull-down list. I had visited a stakeholder and they complained about old values in the list no longer being valid, and they wanted them removed from the list. I explained this to the developer, and he went ballistic on me, saying that doing that would screw up the referential integrity of the database and he would not do it. I calmly pointed out that I said that the customer did not want to see the values. I had said nothing about deleting the values from the database. To which the developer said, “Oh.”
So, you need to learn enough about the system (at least once it is deployed) so you can look out for the customer and work with the developers, designer, architects, testers, and even those who deploy it so you can aid the customers.
To generate growth over time whether for extensibility, scalability, or even just performance, some knowledge about the past is useful. If you have an older system that is fairly stable, you can get some good projections, with one proviso. If you are just improving on an old system but adding significantly new capabilities or new data sources, this projection may not be so stable.
Assume you were digitizing all your old hard-copy records; you probably have a good idea how much you have to digitize and how much that is likely to grow. For example, the federal government when they were given an Executive Order that says all digital records must be included by 2019. That means all existing digital records need to be included. You may not have a grasp of how much your organization has in e-mail, hard drive files, and databases. There could be significant growth there. Factors like this will significantly affect your growth that would not be represented by adding, say, 50 percent to existing hard-copy records. It could be a factor of three, four, or even ten times more.
In addition, newer systems may not have good historical information to help with estimating growth. Here, being conservative to keep costs down will have severe adverse impacts very quickly. It is better to estimate higher numbers rather than be too low. A word to the wise: This also explains the push by organizations to embrace the cloud architecture to help mitigate scalability. However, that discussion is beyond this text. Besides, it is implementation (unless mandated by architecture).
Usability
As defined by Merriam-Webster’s Collegiate Dictionary, usabilityis
convenient and practicable for use 5
Usability is how effectively users can learn and use a system. While many people think this applies only to computer software, think of your phone. That is a complete system with both hardware and software. Alternatively, think of your car. That needs to be easy to use.
Note
If you have ever test-driven many different makes of cars, say, at CarMax, or traveled often where you have lots of rental cars, you will understand that while the operation of the vehicle is consistent, the user interface, where everything in the interior is and how it works, varies drastically, which reinforces the point for standardization. That is another topic to discuss elsewhere.
How do you define user interface requirements for software and hardware? In part, a user interface is an implementation. Remember, what is good is clearly subjective, and requirements cannot capture subjectivity.
Then how can you capture user interface needs? One approach, and many projects take this, is to define user interface standards. This approach can take the subjectivity out of the requirements.
Another approach that is used extensively is prototyping. Again, you will learn more about this approach in Chapter 9. Basically, developers try approaches, run them by stakeholders, get feedback, and keep cycling through this process to get a valid approach that is acceptable to users.
Because of the importance of usability, you will spend a good deal of time on it. Thus, this topic will be captured in the Chapter 10 on user interfaces, given its importance.
Accessibility
Accessibility is the degree to which a product, device, service, or environment is available to as many people as possible. This usually focuses on people with disabilities or special needs and their right of access, enabling the use of assistive technology.
Do not confuse accessibility with usability, which is the extent to which a product or service achieves specified effectiveness, efficiency, and satisfaction goals. A significant source of accessibility comes from the U.S. government in the form of Section 508 of the U.S. Rehabilitation Act, which U.S. federal agencies must comply with in order to make their web sites accessible to the general public as well as government workers. Check out the U.S. General Services Administration web site, which has online training courses for free to learn about these rules.
What requirements should you capture for this subject? Obviously, you could say the following:
5-112 DRAFT—PARENT The BOSS shall be fully compliant with Section 508 of the US Rehabilitation Act.
As you have seen before, this does not address every aspect of it. You should go through Section 508 to address children requirements that are needed to be addressed for your situation.
Note
There are exemptions to 508 compliancy, such a military intelligence gathering systems in a combat zone and other special cases. Read about these and see if your situation applies. Look at www.section508.gov/ .
What are some candidate children requirements?
5-113 CHILD The BOSS shall provide a text equivalent for every non-text element (e.g., icon selection).
5-114 CHILD The BOSS shall provide a text equivalent for image linkages.
5-115 CHILD When electronic forms are designed to be completed online, the BOSS form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.
Clearly, this list is not complete; just a few examples were illustrated. However, you get the idea.
Interoperability
Merriam-Webster’s Collegiate Dictionary defines interoperability as the
ability of a system (as a weapons system) to work with or use the parts or equipment of another system 6
For software, interoperability describes the ability of different programs to exchange data via a common set of exchange formats so that they can read and write to the same file formats. The lack of interoperability can happen when people do not follow standards.
In software without standard data exchange formats, even within one application, the interface between modules of code becomes very complex. You can see how the need to have an interface with every other module grows quickly to be unmanageable. Hence, the industry developed SOA where there was an enterprise service bus (ESB ), the foundation/framework that all services (think a phone app) interact with, where the ESB provides the communications among the services. Then the services have one standard interface that they all must use. This is not intended to be a tutorial on SOA but introduces the concept so that you understand the concept and how you can write requirements should you need to define SOA and help craft interoperability requirements.
How do you write requirements for this? You might try something like this initially:
5-116 DRAFT—The BOSS shall be interoperable.
However, when you think back to the attributes of a good requirement, more than one attribute is not met. It clearly is not atomic, written to its lowest level. Additionally, this is subjective. Is it verifiable? Clearly, you need to be more specific. How about the following?
5-117 DRAFT—The BOSS shall follow the service-oriented architecture.
That is better, but again this clearly is not decomposed to the lowest level. What should you be defining? In this case, look at a write-up on SOA to see what capabilities it needs and capture those. For example, you could write the following:
5-118 The BOSS shall have a communications layer with only one interface for all services must follow.
5-119 The BOSS shall require all services to communicate only to the communications layer, not with other services.
Notice that this statement did not specify an ESB, JBoss, JEMS, and so on, but only using generic terms like services to keep from forcing an implementation onto the designers. That said, if your management or office architect has mandated that SOA will be followed, you can start with the SOA requirement written as draft earlier. That would be the parent requirement, say requirement 1.1, with all the SOA detailed requirements written as children to that 1.1 (e.g., 1.1.1, 1.1.2, … 1.1.N, where N is some number). That way, the testing would be done at the 1.1.N level, not at the 1.1 level, so you still have good requirement attributes.
Portability
Portability is the ability to run on numerous different computing platforms. You should address the following questions, at a minimum:
Can you application run on different operating systems?
Can you migrate the data to other systems?
Will your web applications work on different browsers?
Can the application run on different platforms without significant rework?
Look at requirements to consider as a start for the first three at least.
Different Operating Systems
5-120 The BOSS shall work on Windows 8.
5-121 The BOSS shall work on Mac OS X.
5-122 The BOSS shall work on Unix version 7.
5-123 The BOSS shall work on Linux version 3.13.
5-124 The BOSS shall work on Android OS 4.4.
5-125 The BOSS shall work on Unix.
Different Systems
5-126 The BOSS shall work on personal computers.
5-127 The BOSS shall work on Android phones.
5-128 The BOSS shall work on Xbox 360.
Different Browsers
5-129 The BOSS shall work on Internet Explorer 11.
5-130 The BOSS shall work on Firefox 29.
Remember to specify what, not how—that’s what the developers get paid the big bucks for. (Of course, given the RE’s significant value to the project, —REs should get bigger bucks. First, REs impact more defect reduction, and there are fewer REs than coders.)
Stability
In the medical field, this would relate to how long a drug would maintain its effectiveness. This would apply to any substance whose properties change with time. Clearly, the medical field is the primary area where this occurs.
5-131 The BOSS high blood pressure drug shall retain its potency of 95% for 12 months.
Does this apply to hardware components? That depends on if there are elements within the system that change with time. If, say, a battery is included, you might need to specify the life of the battery as it ages.
5-132 The BOSS Unit Radiation Dosimeter battery shall provide 5 volts DC for three years without replacement.
What about software? Can you think of any component of a software system that is volatile with time? None come to mind. (If you can, write to me.) The only stability relationship to software deals with how stable requirements in total are with respect to the original system. This would deal more with how well you maintain the requirements scope creep of a project, to help ensure its success, and not specific to particular group of requirements. In addition, the same would apply to any system, hardware and software. You have heard of cost overruns of military systems. That usually is significant changes in requirements with time.
Supportability
Supportability refers to “the inherent characteristics of design and installation that enable the effective and efficient maintenance and support of the system throughout the life cycle,” from class lecture at San Jose State University.
These are the requirements to make the deployment and maintenance as efficient as practical. For example, consider the following for the hardware project:
5-133 The BOSS Unit Radiation Dosimeter shall require no maintenance by the individual who wears its.
For software, it could involve requirements like the following:
5-134 The BOSS services shall be replaceable individual units that can be plugged into the infrastructure with requiring no affect to other services in the system.
There are more opportunities for additional supportability requirements, of course, so it may take some digging on your part to find them. You will see more about this subject in Chapter 8.
Testability
Initially, you might think that this is not something you would specify in the requirements, that this is captured in either contract documentation or test planning documentation. What about having certain testability built in to the hardware and software?
In the hardware example, look at the testability requirement:
5-135 The BOSS Unit Radiation Dosimeter shall require quarterly comparison of individual dosimeters against the BOSS Radiation Calibration Source.
There can be more examples of diagnostics in hardware systems. Think of a military aircraft that needs diagnostics run against various systems without requiring the aircraft to be taken down for maintenance.
In, the software example, think of diagnostic requirements:
5-136 The FBI BOSS Records Management Scanning function shall contain sample records to be used for scanning calibration.
As always, there are many more examples that you will want to consider for these types of requirements. A significant driver is the likelihood of change over time or the difficulty of making updates to the system. Think of software controlling a nuclear power plant or hardware on a deep-space probe. Testability is how easily something can be tested.
Recoverability
This means the ability to recover from some event, say, the crash of a system. How quickly do you return to full operations? Here’s an example:
5-137 In the event that the FBI BOSS Records Management system crashes, the system shall be returned to full operations in 48 hours from the beginning of the crash.
Of course, there can be varying grades of recovery. Here’s an example:
5-138 In the event that the FBI BOSS Records Management system crashes, the six critical functions shall be returned to operations in 4 hours from the beginning of the crash.
You will need to define what your critical functions are. Naturally, six may not be your number. This was just for the example. Notice that the requirement specified when the clock started—from the beginning of the crash. You could use start with the time the crash was detected or when the crash completed. Remember, some crashes may be gradual. This is why you should use the start of the crash.
The criticality of the system will drive how quickly you will want the system restored. In some extreme cases, you want it within, say, five seconds, in life-critical systems. This will drive design decisions such as the backup capability of the system and where all backups are stored with respect to the operational system. You may have an immediate backup co-located for quick switchover and maybe a second backup at another facility in the event of a natural disaster that destroys or eliminates the operational location for some significant time.
Would you use this requirement for hardware? Of course, not only do applications crash, but so do computer systems. If a lightning strike fries your server’s hard drive, you need a way to recover. In fact, look at the two requirements in this section. Nowhere does it say hardware or software. Therefore, these requirements apply to both.
Serviceability
Serviceability means how easy it is to perform service when it is required. Here’s an example:
5-139 The BOSS Unit Radiation Dosimeter battery shall be replaced with removal of the battery storage cover in five second and the battery replacement in three second.
For software, it could be the following:
5-140 The BOSS pick list values shall be replaced by copying a new XML file to the deployed software system without requiring recompiling any code.
Manageability
Manageability is defined as the ability to manage the system to ensure the continued health of a system.
The distinction between manageability and maintainability may not seem like much, but the nuance is important. Earlier in this chapter, you saw very detailed maintainability requirements, but here are some additional examples of maintainability requirements:
5-141 The BOSS Unit Radiation Reader shall have hardware functions as standalone cards that can be removed and reinstalled as plug and play components.
5-142 The BOSS Unit Radiation Reader shall have software functions as standalone services that can be removed and reinstalled as plug and play software components without affecting the rest of the software.
Now, look at some manageability requirements.
5-143 The BOSS Unit Radiation Reader shall have the ability to expand Random Access Memory chips on the standalone memory cards that can be removed and reinstalled as plug and play components.
5-144 The BOSS Unit Radiation Reader shall have software pick lists stored as files in order to add, change, or delete values without having to recompile the code and instead just replace the file.
The best distinction is to equate maintainability with the current system and to equate manageability with the future system. In addition, future does not mean years or decades from now; it could be weeks or days. Nevertheless, it helps to deal with the timing of changes. Having looked at other definitions, the boundary between the two is blurry. Regardless, this distinction you may or may not need to make. Nevertheless, if you combine the two, consider both the current and future aspects and you will not go wrong.
Summary
This chapter covered the more numerous nonfunctional requirements. Because of the more specialized nature of them, you will find that most stakeholders will be less knowledgeable about these types of requirements than the functional ones discussed in Chapter 4. In Chapter 9 you will learn some techniques for how to collect nonfunctional requirements. This chapter gets you started by identifying the types of requirements you will need to define.
References
“What is functional and non-functional requirement.” Stack Overflow. Feb. 2015. http://stackoverflow.com/questions/16475979/what-is-functional-and-non-functional-requirement
United States Government. Resources for understanding and implementing Section 508. Feb. 2015, www.section508.gov/
Zargar, Ali. “Supportability.” Tech 101 class lecture from Department of Aviation and technology at San Jose State University. Feb. 2015. www.engr.sjsu.edu/azargar/Tech-101/TECH%20101-Supportability.ppt
“Merriam-Webster’s Collegiate® Dictionary, 11th Edition ©2016 by Merriam-Webster, Inc. ( www.merriam-webster.com/ )
Office of the Under Secretary of Defense (Acquisition, Technology, and Logistics). DoD 4120.24-M Defense Standardization Program (DSP) Policies and Procedures. March 2000.
“How to write Performance Requirements with Example.” 2012. 1202PERFORMANCE, Performance by Design, Feb. 2015. www.1202performance.com/atricles/how-to-write-performance-requirements-with-example/
Exercises
Exercise 1
Define survivability with respect to the Hubble replacement. Determine whether this is functional or nonfunctional. Explain why.
Exercise 2
Define survivability with respect to the M-1 main battle tank replacement. Determine whether this is functional or nonfunctional. Explain why.
Exercise 3
Define cybersecurity for the Department of Defense’s Internet. Determine whether this is functional or nonfunctional. Explain why.
Exercise 4
At the Three Mile Island Nuclear Power Plant, their control room had alarms and flashing lights to alert operators of emergency situations. One factor that inhibited responses was the constant sounding of the alarms and the flashing of the lights. Should sounding alarms and flashing lights be used in the future? If so, why and how? If not, why not?
Exercise 5
Define the requirements for a phone to only call and receive phone calls, with no other features.
Exercise 6
Define the requirements for deep-space probe in the “Capacity” section in this chapter and show that the numbers work for transmission rate and capacity.
Exercise 7
In the “Quality” section, you examined the following scan scenario.
5-140 (5-20) The FBI BOSS Records Management scanning shall capture 75% of the characters per page to be considered a quality scan.
Now the default scan will be 300 DPI. If the scan does not meet the 75 percent, the process will be repeated at the 600 DPI, 1200 DPI, and finally 2400 DPI. If the 75 percent cannot be achieved at 2400 DPI, the quality achieved there will be the default.
Write the remaining requirements to address the last three sentences.
Exercise 8
This is a RAM exercise.
R1 to R6 all have reliabilities of 0.9. For the following configuration, what is the reliability for the following combination?
Exercise 9
Write the access requirements for the BOSS system that is stand-alone but with import of data.
Exercise 10
What areas on your cell phone’s specific phone services would need scalability?
Exercise 11
Write sample requirements to address portability so that the application can run on different platforms without significant rework.
Footnotes
1 By permission. From Merriam-Webster’s Collegiate® Dictionary, 11th Edition ©2016 by Merriam-Webster, Inc. ( www.merriam-webster.com/ )
2 By permission. From Merriam-Webster’s Collegiate® Dictionary, 11th Edition ©2016 by Merriam-Webster, Inc. ( www.merriam-webster.com/ )
3 By permission. From Merriam-Webster’s Collegiate® Dictionary, 11th Edition ©2016 by Merriam-Webster, Inc. ( www.merriam-webster.com/ )
4 By permission. From Merriam-Webster’s Collegiate® Dictionary, 11th Edition ©2016 by Merriam-Webster, Inc. ( www.merriam-webster.com/ )
5 By permission. From Merriam-Webster’s Collegiate® Dictionary, 11th Edition ©2016 by Merriam-Webster, Inc. ( www.merriam-webster.com/ )
6 By permission. From Merriam-Webster’s Collegiate® Dictionary, 11th Edition ©2016 by Merriam-Webster, Inc. ( www.merriam-webster.com/ )