1. University of Southern California Center for Systems and Software Engineering Common mistakes in Core FC Package

2. University of Southern California Center for Systems and Software Engineering Outline OCD SSAD FED

3. University of Southern California Center for Systems and Software Engineering Operational Concept Description Benefit Chain Diagram –How each stakeholder create benefit, especially in operation phase ? –Should correspond to your organization goals and core capabilities Element Relationship Diagram –What are the elements that you develop(put them in dashed box) ? –What are the elements that you have to coordinate/ interoperate (put them outside the dashed box)? Business Workflow –Sequence of worksthat stakeholdershave to perform –Will reflect on how your new system improve the current workflow –Do not care about how your system works (not a technical flow)

4. University of Southern California Center for Systems and Software Engineering A not so good Benefit Chain Diagram Common Mistakes -Focus too much on what you develop -Missing critical stakeholder -Missing core initiatives -Missing contributions -Wrong notations -Initiative and outcome don’t match Overemphasized Underemphasized

5. University of Southern California Center for Systems and Software Engineering A Good example of Benefit Chain Diagram

6. University of Southern California Center for Systems and Software Engineering A not so good example of Element Relationship Diagram User AUTHENTICATIONAUTHENTICATION Stage Manager Editor/D esigner Show Roster Administ rator Budget Data Scheduling Data D at ab as e M an ag e m en t Sy st e m Tas ks Database Reporting Task Tracker Project Operation s Activate s Contro ls Uses Creates report using budget data Tracked using Username / Password Visitor Requests for access Creates and manages show Manages designer tasks View schedule and tasks Creates Show, Budget manages user account Common Mistakes - Unorganized drawing -Mixing between the module you develop and module you link to - missing elements that you link with

7. University of Southern California Center for Systems and Software Engineering A good example of Element Relationship Diagram

8. University of Southern California Center for Systems and Software Engineering A not so good example Visit website homepage Already a member? Log-in Sign-up no yes Access training videos and material, Provide feedback, securely download material, Access the discussion board, Online shopping, Access coupons User System Common Mistakes - Focus on technical flow - Too detail on system’s behavior instead of “business” transaction

9. University of Southern California Center for Systems and Software Engineering A good example of Business Workflow Diagram

10. University of Southern California Center for Systems and Software Engineering SSAD

11. University of Southern California Center for Systems and Software Engineering System Context Diagram Incorrect hierarchy of actor classes –Should match exactly with the use-case model –Look for common functionalities Incorrect system scope –What you are developing External systems –Not a sub-system –Should be shown as an actor

12. University of Southern California Center for Systems and Software Engineering Artifacts and Information Many components are not artifacts Association = sharing of information Persistent data that are stored/used by system for execution Artifacts are: –User profile –Report –Application form Artifacts are not: –User –System

13. University of Southern California Center for Systems and Software Engineering Use-Case Hierarchy of users –Look for common use-cases Missing related capability requirements/win conditions Incorrect pre-/post- conditions Course of actions not shown in sequence Missing actors described in the system context

14. University of Southern California Center for Systems and Software Engineering Pre-/Post- Conditions Bad precondition: “User wants to access the website” “User needs to provide valid information” Good precondition: “User is Administrator. Database is initialized” Bad postcondition: “Information was changed” Good postcondition: “User information is saved to the database.” “If username and password are verified, user is granted access; otherwise, user is denied access.”

15. University of Southern California Center for Systems and Software Engineering Course of Actions GoodBad #Actor’s ActionsSystem’s Response 1[User] Enters the payment amount 2[User] Clicks “Donate” 3Sends information to Paypal and redirects to Paypal 4[Paypal] Generates confirmation 5Receives confirmation from Paypal 6Displays message “Donation complete” #Actor’s ActionsSystem’s Response 1[User] Enters the payment amount and clicks “Donate” Sends information to Paypal and redirects to Paypal 2[Paypal] Generates confirmation Receives confirmation from Paypal and displays confirm message

16. University of Southern California Center for Systems and Software Engineering Use-Case BadGood

17. University of Southern California Center for Systems and Software Engineering FED 4.2.1 NDI/NCS Candidates –For each functionality you are looking for in NDI/NCS, you should evaluate more than 1 product 4.2.2 NDI/NCS Evaluation Criteria –Trace back with OCD for Capability Goals and LOS Goals

18. University of Southern California Center for Systems and Software Engineering 4.2.1 NDI/NCS Candidates Think about what are available in the market List the possible candidates (more than one) Prove by using 4.2.2 criteria and show results in 4.2.3 results which your choice is the best

19. University of Southern California Center for Systems and Software Engineering For example: you are looking for one or more NDI/NCS that has the following functionalities –content management system –an online calendar tool Example: NDI/NCS productsRationale Content Management System 1. Joomla > 2. Drupal > 3. Moodule > An online calendar tool 1. Google Calendar > 2. LiteCalendar > 3. XLCalendar >

20. University of Southern California Center for Systems and Software Engineering 4.2.2 NDI/NCS Evaluation Criteria One table for the attributes –Check ICM EPG for common attribute –Check your OCD for LOS goals –Example: Concurrency, 24/7 availability, interoperability At least one table for the features –Check your OCD for capability goals –Elaborate Capability Goals into features or sub features –Could separate into many tables for different Capability, e.g. one table for CMS, one table for online calendar tool You will later use table of attributes and table of features as a scoring guide in 4.2.3

21. University of Southern California Center for Systems and Software Engineering Example of table of features No.FeaturesScore CMS1Publishing web pages30 CMS2Discussion board15 CMS3User Profiles10 CMS4Various authorization level10 CMS5Blog25 CMS 6Users statistics10 Total100 Features for the Content Management system No.FeaturesScore CAL1Add / update / delete event50 CAL2Add / update / delete photo10 CAL3Synchronization with mobile phone10 CAL4Email reminder30 Total100 Features for the Content Management system