Idea Transcript
CSE4006: Software Engineering
Lab 4: Business Process Modeling & Software Requirements Specification Software Engineering Lab Except where otherwise noted, the contents of this document are Copyright 2016 Gwanggyu Choi, Scott UkJin Lee. All rights reserved. Any redistribution, reproduction, transmission, or storage of part or all of the contents in any form is prohibited without the author's expressed written permission.
Business Process Model and Notation Business Process Model and Notation (BPMN) is a graphical representation for specifying business process in a business process model.
Example
Refernce : http://bit.ly/1moMm1T
Elements of BPMN 1. Flow objects •Events, activitys, gateways
2. Connecting objects •Sequence flow, message flow, association
3. Swim lanes •Pool, lane
4. Artifacts •Data object, group, annotation Reference : https://www.businessprocessincubator.com/bpmnquickguide-embed
Flow Objects - Event Basic Events
Tasks Start Event
Task
Intermediate Event End Event
Gateway Gateway
Sub Process Call Activity
Flow Objects - Events None Start Event Interrupting -Message Start Event Interrupting - Timer Start Event Interrupting - Conditional Start Event Interrupting Signal Start Event Interrupting Multiple Start Event Interrupting -Parallel Multiple Start Event Interrupting -Escalation Start Event Interrupting -Error Start Event Interrupting -Compensation Start Event Catch - Link Intermediate Event Throw - Link Intermediate Event Boundary --Catch - Cancel Intermediate Event Cancel End Event Terminate End Event
Flow Objects - Tasks Abstract Task Service Task Send Task Receive Task User Task Manual Task Business Rule Task Script Task
Flow Objects - Gateways Exclusive Gateway - without Marker Exclusive Gateway - with Marker Inclusive Gateway Parallel Gateway Complex Gateway Event-Based Gateway Event-Based Gateway to Start a Process Parallel Event-Based Gateway to Start a Process Gateways do not perform any work or make decisions; it is simply a visualization of divergence or convergence of flow
Connecting Objects Sequence Flow Conditional Sequence Flow Default Sequence Flow Message Flow Initiating Message Flow with Decorator Non-Initiating Message Flow with Decorator Data Association Association Directional Association Bi -Directional Association Sequence flows coming out of diverging Gateways of type Exclusive, Inclusive and Complex using their associated conditions stated as outcomes
Swim Lanes Lane
Pool
Name Pools using the Participant’s name Name Lanes using the Category’s name
Artifects Data Object Data Object Collection Data Input Data Input Collection Data Output Data Output Collection Data Store Group Text Annotation
Basic Rules Sequence Flows •Are used to show the order that Activities will be performed in a Process •They cannot cross Sub-Process boundaries •They cannot cross Pool boundaries Message Flows •Are used to show communication between Participants •They cannot connect objects that are within the same Pool Boundary Events •Must have at most one outgoing Sequence Flow •Must not have any incoming Sequence Flow Sub-Process •A Start Event in a Sub-Process must be of type None
Example
Refernce : http://bit.ly/1moMm1T
Visual Paradigm •
Download Visual Paradigm
http://www.visual-paradigm.com/download/
•
Try BPMN tutorial http://www.visual-paradigm.com/tutorials/?category=bpmodeling
Ex1: Online-Shopping Process BPM • there
are two users(Business entities),
Shopping-Site and Customer • there
is a payment system
• customer
can’t buy sold-out product
• products
must be delivered within a week
• upload
your BPM to Trello
SRS
Software Requirements Specification •
a communication tool between stakeholders and software designers
•
description of a software system to be developed, laying out functional and non-functional requirements
IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830TM-1998(R2009)
IEEE Standard SRS Form •
Introduction • • • • •
•
•
Purpose Scope Definitions, acronyms, and abbreviations References Overview
Overall description • Product perspective • Product functions • User characteristics • Constraints • Assumptions and dependencies • Apportioning of requirements Specific requirements • External interface requirements • Functions • Performance requirements • Design constraints • Software system attributes • Other requirements
IEEE Standard SRS Form (cont.) 1. Introduction •
Provide an overview of the entire SRS
•
Subsection •
Purpose - describe the purpose of this document, not the purpose of the software being developed.
•
Scope - describe the scope of this document, not the scope of the software being developed.
•
Definitions - should be write using the following template: word_defined. Followed by a definition.
•
Overview - provide an overview of this document, not the overview of the software being developed.
IEEE Standard SRS Form (cont.) 2. Overall Description •
A Context Diagram is mandatory.
•
describe the general factors that affect the product and its requirements. this section does not state specific requirements.instead, it provides a background for those requirements
•
Other important characteristics are: Product Perspective, product Functions, User Characteristics, Constraints, Assumptions and Dependencies
IEEE Standard SRS Form (cont.)
3. Specific requirements •
Never specify the Operating System or Language in the SRS, unless the customer demands doing so.
•
Use Case Diagrams have to be included in most sections, specifically in the “Functional Requirements” section.
IEEE Standard SRS Form (cont.) 3. Specific requirements •
Specific Requirements Section should be split into: •
“External Interfaces” derived from the Context Diagram
•
“Functional Requirements” that should be further split into
“Input Requirements” (related to user inputs, commands, etc.),
“Output Requirements” (mostly related to the GUI), “Input/Output Requirements” (if they cannot be separated), and “Processing Requirements”
•
“Non-Functional Requirements”, such as performance, reliability, safety, security, etc.
•
“Design Constraints”, normally related to software and hardware limitations (OS, platform, stand-alone or networked, network protocols, standards, etc.);
•
“Database Requirements” – can be combined with “Design Constraints”.
IEEE Standard SRS form example
•
http://www.cse.msu.edu/~chengb/RE-491/Papers/ SRSExample-webapp.doc
Ex2: Project SRS •
elicit and elaborate required functions for the course project
•
equally assign the functions to each team member
•
writes an SRS document for the assigned functions
•
upload your document to your remote repository
•
PM merge and complete the SRS document
Additional Business process model and notation http://www.ibm.com/support/knowledgecenter/SS6RBX_11.4.3/com.ibm.sa.bpr.doc/topics/ c_Intro_mdlng_BPMN.html?lang=ko http://www.bikorea.net/news/articleView.html?idxno=787 http://moova.tistory.com/entry/%EC%99%9C-%EB%95%8C%EC%95%84%EB%8B%8CBPM%EC%9D%B8%EA%B0%80 https://social.technet.microsoft.com/Forums/ko-KR/3e3ded8a-7ac6-4ea1-9206be7964d16807/bpm-?forum=biztalkserverko
Software requirements specification
http://www.onedesk.com/writing-a-software-requirements-specification-document/ http://www.microtoolsinc.com/Howsrs.php http://www.jaysonjc.com/programming/how-to-write-a-software-requirements-specificationsrs-document.html