Chapter 4 – Requirements Engineering

Lecture 3

1Chapter 4 Requirements engineering

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.

Chapter 4 Requirements engineering 2

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.

Chapter 4 Requirements engineering 3

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.

Chapter 4 Requirements engineering 4

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

articulate or think that it isn’t worth articulating.

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.

Scenario for collecting medical history in MHC-PMS

Mental Health Care-Patient Management System

7Chapter 4 Requirements engineering

Scenario for collecting medical history in MHC-PMS

8Chapter 4 Requirements engineering

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.

• Sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system.

9Chapter 4 Requirements engineering

Use cases for the MHC-PMS

10Chapter 4 Requirements engineering

11

Goals of Analysis Modeling• Provides the first technical representation of a system• Is easy to understand and maintain• Deals with the problem of size by partitioning the system• Uses graphics whenever possible• Differentiates between essential information versus implementation

information• Helps in the tracking and evaluation of interfaces• Provides tools other than narrative text to describe software logic and

policy

Requirements Analysis

13

Overall Objectives

• Three primary objectives– To describe what the customer requires– To establish a basis for the creation of a software design– To define a set of requirements that can be validated once the software

is built

14

Analysis Modeling Approaches• Structured analysis

– Considers data and the processes that transform the data as separate entities– Data is modeled in terms of only attributes and relationships (but no

operations)– Processes are modeled to show the 1) input data, 2) the transformation that

occurs on that data, and 3) the resulting output data

• Object-oriented analysis– Focuses on the definition of classes and the manner in which they collaborate

with one another to fulfill customer requirements

15

A Set of Models• Flow-oriented modeling – provides an indication of how data objects are

transformed by a set of processing functions • Scenario-based modeling – represents the system from the user's point

of view• Class-based modeling – defines objects, attributes, and relationships• Behavioral modeling – depicts the states of the classes and the impact of

events on these states

16

Elements of the Analysis Model

Use case textUse case diagramsActivity diagramsSwim lane diagrams

Scenario-basedmodeling

Class diagramsAnalysis packagesCRC modelsCollaboration diagrams

Class-basedmodeling

Data structure diagramsData flow diagramsControl-flow diagramsProcessing narratives

Flow-orientedmodeling

State diagramsSequence diagrams

Behavioralmodeling

Structured AnalysisObject-oriented Analysis

Flow-oriented Modeling

18

Data Modeling• Identify the following items

– Data objects (Entities)– Data attributes– Relationships– Cardinality (number of occurrences)

19

Data Flow and Control Flow

• Data Flow Diagram– Depicts how input is transformed into output as data objects

move through a system

• Process Specification– Describes data flow processing at the lowest level of

refinement in the data flow diagrams

• Control Flow Diagram– Illustrates how events affect the behavior of a system

through the use of state diagrams

20

Diagram Layering and Process Refinement

Context-level diagram

Level 1 diagram

Process Specification

Scenario-based Modeling

22

Writing Use Cases• Writing of use cases was previously described in

Chapter 7 – Requirements Engineering• It is effective to use the first person “I” to describe how the actor interacts with the software • Format of the text part of a use case

(See examples in Pressman textbook on pp. 188-189)

Use-case title:

Actor:

Description: I …

23

Example Use Case Diagram

Make automated menuselections

Order food and drink

Pay for food and drink

Notify customer thatfood and drink are ready

Customer

Cook

PaymentSystem

Expert MenuSystem

24

Activity Diagrams

• Creation of activity diagrams was previously described in Chapter 7 – Requirements Engineering

• Supplements the use case by providing a graphical representation of the flow of interaction within a specific scenario

• Uses flowchart-like symbols– Rounded rectangle - represent a specific system function/action– Arrow - represents the flow of control from one function/action to another– Diamond - represents a branching decision– Solid bar – represents the fork and join of parallel activities

25

Example Activity Diagram

Class-based Modeling

27

Example Class Box

Component

+ componentID- telephoneNumber- componentStatus- delayTime- masterPassword- numberOfTries

+ program()+ display()+ reset()+ query()- modify()+ call()

Class Name

Attributes

Operations

UML Class Diagrams and Examples

Behavioral Modeling

Hotel Reservation State Transition Diagram