Illustrate system requirements: Difference between revisions
No edit summary |
No edit summary |
||
Line 5: | Line 5: | ||
There are several ways to represent system requirements, including: | There are several ways to represent system requirements, including: | ||
Use Cases: A use case is a description of a system's behavior as it responds to a request from one of its users. Use cases can be used to represent the functional requirements of a system. | # Use Cases: A use case is a description of a system's behavior as it responds to a request from one of its users. Use cases can be used to represent the functional requirements of a system. | ||
# User Stories: A user story is a short, simple description of a feature written from the perspective of the user. User stories can be used to represent both functional and non-functional requirements of a system. | |||
User Stories: A user story is a short, simple description of a feature written from the perspective of the user. User stories can be used to represent both functional and non-functional requirements of a system. | # Requirements Specification: A requirements specification is a detailed document that describes the requirements for a system. It can include functional and non-functional requirements, as well as constraints, assumptions, and dependencies. | ||
# Requirements Traceability Matrix: A requirements traceability matrix is a table that shows the relationships between different requirements in a system. It can be used to track the progress of the development of a system and ensure that all requirements have been addressed. | |||
Requirements Specification: A requirements specification is a detailed document that describes the requirements for a system. It can include functional and non-functional requirements, as well as constraints, assumptions, and dependencies. | # Prototypes: Prototypes are simplified versions of a system that are used to test and refine the requirements. Prototypes can be used to represent both functional and non-functional requirements. | ||
# Flowcharts: Flowcharts are diagrams that show the steps in a process. They can be used to represent the logic and flow of a system, and can be useful in representing functional requirements. | |||
Requirements Traceability Matrix: A requirements traceability matrix is a table that shows the relationships between different requirements in a system. It can be used to track the progress of the development of a system and ensure that all requirements have been addressed. | |||
Prototypes: Prototypes are simplified versions of a system that are used to test and refine the requirements. Prototypes can be used to represent both functional and non-functional requirements. | |||
Flowcharts: Flowcharts are diagrams that show the steps in a process. They can be used to represent the logic and flow of a system, and can be useful in representing functional requirements. | |||
Revision as of 06:12, 8 January 2023
Once you have understood and chosen a system, you must diagram how the system works. This works prevents problems in the future by ensuring you understand all inputs and outputs, AND how a system is organized.
There are several ways to represent system requirements, including:
- Use Cases: A use case is a description of a system's behavior as it responds to a request from one of its users. Use cases can be used to represent the functional requirements of a system.
- User Stories: A user story is a short, simple description of a feature written from the perspective of the user. User stories can be used to represent both functional and non-functional requirements of a system.
- Requirements Specification: A requirements specification is a detailed document that describes the requirements for a system. It can include functional and non-functional requirements, as well as constraints, assumptions, and dependencies.
- Requirements Traceability Matrix: A requirements traceability matrix is a table that shows the relationships between different requirements in a system. It can be used to track the progress of the development of a system and ensure that all requirements have been addressed.
- Prototypes: Prototypes are simplified versions of a system that are used to test and refine the requirements. Prototypes can be used to represent both functional and non-functional requirements.
- Flowcharts: Flowcharts are diagrams that show the steps in a process. They can be used to represent the logic and flow of a system, and can be useful in representing functional requirements.
About system requirements[edit]
Once you have selected a system you should map how the system will interface with other systems in the organization, how data will flow into and out of the system (the inputs and outputs), and how the system is organized. We use the three techniques below to understand this. Please watch this video for a very basic introduction to flowcharts.
Method | Example | Definition |
system flow charts | click here for example | System flowcharts are a way of displaying how data flows in a system and how decisions are made to control events.[2] |
data flow diagrams | click here for example | A data flow diagram (DFD) is a graphical representation of the "flow" of data through an information system, modelling its process aspects. A DFD is often used as a preliminary step to create an overview of the system, which can later be elaborated. DFDs can also be used for the visualization of data processing (structured design).[3]. Diagrams representing how information is moving through the system together with identifying all relevant inputs and outputs to the system. [4] |
structure chart | click here for example | A Structure Chart (SC) in software engineering and organizational theory, is a chart which shows the breakdown of a system to its lowest manageable levels[5] |
Real-world practical advice[edit]
This step is especially important when you are working with many different interdependent systems.
Standards[edit]
- Construct suitable representations to illustrate system requirements