Software requirements full sides & concepts

Software Requirements Engineering
[SRE]
----------------------------------------------
[System Analysis and Modeling]
Chapter-[3]
Chapter 3 Software Requirement
Engineering-(Analysis and Modeling)
1

Topics covered
 The software requirements document
 Functional and non-functional requirements
 Requirements specification
 Requirements engineering processes
 Requirements elicitation and analysis
 Requirements validation
 Requirements management
2

System Analysis
(Requirements Analysis)
Lecture 1
3

What is a Requirement?
 It may range from a high-level abstract statement of a
service or of a system constraint to a detailed
mathematical functional specification.
 This is inevitable as requirements may serve a dual
function
▪ May be the basis for a bid for a contract - therefore must be open
to interpretation;
▪ May be the basis for the contract itself - therefore must be
defined in detail;
▪ Both these statements may be called requirements.
4

Requirements Engineering
 The process of establishing the services that the
customer requires from a system and the constraints
under which it operates and is developed.
 The requirements themselves are the descriptions of the
system services and constraints that are generated
during the requirements engineering process.
5

Types of requirement
 User requirements
▪ Statements in natural language plus diagrams of the services the
system provides and its operational constraints written for
customers.
 System requirements
▪ A structured document setting out detailed descriptions of the
system’s functions, services and operational constraints.
▪ Defines what should be implemented so may be part of a
contract between client and contractor.
6

User and system requirements
7

Readers of different types of requirements
specification
8

Types of requirement
 Functional requirements
▪ Statements of services the system should provide, how the
system should react to particular inputs and how the system
should behave in particular situations.
▪ May state what the system should not do.
 Non-Functional requirements
▪ Constraints on the services or functions offered by the system
such as timing constraints, constraints on the development
process, standards, etc.
▪ Often apply to the system as a whole rather than individual
features or services.
 Domain requirements
▪ Constraints on the system from the domain of operation
9

Functional requirements
 Describe functionality or system services.
 Depend on the type of software, expected users and the
type of system where the software is used.
 Functional user requirements may be high-level
statements of what the system should do.
 Functional system requirements should describe the
system services in detail.
10

Functional requirements for the MHC-PMS
 MHC-PMS stands for ‘Mental Health Care-Patient
Management System’ which has been proposed with two
overall goals as: 1. To generate management information that
allows health service managers to assess performance against
local and government targets. 2. To provide medical staff with
timely information to support the treatment of patients.
 A user shall be able to search the appointments lists for
all clinics.
 The system shall generate each day, for each clinic, a
list of patients who are expected to attend appointments
that day.
 Each staff member using the system shall be uniquely
identified by his or her 8-digit employee number. 11

Requirements completeness and consistency
 In principle, requirements should be both complete and
consistent.
 Complete
▪ They should include descriptions of all facilities required.
 Consistent
▪ There should be no conflicts or contradictions in the descriptions
of the system facilities.
 In practice, it is impossible to produce a complete and
consistent requirements document.
12

Non-Functional requirements
 These define system properties and constraints
▪ e.g. reliability, response time and storage requirements.
Constraints are I/O device capability, system representations,
etc.
 Process requirements may also be specified mandating
a particular IDE, programming language or development
method.
 Non-functional requirements may be more critical than
functional requirements. If these are not met, the system
may be useless. 13

Types of nonfunctional requirement
14

Non-functional classifications
 Product requirements
▪ Requirements which specify that the delivered product must
behave in a particular way e.g. execution speed, reliability, etc.
 Organisational requirements
▪ Requirements which are a consequence of organisational
policies and procedures e.g. process standards used,
implementation requirements, etc.
 External requirements
▪ Requirements which arise from factors which are external to the
system and its development process e.g. interoperability
requirements, legislative requirements, etc.
15

Usability requirements
 The system should be easy to use by medical staff and
should be organized in such a way that user errors are
minimized. (Goal)
 Medical staff shall be able to use all the system functions
after four hours of training.
 After this training, the average number of errors made by
experienced users shall not exceed two per hour of
system use. (Testable non-functional requirement)
16

Metrics for specifying nonfunctional
requirements
Property Measure
Speed Processed transactions/second
User/event response time
Screen refresh time
Size Mbytes
Number of ROM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systems
17

Domain requirements
 The system’s operational domain imposes requirements
on the system.
▪ For example, a train control system has to take into account the
braking characteristics in different weather conditions.
 Domain requirements be new functional requirements,
constraints on existing requirements or define specific
computations.
 If domain requirements are not satisfied, the system may
be unworkable.
18

Key points
 Requirements for a software system set out what the
system should do and define constraints on its operation
and implementation.
 Functional requirements are statements of the services
that the system must provide or are descriptions of how
some computations must be carried out.
 Non-functional requirements often constrain the system
being developed and the development process being
used.
 They often relate to the emergent properties of the
system and therefore apply to the system as a whole.
19

Lecture 2
20

The software requirements document
 The software requirements document is the official
statement of what is required of the system developers.
 Should include both a definition of user requirements
and a specification of the system requirements.
 It is NOT a design document. As far as possible, it
should set of WHAT the system should do rather than
HOW it should do it.
21

Users of a requirements document
22

Requirements document variability
 Information in requirements document depends on type
of system and the approach to development used.
 Systems developed incrementally will, typically, have
less detail in the requirements document.
 Requirements documents standards have been
designed e.g. IEEE standard.
 These are mostly applicable to the requirements for
large systems engineering projects.
23

Requirements specification
 The process of writing on the user and system
requirements in a requirements document.
 User requirements have to be understandable by end-
users and customers who do not have a technical
background.
 System requirements are more detailed requirements
and may include more technical information.
 The requirements may be part of a contract for the
system development
▪ It is therefore important that these are as complete as possible.
24

Guidelines for writing requirements
 Invent a standard format and use it for all requirements.
 Use language in a consistent way. Use shall for
mandatory requirements, should for desirable
requirements.
 Use text highlighting to identify key parts of the
requirement.
 Avoid the use of computer jargon.
 Include an explanation (rationale) of why a requirement
is necessary.
25

Requirements Engineering Processes
 The processes used for RE vary widely depending on
the application domain, the people involved and the
organisation developing the requirements.
 However, there are a number of generic activities
common to all processes
▪ Requirements elicitation;
▪ Requirements analysis;
▪ Requirements validation;
▪ Requirements management.
 In practice, RE is an iterative activity in which these
processes are interleaved.
26

Requirements elicitation and analysis
 Sometimes called requirements elicitation or
requirements discovery.
 Involves technical staff working with customers to find
out about the application domain, the services that the
system should provide and the system’s operational
constraints.
 May involve end-users, managers, engineers involved in
maintenance, domain experts, trade unions, etc. These
are called stakeholders.
27

Requirements elicitation and analysis
 Software engineers work with a range of system
stakeholders to find out about the application domain,
the services that the system should provide, the required
system performance, hardware constraints, other
systems, etc.
 Stages include:
▪ Requirements discovery,
▪ Requirements classification and organization,
▪ Requirements prioritization and negotiation,
▪ Requirements specification.
28

The requirements elicitation and analysis
process
29

Process activities
 Requirements discovery
▪ Interacting with stakeholders to discover their requirements.
▪ Domain requirements are also discovered at this stage.
 Requirements classification and organisation
▪ Groups related requirements and organises them into coherent
clusters.
 Prioritisation and negotiation
▪ Prioritising requirements and resolving requirements conflicts.
 Requirements specification
▪ Requirements are documented and input into the next round of
the spiral.
30

Key points
 The software requirements document is an agreed
statement of the system requirements. It should be
organized so that both system customers and software
developers can use it.
 The requirements engineering process is an iterative
process including requirements elicitation, specification
and validation.
 Requirements elicitation and analysis is an iterative
process that can be represented as a spiral of activities
▪ requirements discovery, requirements classification and
organization, requirements negotiation and requirements
documentation.
31

Lecture 3
32

Requirements discovery
 The process of gathering information about the required
and existing systems and distilling the user and system
requirements from this information.
 Interaction is with system stakeholders from managers to
external regulators.
 Systems normally have a range of stakeholders.
33

Stakeholders in the MHC-PMS
 Patients whose information is recorded in the system.
 Doctors who are responsible for assessing and treating
patients.
 Nurses who coordinate the consultations with doctors
and administer some treatments.
 Medical receptionists who manage patients’
appointments.
 IT staff who are responsible for installing and maintaining
the system.
34

Stakeholders in the MHC-PMS
 A medical ethics manager who must ensure that the
system meets current ethical guidelines for patient care.
 Health care managers who obtain management
information from the system.
 Medical records staff who are responsible for ensuring
that system information can be maintained and
preserved, and that record keeping procedures have
been properly implemented.
35

Interviewing
 Formal or informal interviews with stakeholders are part
of most RE processes.
 Types of interview
▪ Closed interviews based on pre-determined list of questions
▪ Open interviews where various issues are explored with
stakeholders.
 Effective interviewing
▪ Be open-minded, avoid pre-conceived ideas about the
requirements and are willing to listen to stakeholders.
▪ Prompt the interviewee to get discussions going using a
springboard question, a requirements proposal, or by working
together on a prototype system.
36

Interviews in practice
 Normally a mix of closed and open-ended interviewing.
 Interviews are good for getting an overall understanding
of what stakeholders do and how they might interact with
the system.
 Interviews are not good for understanding domain
requirements
▪ Requirements engineers cannot understand specific domain
terminology;
▪ Some domain knowledge is so familiar that people find it hard to
37

Scenarios
 Scenarios are real-life examples of how a system can be
used.
 They should include
▪ A description of the starting situation;
▪ A description of the normal flow of events;
▪ A description of what can go wrong;
▪ Information about other concurrent activities;
▪ A description of the state when the scenario finishes.
38

Use cases
 Use-cases are a scenario based technique in the UML
which identify the actors in an interaction and which
describe the interaction itself.
 A set of use cases should describe all possible
interactions with the system.
 High-level graphical model supplemented by more
detailed tabular description (see Chapter 5).
 Sequence diagrams may be used to add detail to use-
cases by showing the sequence of event processing in
the system.
39

Use cases for the MHC-PMS
40

Requirements validation
 Concerned with demonstrating that the requirements
define the system that the customer really wants.
 Requirements error costs are high so validation is very
important
▪ Fixing a requirements error after delivery may cost up to 100
times the cost of fixing an implementation error.
41

Requirements checking
 Validity. Does the system provide the functions which
best support the customer’s needs?
 Consistency. Are there any requirements conflicts?
 Completeness. Are all functions required by the
customer included?
 Realism. Can the requirements be implemented given
available budget and technology
 Verifiability. Can the requirements be checked?
42

Requirements validation techniques
 Requirements reviews
▪ Systematic manual analysis of the requirements.
 Prototyping
▪ Using an executable model of the system to check requirements.
 Test-case generation
▪ Developing tests for requirements to check testability.
43

Requirements reviews
 Regular reviews should be held while the requirements
definition is being formulated.
 Both client and contractor staff should be involved in
reviews.
 Reviews may be formal (with completed documents) or
informal. Good communications between developers,
customers and users can resolve problems at an early
stage.
44

Review checks
 Verifiability
▪ Is the requirement realistically testable?
 Comprehensibility
▪ Is the requirement properly understood?
 Traceability
▪ Is the origin of the requirement clearly stated?
 Adaptability
▪ Can the requirement be changed without a large impact on other
requirements?
45

Requirements management
 Requirements management is the process of managing
changing requirements during the requirements
engineering process and system development.
 New requirements emerge as a system is being
developed and after it has gone into use.
 You need to keep track of individual requirements and
maintain links between dependent requirements so that
you can assess the impact of requirements changes.
 You need to establish a formal process for making
change proposals and linking these to system
requirements.
46

Changing requirements
 The business and technical environment of the system
always changes after installation.
▪ New hardware may be introduced, it may be necessary to
interface the system with other systems, business priorities may
change (with consequent changes in the system support
required), and new legislation and regulations may be introduced
that the system must necessarily abide by.
 The people who pay for a system and the users of that
system are rarely the same people.
▪ System customers impose requirements because of
organizational and budgetary constraints. These may conflict
with end-user requirements and, after delivery, new features may
have to be added for user support if the system is to meet its
goals. Chapter 3 Software Requirement
47

Changing requirements
 Large systems usually have a diverse user community,
with many users having different requirements and
priorities that may be conflicting or contradictory.
▪ The final system requirements are inevitably a compromise
between them and, with experience, it is often discovered that
the balance of support given to different users has to be
changed.
48

Requirements evolution
49

Requirements management planning
 Establishes the level of requirements management detail
that is required.
 Requirements management decisions:
▪ Requirements identification Each requirement must be uniquely
identified so that it can be cross-referenced with other requirements.
▪ A change management process This is the set of activities that
assess the impact and cost of changes.
▪ Traceability policies These policies define the relationships between
each requirement and between the requirements and the system
design that should be recorded.
▪ Tool support Tools that may be used range from specialist
requirements management systems to spreadsheets and simple
database systems.
50

Requirements change management
 Deciding if a requirements change should be accepted
▪ Problem analysis and change specification
• During this stage, the problem or the change proposal is analyzed
to check that it is valid. This analysis is fed back to the change
requestor who may respond with a more specific requirements
change proposal, or decide to withdraw the request.
▪ Change analysis and costing
• The effect of the proposed change is assessed using traceability
information and general knowledge of the system requirements.
Once this analysis is completed, a decision is made whether or not
to proceed with the requirements change.
▪ Change implementation
• The requirements document and, where necessary, the system
design and implementation, are modified. Ideally, the document
should be organized so that changes can be easily implemented.
51

Requirements change management
52

Key points
 You can use a range of techniques for requirements
elicitation including interviews, scenarios, use-cases and
ethnography.
 Requirements validation is the process of checking the
requirements for validity, consistency, completeness,
realism and verifiability.
 Business, organizational and technical changes
inevitably lead to changes to the requirements for a
software system.
 Requirements management is the process of managing
and controlling these changes.
53

System Modeling
(Process Modeling)
Lecture 5
54

Topics covered
 Context models
 Interaction models
 Structural models
 Behavioral models
 Model-driven engineering
55

System Modeling
 System modeling is the process of developing abstract
models of a system, with each model presenting a
different view or perspective of that system.
 System modeling has now come to mean of representing
a system using some kind of graphical notation, which is
now almost always based on notations in the Unified
Modeling Language (UML).
 System modelling helps the analyst to understand the
functionality of the system and models are used to
communicate with customers.
56

Existing and Planned System Models
 Models of the existing system are used during requirements
engineering.
 They help clarify what the existing system does and can be
used as a basis for discussing its strengths and weaknesses.
 These then lead to requirements for the new system.
 Models of the new system are used during requirements
engineering to help explain the proposed requirements to
other system stakeholders.
 Engineers use these models to discuss design proposals and
to document the system for implementation.
 In a model-driven engineering process, it is possible to
generate a complete or partial system implementation from
the system model. 57

System Modeling Perspectives
 An external perspective, where you model the context or
environment of the system.
 An interaction perspective, where you model the
interactions between a system and its environment, or
between the components of a system.
 A structural perspective, where you model the
organization of a system or the structure of the data that
is processed by the system.
 A behavioral perspective, where you model the dynamic
behavior of the system and how it responds to events.
58

UML Diagram Types
 Activity diagrams, which show the activities involved in a
process or in data processing .
 Use case diagrams, which show the interactions
between a system and its environment.
 Sequence diagrams, which show interactions between
actors and the system and between system components.
 Class diagrams, which show the object classes in the
system and the associations between these classes.
 State diagrams, which show how the system reacts to
internal and external events.
59

Use of graphical models
 As a means of facilitating discussion about an existing or
proposed system
▪ Incomplete and incorrect models are OK as their role is to
support discussion.
 As a way of documenting an existing system
▪ Models should be an accurate representation of the system but
need not be complete.
 As a detailed system description that can be used to
generate a system implementation
▪ Models have to be both correct and complete.
60

Context models
 Context models are used to illustrate the operational
context of a system.
 They show what lies outside the system boundaries.
 Social and organisational concerns may affect the
decision on where to position system boundaries.
 Architectural models show the system and its
relationship with other systems.
61

System boundaries
 System boundaries are established to define what is
inside and what is outside the system.
▪ They show other systems that are used or depend on the system
being developed.
 The position of the system boundary has a profound
effect on the system requirements.
 Defining a system boundary is a political judgment
▪ There may be pressures to develop system boundaries that
increase / decrease the influence or workload of different parts of
an organization.
62

The context of the MHC-PMS
63

Process Modeling Perspective
 Context models simply show the other systems in the
environment, but not how the system being developed is
used in that environment.
 Process models reveal how the system being developed
is used in broader business processes.
 UML activity diagrams may be used to define business
process models.
64

Interaction models
 Modeling user interaction is important as it helps to
identify user requirements.
 Modeling system-to-system interaction highlights the
communication problems that may arise.
 Modeling component interaction helps us understand if a
proposed system structure is likely to deliver the required
system performance and dependability.
 Use case diagrams and sequence diagrams may be
used for interaction modelling.
65

Use case diagrams
 Use cases were developed originally to support
requirements elicitation and now incorporated into the
UML.
 Each use case represents a discrete task that involves
external interaction with a system.
 Actors in a use case may be people or other systems.
 Represented diagrammatically to provide an overview of
the use case and in a more detailed textual form.
66

Transfer-data use case
 A use case in the MHC-PMS
67

Tabular description of the ‘Transfer data’ use-
case
MHC-PMS: Transfer data
Actors Medical receptionist, patient records system (PRS)
Description
A receptionist may transfer data from the MHC-PMS to a
general patient record database that is maintained by a
health authority. The information transferred may either
be updated personal information (address, phone
number, etc.) or a summary of the patient’s diagnosis
and treatment.
Data Patient’s personal information, treatment summary
Stimulus User command issued by medical receptionist
Response Confirmation that PRS has been updated
Comments The receptionist must have appropriate security
permissions to access the patient information and the
PRS.
68

Use cases in the MHC-PMS involving the role
‘Medical Receptionist’
69

Sequence diagrams
 Sequence diagrams are part of the UML and are used to
model the interactions between the actors and the
objects within a system.
 A sequence diagram shows the sequence of interactions
that take place during a particular use case or use case
instance.
 The objects and actors involved are listed along the top
of the diagram, with a dotted line drawn vertically from
these.
 The Interactions between objects are indicated by
annotated arrows.
70

Sequence diagram for View patient information
71

Sequence diagram for Transfer Data
72

Structural models
 Structural models of software display the organization of
a system in terms of the components that make up that
system and their relationships.
 Structural models may be static models, which show the
structure of the system design, or dynamic models,
which show the organization of the system when it is
executing.
 You create structural models of a system when you are
discussing and designing the system architecture.
73

Class diagrams
 Class diagrams are used when developing an object-
oriented system model to show the classes in a system
and the associations between these classes.
 An object class can be thought of as a general definition
of one kind of system object.
 An association is a link between classes that indicates
that there is some relationship between these classes.
 When you are developing models during the early stages
of the software engineering process, objects represent
something in the real world, such as a patient, a
prescription, doctor, etc.
74

UML classes and association
75

Classes and associations in the MHC-PMS
76

The Consultation class
77

Key points
 A model is an abstract view of a system that ignores system details.
 Complementary system models can be developed to show the
system’s context, interactions, structure and behavior.
 Context models show how a system that is being modeled is
positioned in an environment with other systems and processes.
 Use case diagrams and sequence diagrams are used to describe
the interactions between users and systems in the system being
designed.
 Use cases describe interactions between a system and external
actors; sequence diagrams add more information to these by
showing interactions between system objects.
 Structural models show the organization and architecture of a
system. Class diagrams are used to define the static structure of
classes in a system and their associations.
78

System Modeling
Lecture 6
79

Generalization
 Generalization is an everyday technique that we use to
manage complexity.
 Rather than learn the detailed characteristics of every
entity that we experience, we place these entities in
more general classes (animals, cars, houses, etc.) and
learn the characteristics of these classes.
 This allows us to infer that different members of these
classes have some common characteristics e.g.
squirrels and rats are rodents.
80

Generalization
 In modeling systems, it is often useful to examine the classes in
a system to see if there is scope for generalization.
 If changes are proposed, then you do not have to look at all
classes in the system to see if they are affected by the change.
 In object-oriented languages, such as Java, generalization is
implemented using the class inheritance mechanisms built into
the language.
 In a generalization, the attributes and operations associated with
higher-level classes are also associated with the lower-level
classes.
 The lower-level classes are subclasses inherit the attributes and
operations from their super classes. These lower-level classes
then add more specific attributes and operations.
81

A generalization hierarchy
82

A generalization hierarchy with added detail
83

Object class aggregation models
 An aggregation model shows how classes that are
collections are composed of other classes.
 Aggregation models are similar to the part-of relationship
in semantic data models.
84

The aggregation association
85

Behavioral models
 Behavioral models are models of the dynamic behavior
of a system as it is executing.
 They show what happens or what is supposed to happen
when a system responds to a stimulus from its
environment.
 You can think of these stimuli as being of two types:
▪ Data Some data arrives that has to be processed by the system.
▪ Events Some event happens that triggers system processing.
Events may have associated data, although this is not always
the case.
86

Data-driven modeling
 Many business systems are data-processing systems
that are primarily driven by data.
 They are controlled by the data input to the system, with
relatively little external event processing.
 Data-driven models show the sequence of actions
involved in processing input data and generating an
associated output.
 They are particularly useful during the analysis of
requirements as they can be used to show end-to-end
processing in a system.
87

Order processing
88

Event-driven modeling
 Real-time systems are often event-driven, with minimal
data processing. For example, a landline phone
switching system responds to events such as ‘receiver
off hook’ by generating a dial tone.
 Event-driven modeling shows how a system responds to
external and internal events.
 It is based on the assumption that a system has a finite
number of states and that events (stimuli) may cause a
transition from one state to another.
89

State machine models
 These model the behaviour of the system in response to
 They show the system’s responses to stimuli so are
often used for modelling real-time systems.
 State machine models show system states as nodes and
events as arcs between these nodes.
 When an event occurs, the system moves from one state
to another.
 State charts are an integral part of the UML and are used
to represent state machine models.
90

State diagram of a microwave oven
91

States and stimuli for the microwave oven (a)
State Description
Waiting The oven is waiting for input. The display shows the current time.
Half power The oven power is set to 300 watts. The display shows ‘Half power’.
Full power The oven power is set to 600 watts. The display shows ‘Full power’.
Set time The cooking time is set to the user’s input value. The display shows
the cooking time selected and is updated as the time is set.
Disabled Oven operation is disabled for safety. Interior oven light is on.
Display shows ‘Not ready’.
Enabled Oven operation is enabled. Interior oven light is off. Display shows
‘Ready to cook’.
Operation Oven in operation. Interior oven light is on. Display shows the timer
countdown. On completion of cooking, the buzzer is sounded for five
seconds. Oven light is on. Display shows ‘Cooking complete’ while
buzzer is sounding.
92

States and stimuli for the microwave oven (b)
Stimulus Description
Half power The user has pressed the half-power button.
Full power The user has pressed the full-power button.
Timer The user has pressed one of the timer buttons.
Number The user has pressed a numeric key.
Door open The oven door switch is not closed.
Door closed The oven door switch is closed.
Start The user has pressed the Start button.
Cancel The user has pressed the Cancel button.
93

Microwave oven operation
94

Model-driven engineering
 Model-driven engineering (MDE) is an approach to
software development where models rather than
programs are the principal outputs of the development
process.
 The programs that execute on a hardware/software
platform are then generated automatically from the
models.
 Proponents of MDE argue that this raises the level of
abstraction in software engineering
 So that engineers no longer have to be concerned with
programming language details or the specifics of
execution platforms.
95

Usage of model-driven engineering
 Model-driven engineering is still at an early stage of
development, and it is unclear whether or not it will have
a significant effect on software engineering practice.
 Pros
▪ Allows systems to be considered at higher levels of abstraction
▪ Generating code automatically means that it is cheaper to adapt
systems to new platforms.
 Cons
▪ Models for abstraction and not necessarily right for
implementation.
▪ Savings from generating code may be outweighed by the costs
of developing translators for new platforms.
96

Model driven architecture
 Model-driven architecture (MDA) was the precursor of
more general model-driven engineering
 MDA is a model-focused approach to software design
and implementation that uses a subset of UML models to
describe a system.
 Models at different levels of abstraction are created.
 From a high-level, platform independent model, it is
possible, in principle, to generate a working program
without manual intervention.
97

Types of model
 A computation independent model (CIM)
▪ These model the important domain abstractions used in a
system. CIMs are sometimes called domain models.
 A platform independent model (PIM)
▪ These model the operation of the system without reference to its
implementation. The PIM is usually described using UML models
that show the static system structure and how it responds to
 Platform specific models (PSM)
▪ These are transformations of the platform-independent model
with a separate PSM for each application platform.
▪ In principle, there may be layers of PSM, with each layer adding
some platform-specific detail.
98

MDA transformations
99

Multiple platform-specific models
100

Executable UML
 The fundamental notion behind model-driven
engineering is that completely automated transformation
of models to code should be possible.
 This is possible using a subset of UML 2, called
Executable UML or xUML.
101

Features of executable UML
 To create an executable subset of UML, the number of
model types has therefore been dramatically reduced to
these 3 key types:
▪ Domain models that identify the principal concerns in a system.
They are defined using UML class diagrams and include objects,
attributes and associations.
▪ Class models in which classes are defined, along with their
attributes and operations.
▪ State models in which a state diagram is associated with each
class and is used to describe the life cycle of the class.
 The dynamic behaviour of the system may be specified
declaratively using the object constraint language (OCL),
or may be expressed using UML’s action language.
102

Key points
 Behavioral models are used to describe the dynamic behavior
of an executing system.
 This behavior can be modeled from the perspective of the
data processed by the system, or by the events that stimulate
responses from a system.
 Activity diagrams may be used to model the processing of
data, where each activity represents one process step.
 State diagrams are used to model a system’s behavior in
response to internal or external events.
 Model-driven engineering is an approach to software
development in which a system is represented as a set of
models that can be automatically transformed to executable
code. Chapter 3 Software Requirement
103

Software requirements full sides & concepts

More Related Content

Similar to Software requirements full sides & concepts (20)

Recently uploaded (20)

Software requirements full sides & concepts