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