The analysis model’s goal is to provide a description of the informational, functional, and behavioural domains required for a computer-based system. The model evolves dynamically as you learn more about the system to be developed and other stakeholders gain a better understanding of what they actually require. As a result, the analysis model represents a snapshot of requirements at any given time.
Elements of the Requirements Model
There are numerous approaches to analysing the requirements for a computer-based system. Different modes of representation require you to analyse requirements from many perspectives—a method that has a higher likelihood of uncovering omissions, inconsistencies, and ambiguity.
A scenario-based approach is used to describe the system from the perspective of the user. For example, basic use cases and their related use-case diagrams, evolve into more complicated template-based use cases. Scenario-based requirements model elements are frequently the first parts of the model to be produced. There are three levels of elaboration shown, ending in a scenario-based portrayal.
Each usage scenario entails a collection of objects that are modified as an actor interacts with the system. These objects are classified as classes— a collection of things with similar characteristics and behaviour.
The behaviour of a computer-based system can have a significant impact on the design and implementation techniques used. As a result, the requirements model must include modelling elements that represent behaviour. The state diagram is one approach of expressing a system’s behaviour by illustrating its states and the events that cause the system to change state. Any externally observable form of conduct is referred to as a state. Furthermore, the state diagram indicates activities taken as a result of a specific event.
As data moves through a computer-based system, it is transformed. The system accepts input in a variety of formats, transforms it using functions, and produces output in a variety of forms. A control signal transmitted by a transducer, a series of numbers written by a human operator, a packet of information transmitted over a network link, or a large data file retrieved from secondary storage can all be used as input. The transform(s) may consist of a single logical comparison, a complex numerical algorithm, or an expert system’s rule-inference approach.
Anyone who has done requirements engineering on a number of software projects will note that some issues repeat across all projects within a certain application area. These patterns of analysis provide solutions (e.g., a class, a function, or a behaviour) inside the application domain that can be reused when modelling several applications.
By referencing the pattern name, analysis patterns are integrated into the analysis model. They are also stored in a repository so that requirements engineers can find and apply them using search facilities. Information about an analysis pattern (and other sorts of patterns) is contained in a standard template.