Lecture - Requirements and Elicitation.pdf

Welcome to INFO8655 Requirements Modelling and Visualization Couse Requirements and Elicitation Conestoga College Why Requirements Matter …. Camera Placement The buddy system… Take a walk J Stairs are hard…. New downstairs shortcut… For tho...

Welcome to INFO8655 Requirements Modelling and Visualization Couse Requirements and Elicitation Conestoga College Why Requirements Matter …. Camera Placement The buddy system… Take a walk J Stairs are hard…. New downstairs shortcut… For those who are disabled for only 9/10’s of the way up… It is good to be short sometimes… Sometimes better to be tall though… Uhhh…. No caption needed. Apparently roads and driveways are hard. Trains can just go around… …I am really hoping there is a real explanation for this one… Because tracks don’t warp like that… Not even going to make a joke here…  Tools of the Trade Rich Picture Pseudocode Dashboard Brainstorm PowerBI USE CASE Communication Paths Geographic Information Cockburn Notation Systems Mapping Champions PowerMaps Elicitation Practices Context Diagram ETL (*Time permitting) EcoSystem Map UXD/UI Tree Diagrams Mockups Feature Tree Wireframes Activity Diagrams Actor Diagram Prototypes State Activity Diagram Before we begin – Industry “Good” Practices Any diagram or stand-alone document should include: …a descriptive title …a project/software reference …a company name, department …a document date …a version number …an author name …a packet/index codes if appropriate Classifying the Customer Input to Build Requirements ELICITATION TECHNIQUES  Elicitation Techniques What is elicitation? Identifying the needs and constraints of the various stakeholders for a software system Collaborative and analytical process that includes activities to collect, discover, extract and define requirements.  Elicitation Techniques Questionnaires Workshops Surveys Documentation Analysis Focus Groups Examine histometric files Examine error reports JADs Examine logs and files Elicitation Interviews Narratives User Observation USE Cases Select Champions CHAMPIONS  Champions What is a champion? Internal and/or External They are the primary interface between members of a single user class and the BA. How do champions help? They become human representatives of your product. How to pick a champion? Dissenting view on champion selection. Promoting view on champion selection.  Champions Champions are used to create acceptance and to engage end-users and clients. Review Table 6-2 Product Champion Activities  Role of Project Sponsor Wait! We did a PRODUCT champion. So what is a PROJECT champion? Project champions act in a similar fashion to product champions. PROJECT champions maintain stakeholder faith in a project. They ensure Project Sponsors remain favorable. They ensure direct stakeholders (typically financial) continue support. COMMUNICATION PATHS  What is Communication Pathways Graphical representation of communication flows Explains hierarchy of communication  Communication Paths Who can ‘talk’ to whom in the Dell case? Client Sales (Customer (Purchaser) Service) Shipping Manufacturing ASSUMING SALES IS A PERSON, NOT AN AUTOMATED SERVICE! UML 2.0 Use Case Spectrum  UML 2.0 Interaction Diagrams Activity Diagram AS-IS TO-BE Class Diagram USE Case Diagram  AS-IS, TO-BE Process Flow Diagram AS-IS TO-BE Process flow diagram Process flow diagram Shows the EXACT process as Shows the IDEAL FUTURE state of the it exists process flow. No extra information Has recommendations and suggestions May require commenting May require supporting documentation  Use Case Diagram Graphical Text  UML 2.0 Interaction Diagrams Activity Diagram AS-IS TO-BE Class Diagram USE Case Diagram  UML 2.0 (Interaction Diagrams - Sequence Diagram) Does not address cardinality or specific details Demonstrates directional flow of activities and/or actions Includes only interactive elements Users Software/Enterprise Systems Databases, etc  UML 2.0 (Interaction Diagrams - Sequence Diagram) In a horizontal line, list all interactive elements Extend a dashed line vertically down from each element Elements have activities ‘instances’ shown on corresponding line All instances must be listed sequentially Interaction between any 2 instances must contain verbiage Each interaction will be sequentially numbered Each instance can ONLY connect to ONE other instance at a time.  Entity Relationship Diagrams(ERD) Show logical groups of information from the problem domain & their interconnections. Why? Show high level view of system data. Crow’s Foot notation GATHERING AND WRITING REQUIREMENTS  A Critical Tool! Take any BA in the field and ask them… What is the most critical skill? What does the class think that skill would be? EVERY BA WILL SAY: COMMUNICATIONS  Communications Our main topic of the day is a critical one It directly relates to communications Writing Gathering Requirements Requirements  Communications Course As you progress through communications you must: Keep ‘requirements’ in mind In that course we will look at: How-to elicit requirements In-depth requirements How-to write requirements Best practices  Writing Requirements There will be significant coverage of this topic in Communications Today we just want to understand some of the rules How they apply And get some ‘practice’ with requirement writing!  Rules for Requirements Writing Gathering Complete Complete Correct Consistent Feasible Modifiable Necessary Maintain a history Prioritized Traceable Unambiguous (clear) From collection to completion Verifiable  Writing a Requirement What were some of the common practices you read about? Understand your client (Internal/External) ACTIVE writing styles Each requirement is written as an individual statement Do not use objective/subjective pronouns I/He/Her Indicate ‘what’ will be fulfilling the requirement “Sales Department” “Transaction System” “The Buyer”  Writing a Requirement What were some of the common practices you read about? Words we try to avoid and why: AND, OR, ALSO, UNLESS, EXCEPT, BUT Words that indicate multiple requirements in one line Reasonably, appropriately, generally, approximately, quickly…. Not measurable, these are subjective  Why…. Why do we need to make requirements painfully clear? Why go through all of this effort? Ambiguity leads to unnecessary mistakes. If someone later in the project discovers the mistake, will they fix it, or continue knowing what they are doing is WRONG? There was a reason we looked at these joke images earlier  Why Requirements Matter So why are requirements so critical? I know it seems kind of silly… To make this easier we will take 3 approaches 1. We will look at a written requirements Discussing what it means 2. We will discuss when requirements went wrong in real-life 3. We will have you practice your requirement writing skills  What’s wrong? Complete Correct Feasible We will provide a state-of-the-art network for CDL Necessary Prioritized ensuring a 100% up-time for network traffic. Unambiguou s Verifiable  We We Who is we Define it… Is it an entire company? A department? A team? A subcontractor?  Provide Provide We will give them the network? We will install the network? We will set up the network? We will instruct them on how to build the network?  State-of-the-Art State-of-the-art: Is completely subjective… Is time-based as ‘state-of-the-art’ changes constantly Is SUBJECTIVE, meaning different interpretations Does not clarify the deliverable  100% up-time for network traffic 100% up-time for network traffic Raise your hand if you have a piece of technology that: Has work 100% of the time without any failure ever… What happens if the city/province loses power? What happens if the building burns down with all equipment inside? Yes, we plan for this using risk management! …requirements are poorly recorded WHAT HAPPENS WHEN…  Poorly Worded Requirements This is a topic that doesn’t receive proper attention Requirements are critical Choice of words is critical Requirements become basis for legal matters They define what we are required to do They define our scope They allow us control, safety and clarity  Kitchener Public Library RIM Park Fiasco Lee, P. (2015, March 19). [ Library entrance Peter Lee,Record staff A sculpture hangs inside the atrium of the entrance of the renovated Kitchener Public Library's central branch.]. Retrieved January 21, 2016, from http://www.therecord.com/news- story/5513902-contractor-sues-city-architects-for-7m-over- delays-in-library-renovation/ Charles/Brenton Parking Structure IMPACT OF POOR Bebee, D. (2014, May 26). Benton Street garage [Digital image]. Retrieved March 25, 2017, from REQUIREMENTS http://www.therecord.com/news -story/4539619-downtown- safety-parking-top-priorities-in- kitchener-survey/