Scenario Analysis

Requirements Modeling
Dr. Joseph Kibombo Balikuddembe

For comments and issues
jbalikud@cit.mak.ac.ug.
© JK Balikuddembe - Requirements
7-Apr-21 1
Engineering
Definition
• Requirements modeling is the process used in
software development projects
– where requirements and solutions constantly
evolve through collaborative efforts and
teamwork.
– Purpose: to ensure that the exact needs of the
stakeholders are met.
7-Apr-21 2
Engineering
How it is done
• Modeling Requirements: from customer views to
something translatable to software
– It involves using techniques for developing functional
requirements
• In other words, translating into What the software is
supposed to do!
• We build models in requirements analysis to
understand
– current systems or business processes which we are
trying to automate
– how users will use a new system
7-Apr-21 3
Engineering
Tools for modeling requirements
• Use Cases
• State Diagrams
• UI Mockups
• Storyboards
• Prototypes
Modeling Functional Requirements
• Identify user classes
• For each user class identify goals
• For each goal, identify how the user will use
the system
7-Apr-21 5
Engineering
Example
• Requirement:
– The system should allow a user to annotate a tooth or a set of teeth when
dental charting a patient`s oral status.
• Goal:
– For the user to be able to make an annotation on a single tooth or a set of
teeth
• Functions
– Annotate teeth
• ability to add an annotation to a tooth/a set of teeth elements
– Save annotation
• ability to save an annotation selection to the database
– Edit annotation
• ability to change an annotation by allowing substitution of an annotation selection
– Delete annotation
• ability to delete an annotation done on any tooth element
– View complete patient oral annotation
• ability to view each individual annotation arising out of oral examination
7-Apr-21 6
Engineering
Example Cont.
• Name: annotate a tooth
• Actors: student(user)
• Initiator: student
• Scenario:
1. Student selects to perform dental charting for a patient
2. The system responds by displaying the dental chart on
the screen
3. The student selects a tooth or a set of teeth from the
dental chart
4. The system responds by displaying the charting menu
options
USE CASE
7-Apr-21 7
Engineering
Use case model
7-Apr-21 8
Engineering
Use Case Narrative
• Use case narration is a textual representation
of the course of events encountered when an
actor is interacting with the system.
• There can be several use cases associated with
a system, each of which describes the system
in a functional or behavioral point of view.
7-Apr-21 9
Engineering
Purpose
• Use case narrations help identify possible
misunderstandings during the early stage.
– All the course of events are written in as a form of
communication between the actor and the
system.
7-Apr-21 10
Engineering
Parts of the Narration
• Author
• Date ( date of last modification)
• Version (Current Version of the use case)
• Name (to begin with a verb)
• Goal which the use case is trying to achieve
7-Apr-21 11
Engineering
The Components
Use case Name Annotate teeth
Use case ID USC002
Priority High
Source Oral Patient examination policy 231
Use Case Type Business Requirement
Author. Cliff Kimbugwe, Date: 5/10/2021 Version 1.0
7-Apr-21 12
Engineering
Main Elements
• Trigger
– The event that initiated the scenario
• The students wants to perform dental charting for a patient
• Typical Course of events
– The main path to the goal – don’t contain conditional
events
• Usually in this format
– Step 1.
– Step 2.
– Step X.
7-Apr-21 13
Engineering
Typical Course of events
1. Student selects to perform dental charting examination
for a patient
2. The system responds by displaying the dental chart on
the screen
3. The student selects a tooth or a set of teeth from the
dental chart
4. The system responds by displaying the charting menu
options
5. The student selects the menu option and save option
6. The system
1. Saves the details to the database
2. displays a confirmation message
3. Redirects the students back to the dental charting page
7-Apr-21 14
Engineering
Representation
7-Apr-21 15
Engineering
Representation –Cont..
Main success scenario 1. Student selects to perform dental charting
examination for a patient
2. The system responds by displaying the dental chart
on the screen
3. The student selects a tooth or a set of teeth from
the dental chart
4. The system responds by displaying the charting
menu options
5. The student selects the menu option and save
option
6. The system
1. Saves the details to the database
2. displays a confirmation message
3. Redirects the students back to the dental
charting page
7-Apr-21 16
Engineering
Main Elements
• Primary Business Actor
– A stakeholder who principally benefits from the execution
of the use case by receiving something of measurable or
observable value
• Other Participating Actors
– Other participating actors including system actors,
server/receiver actors and secondary actors
• Description
– A summary about what does this use case do
• Precondition
– This describes what should be true before this user
scenario can happen
7-Apr-21 17
Engineering
Main Elements
• Alternate courses
– They are extensions to the main path – usually looking the
numbering in the main course of events
– Usually in this format
• Alt 3.
• Alt 4.
• Post Condition
– Describes what should be true on the successful ending of the
use case , may be through the typical course of events or
alternative course
• Business Rules
• Assumptions
– Assumptions that were made by the author
7-Apr-21 18
Engineering
Alternative Course Example
• Alternate courses
– user tries to save a chart without an annotation
Alternative scenario 1 4a. The student selects the save dental chart
User saves chart 4a.1 The system
without annotation 1. Validates that no annotation is made
2. Displays error message
“You need to make an annotation for the
selected [tooth/teeth]”.
3. Resume step 3 in main scenario
7-Apr-21 19
Engineering
Other sections-Example
• Pre condition
– The user is logged in and has the system rights to
perform dental charting
• Post Condition
– The user is redirected back to the dental chart page
• Business Rules
– Any dental charting must be accompanied by a
specific tooth annotation that describes the oral
condition
• Assumptions
– Auto annotations are predefined
7-Apr-21 20
Engineering
Data Model
7-Apr-21 21
Engineering
7-Apr-21 22
Engineering
Method - annotateTeeth()
Mapping Attribute Mapping Element
THIS [DentalChart].(toothSelection) AND Tooth selection
THIS [DentalChart].(toothSelection) ≥ 1
THIS [AnnotationOption].(option)) = allowed Is allowed option
THIS [DentalChart].(annotation) Annotation Added
Version 1.0
Tooth Selection Is allowed option Annotation Added Result
TRUE TRUE TRUE TRUE
ELSE FALSE
Constraint Action Set Property Warning ERROR: “You need to make
Persistence Critical an annotation for the
selected [tooth/teeth]”.
7-Apr-21 23
Engineering
UI Mockups
7-Apr-21 24
Engineering
UI Mock UP
• UI Mock Up (or even full design) is often considered part of
the requirements process because
•it summarizes the ways a user can interact with the
system.
• UI design can also address non functional requirements, e.g.,
look and feel
Why Mockups
• Screen mockups can support the requirements
gathering process when introduced at the
right time, but if introduced too early they can
become problematic
– Mockups are nice because they help the business
representatives or clients visualize the
functionality of the system.
– This can be a big advantage to help analysts and
stakeholders identify problems early on
7-Apr-21 26
Engineering
7-Apr-21 27
Engineering
UI Specification
• Menu and Submenus
• Buttons
– Selecting the Save button will commit the changes to the database
– Selecting the Cancel button will clear the annotation added
– Selecting the Edit button will make the added annotations editable
• Calculated fields
– None
• Mandatory/Required fields
• Dropdown data
• Scheduled processes
• Field Validations
7-Apr-21 28
Engineering
Free open source code
• https://sourceforge.net/projects/denspc/
• https://github.com/jacobwalkr/dental-chart
7-Apr-21 29
Engineering
Agile perspective
7-Apr-21 30
Engineering
User Stories
• A user story is a tool used in Agile software
development to capture a description of a
software feature from an end-
user perspective.
• The user story describes the type of user,
what they want and why.
• A user story helps to create a simplified
description of a requirement.
7-Apr-21 31
Engineering
The ThreeCs
• Cards
– Stories are traditionally written on note cards.
– Cards may be annotated with estimates, notes, etc.
• Conversation
– Details behind the story come out during
conversations with product owner
• Confirmation
– Acceptance tests confirm a story was coded correctly
7-Apr-21 32
Engineering
Example – Dental charting
• Need: Ability for the user to annotate a tooth or a set of
teeth when dental charting a patient`s oral status.
• User story
– As a user I want to be able to annotate a tooth or
teeth when dental charting so as to determine a
patient`s oral status
• Conversation
– How should it work?
• Confirmation
– How will you test that it is working well?
7-Apr-21 33
Engineering
Where are the details
• As a user I want to be able to annotate a tooth or teeth
when dental charting so as to determine a patient`s oral
status.
– Is it the same annotation done for all teeth or it
differs?
– What if the user selects more than one tooth, what
happens?
– Can a tooth or a teeth have more than one
annotation?
– What different annotation types exist?
– Are these annotations types based on selection type?
• For example: A line cross, an X Mark, a circle etc
7-Apr-21 34
Engineering
Details as conditions of satisfaction
• As a user I want to be able to annotate a tooth
or teeth when dental charting so as to
determine a patient`s oral status
– Verify that a user can annotate a tooth or teeth.
– Verify that based on an annotation type selection,
allowed types are displayed.
– Verify that each annotation added is visible on the
screen.
– Verify that upon a successful annotation save, a
user is given an option to add another annotation
7-Apr-21 35
Engineering
Writing user stories
• Examples:
• As a registered user, I am required to log in so
that I can access the system.
• As a forgetful user, I can request a password
reminder so that I can log in if I forget mine.
– “As a <user role>, I <want /need/can etc><goal>so
that <reason>.”
7-Apr-21 36
Engineering
Story-writing workshops
• Includes whole team plus possibly some
external stakeholders
• Typically not done every sprint
• Brainstorm to generate stories
• Goal is to write as many stories as possible
– Some will be “implementation ready”
– Others will be epics
• No prioritization at this point
7-Apr-21 37
Engineering
Start with the epics and iterate
7-Apr-21 38
Engineering
Why user stories
• Shifting Focus from writing to talking
• The user can enter a name. It can be 127
characters.
– Must the user enter a name?
– Can it be other than 127 chars?
• The system should prominently display a warning
message whenever the user enters invalid data.
– What does should mean?
– What does prominently display mean?
– Is invalid data defined elsewhere?
7-Apr-21 39
Engineering
Why user stories
• Stories are understandable
– Developers and customers understand them
– People are better able to remember events if they are
organized into stories†
• Support and encourage iterative development
– Can easily start with epics and disaggregate closer to
development time
• Stories are the right size for planning
• Stories support opportunistic development
– We design solutions by moving opportunistically between
top-down and bottom-up approaches†
• Stories support participatory design
7-Apr-21 40
Engineering
User story specification
• GIVEN that
– Some context
• WHEN
– Some action is carried out
• THEN
– a particular set of observable consequences
should obtain
• AND WHEN
• THEN
7-Apr-21 41
Engineering
Example
• Given
– The use is logged in and has system rights to annotate teeth
• When
– The user selects a tooth on the chart
• Then
– The system displays annotation menu options
• AND WHEN
– The user annotates a tooth
• THEN
– The system activates the Save button
• AND WHEN
– The user selects the Save annotation option
• THEN the system
• Save the details to the database
• Displays a confirmation message
• Redirects the user back to dental chart page
7-Apr-21 42
Engineering

Scenario Analysis

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Scenario Analysis

Uploaded by

Copyright:

Available Formats

Requirements Modeling

Dr. Joseph Kibombo Balikuddembe

You might also like