Software Engineering (CSC 4350/6350) Rao Casturi

Transcription

1 Software Engineering (CSC 4350/6350) Rao Casturi

2 Recap UML Introduction Basic UML concepts 2

3 Basic Notations of UML Requirement Phase Analysis Phase Design Phase Object Design Phase 1. Use Case Diagrams 2. Class Diagrams 3. Interactive Diagrams 4. State Machine Diagrams 5. Activity Diagrams 3

4 3 Major areas of focus in System Development System Development Functional Model Object Model Dynamic Model Use Case Diagrams Output or produces Class Diagrams Output or produces Interaction, State Machine, Activity Diagrams UML helps us in modeling our problem to get a meaningful solution Functional Model Functionality of the system from users view. Represented in UML via use case diagrams. Object Models Represented in UML: via class diagrams describing the Structure of the system in terms of objects, associations and operations. Dynamic Models Represented in UML via sequence diagrams (ID), state charts and activity diagrams describing the internal behavior of the system. 4

5 Format for an Use Case Use Case Name Actors/Participants Flow of events Entry Condition Exit Condition Quality constraints UC_001_BalancePortfolio Portfolio Manager 1. Select the Portfolio name 2. Get the Portfolio market value and available case in portfolio 3. Select sell/buy option depending on the cash balance to deploy 4. Confirmation notification for the selected order 5. Confirm the order 6. Generate the trade ticket and request the order and generate order code 7. Enter the order code on trade transmission and submit the order When a Portfolio Manager should be logged on to the Trade Order Management Module When the case in the portfolio is near zero or less than.01 % of the portfolio value The transaction should be completed with in 3 minutes from the time the system generates an order code 5

6 Scenarios Use case is an abstraction that describes all possible scenarios involved in a functionality Scenario is an instance of the use case describing a concrete set of action from a single user point There is no need for Entry or Exit Conditions Scenario describes only a specific situation so exit and entry conditions won t apply Scenario Name Actors/Participants PortfolioMarketValue Rao:PortfolioManager Flow of events 1. System will get go to the holdings database to filter the portfolio name 2. Sum all the holding for a given date 3. Return the sum value as market value 6

7 4. Schedule Mapping of task on a timeline or plot Each task has a life of its own (Start and End) 2 Types of Schedule Charts are widely used PERT and Gantt Charts Gantt Chart ( TASK vs Time) 7

8 PERT Charts (Program Evaluation Review Technique) Project Plan preparation 1 Hardware Purchase Requirement 20 Documentation Coding Standards setup Analysis 7 Feedback to client Object Design 5 Budget Rework Coding Testing 3 Release Numbers boxes are Nodes and represent a significant milestones or tasks in project Number on the lines indicate the days the task will take to reach next node Directional arrows indicate dependent tasks. (Sequential order) Fork or divergence arrows are possible parallel tasks 8

9 Requirement Elicitation 9

10 Requirement Engineering First step for understanding the System Very Critical for the System Success 2 Components Requirement Specification (Gathering) Analysis Model Problem Statement Requirement Elicitation Requirements Specification Functional Non Functional Analysis Analysis model Dynamic Model Analysis Object Model 10

11 Requirement Engineering Key Ideas: This is about the communication among the resources working on the project Human interaction & Observation (Scenarios) Story board about the System Proposed Understanding the problem and articulate it back Ability to establish the boundaries 11

12 Problem Statement Requirement Elicitation Requirement Engineering Functional requirements :- This describe the interactions between the system and its environment independent of its implementation. The environment includes the user and any other external system with which the system interacts. Nonfunctional requirements : This activity describe aspects of the system that are not directly related to the functional behavior of the system. Nonfunctional requirements include a broad variety of requirements that apply to many different aspects of the system, from usability to performance. GSU: Software Engineering - CSC4350/ Rao Casturi 12

13 Requirement Elicitation - Goal Goal of this activity is to capture all the Shall statement sentences from the requirement documents as project requirements as a tabular form End of this activity the Requirements Trace Matrix (RTM) is a deliverable to the project team Why is this activity important? Scope Creep Foundation for next phases (Use Cases, Categories, Classes, Methods) Cost & Time lines of project Future development (Incremental) Issues 13

14 Requirements Trace Matrix Entry # Paragraph # RTM Entry Type New System shall provide user log in for menu selection New System shall indicate the price of the selected item User selection shall be indicated by a audible sound 4 - Tax on the purchase shall be displayed to show the total amount Pre-agreed categories (Type) Software Requirement (SW) Hardware Requirement (HW) Derived Requirement (DR) Nice to have Requirement (NTH) Software Constraint (SWC) SW SW HW DR 14

15 Functional Requirements Object-Oriented Software Engineering Bernd Bruegge and Allen Dutoit 15

16 Non-Functional Requirements Object-Oriented Software Engineering Bernd Bruegge and Allen Dutoit 16

17 Requirement Elicitation Concepts: MUST to have Interactions with the system From Start Develop or work on existing system Build UI/Interfaces Functional Requirements Usability Reliability Robustness Supportability Performance Greenfield, Re Engineering, Interface Development Non Functional Requirements Complete with all variations Unambiguous Correct Completeness, Consistency, Clarity, Accuracy Realism, Verifiability, Traceability Should be realist Able to verify the outcome Should match with the original requirements 17

18 Requirement Elicitation Activities: Identify the Actors (Roles) During this phase the system developers will try to layout the various users and their roles This helps understanding of the Application Domain Identify Scenarios: Have discussions on some example how the system will work Helps in understanding the system better Identify Use Case: This is a detailed document of the various scenarios Capture all the possible functions the system should able to perform 18

19 Requirement Elicitation Activities: Refine the Use Cases: This phase is utilized to refine and eliminate any of the duplicate Re verify that all the requirements re captured and each one has its own Use Case Identify the Relations: During this phase the relationship between the various Use Cases Dependencies are identified Identify the common functions in the system Identify the Non-Functional Requirements Get a confirmation from the client Document the non functional requirements 19

20 Requirement Elicitation Activities: (Actor) Actors are Role Abstraction - not necessary to map to a persons One Actor can take multiple roles Subsystems can be Actors Questions for identifying actors Which user groups are supported by the system to perform their work? Which user groups execute the system s main functions? Which user groups perform secondary functions, such as maintenance and administration? With what external hardware or software system will the system interact? 20

21 Requirement Elicitation Activities: (Scenarios) Scenario is a description of the behavior of an ACTOR Single Actor View point Can t replace an Use Case Types (As-Is, Futuristic, Testing and Evaluation, Training) Questions for identifying scenarios What are the tasks that the actor wants the system to perform? What information does the actor access? Who creates that data? Can it be modified or removed? By whom? Which external changes does the actor need to inform the system about? How often? When? Which events does the system need to inform the actor about? With what latency? 21

22 Requirement Elicitation Activities: (Use Cases) Aggregation of the Scenarios Use Case is initiated by an ACTOR Use Case can interact with other Actors Writing Use Case is an ART Best Practices of Use Case Number each Use Case Uniquely Name the User Case to represent the ACTION (Verb) Name the ACTORS with the Role (Noun) Exit and Entry conditions should be clear Don t write about the user interface Exceptions should be outlined clearly Flow of activity should be clear and numbers for easy identification 22

23 Requirement Elicitation Activities: (Refine Use Cases) Goal: Completeness and Correctness Any missing details to be noted and added to the User Case Go over with the client if possible. Let an outsider read the Use Case Best Practices of Use Case Refine More eyes are better. Run through with fine tooth comb on scenarios & User Cases 23

24 Requirement Elicitation Activities: (Relationships) Goal: Find the Relationship between ACTORs and Use Cases This will reduce the complexity and makes it easy for developers Identify the Common and Exceptional scenarios Reduce redundancy Best Practices of Relationships Identify common scenarios or user cases EXTEND for rarely used scenario or use case INCLUDE when the scenario is used in more than one use case Don t over use. 24

25 Identifying Terminology / Glossary Participating objects should have a name Terminology is the first step towards the Analysis Need to be updated regularly Best Practices of Glossary User Application Domain Names Clarify any Technical Terms Data sources to be mentioned 25

26 Requirement Elicitation Activities: Non Functional Non Functional Product Organizational External Performance Security Dependability Usability Operational Environment Development Standards Legal Accounting Standards Regulatory Ethical 26

27 Requirement Elicitation Management Putting it all together RAD (Requirement Analysis Document) 1. Introduction 2. Current System 3. Future System 4. System Model 5. High Level Time Line Diagrams 6. Appendix (Proto type, Screen Shots etc) 7. Glossary 27

28 Requirement Trace Matrix 28

29 From :USE CASES COMBINED WITH BOOCH OMT UML by Putnam P. Texel and Charles B. Williams For educational purpose only 29

30 HCC Case Study Continued From :USE CASES COMBINED WITH BOOCH OMT UML by Putnam P. Texel and Charles B. Williams For educational purpose only 30

31 Requirement Elicitation Activities How do we complete this activity? Simple steps to follow to complete the activity Agree upon a set of initial documents to extract the requirements Look for any sentence with SHALL word Any sentence with Will be extracted and discussed further Prepare the Requirements Trace Matrix (RTM) Example of this activity Number the paragraphs of the agreed upon document Any sentence can now be identified by the paragraph # Scan the sentences for SHALL and note them and number them as individual items on an EXCEL Spread Sheet or any tool which can capture as individual items with Sorting facility Facts but not in a form of requirements First set of Shall identified with an unique line entry Req. Entry Number Paragraph Number Requirement sentence 31

32 First set of Shall identified with an unique line entry Req. Entry Number Paragraph Number Requirement sentence Some Definitions Shall statement is a conceptual requirement for the complete system development Requirements Trace Matrix (RTM) an organized list of system requirements gathered during the initial phase from the system specification or requirement documents. Derived Requirements where the Shall can t be seen but can still be a requirement for the overall project or system Software Engineering - Fall 2014 GSU: Software CSC4350/6350 Engineering - CSC4350/ Rao Casturi- Rao Casturi 32

33 How to Address Will? Note: The Will sentences usually grouped together either at the end or with the appropriate section with the order. Capture Derived Requirements with out any paragraph number All Windows for the same environmental condition will be same Each environmental condition will be represented by a different color 33

34 What is the final deliverable? Requirements Traceability Matrix Derived Requirements From :USE CASES COMBINED WITH BOOCH OMT UML by Putnam P. Texel and Charles B. Williams For educational purpose only Only One per project Requirements Traceability Matrix 34

35 What is Type Column? Pre-agreed categories Software Requirement (SW) Hardware Requirement (HW) Derived Requirement (DR) Nice to have Requirement (NTH) Software Constraint (SWC) From :USE CASES COMBINED WITH BOOCH OMT UML by Putnam P. Texel and Charles B. Williams For educational purpose only 35

36 What is next Deliverable? Due: 09/18/ Problem Statement with Shall statements 2. RTM (4 columns ID#, Paragraph#, Description of the requirement, Type 3. Project Timeline (Gantt Chart with Tasks and allocation up to now) 4. Terminology 5. Rational for the project and the requirements Presentations : Each Group Present their project to the Class 36

37 Questions? 37