chapter 4 – requirements engineering lecture 3 1chapter 4 requirements engineering
TRANSCRIPT
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
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
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
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
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
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
27
Example Class Box
Component
+ componentID- telephoneNumber- componentStatus- delayTime- masterPassword- numberOfTries
+ program()+ display()+ reset()+ query()- modify()+ call()
Class Name
Attributes
Operations