Business Rules

Business rule requirements will generally be the larger section since many requirements can fall into this. What do you need your system to do? What are the features you need to have it do for you?

For example, in the Radiation collection example, you could start with this:

• 4-1 The BOSS Unit Radiation Dosimeter shall collect radiation exposure from nuclear fallout in a nuclear battlefield for the individual who is wearing the dosimeter.

You need to define all the features and activities for the various functions within the system. This chapter will address all these functional requirement types. In Chapter 7, you will learn how to organize documents (if you need to make a hard copy of your files or database). In Chapter 11, you will learn how to organize the requirements in the requirements database, although using the structure you learn about in this chapter is one approach. Remember, there is no one correct way to organize it. It is whatever works for you and your organization. You’ll learn more about that later.

For a software example, you can have the following:

• 4-2 The BOSS Payroll Function shall capture all payroll activities for the BOSS Company.

Realize that this is just one of many such requirements you will need to list to completely define your system. Obviously, this is a high-level requirement that needs subordinate requirements. For example, you might have the following:

• 4-3 The BOSS Payroll Function shall capture all people who will have payroll activities within the BOSS Company.

Based on the discussion earlier, 4-2 is a parent requirement, and 4-3 is a child requirement. That relationship was not obvious until you crafted requirement 4-3.

What kinds of features do you need to capture? The simple answer is everything. While the answer is simple, actually doing so is more challenging. Naturally, you will analyze this in more detail in Chapter 9. However, you will need to define all the kind of information that needs to be created, read, updated, and deleted (also known as CRUD—and no, it is not cruddy!), searched, reported on, and any other operations that need to be performed on it.

For hardware systems (with embedded software or not), you need to define everything it must do. Think of a car. At a very high level, you need to move from point A to point B. Then you get down to details such as moving forward in more than one gear ratio and going in reverse, steering the vehicle, looking in multiple directions, and so on.

Think of your phone. You need to be able to communicate with another person. So, you need to be able to connect with other phones (which implies some phone standards, but more on that later). You need to be able to receive calls. You want to have preloaded contacts that are easier to select from rather than remembering the phone numbers from memory. (Unlike the pre-digital age, you had to remember them.) Now, you want the ability to take pictures, see video, and so on. You need to break all these functions down into groups and then define all the requirements.

Transactions

This topic will cover several aspects of transactions. Not only will you examine entry of a transaction, but changing, deleting, deactivating/cancelling, and error checking and handling. I broke this into three sections, transaction entry, transaction change, and transaction errors, so you can see how to handle each.

Administrative Functions

Administrative functional requirements describe the functions that a system administrator (SA) performs on your system. Think of this as the person who can do virtually anything that most users cannot. These are the functions that maintain the system as a whole. The requirement should take the following form:

• 4-12 The BOSS System Administrator shall be able to (describe specific function).

First, make certain that there are at least two system administrators. The expression you may hear is, “What if he/she is hit by a bus?” First, you want to know where there are these crazed bus drivers so you can avoid them. Second, you should never be single-threaded no matter what management says. Have a requirement like this:

• 4-13 The BOSS System Administration function shall ensure at least two System Administrator accounts exist in the system.

What functions should they have? In some cases, data management in general is highly restricted, and the SA will perform all data-related functions, such as adding, changing, and deleting data. In other cases, there may be only a subset of data that is restricted to the SA. For example, give people accounts to the system as follows:

• 4-14 The BOSS System Administrator shall be able to add user accounts.

• 4-15 The BOSS System Administrator shall be able to change user accounts.

• 4-16 The BOSS System Administrator shall be able to deactivate user accounts.

• 4-17 The BOSS System Administrator shall be able to reactivate user accounts.

• 4-18 The BOSS System Administrator shall be able to delete user accounts.

You need to understand the difference between deactivate and delete. Deletion of accounts is a very rare case, say when a user erred when creating an account. Deactivate is when a person will no longer need access, although it could be reactivated again when the need arises—say a person has taken an extended leave of absence or gone to another part of the company, such as overseas.

SAs need the capability to manage system preferences and system values, back up and restore data, and generate and maintain system reports. Some system reports fall into the system monitoring reports that tell the SAs what the working condition is of the system, helping them to keep it running smoothly and efficiently.

If there are specific security levels within the system, the SAs usually maintain that. In some instances, there may be a security officer (SO) responsible for this function, but in others, the SA function performs it. Here the SA or SO assigns the different categories of access of the data or portions of the data. For example, if you have an HR system, most employees of the organization would have read access only. The HR personnel would have Add, Change, and Delete access. The SA or SO will create and maintain these levels.

SAs spend a significant amount of time monitoring the system; hence, most SAs are network or hardware types of individuals, where the maintenance of the accounts and other data manipulation is almost a secondary duty for them. However, your mileage may vary.

Authentication

Authentication is a mechanism to validate that the person or system is authorized to interact with the system. This is a mechanism put in place to verify the person/system is who they say they are. Think about paying for something online. When you pay via a credit card, you have to put in that three- or four-digit number on your card as a mechanism to prove you have the card. (Of course, that is not foolproof, such as when someone has your physical card.) There are devices to access computer systems to prove who you are. Think of biometrics where they read your fingerprint or perform a retinal scan as a way to ensure you are who you are.

Thus, the stakeholders will decide whether authentication is necessary for your system. It will aid in access control. The level of authentication then is important. For example, you could specify varying levels, like so:

• 4-19 The BOSS HR Regulation Function shall require fingerprint authentication to perform all tasks other than reading.

• 4-20 The BOSS HR Payroll function shall require retinal scan authentication to perform all tasks other than reading.

One area that is growing in use for authentication is biometrics. Therefore, it is important for you as an RE to know something about biometrics when you need to specify this type of authentication. First, the two requirements are one-for-one comparison. The system is only verifying you are who you say you are. This is not using, say, facial recognition at the airport to look for people on the no-fly list, where you are looking at all people and comparing them to a list of, say, thousands of people, a many-to-many comparison, which is much more difficult to accomplish than one-to-one comparison. One caveat with the many-to-many comparison usually applies only to identification. Since biometrics is being discussed here, the many-to-many comparison was included for completeness.

Additionally, and you can verify this by doing some research, biometric techniques have varying levels of confidence. Actually, facial recognition is one of the least effective (at the time of this writing, but it is improving) because of the few discrimination features and how faces vary day to day, with, say, facial hair or length of hair; the angles of the imaging versus the standard that it is compared to; and many other factors. Fingerprints are the most pervasive biometrics as they have been collected by far the longest, by decades. Retinal scans are the best at this point. (Obviously, DNA is the absolute best, but that is very difficult to use for a comparison needed in a matter of seconds or minutes—at least based on current technology.) However, each biometric has limitations for use.

Retinal scans would be difficult in airports. Think of the delays that would add to going through security. In addition, the public may be reluctant to expose themselves to it. Therefore, you must consider these factors. Do you need biometrics? If so, is it one-to-one, one-to-many, or many-to-many? What biometric should you use? If not biometrics, say you are in a trusted environment, what do you add to your system to authenticate the person or system? You need to look at the potential for harm if the system is compromised and the likelihood of it this compromise occurring. Here’s an example:

• 4-21 The Nuclear, Chemical and Biological (NBC) Officer shall be able to authenticate access to the BOSS Unit Radiation Dosimeter by entering his/her service number.

While this information needs a level of control, it is not catastrophic if others knew the information, which is the reason for the lesser level of authentication. The payroll system in the first two requirements in this section is more of a risk than the HR regulations, which is the reason for the higher level of protection.

Authorization Levels

Earlier in the “Administrative Functions” section, you briefly saw varying access levels of the data mentioned. Therefore, for the access, the HR data would look something like this:

• 4-22 The BOSS HR regulations shall be able to read by all company employees.

• 4-23 The BOSS HR employee only shall be able to add HR regulations.

• 4-24 The BOSS HR employee only shall be able to change HR regulations.

• 4-25 The BOSS HR employee only shall be able to delete HR regulations.

You will have to determine whether deactivate and reactivate is necessary for each function where deletions are possible.

You should examine all types of data that reside in your system and determine who can CRUD (change, read, update, or delete)—HR regulations, personnel information, payroll data (while it might be nice, should everyone have change privileges to their salary?), vendor data, billing, and so on.

This is not limited to only database or software systems. Think of the BOSS radiation system. You may want to have only the NBC officer in the unit read the values of the BOSS individual dosimeters so they may be able to determine the likely effectiveness of units after exposure to a nuclear battlefield. Alternatively, you only allow military medical personnel to read the values of a given soldier to determine what treatments a given person may need. For this example, assume it is both. Therefore, you would have something like this:

• 4-26 The NBC Officer shall be able to run the BOSS Unit Radiation Dosimeter to collect the individual radiation exposures of a designated unit.

• 4-27 The Medical Doctor shall be able to run the BOSS Unit Radiation Dosimeter to collect individual radiation exposure of a given person to assist with radiation treatment.

Audit Tracking

Audit tracking here does not refer to an Internal Revenue Service (IRS) audit, although there is a similarity. This process tracks important data and what happens to that data. For example, you want an audit of all transactions that the SA does. Given that is the most powerful person on your system, you want to know the history of changes made. Therefore, you want statements like the following:

• 4-28 The BOSS Audit Function shall capture all adds, changes, deletions, deactivations, and reactivations made by all system administrators.

• 4-29 The BOSS Audit Function shall provide a report that capture all adds, changes, deletions, deactivations, and reactivations made by all system administrators.

• 4-30 The BOSS Audit Function shall provide a report that capture all adds, changes, deletions, deactivations, and reactivations made by a specified system administrators.

• 4-31 The BOSS Audit Function shall provide a report that capture all adds, changes, deletions, deactivations, and reactivations over a given time frame.

• 4-32 The BOSS Audit Function shall provide a report that capture all adds, changes, deletions, deactivations, and reactivations for specified data records.

Remember that there are a lot more variations that you may think of or need, depending on the analysis. Realize that these audits may help if you have an SA that causes a problem, but that is the rare case (assuming your organization has good policies and pay in place). More likely, if an issue happens with some data, the auditing will help track down the reason so that the problem can be fixed or at least prevented in the future.

You will also want to do auditing for access to the system. Therefore, you will need the following auditing requirements :

• 4-33 The BOSS Audit Function shall capture all adds, changes, deletions, deactivations, and reactivations to access made by all security officers.

• 4-34 The BOSS Audit Function shall provide a report that capture all adds, changes, deletions, deactivations, and reactivations made by all security officers.

There are more potential requirements depending on your needs. In addition, here are some requirements for the Unit Radiation Dosimeter :

• 4-35 The BOSS Unit Radiation Dosimeter Audit Function shall provide a report that capture all adds, changes, deactivations, reactivations, and deletions of access to the BOSS Unit Radiation Dosimeter.

• 4-36 The BOSS Unit Radiation Dosimeter Audit Function shall provide a report that capture all adds, changes, deletions, deactivations, and reactivations for specified data records.

Do you need auditing of everything that exists in your system? Well, it depends. On what? It depends on the importance of the data therein. You can see the importance of the data that an SA or SO does, so it obviously needs to be audited. Now think of the online game World of Warcraft. Do you think everything that happens on that is audited? With millions of users and all the activity they do, it is not likely. Therefore, it comes down to how important it is to track changes to the data. If it does not change frequently, such as HR regulations, then you probably want it; in fact, it is most likely required.

On a more business-related note, do you need to audit all reads of the system? Chances are you do not. That said, there may be specific types of data for which you may need to do so. For example, you may want to track all queries of the roles and responsibilities assigned to users. If managers and SAs are reading this information, that is probably OK, and even a person checking their own data is also permissible. However, wouldn’t you like to know if one employee is searching all his/her co-workers’ data? This may be an intrusion of some kind.

In addition, are there laws or policies that require it? That is a decision for you to make, but not in a vacuum, as there are specialized stakeholders who will help you decide this .

External Interfaces

When you examine external interfaces, you are evaluating a system, program, or application that is not part of the system, program, or application you are defining. For example, if you are defining the personnel system for your organization and the organization already has the access control application implemented organization-wide, the access control application is external to the personnel system. In this case, you should capture the following requirement:

• 4-37 The BOSS Personnel System shall provide all access functionality by interfacing with the BOSS Access Control Application.

This is only identifying what interface the personnel system must have. You must specify much more information to define exactly what all the elements are and in what formats. You will see this level of detail in Chapter 7.

You need to apply the same approach to hardware as well. For example, an aircraft needs to interface with air traffic control, so you need to define that. In this case, the air traffic control specification is defined first, and then all aircraft need to follow that interface. Otherwise, if the aircraft defined a different one each time, what kind of mess would you have in the air? Think of one place where you see this implemented—especially if you have traveled to other states and countries and had different rental cars. The dashboards for cars are inconsistently implemented, such that the controls, like wiper blade activation, are often not where you expect them to be. Thus, for the radiation detection system, you will define the following interface:

• 4-38 The BOSS Individual Radiation Dosimeter shall interface with the BOSS Unit Radiation Dosimeter using a USB connection.

Whenever practical (and that is the important aspect), use something that is commercially available to allow flexibility to use standard equipment. Again, you must specify much more information to define exactly what all the elements are and in what formats. As before, you will see this level of detail in the Chapter 7.

Certification Requirements

Are there certifications that your organization or government requires for work done on your system?

Therefore, you may need a requirement such as the following:

• 4-39 The BOSS shall meet the Security Certification specified by (enter the appropriate organization here, say ABC Company Security Office).

This may spawn additional requirements that are specified in the security certification process, so you need to do some examination of it.

This also may apply to hardware, both computers, as well as the BOSS Dosimetry project:

• 4-40 The BOSS Unit Radiation Dosimeter Calibration Source shall meet the Nuclear Regulatory Commission Radiation Certification.

You get the idea. This can be an empty section or very small, depending.

Searching and Reporting Requirements

For many computer systems, this can be a large portion of the requirements as you specify what search and reporting requirements you need. This is also important for any embedded systems where data is resident inside the system that various users need to retrieve. This section of requirements will tell you how the users can retrieve the data.

Many of the systems in the past dealt solely with Boolean searches. If you do not understand what this means, you will need to learn it ASAP. Therefore, this will likely be your first requirement:

• 4-41 The BOSS Search Function shall execute user specified queries using the following Boolean operators:

  1. AND

  2. OR

  3. NOT

  4. AND NOT

  5. OR NOT

  6. ()

  7. NEAR—Term A and Term B are within N number of words

With the advent of more sophisticated search capabilities and the fact that many users are not trained Boolean users, other more robust techniques exist that may help users find what they need; for example, concept search exploits related terms without the user having to enter them specifically. For example, a user is interested in bombs. However, using Boolean-only operators, the user would need to have something like this:

• Find Bombs OR Explosives OR IED OR Weapons of Mass Destruction

You can see how quickly it gets complicated and still may miss something if they forget a particular word or phrase. (FYI, IED stands for Improvised Explosive Device .)

Thus, you probably want to have something like the following:

• 4-42 The BOSS Search Function shall execute user specified queries using the Concept Search capabilities to find terms that are related to terms entered by the user.

Examine an example for a medieval history class you might take. You need to find out about the Vikings. You would search on Vikings but not the Minnesota Vikings, so you might also omit football or NFL. However, did you consider Norse or Scandinavia or Scandinavian?

Writing good queries is an art form (just like writing good requirements). That said, requirements engineers need to provide the tools that could aid the user in finding the most correct information without overloading them with false hits. Another area that is growing in state-of-the-art querying is the use of machine learning. You will not see a big dissertation on this here as you can research it yourself if you do not understand it; however, it provides the capability to find subjects that may be close to what you are looking for, but you might not necessarily make a connection. There are many implementations of machine learning such as Latent Semantic Indexing (LSI), Entity Extraction, Natural Language Processing (NLP) , and many more. You may need to add requirements for machine learning .

• 4-43 The BOSS Search Function shall exploit machine-learning techniques to find data that are related to terms entered by the user.

Again, this may be a high-level requirement that you need to decompose, but this is the start point.

Of course, you need to specify what data a user can query. In most cases, users can see everything within a database. Other times, you will restrict what they want. You will learn more about that in the “Security” section in Chapter 5. However, the user may want to restrict what data elements they want returned. If you have 45 data elements in your vendor data but you want only the company name, address, phone and fax numbers, and points of contact, you should allow users to define that.

• 4-44 The BOSS Search Function shall allow users to specify the data elements returned in their query results.

• 4-45 The BOSS Search Function shall allow users to specify the order data elements returned in their query results.

• 4-46 The BOSS Search Function shall allow users to specify the format of the data elements returned in their query results.

This allows users to control how the data looks to them. Of course, there are many more query/search requirements. That said, once you define good search requirements, you should be able to reuse these core requirements the rest of your career. This gets into the requirements reuse previously mentioned.

Will there be search requirements unique to systems? Absolutely, just as there are data elements unique to a particular program or system, the manipulation of some of these elements will be different. Reuse what you can. In fact, ask around. Someone else in the company or organization may have done your work for you. Use it if you can find it. (Sometimes it is hard to locate, but the reward is good once you find it. Think of it as a requirements treasure hunt—finding the gold at the end of the rainbow.)

Now, what is the boundary between search and reporting? Well, gentle reader, this distinction is very distinctly blurred. A search result presented on your screen is in its essence, a report, usually just provided to the requester. Some define a report as something more formal and possibly more detailed. The report may be automatically generated by the system, on a specific schedule, and even distributed to various consumers of the data. Of course, the traditional report is printed out, though now reports are often distributed electronically in PDF or other forms. Printing becomes a personal preference.

The point is that the need will exist to create a hard copy in some instances. Of course, you could always save the report to a file also.

Here comes the quandary. Do you provide only the report generator and let users define all their reports, or do you have some canned reports that the development team creates and maintains? Realistically, you will generally see a mixture. How many of the canned reports are created by development is the main variable.

You will need to have some of both, then. Therefore, you will start with the following:

• 4-47 The BOSS shall provide a report generating capability.

Again, this is a high-level requirement that you need to decompose, but this is the start point. Now you need to list all the functions you want the report generator to provide. As with the general search requirements, once you have described report generator requirements, that should be the last time you have to define them, reusing them thereafter. In addition, as stated, reuse if someone else has done the work. Why reinvent the wheel when someone did it for you?

If you strike out finding a prebuilt set, what should you do? Actually, this is quite easy. Do some research of what capabilities report generators do, convert them to requirements, and you are done. You should look at more than one report generator, as some may be more specialized than others. Some may focus more on graphical representations versus textual capabilities. How many different graphical representations do you want? How much flexibility in column and row specifications do you need?

Many times, you create several dozen user stories (more about these in Chapters 12 and 13) and more than 100 requirements. All of these requirements should be of the following format :

• 4-48 The BOSS report generating capability shall provide (enter the need here).

Do not forget to provide the ability to create report templates that users can reuse and modify to suit their needs or to copy existing reports and modify appropriately.

Next, have a section for the canned reports. Here, you will have the following form :

• 4-49 The BOSS Report Function capability shall generate a (Report Name) Report which included the following data values scheduled every (enter the time period here, e.g., daily, weekly, monthly, quarterly, annually, every third Wednesday).

  1. Value A with Format NNNN

  2. Value C with Format A A A A A A

  3. Value D with Format NNA A A

  4. Value Q with Format A A A A A A A A A A A A A A A A A A A A A A A A

Is the canned report automatically generated, only manually activated, or both automatically and on occasion activated by a user? You have to specify it. Think about paper orientation, page size, and so on. What formats are reports saved to? Can they be exported to other applications, say Microsoft Excel or Microsoft Word or some other application your organization uses?

One word of caution with these two areas, search and reporting—cost. Given the number of capabilities in the market place, one likely solution is for the organization to buy a commercial, off-the-shelf package to do it. That is good. Why reinvent something someone else has already done? However, given the size of some organizations, you may want to place some constraints in the requirements set. For instance, you may want a requirement that says the following:

• 4-50 The BOSS Report Function capability shall not require a per-seat fee.

This is so that if you have an organization that has 5,000 people and a $10 per-seat license per year, you have a $50,000 bill just for your users every year. Some people may say this is out of scope for requirements, but REs should be responsible for the entire project, not just technical requirements. You will have to judge how much impact you can have. Ask for it, and the powers that be will take appropriate steps.

Compliance, Legal, or Regulatory Requirements

These are laws, regulations from government, compliance statements from organizations, and even internal policies and regulations that a given part of the organization or their particular systems must follow. In records management within the federal government, for example, there are mandated requirements all federal agencies must follow. State governments have them as well.

• 4-51 The BOSS website shall have every non-text item on a page is to have a text description to be fully compliant with Section 508 of the US Rehabilitation Act.

• 4-52 The FBI BOSS Records Management function shall retain a record of every hardcopy document in the permanent archive for the life of the Republic.

You will have to follow whatever legal, regulatory, or policy needs specified for your organization or type of project. It varies depending on what business you are in or project you are working on. Your stakeholders will know this, in many cases your senior stakeholders.

There may be other elements that you must comply with. For example, your company may have particular human resource compliance policies such as the following:

• 4-53 The BOSS Human Resource (HR) Policies shall only be modifiable by HR administrators.

• 4-54 The BOSS Human Resource (HR) Policies shall only allow a person’s Social Security Number to be used for HR purposes when the person gives permission to do so.

Legal regulations apply to various mandated laws such as Health Insurance Portability and Accountability Act (HIPAA) of 1996 levies rules about the release of your personal medical information.

• 4-55 The BOSS Human Resource (HR) Medical Policies shall be in compliance with HIPAA regulations.

This previous statement may need to be broken into more detailed requirements based on what data you collect and need to disseminate. This shows the high-level requirement you need to decompose, but this is your start point .

These types of requirements may not come from your typical system users but more specialized stakeholders, so you will need to do digging. You will see more about this when in the elicitation phase.

Historical Data

If you have a dynamic database, say all the purchases and sales by your large tire-producing company, you will have growth of data. Given that your data will grow, you need to define storage and retention requirements to accommodate this growth of data. Therefore, you can have requirements like the following:

• 4-56 The BOSS Tire Purchasing and Sales function shall generate 3 Gigabytes of data per year for five years.

You base this on a calculation of 1,000,000 purchases and sales per year and 2,000 bytes per transaction or 2 gigabytes. Then 50 percent was added to accommodate for unexpected surges.

You should also have a statement that defines the length of time given data should be available to be easily recalled by the users.

• 4-57 The BOSS Tire Purchasing and Sales data shall be available online for five years.

Is it a coincidence that this statement has the same length of time? Probably not. What drives this time period? How often do people need to access the data, whether for query or reporting? If it is less than once a year, clearly do not keep it online. However, if it is dozens of times by several departments, then keep it. Of course, the cost of storage may affect this decision when development comes along, so be prepared to justify why you gave the time period.

For the radiation dosimetry project, you could have this as well:

• 4-58 The BOSS Unit Radiation Dosimeter shall be able to maintain data for 1,000 transactions.

What happens after 1,000 transactions? Good question. That leads to the subject of the next section, archiving.

Archiving

At some point, the data within your system may grow beyond the storage capacity. In the case of the radiation dosimetry project’s 1,000 transaction limit, the project has the capability to archive the data to a hardened laptop for long-term storage. Thus, you will have requirements like this:

• 4-59 The BOSS Unit Radiation Dosimeter shall have the ability to download up to 1,000 transactions to the BOSS Dosimetry Archive Laptop.

• 4-60 The BOSS Dosimetry Archive function shall be able to maintain data for 5,000,000 transactions for fifty years.

Why so long? Think of the medical reasons associated with a soldier applying for benefits with the Veterans Administration after the war; the government must maintain the data for as long as the person was alive. Maybe 50 years is too short. Think of an 18-year-old soldier who lives to 90 years old. Don’t forget the following requirement:

• 4-61 The BOSS Dosimetry Archive Laptop shall allow the ability to recall archived transaction data.

Trust me, the ability to recall it is very important or why bother to archive it?

You need to apply the same process 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. Then you should have requirements as follows:

• 4-62 The FBI BOSS Records Management data shall be archived after five years online.

• 4-63 The FBI BOSS Records Management Archived data shall allow the ability to recall archived transaction data to the online system.

How long should the data be archived? The compliance, legal, or regulatory requirements section earlier would be the likely source that would specify such needs. For the U.S. government, permanent records are for the life of the Republic. Therefore, you might have the following:

• 4-64 DRAFT The FBI BOSS Records Management Archived data shall be maintained for the life of the Republic.

Hm, is that really practical? Are you going to be around to ensure this happens? You know you will not—life expectancy is not that long. So, how do you handle this? From past experience, very large systems may last 5 to 15 years, so the life of the Republic clearly is not met. One way is the following:

• 4-65 The FBI BOSS Records Management Archived data shall be maintained for the life of the FBI BOSS Records Management System.

• 4-66 When the FBI BOSS Records Management System is being replaced, the FBI BOSS Records Management Archived data shall be migrated to the replacement archive system so the data can be maintained for the life of the Republic.

Elegant, no? Important, clearly. How do you verify that? Hm, good question. That one cannot be implemented until the next system comes along, but the requirements should be carried forward, and then it can be verified by the next development effort.

Structural

This section primarily applies to hardware systems. You are looking for those items that address how hardy the part needs to be. For example, if you are building a bridge, how much of a load must the bridge be able to support? Here’s an example for a bridge across a small ravine that spans about 100 feet:

• 4-67 The BOSS Lost Creek Bridge shall support two lanes of traffic of 300 tons.

You will need to consider many factors, such as wind shear, and all other such needs. You must define any force applied to your system. Will it be exposed to lightning, rain, snow, hail, salt, seawater, freezing, heat? Will the system be moving? If so, drag will be a factor. Will oxidation be a factor? The DoD has extensive documentation to help with these kinds of factors. You need to define all these environment stresses to the hardware that will affect the structural integrity.

There could be structure in software, such as architectural structure for a database, which is specified by architects. Users specify the data that resides within that structure but not the structure itself. Chapter 7 details the user data needs you need to define in the database section. Sometimes, you may have specific structural requirements as standards your organization needs to follow. That is about all you would do for requirements. Design specifications are another matter. Then the designers would get specific about what they have chosen. The architect may have identified that the BOSS Architectural standard must be followed. The designer provides a statement that “the BOSS HR system will use the ORACLE database, which meets the BOSS architectural standard.”

Notice that this type of requirement is hardware specific.

Algorithms

Algorithms capture any formulas or specific manipulations of data elements that need to occur. It could be something as simple as calculating how much postage to put on a first-class envelope based on the weight as follows:

• 4-68 The BOSS Cost of First Class Letter Postage data element shall be determined with the following look-up table:

Alternatively, it could be something more like Einstein’s famous equation E = MC², as follows:

• 4-69 The BOSS conversion of mass to energy data element shall be determined by multiplying the change in mass by the speed of light times the speed of light, using the metric units.

The requirements are as unique to the needs of your system. For example, in the radiological collector, the energy is collected by the energy of the particles and photons incident on the collectors, and a conversion to the REM equivalency must be specified. You will not do that here as that is beyond the scope of this text, but you understand the need for it. If you are in a situation where such a technical capability is needed, find the resident expert that can explain to you what requirement needs to be captured.

Depending on the kind of project you are working on, you may not have any algorithms, especially sophisticated mathematical formulas.

Notice that this type of requirement is software specific. Yes, hardware may have algorithms embedded in them, but they reside in the software.

Database

Here you are going to learn what data elements and formats you should use when defining data to store in the proposed system. You will spend a significant amount of time learning how to do this in Chapter 7. However, you will need to define all the elements that users need. For example, in the record management example:

• 4-70 The FBI BOSS Records Management shall store the record title/subject in a text field of up to 80 characters.

For the hardware example, you would do the same:

• 4-71 The BOSS Individual Radiation Dosimeter shall store exposures in a range of 1 to 800 Rem.

• 4-72 The BOSS Individual Radiation Dosimeter shall store exposures in the following format, NNN where N is numeric only.

Notice that this type of requirement is software specific. The dosimetry requirements are for the software embedded in the system.

Again, reference Chapter 7 for the detailed examination.

Power

This is very straightforward. What power do you need for your system? For the dosimetry project, you might have the following:

• 4-74 The BOSS Individual Radiation Dosimeter shall require 5 volts direct voltage.

Will this require the individual radiation dosimeter to have an adapter to recharge it? If so, you may not need to replace batteries. The soldier will be walking around away from equipment. Thus, the combat situation might mean that the device cannot connect to a charger easily. However, the Unit Radiation Dosimeter might need all of the following:

• 4-75 The BOSS Unit Radiation Dosimeter shall use an internal 12 direct current source of power.

• 4-76 The BOSS Unit Radiation Dosimeter shall use an external 110 to 120 alternating current source of power with 60 Hz.

• 4-77 The BOSS Unit Radiation Dosimeter shall use an external 220 to 240 alternating current source of power with 50 Hz.

Why do you need U.S. and non-U.S. specifications? Because this system can be deployed anywhere in the world.

Do you need to specify this for the computer system, say the records management system? If the application will be placed into an existing network, no. If, however, you are going to specify the hardware for your system, then you do need to. Here’s an example:

• 4-78 The FBI BOSS Records Management shall use an external 110 to 120 alternating current source of power with 60 Hz.

This system will not be deployed anywhere except in the United States; hence, the U.S. power grid is sufficient.

Notice that this type of requirement is hardware specific.

Network

As part of your requirements, you will define any network that is needed for your project. Will you need it for the dosimetry project? The individual dosimeters are read by the Unit Radiation Dosimeter, through a direct connection, so no. The Unit Radiation Dosimeter is a stand-alone device, so no network is involved. The backup is an external hard drive, and even the connection to the archive is by Wi-Fi, so technically you have no network. However, you should ask yourself these questions for each project.

The records management project is another matter. You will have a network for it. Of course, if the FBI center you go into has a network that the application will reside on, you just need to specify that. However, if one does not exist, you will need to specify what your network should consist of.

• 4-79 The FBI BOSS Records Management shall need a server for application and data records of the system.

You will need more information about the server. However, you will derive some of the specifications from the storage that the system needs, how much memory, and so on. So, let the developers and designers come up with it. What will the user need to connect to the server?

• 4-80 The FBI BOSS Records Management shall need 240 individual devices to connect to the server to access the application and data records of the system.

Elsewhere you will learn about any growth, but you should have a good estimate of the number of users when you write this requirement. What kind of network must it be? If it is known, capture it. Any other data should be specified also, from the needs standpoint, not the implementation. Is this a LAN, just a local network, in say one building, or is it a WAN, a wide area network, say in multiple states, or an entire city? All these needs affect the network requirements.

Notice that this type of requirement is hardware specific.

Infrastructure

Let me differentiate between structural requirements and infrastructure requirements. Structural requirements deal with the item itself. This includes what kinds of things it is made of and how it might be built to withstand its operational environment. Infrastructure consists of the things around the item so that it can do what it needs to do. The easiest example is to think of yourself as a “system.” When you go to work, what things are at your place of employment so you can do your job? Those things are the infrastructure.

If you were going to build a call center, what kind of support would you need? If the building existed, that is one item out of the way. You would need something like the following:

• 4-81 The FBI BOSS Records Management Call Center shall need an external 110 to 120 alternating current source of power with 60 Hz.

What phone connectivity will you need? Will you need Wi-Fi? Internet connectivity? If so, what throughput will you need? If you do need to construct the building, what specifications will you need? Here the experts will be necessary.

For the dosimetry project, will you need infrastructure? Since this is a system deployed in the field, the system probably will not require infrastructure, except for possibly the archive system. Where will it reside? How will the system transmit the archived data to it? Does power, security Internet, possibly Wi-Fi, and so on? Probably not? If so, you will need the following:

• 4-82 The BOSS Dosimetry Archive Laptop shall need a Wi-Fi source at the Brigade headquarters (HQ) element to receive archive transmissions from the field BOSS Unit Radiation Dosimeters.

Notice that this type of requirement is hardware specific.

Backup and Recovery

You will want to have a backup and recovery function within your system. Otherwise, what happens if your system crashes and wipes out all your data? Therefore, you might have something like the following:

• 4-83 The FBI BOSS Records Management shall have a complete system and data backup once a week.

Obviously, losing a week’s worth of data in unsatisfactory, so you should have maybe a daily incremental backup, where that service captures the difference from the previous day. However, is even losing one day’s worth of data acceptable? Most likely not. Therefore, you may want to capture backups of transactions as they occur.

• 4-84 The FBI BOSS Records Management shall capture an incremental backup of each transaction as they occur.

You will need to specify where the backup is. Will you have one onsite? If so, what happens if a hurricane, earthquake, terrorist bombing, tsunami, tornado, or flood hits? You should have a backup site in a completely different site as well.

For the recovery aspect, you should specify how quickly you should be up and running. Here’s an example:

• 4-85 The FBI BOSS Records Management shall be able to recover from the operational system within four hours from the local backup.

This may be unacceptable for many mission-critical situations, where it may be in seconds. It depends on your needs. It may be longer if you have to do it from the remote site. There it may be dependent on getting users to the remote site. It might be a day.

Would you need the same backup for the dosimetry system? An individual dosimeter may not be catastrophic, as there are other people in the same unit. The Unit Radiation Dosimeter might want a hard drive backup and a restore feature.

• 4-86 The BOSS Unit Radiation Dosimeter shall capture an incremental backup of daily transactions.

• 4-87 The BOSS Unit Radiation Dosimeter shall be able to recover from the operational system within four days from the local backup.

Why so many days? Good question. If the laptop is inoperable and cannot be repaired, it needs to be replaced. How quickly can one be acquired? Second, is it critical that the information be readily available compared to other operational status? Probably not, so the four days may be acceptable.

Exercise 1

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 2

Define the requirements for a phone to only call and receive phone calls, with no other features.