Workshop on requirements and modeling at HAE 2015
1 like562 views
1. The document discusses requirements modeling in IT projects and how modeling techniques can be used to better understand requirements and be understood. 2. It provides background on the presenter and an overview of various modeling techniques such as use case diagrams, class diagrams, and collaboration diagrams that can be used. 3. The document then walks through an example of modeling the requirements for a deal initiation system using techniques like identifying entities, controllers, boundaries, use cases, and class responsibilities to develop a conceptual model of the system requirements.
Workshop on requirements and modeling at HAE 2015
- 1. RequirementsModeling in IT Projects Modeling & Requirements in IT Projects How to better understand and be understood? By July 6th 2015, Hellenic American Union
- 2. IT Projects RequirementsModeling IT System Organisation Description Realisation Realisation DescriptionRoadmap
- 3. A bit of background 1997 1999 Bachelor Industrial & Telecommunication Computing Rational Software 2003 IBM 2005 Empulsys Developer Tools Specialist RUP Consultant Trainer http://disciplinedagileconsortium.org/ Agile/UP Mentor 2015
- 4. Modeling -‐ What is it? What for? Communication and understanding over documentation and standards (UML, BPMN,…) HoldCold Richness of the communication channel Effectiveness of the communication Modeling options Documentation options Understand and be understood Face-‐to-‐face (whiteboard) Face-‐to-‐face (conversation) Video conversation Phone conversationEmail conversation Video recording Audio recording Paper http://www.agilemodeling.com/
- 5. Modeling – Many techniques http://www.agilemodeling.com/ Modeling artefacts Activity diagram Business Rule definition Change Case Class diagram Class-‐Collaboration-‐ Responsibility cards Data diagram Component diagram Constraint definition Collaboration diagrams Deployment diagram Data flow diagram System User Interfaces (mockups) External Interface Specification Use Case diagram Essentials User Interfaces Feature Flowchart Organisation chart Robustness diagram Statechart Sequence diagram Used to explore use cases and identify controllers, boundaries and entities. Used to explore the conceptual model Appropriate for OO designs. UML and BPMN are not the only valid modeling notations Used to express the design of systems using Object-‐ Oriented concepts.
- 6. Customer End-user Supplier PM P SCM BM Development Test Acceptance Production Process Engineering (Methodology) Implementation (Coding) Testing Change Request Management Project Management Deployment Management Software Configuration Management PPM Portfolio Management AD I T DM CRM RDM Build Management Product Owner Analyst Developer BM Business Modeling Tester SCRUM Master Project Manager Requirements Specifier Architect Owner Software Architect User Representative System Analysis and Design We have €€€. You build VALUE We have PROBLEMS.You build SOLUTIONS Team Members Requirements Definition and Management Business Reprenetative Modeling – Many opportunities
- 7. Requirements -‐ Refresh • Requirements • A condition or a capability a system must conform to. • A capacity required by a user to reach an objective or solve a problem. • Requirements (Definition and) Management • To come to an agreement with the customer and the user on what the system should do. • To give the development team better understanding of the system requirements. • Ensure that our customer interests are satisfied. Requirements What the system must do How the system will do it Solution Problem space vs Solution space Customer End-user Supplier RDM
- 8. http://www.empulsys.com/en/free-‐resources/94-‐frombusiness2systems Information Families Modeling Concepts A Information describing “What” an organization does and ”Why” the organization needs to do so à Business Use Case Model B Information describing “How” an organization is (or should be) supported by an IT environment and humans à Business Object Model C Information describing “What” are the user (human) needs in regard to an application and ”Why” these user needs are important à System Use Case Model, Use Case Specifications, Supplementary Specifications, Glossary, Vision D Information regarding “How” an application is structured to offer a solution aligned on user needs à System Analysis/Design Model, Software Architecture Document E All other information used/produced to organize a project, monitor progress and verify the quality of project outcome à Project Plan, Test Plans, Tasks, Test Cases,… Problems & Contexts Priorities Planning Software Requirements Software Requirements Progress Impact Inter-‐dependencies between disciplines <<candidate>> <<candidate>> Business Actor Business Use Case Business Worker Operation <<candidate>> <<candidate>> Business Rule Business Entity System Actor System Use Case <<implements>> <<implements>> EntityControllerBoundary 1 * <<realizes>> <<realizes>> State Machine <<implements>> <<details>> <<candidate>> Scenario OK X Test CaseTask <<verifies>> <<covers>> Progress Scope & Business Values Business Case Processes & Objectives PPM BM RDM AD T BMDM SCM P Requirements – Are central
- 9. Part 1: Modeling and System Requirements
- 10. Hands-‐on – Understanding System Requirements from to How ? REFINED
- 11. Understanding System Requirements (1/8) I initiate a deal Other person has an account? Single payment scheme? Accept deal conditions? YES NO YES YES NO NO from to As a trainer, I want to record a new deal in the systemso that the company which requested the training accepts my payment conditions. 1. The system retrieves the information about the deal initiator (DI). 2. The system requests to provide the email address of another member of the system. 3. The DI submits the email address of the other member. 4. The system verifies if the email address is known. 5. The system informs the DI that other member is known. 6. The system asks the DI to specify his/her role in the deal. 7. The system requests the DI to specify the product/service subject of the deal, a reference (optional), a currency and amount, a reckonable price date and a reckonable amount date. 8. The DI enters the requested information. 9. … End-User Analyst Specification ? Example StoryDriven Modeling Product Owner Team Members
- 12. Understanding System Requirements (2/8) Controller. It represents something that coordinates the behavior of the system for a particular scenario. Boundary. It represents something that intermediates between the system and the outside Step #1: identify the controllers and boundaries DEALINITIATIONCONTROLER DEALINITIATIONINTERFACE EMAILNOTIFCATIONSYSTEM SHORTMESSAGESYSTEM Interfaces to systems, devices, users are boundaries
- 13. Understanding System Requirements (3/8) Step #2: Filter nouns from the scenario description 1. The system retrieves the information about the deal initiator (DI). deal initiator Information 2. The system requests to provide the email address of another member of the system. email address, (another) member 3. The DI submits the email address of the other member. email address, (other) member 4. The system verifies if the email address is known. email address 5. The system informs the DI that other member is known. (other) member 6. The system asks the DI to specify his/her role in the deal. role, deal 7. The system requests the DI to specify the product/service subject of the deal, a reference (optional), a currency and amount, a reckonable price date and a reckonable amount date. product/service, deal subject, reference, currency, amount, (reckonable) price date, (reckonable) amount date 8. The DI enters the requested information. (requested) information 9. The system asks for the number of payments. number, payments Be caution with references to actors (will be addressed through boundaries) Ignore operations (e.g. “the processing”, particularity of english). Ignore synonyms, duplicates.
- 14. Understanding System Requirements (4/8) Step #3: Create list of candidate entities Entity. It represents a key abstraction of the system. SHORTMESSAGEEMAILNOTIFICATION DEALINITIATIORINFO -‐ role DEALPARTICIPANTINFO -‐ email address -‐ role DEAL -‐ buyer -‐ seller -‐ currency -‐ amount -‐ reckonable price date -‐ reckonable amount date -‐ official amount -‐ unique deal number -‐ status PRODUCT -‐ description -‐ reference -‐ status PAYMENT -‐ scheme
- 15. Understanding System Requirements(5/8) Step #4: Prepare your Class-‐Responsibilities-‐Collaboration cards DEALPARTICIPANTINFO A4 SHORTMESSAGE DEAL EMAILNOTIFICATION DEALINITIATIORINFO PRODUCT PAYMENT DEALINITIATIONCONTROLER SHORTMESSAGESYSTEM DEALINITIATIONINTERFACE EMAILNOTIFICATIONSYSTEM
- 16. Understanding System Requirements (6/8) Step #5: Identify required interactions DEALPARTICIPANTINFO DEAL DEALINITIATIORINFO PRODUCT MEMBERLIST DEALINITIATIONCONTROLER DEALINITIATIONINTERFACE Deal Initiator 2. Ask Email Other Member 3. Check Existence Other Member 11. Present Other Member Details 13. Ask Role And Deal Details 14. Set Deal Settings 25. Ask Payment Scheme 26. Set Payment Scheme 1. Get Deal Initiator Info 4. Get Other Member ID 5. Find Other Member Email 12. Get Product Specifications 24. Get Payment Scheme 16. Get Member ID 15. Set Seller 17. Set Buyer 19. Set Product Description 21. Set Product Reference 23. Set Amount and Currency … 6. Find Member by Email 7. Get Member Details 8. Get Member ID 9. Get First Name 10. Get Last Name 18. Get Member ID DEALINITIATIORINFO DEALINITIATIONINTERFACE MEMBERLIST DEALINITIATIONCONTROLLER DEALINITIATIONCONTROLLER - - - - - DEALINITIATORINFO DEALPARTICIPANTINFO PRODUCT PRODUCT - 20. Set Description 22. Set Reference - - - - - - - DEALPARTCIPANTINFO Product Owner Team Members New Class-‐Collaboration-‐Responsibility cards modeling artefact
- 17. Understanding System Requirements(7/8) Step #6: Identify required classes, operations and attributes DEALINITIATIONINTERFACE AskEmailOtherMember() CheckMemberExistence() PresentMemberDetails() AskRole() AskDealDetails() RecordDealSettings() AskPaymentScheme() SetPaymentScheme() DEAL SetSeller(Member) SetBuyer(Member) SetProductDetails(description, reference) SetDealAmountAndCurrency() amount currency PRODUCT SetDescription() SetReference() description reference MEMBER GetID() GetFirstName() GetLastName() GetEmail() id Lastname Firstname email MEMBERLIST FindMemberByEmail(email) DEALINITIATIONCONTROLLER GetDealInitiator(): Member GetDealParticipant(): Member GetDealDetails(): Deal GetFinancialConditions() 1 1 1 1 1 0..* 0..* Team Members Can we have members in the system not involved in any deal? Can members be involved in several deals? If so, any limits? Product Owner 0..* 1 Class diagram modeling artefact
- 18. Understanding System Requirements(8/8) Step #7: Identify candidate development activities As a trainer, I want to record a new deal in the system so that the company which requested the training accepts my payment conditions. We need to build a user interface that will allow a member: -‐ to find and see details of another user -‐ to get the role of the member (cfr. ”trainer” -‐> “seller”) -‐ to get the details of the deal (product, etc) -‐ to get the financial conditions We need to build some logic that will: -‐ Create deals and products -‐ Associate members to deals We need to build “services” that will: -‐ Handle the members -‐ Find members -‐ Handle deals and products Team MembersDeveloper
- 19. Hands-‐on – Your turn!! Inputs • Scenario for the initiation of a deal • Scenario for the management of sell • Scenario for the management of a purchase Outputs • List of entities, boundaries, controllers • CRC sessions • Overall class diagram • Summary of activities Steps #1: identify the controllers and boundaries #2: Filter nouns from the scenario description #3: Create list of candidate entities #4: Prepare your Class-‐Responsibilities-‐Collaboration cards #5: Identify required interactions #6: Identify required classes, operations and attributes #7: Identify candidate development activities
- 20. Part 2: Modeling and Business Requirements
- 21. Insight – Understanding business requirements from to How ? REVISITED
- 22. By the way… Modeling applied toSystem Organisation (Business) Business Use Cases describe what the business delivers from an external perspective Following elements are used to describe how business processes are performed Static: Business Workers Business Entities Business Systems Dynamic: Business Use Case Realizations Static: Business Actors Business Use Cases Dynamic: Business Use Case Descriptions System Use Cases describe what a system will offer to people/system interacting with Following elements are used to describe how system use cases are realised Static: Boundaries Entities Controllers Dynamic: Use Case Realizations Static: Actors Use Cases Dynamic: Use Case Descriptions Modeling an Information System-‐ Describing it from the outside (screens, interactions, capabilities, deployment) and from the inside (data, logic, structure) Modeling an Organisation–Describing it from the outside (partners/providers, services, qualities) and from the inside (people, information, systems) Class-‐Collaboration-‐ Responsibility cards Class diagram Class diagram Activity diagrams
- 23. Business Modeling – Some key concepts Business Worker. It represents a role within the business/organisation. It can be a human or a system inside the organisation. Interacts with other business workers and with business entities Business Entity. It represents a piece of information manipulated by business workers. Has relationships with other business entities Business System. It represents an independent capability within an organisation. Is used to structure the organisation in manageable chunks and understand it. It binds and contain roles and resources 1 1 * *
- 24. 1. Depicting the context 2. Claryfing involved units/people (stakeholders) 3. Drafting the situation (who, why) Business Modeling – Concrete application 2h effort
- 25. Business Modeling – Importance of Doing It Conflicting requirements from users. The broader context of the system is not well understood. Difficulty baselining the requirements. No understanding of the relationship between the scope of work and the business’ goals. Customers/Users continuously change their mind. No clear idea of the problem they are trying to solve in relation to the business’ objectives. Solve the wrong problem. No understanding of the relationship between the scope of work, the business’ goals, and impact to business processes Users get what they asked for but it turns out it is not what they needed. No understanding of the relationship between the scope of work, the business’ goals and impact to business processes Solutions deliver little or no value. No understanding of the relationship between the scope of work, the business’ goals, and the obstacles to those goals. Difficulty deploying solution into business process. The broader context of the system is not well understood. No system is an island into itself Address root causes behind the symptoms