MIS 322 Chapter 4

Specifying Functional Requirements for System Design

(1) Business process: - The DFDs themselves (2) User-perceived information: - The DFDs themselves (3) Business rules: A workflow is a sequence of operations of a routine which has its start point and end point. - A fragment of DFD for an operational sequence. A decision is the selection of a course of action among several alternative actions in response to a certain condition(s). In process descriptions

Level 2 diagram

(1) Select a process in the Level-1 DFD to decompose it into the Level-2 DFD. (2) Include all external entities and data stores which are directly linked to the decomposed process in the Level-1 DFD (see the external entities and data stores marked in bold-line in Figure 4.14) in the Level-2 DFD (see the external entities and data stores marked in bold-line in Figure 4.15). (3) Include all data flows in the Level-1 DFD which are directly attached to the decomposed process (see the data flows marked in bold-line in Figure 4.14) in the Level-2 DFD (see the data flows marked in bold-line in Figure 4.15). (4) Replace the decomposed process in the Level-1 DFD with several (e.g., 7 plus and minus 2) detailed processes for the Level-2 DFD, and link all external entities, data flows, and data stores inherited from the Level-1 DFD to the processes in the Level-2 DFD (see the part marked in bold-line in Figure 4.15). (5) Create data flows between the detailed processes in the Level-2 DFD. New secondary data flows to or from the external entities as well as new detailed data stores may be added if needed (see the data flows to/from Client in fine-line in Figure 4.15). (6) Assign an ID for each detailed process in the Level-2 DFD, following the DFD convention that a process ID in the Level-2 DFD is an extension of the process ID of its parent (Level-1) process. For example, the process ID in the Level-1 DFD is "1", and the its children processes' IDs in the Level-2 DFD would be "1.1", "1.2", and so on (see Figure 4.15).

Decomposition

(1) System decomposition needs business skills and system thinking skills. (2) The decomposition procedure is rather artistic. (3) To describe the segments clearly, one step of decomposition creates around 7 (plus or minus 2) segments in common practices. (4) The identified segments should have overlaps with each other. This would make the integration of segments easier.

functional requirement : Business process

A business process is a set of business activities performed by human actors and/or the information system to accomplish a specific outcome.

Major Tools of Business Process Modeling

A business process modeling tool is a formalized visual language that provides systems analysts with the ability to describe the business processes unambiguously, to visualize the business processes for systematic understanding, and to communicate the business process models for the information systems development.

functional requirement : Business rules

A business rule is a statement that aims to influence or guide business processes in the organization. A business rule specifies the relationships between an anticipated condition and expected actions or outcomes.

Decomposition

A context diagram describes the overall system, but does not describe perceptible and measureable system requirement in detail. To understand more about the information system, the system analysts must decompose the entire information system into sub-systems. To do so, segments are identified.

Context diagram characteristics

A context diagram has the following characteristics. (1) A context diagram has a single overall process that represents the entire information system. (2) A context diagram includes all external entities. (3) A context diagram includes all major data flows that represent the substantial interactions with the external entities. (4) A context diagram does not show data stores which are inside the overall process.

Context diagram

A context diagram shows the entire system as a single process, and represents the system's interactions with the environment using data flows. A context diagram is also commonly known as "Level-0 DFD".

Data Flow Diagram

A data flow diagram (DFD) is a graphical representation of the business processes and the flows of data through an information system. The central concept of DFD is the top-down approach to understanding a system. The DFD tool is good at modeling business processes in the aspects of operation and data, but is weak in the aspect of business rules A business process can be decomposed into several sub-processes. Each of the sub-processes has its own goal of transforming its input into the output, and can be further decomposed into its sub-processes.

Nonfunctional requirements

A nonfunctional requirement specifies a characteristic or property of the information system must have.

functional requirement : User-perceived information

A piece of user-perceived information is always associated with a process. Input is the acquired information captured by the process. Output is the delivered information produced by the business process. Navigation information provides the direction for the user to proceed through the business process.

Systems Analysis Report

A system analysis report is a documentation of system requirements for the to-be system. The complete definition of the project scope. The problem analysis of the as-is system, and the objective of the to-be system. The system requirements analysis, including all information collected by the requirements process.

system is

A system is a set of interacting or interdependent components that form an integrated whole to achieve a certain goal. An information system is a system.

Simple rules can be applied to system decomposition:

Any external entity in the parent DFD must be kept in the children DFDs. Any data flow in the parent DFD must be kept in the children DFDs. In some cases, a data flow in the parent DFD can be split into two or more data flows in the children DFDs, but the data items conveyed by the data flow must not be lost. Any data store in the parent DFD must be kept in the children DFDs. In some cases, a data store in the parent DFD can be split into two or more data stores in the children DFDs, but the data items stored by the data store in the parent DFD must not be lost.

Business Process Modeling Notations (BPMN)

BPMN is a graphical representation for specifying sequences and steps of business processes. BPMN can provide detailed specifications for automation of business processes, and thus are ideal for systems construction, but is short of the ability of top-down system modeling.

Balancing

Balancing refers to ensuring that the information presented in the parent DFD is accurately represented in its children DFDs. This does not mean that the information presented in the two generation DFD is identical. Balancing means that the children DFDs can always present more detailed information than the parent DFD does, but must not lose the information presented in the parent DFD.

Business Process Modeling

Business process modeling is the primary systems modeling work for systems analysis and design because the business process model of the organization is the central abstraction that describes the business functional requirements and lays the foundation for other system models in the system development.

CASE tools

CASE (Computer Aided Systems Engineering or Computer Aided Software Engineering) tools are a category of software that supports the information systems development process A CASE tool can be used to coordinate the project team activities, and to facilitate knowledge sharing among the project team members. A CASE tool allows the project team to follow the standard terminology. A CASE tool is not just a computer drawing tool. It can have intelligent features to verify the systems analysis and design results. A CASE tool can generate consistent documents with detailed information for each phase of the SDLC.

Important properties of DFD

DFD is a better tool than natural languages (e.g., English). DFD is quite simple to use, and is easy to understand. The processes expressed in a DFD may or may not operate sequentially.. This example of DFD represents a simple business process. If the business process is complicated, a one-page DFD can be huge. A huge DFD is not practically usable for communicating system requirements.

Level-2 diagram

Each process in the Level-1 DFD can be decomposed into a more detailed DFD, called a Level-2 DFD, in the similar way that the context diagram is decomposed into the Level-1 DFD.

. Data Modeling

Entity-Relationship Diagram (ERD) for data modeling. For system acquisition, data modeling is not really needed. This part is fully covered by an independent database course.

Techniques of Requirements Information Collection

Experiencing and observation Interview Joint Analytical Development (JAD) Documents review Questionnaire

DFD Elements

External entity Process Data store Data flow

(1) Start with the external entities. Heuristic-1:

For each external entity, there is a segment which contains operation process and/or support process to provide information services to the external entity.

(2) Move to organizational support. Heuristic-2:

For each organizational function areas, including accounting, human resource management, marketing, finance, inventory management, and supplier chain management, identify a segment(s) with a general supporting process(es) that supports the processes in the identified segments for external entities.

Move to managerial decisions. Heuristic-3:

Look into managerial decision processes that are applicable to the systems.

Nonfunctional requirements: Others

Multiple languages. Pricing competitiveness. Cultural and religion consideration.

Primitive processes:

Primitive processes: a process can be described clearly in no more than a dozen lines of short sentences of English, so-called structured English.

Nonfunctional requirements: Performance

Reliability - the extent to which the system is available to the users in all circumstances. Scalability - the ability of the system to increase the capacity in response to additional needs. Speed - the time for the business processes.

Nonfunctional requirements: Vendor

Reputation. Services such as maintenance and upgrading. Business alliance for the long term consideration. Training availability. Standardization and industrial common platform.

Systems thinking approach

Systems thinking is the process of understanding how components of the system influence one another within a whole. Systems thinking provides a view of the business process as a whole in the context of information services, and concerns an understanding of the linkages and interactions between the elements that compose the entirety of the information system.

Unified Modeling Language (UML)

The UML includes a set of various types of diagrams with different subjects of modeling and diversified graphics styles. Four dominant UML diagramming techniques are: use case diagrams, class diagrams, sequence diagrams, and behavior state machine diagrams. It is good for software construction, but is weak in business process modeling.

Unified Modeling Language (UML)

The UML is a general-purpose modeling tool in the field of software engineering for constructing all types of computerized systems including computer operating systems, industrial control systems, geographical information systems, image processing systems, data communication systems, business information systems, and others. The object-oriented approach views a system as a collection of self-contained objects, including both data and processes.

Summary of business process modeling tools

The business process modeling tool used for systems acquisition development must be effective for examinations of software products. DFD is a practicably workable tool for systems acquisition development in comparison with other builder-centered business process modeling tools.

. Systems Analysis Report (cont'd

The business process models of the as-is system and the to-be system. If the system project is systems construction development, the data model for the to-be system should also be included. A proposal for the systems design phase. The systems analysis report must go through an approval process in accordance with the structure and rules of the organizational.

Level-1 diagram

The layout of DFD is not crucial. However, the number of data flows that cross each other should be minimized to avoid confusion or disorganization. Commonly, the shared data stores are placed in the middle of the diagram, the external entities are placed near the edges, and the processes are placed close to the data stores. If necessary, data stores and external entities can be duplicated. Generally, the processes represented in a Level-1 DFD operate in a parallel manner, and a sequential order between the processes may or may not exist.

Scope of system and lower level DFD

The number of levels of decomposition depends on the scope of the system. It is rare to have cases with more than seven levels for a project.

Nonfunctional requirements: Security

The system should have safeguards against unauthorized access, cyber attacks, and information loss.

Selecting techniques for collecting requirements information

The systems analysts must select several techniques, given the fact that none of these techniques is perfect for systems analysis. Select best techniques to ensure that all functional requirements and nonfunctional requirements for the to-be system are complete, unbiased, and accurate.

Contrasting the As-Is and To-Be systems

To make the contrast of the as-is system and the to-be system easy to observe, the layouts of the DFDs at the corresponding levels should be alike. Technically, the use of copy-paste operations in the CASE tool environment not only saves time, but also, more importantly, makes the two sets of DFDs consistent.

Nonfunctional requirements: Usability requirements

Usability requirements specify the user-friendliness of the information system. Quality of the user interface of the system, and the easiness of use. Degree of error tolerance. Quality of documentation, including reference documents, operation manuals, and tutorials. Unique operational features, e.g., data visualization.

Data store

a data store is a data repository of a set of integrated data used by the system. it can be a data file, a data table, or a set of data tables. A data store has a unique "noun" and a unique identification number (ID). the value of the ID is not important

Process

a process is a set of business activities of the system. It processes the input and produces the output. the name of a process is a unique "verb" or " verb phrase". each process has a unique identification number (ID). The value of ID is not important, but indicates the level of the process.

Heuristics

are applied to identify segments for the system decomposition.

Business process

business process is a collection of related and structured activities or tasks that produce a specific output(s) in response to an input (s). (1) A management process is a managerial decision making process. (2) An operational process is a business process of routine business operations. (3) A supporting process is a business process that supports management processes and operational processes.

Data flow

data flow is an instance of data item or a set of data that flows between an external entity and process, or between two processes, or between a process and a data store. the name of the data flow is a unique "noun"

operational process

is a business process of routine business operations.

supporting process

is a business process that supports management processes and operational processes.

external entity

is a class of persons or a class of organizations outside the system. it provides the source of data for the system and/ or receives the data from a system. the name of the external entity is unique "noun"

management process

is a managerial decision making process, such as budgeting and supplier selection.

business process model

is a model that defines the way in which business activities are carried out to accomplish the intended goal of the entire business process. A business process model describes the business processes and the integration of these processes at multiple abstraction levels.

system requirement

is a statement or expression that specifies what the information system must perform or what characteristics the information system must have. -Functional requirements -Nonfunctional requirements

Questionnaire

is a survey instrument that consists of a series of written questions for collecting information from respondents. The responses rates of questionnaires are usually low.

Joint Analytical Development (JAD)

is a team-based requirements information collection technique. The objective of JAD is to bring representatives of all stakeholders of the organization together to identify system requirements

Observation

is the act of watching ongoing business processes

Interview

is the most commonly used technique for requirements information collecting. It can reach a wide range of the users of the information system including managers, operational staff, and customers. (1) Designing interview questions (2) Selecting interviewees (3) Conducting interview (4) Verifying and releasing interview findings

documents review

is to analyze the documentation of the as-is system, including the previous systems analysis and design reports for the as-is system as well as operational and maintenance records, to understand the requirements for the to-be system.

systems analysis phase

is to determine the requirements for the new information system. (1) Collecting information for understanding the system requirements. (2) Specifying the system requirements using modeling techniques. (3) Contrasting the as-is system and the to-be system in terms of system requirements. (4) Documenting the system requirements for the systems design phase.

semantic errors:

not "grammatical" errors, but are the misrepresentation of the meaning of the system.

experiences

of the pertinent business processes as the user of the information system in that organization.

functional requirement

specifies what the information system must do to accomplish the business processes, the information provision, and the business rules of the organization.

Validating DFD and common errors

syntax errors semantic errors

central component of a CASE tool is the CASE repository

that stores all the diagrams and project information, and is shared by all project team members.

Syntax errors

violation of "grammatical" rules. Syntax errors in the decomposition: Balancing (3) Syntax errors in the entire analysis project: The entire analysis project must use the standard names of the DFD elements across the entire analysis project.