A.4 Ethnography
? A social scientists spends a considerable time observing and analysing how people actually
work
? People do not have to explain or articulate their work
? Social and organisational factors of importance may be observed
? Ethnographic studies have shown that work is usually richer and more complex than
suggested by simple system models
3.4.5 Requirements validation
A.1 Concerned with demonstrating that the requirements define the system that the
customer really wants
A.2 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
3.4.6 Requirements change management
B.1
Requirements management is the process of managing changing requirements during the requirements engineering process and system development
B.2 Requirements are inevitably incomplete and inconsistent
? New requirements emerge during the process as business needs change and a better
understanding of the system is developed
? Different viewpoints have different requirements and these are often contradictory
3.5 Key points
1. Requirements for a software system set out what the system should do and define constraints
on its operation and implementation.
2. Functional requirements are statements of the services that the system must provide or are
descriptions of how some computations must be carried out.
Page 29 of 91
3. Non-functional requirements often constrain the system being developed and the
development process being used.
4. They often relate to the emergent properties of the system and therefore apply to the system
as a whole.
5. 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.
6. The requirements engineering process is an iterative process including requirements
elicitation, specification and validation.
7. 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.
8. You can use a range of techniques for requirements elicitation including interviews, scenarios,
use-cases and ethnography.
9. Requirements validation is the process of checking the requirements for validity, consistency,
completeness, realism and verifiability.
10. 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.
3.6 Excercises(Homework): P116
4.2，*4.4
Page 30 of 91
Chapter 4 (5) System Modeling
4.1
1. 2. 3. 4.
Topics covered
Context models Interaction models Structural models Behavioral models
4.2 System modeling
4.2.1 Introduction
1. System modeling is the process of developing abstract models of a system, with each model
presenting a different view or perspective of that system.
2. System modeling has now come to mean representing a system using some kind of graphical
notation, which is now almost always based on notations in the Unified Modeling Language (UML).
3. System modelling helps the analyst to understand the functionality of the system and models
are used to communicate with customers.
4.2.2 Use of graphical models
A.1 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.
A.2 As a way of documenting an existing system
Models should be an accurate representation of the system but need not be complete.
A.3 As a detailed system description that can be used to generate a system
implementation
Models have to be both correct and complete.
4.2.3 UML diagram types A.1 Activity diagrams
which show the activities involved in a process or in data processing .
A.2 Use case diagrams
which show the interactions between a system and its environment. Sequence diagrams
Page 31 of 91
A.3 which show interactions between actors and the system and between system
components.
A.4 Class diagrams
which show the object classes in the system and the associations between these classes.
A.5 State diagrams
which show how the system reacts to internal and external events.
4.3 Context models
4.3.1 Introduction
? 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.
● The context of the MHC-PMS
(Mental Health Care-Patient Management System)
4.3.2 Process perspective
? 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.
Page 32 of 91