Secure System Analysis

Analysis is “a detailed examination of anything complex in order to understand its nature or to determine its essential features: a thorough study.” In other words, analysis is a detailed investigation of the elements or structure/substructure of something or an entity.” The main purpose of system analysis is to understand the system under study. A system under study can be any entity we want to understand and know about. For example, it can be an organization, a division, or a department. Every entity has an inherent information system that it uses to support its operation and management. This information system can range from an informal and manual system to a formal, automated, and intelligent system. An entity can be viewed as a work system. A work system is “a system in which human participants and/or machines perform work securely using information, technology, and other resources to produce products and/or services for internal or external customers.” This definition highlights the major components a systems analyst must pay attention to understand an entity. An entity which is the object of study is called an object system. An analyst should study the available internal and external resources/documents about the object system to gain a basic understanding of the system. The analyst can then use other fact gathering techniques like interviews, survey, and observation to collect further information about the system so that a detailed understanding of the object system’s needs including security and protection needs can be achieved.

System analysis answers the “What” question. What is required of the new system to support the functional and other needs of the object system? It is very critical to understand the structure and features of the object system to answer what question.

The major output of system analysis activity is the system requirement specification. System requirement specification consists of functional and non-functional requirements. A requirement specification of an object system includes the following:

1. A function model of the object system
2. A data (information) model of the object system
3. Non-functional requirements such as security, protection, performance, usability, and reliability etc.

A requirement specification for the object system becomes input to system design step to develop a new/improved system to support the requirements. Note that the word system in system design refers to the new system to be developed whereas the word system in system analysis refers to the object system. We analyze an object system to identify its requirement specification. We design a new system to fulfil the requirement specification.

Here, we discuss system analysis activities such as identifying the problem, fact gathering, discovering, and understanding the details including the security and protection details, modeling, documenting the requirements, and obtaining the approval, etc.

System Analysis Activities

Generally, system analysis activities begin after the system to be studied has been identified and sanctioned by the management. A quick feasibility study may be performed to evaluate the viability of further analysis.

System analysis consists of several activities. These are:

1. Problem identification.
2. Fact (data or information) gathering.
3. Discover and understand the details.
4. Develop secure function model, secure data model, and dynamics model, if necessary.
5. Identify non-functional requirements.
6. Prepare the system requirements specification document.

We discuss these activities below.

Problem Identification

A problem is defined as the difference or gap between how the object system performs and how it should perform. The problem can also be stated as the gap between “what it is” and “what is needed.”

A problem is often the result of many causes. We must understand the root causes of the problem and not just the symptoms. Symptoms are generally the signs of an existing problem whereas the root causes are the problem (reason) behind the problem.

A problem is defined after gaining the views of users and stakeholders of the system. The problem definition includes the system boundary and the constraints to be considered when specifying the solution to the problem.

Fact Gathering

Fact Gathering is the activity of collecting actions, data, feelings, interpretations, constraints, and plans regarding the system under study. The gathered facts help us get a deeper insight into the functioning of the system. Fact gathering generally starts with reading existing documents about the system.

Reading Technique

Reading is one of the best ways to get the initial bearing about a system. It enables you to collect facts from already existing documents before interviewing people for additional facts. Active reading is required for understanding the material in documents rather than just skimming the material. Reading is not an easy skill to acquire. It requires practice to master the reading skill.

Documents can be internal sources as well as external sources. As an example, let us say that a city mayor wants to improve the city’s budgeting and planning system and the mayor hires an analyst to conduct the analysis of the budgeting and planning system. In this case, the analyst has access to the city’s internal documents on budgeting and planning activities. The city is a municipality. It is a local government and has corporate status. There is a lot of literature on municipalities and their activities. This literature is available in libraries and other places widely and serves as external documents that discuss the various activities of a city. Examples of internal documents include mission statement, vision statement, business model, strategic plans, policies & controls, process descriptions, work records, metrics, reports, e-mails, and customer complaints, etc. Examples of external documents include description of existing solutions to similar problems, reference books, case studies, research papers, and Internet, etc.

Reading techniques are not effective if the internal documents are not accurate and current. Dated documents can give incorrect facts about the organization.

Besides the reading technique, the following techniques are also used to collect facts about the activities of a system.

1. Active and/or passive observation of a process in action.
2. Interviews of selected people.
3. Survey of people involved with the system.
4. Brainstorming with selected people.

Process Observation

Some business processes are too complex to understand by just talking to their users and operators. They require the active participation of an analyst in carrying out the steps and following the workflow of a process. Active observation is a participation technique that clarifies the actions/steps/workflows involved in a business process. It is especially effective in understanding complex processes. Active participation, however, may influence and change the behavior of the users/operators conducting the process. In that case, an analyst may not get a correct view of the steps. In that case, the analyst may have to work with the users and gain their confidence before collecting facts. Passive observation does not require participation in conducting a process. An analyst watches the activities of a process from a distance. Here also, the users have to be taken into confidence to get the real picture of the process.

Interview

Interview is a formal either face-to-face or virtual meetings between an interviewer and interviewee for the ascertainment of certain facts. Interview is one of the primary techniques for fact gathering. Interview is resource intensive. It requires scheduling and time commitment from users. Therefore, an interview should be conducted aptly and to the point. This requires an interviewing skill that an analyst must develop to be an effective interviewer. Proper preparation must be made before the commencement of an interview. Certain ground rules should be followed during the interview and after the interview has terminated. Some of these ground rules are:

1. Let the interviewee know the reasons for the interview.
2. Establishing the tone of the interview.
3. Gaining the interviewee’s trust.
4. Stressing the importance of the interview.
5. Taking the minimum notes during the interview to avoid distractions.
6. Thanking the interviewee for her time.
7. Documenting the interview facts immediately after the interview.

An interview should not last for a long time. A long interview is inefficient in gathering useful information. 20 to 30 minutes of time for an interview is considered optimal. Analysts should use the interview time mainly to confirm the facts.

Survey

Sometimes we need to collect facts from a large group of people. For example, let us say that we are developing a system to be used by many thousand engineers. It would be next to impossible to interview all the engineers. In such a situation, it will be prudent to interview some select group (i.e., a total of 5 to 10) of engineers to collect facts and send out a well-designed questionnaire to the remaining engineers to survey their opinions on the facts. Questionnaires can contain open-ended and closed-ended questions. Questionnaires generally do not provide complete answers because some subjects may not answer all the questions. Also, the answer to open-ended questions may be difficult to interpret.

Brainstorming

Brainstorming technique can be viewed as a creative thing technique to bring out and discuss new ideas among a group of people. Free-thinking and freewheeling are allowed to generate ideas. A consensus is formed after certain iterations of brainstorming. Brainstorming techniques can be used to understand ill-defined problems and processes.

Discovering and Understanding the Details

Fact gathering activities generate data/facts about the object system. These facts need to be put together under the proper context and expanded to reveal finer details to see the big picture of the functional and the non-functional aspects of the object system. Detailed facts may reveal duplicates, similarities, and differences among the facts. The function and data are discussed, described, appraised, examined, questioned, arranged, classified, and clustered to form manageable hierarchies. Formal models are developed from these hierarchies to document the object system’s functional and non-functional needs. Formal models are needed to minimize the ambiguities in the description of the system.

Every system has two main complimentary parts—function and data. Functions represent tasks/activities to be performed by the system. Data represents inputs, outputs, controls, and constraints to be used by functions. So, the functions and data must be represented and documented precisely. Secure functions and data models are used to capture the functional and data needs of an object system.

Secure Function Model

A secure function model is a function model that describes the functional and the security needs of an object system. Identification and description of security and protection functions is an integral part of a secure data model. A secure function model can be developed using various techniques such as data flow diagramming, use case modeling, integrated definition (IDEF) method, etc. In this article we will adapt use case modeling to develop and demonstrate a secure function model.

Secure Data Model

A secure data model is a data model that includes data objects required to design secure functions. The two most popular methods for developing a secure data model are class diagram and entity-relationship diagram. We will use a class diagram (i.e., a UML class diagram) to represent a secure data model in this article.

Most of the functional requirements are covered by secure functions and data models. System requirements specification (SRS) must be complete and correct. One way to cover all aspects of requirements is to use FURPS+ framework. FURPS+ is an acronym that stands for functionality, usability, reliability, performance, and supportability. The “F” in FURPS is equivalent to the functional requirements defined previously. The “URPS+” part of the framework covers the non-functional requirements.

Non-Functional Requirements

Non-functional requirements are various kinds of constraints a system must follow while conducting its activities. Most of the non-functional constraints are categorized as usability, reliability, performance, supportability, and design and implementation constraints.

Usability constraints relate to the utility and the usefulness of the system to its users. Usability constraints may specify, among other things, user-interface, and online help requirements.

Reliability constraints address the robustness, and dependability, etc. of the system. It is generally measured/specified in terms of meantime between failure (MTBF).

Performance constraints specify the performance requirements of the system in terms of its capacity (volume, transactions, etc.) and response time.

Supportability constraints address the ease of installation, configurability, and monitorability, etc. of a system.

The “+” symbol refers to the design, implementation, and other constraints. Design and implementation constraints specify hardware, software, and programming environments, etc. that must be followed in designing and implementing a system.

System Requirements Specification

System requirements specification is a formal statement of object system’s needs for a new and/or improved secure information system. An SRS is a very critical document for the development of the new system. It is the foundation on which the system is built upon. All the subsequent phases of the system development—design, implementation, and maintenance depend upon the requirements specification. Every team member and other stakeholders need to know the specification unambiguously. An SRS describes what new/improved secure information system needs to do. More specifically, an SRS includes:

1. Functional requirements in the form of secure function model and secure data model and the cross-validation of the function and data models.
2. Non-functional requirements such as reliability, performance, and supportability requirements in quantifiable form.
3. Design and implementation constraints.
4. Design standards manual.