Systems Analysis: Requirements, Decomposition, and Modeling
Systems Analysis: Decomposition and Requirements
Systems analysis involves decomposing a system into components for individual study and understanding their interactions. The goal is to produce a requirements document that describes what the future system should do, focusing on what rather than how. Requirements analysis is the process of thoroughly studying these requirements.
Prerequisites: Defining Requirements
A requirement is defined as a condition or capability needed by a user to solve a problem or achieve an objective. It applies to the conditions a system, standard, or specification must meet.
From an Information Systems (IS) perspective, analysis involves decomposing the system and its components. In terms of the life cycle phase, the requirements document describes what the system does, not how it does it.
Decomposition of a Data Flow Diagram (DFD)
The idea is to represent the system in layers, following a top-down approach where each level provides a more detailed view of the previous level. This approach offers several advantages:
- Empowers different people at different levels (directors, managers, users) to understand the system.
- Facilitates the analyst’s work in modeling the system.
DFD Levels
- Diagram 0: Represents the main functions of the system and their relationships. Each function can be further decomposed for different stakeholders.
- Primitive Processes: These are not further decomposed. Each primitive function has a specification describing it.
- Context Diagram: Delineates the boundary between the system and the external world, defining their interfaces. It shows data flows into and out of the system with the environment. It consists of:
- A single process representing the entire system.
- All external entities that reflect the origin and destination of information.
- The data flows between the entities and the process.
- Levels: All levels necessary for dissecting the functions of each subsystem to reach basic levels.
Entity-Relationship (E/R) Model
The E/R model, proposed by Chen in 1976, can be used as a basis for a unified view of data, adopting a natural approach that involves real-world entities and relationships.
E/R Model Elements
- Entity: An object about which we store information in the database. ANSI defines it as ‘a person, place, thing, concept, or event, real or abstract, of interest to the company.’ There are two types: regular (existing independently) and weak (dependent on another entity).
- Relationship: The association between entities.
- Attribute: The data stored for each entity.
Modeling Dimensions
- Function Size: Data flow diagrams display system functions and interfaces. This technique focuses on functions, overlapping with the information dimension supported by the data dictionary and specifications.
- Information Dimension: The entity/relationship diagram identifies entities and relationships between them.
- Time Dimension: When something happens in the system.
Building a system based on maintaining a large database is most affected by the information dimension. A real-time system is dominated by the time dimension.