Suitable Representation to Illustrate System Requirements
1.2.7 Suitable representations to illustrate system requirements
IB Subtopic
There are many ways to show system requirements. You will be using the following types of charts to illustrate your requirements in Criterion B. Remember, these will change many times. Design quickly and change often by getting feedback from the stakeholders.
System Flowcharts
System flowcharts describe the flow of data through any individual program. Flowcharts show the specific hardware that will be used to obtain and store data. You can use the following symbols to create a system flowchart.
Examples:
Data-Flow Diagrams
Data Flow Diagrams are used to describe a particular problem that needs to be solved in your application. You can have many DFD’s for your design and you can connect DFD’s to other DFD’s. The following symbols can be used:
- External entity: an outside system that sends or receives data, communicating with the system being diagrammed. They are the sources and destinations of information entering or leaving the system. They might be an outside organization or person, a computer system or a business system. They are also known as terminators, sources and sinks or actors.
- Process: any process that changes the data, producing an output. It might perform computations, or sort data based on logic, or direct the data flow based on business rules. A short label is used to describe the process, such as “Submit payment.”
- Data store: files or repositories that hold information for later use, such as a database table or a membership form. Each data store receives a simple label, such as “Orders.”
- Data flow: the route that data takes between the external entities, processes and data stores. It portrays the interface between the other components and is shown with arrows, typically labeled with a short data name, like “Billing details.”
Here is a simple data flow diagram:
As you’ll notice, all DFD’s need a process that has inputs and outputs. You can connect processes together to show a more complex idea:
This diagram shows a few possible mistakes you might come across when creating a DFD.
- A black hole is a process that has no outputs
- A grey hole is a process that doesn’t receive enough information to create an output
- A miracle is a process without any inputs that outputs something 🙂
You could also have processes that receive multiple inputs and produce multiple outputs:
DFD’s can also have multiple Levels:
Level 1 DFD:
Level 2 DFD:
Where one part of the level 1 DFD will be explained in more detail:
UML Diagrams
We’ve done UML Diagrams before. As opposed to DFD’s and Flowcharts, UML diagrams show the relationship between objects in your program. The least amount of objects you use, the smaller your UML diagram will be. Here are the Symbols you can use with UML diagrams as illustrated by a great example of what your UML Diagram might look like.
| Notation | Definition |
| Inheritance (or Generalization) | An “is-a” relationship between parent and child class. |
| Association | A simple structural link between two classes that shows some non-specific relationship |
| Aggregation | A “has-a” relationship between classes. In this case, a GUI window has some shapes. |
| Composition | A special type of aggregation where parts are destroyed when the whole is destroyed. |
| Dependency | A “uses-a” relationship where one class uses some other class without storing it or having a parent-child relationship. |
| <<Entity>> <<Boundary>> <<Control>> | – Entity is synonymous with classes that are part of the Model – Boundary is the same as a class that’s part of the View – Control is the same as a class that’s part of the Controller |