iv & v - requirements engineering and system modelling Flashcards
Requirements for a software system set out what the system [1] and define [2].
- should do
- constraints on its operation and implementation
are statements of the services that the system must provide or are descriptions of how some computations must be carried out.
Functional requirements
often constrain the system being developed and the development process being used. These might be product requirements, organizational requirements, or external requirements. They often relate to the emergent properties of the system and therefore apply to the system as a whole.
Non-functional requirements
The [1] is an agreed statement of the system requirements. It should be organized so that both system customers and software developers can use it.
software requirements document
enumeration
The requirements engineering process includes…
- feasibility study
- requirements elicitation and analysis
- requirements specification
- requirements validation
- requirements management
is an iterative process that can be represented as a spiral
of activities—requirements discovery, requirements classification and organization, requirements negotiation, and requirements documentation.
Requirements elicitation and analysis
is the process of checking the requirements for validity, consistency, completeness, realism, and verifiability.
Requirements validation
Business, organizational, and technical changes inevitably lead to changes to the requirements for a software system. [1] is the process of managing and controlling these changes.
Requirements management
A [1] is an abstract view of a system that ignores some system details. [2] models can be developed to show the system’s context, interactions, structure, and behavior.
- model
- Complementary system
[1] show how a system that is being modeled is positioned in an environment with other systems and processes. They help define the boundaries of the system to be developed.
Context models
[1] are used to describe the interactions between user the system being designed and users/other systems. [2] describe interactions between a system and external actors; [3] add more information to these by showing interactions between system objects.
- Use case diagrams and sequence diagrams
- Use cases
- sequence diagrams
[1] show the organization and architecture of a system. [2] are used to define the static structure of classes in a system and their associations.
- Structural models
- Class diagrams
are used to describe the dynamic behavior of an executing system. This can be modeled from the perspective of the data processed by the system or by the events that stimulate responses from a system.
Behavioral models
may be used to model the processing of data, where each activity represents one process step.
Activity diagrams