1.2 Building the Right System. Identifying Needs & Expectations. Where to look for needs & expectations? or Who are the stakeholders?

Transcription

1 These slides are designed for presentation, not for stand-alone reading. 1.2 Building the Right System Elizabeth Bjarnason Department Of Computer Science Lund University Identifying Needs & Expectations Requirements Elicitation Where to look for needs & expectations? or Who are the stakeholders? Users of product Customer who order / purchase the product Customer/User s IT department service and admin of product Legal and regulatory entities Suppliers, e.g. of components Stakeholders of connected systems Competitors? Developing company Development organisation Technique: Stakeholder analysis Who are the stakeholders? What are their goals for the product? Why contribute? Risks and costs? Envisioned solutions, e.g. suppliers, resources. Make-or-Buy, Replaceor-Extend, etc.

2 Bespoke Development vs Market-Driven Development Customer-specific solutions, e.g. ticket solution for Flytoget, Oslo With the new ticket solution it will be easier to travel with Flytoget, both for firsttime users and frequent travellers. Aug-15 1 In-house solutions, e.g. dev tools, student admin systems Customer adaptions of complete solutions, e.g. operator-specific mobile phones, tailor-made services for industrial robot 1 Technique: Context Diagram Interact at event Gradually, More Detailed Levels Goal: what are the business goals - $? Domain: Product in context Product: Function, data and quality Design: What, but not how? $ SEK

3 What info is needed? Present work of users Present problems Goals and critical issues Ideas for future product Realistic possibilities Commitment from stakeholders Conflict resolution between stakeholders Prioritisation of needs How hard can it be? Barriers in elicitation Cannot express need Difficulty explaining performed tasks Specify a solution rather than need Hard to imagine new solution approaches Conflicting views Personal agendas, power struggles Resistance to change nice to have Collaborative Representative Accountable Committed Knowledgeable Elicitation Techniques Interviews Questionnaires Brainstorming Focus groups Domain workshops Design workshops Observations Task demos Document studies Prototyping Pilot experiments Competitor analysis Ask suppliers Negotiation Risk analysis Cost/benefit analysis Goal-domain analysis Domain-requirement analysis Data-Driven Requirements Engineering Elicit needs from user feedback - Issue tracker in OSS projects - Social media, User forums, Review systems Feedback from usage data -> identify usage situations and context

4 What does a requirement look like? This product should have better performance than Got it right? Requirements Validation I want to be able to So we agree to implement feature X with this behaviour due to limitations in our architecture. Validation Techniques Of documented requirements Content Consistency Goal-requirements tracing CRUD on data entities Correct, complete, consistent, clear etc Ensure same view of what to build! Prototyping and demos User testing User experimentation Large-Scale User Testing: On-line Experiments Test product variants in-field -> validating ideas Used by Amazon, ebay, Etsy, Facebook, Google etc Example: Bing, ads w site links Overall Evaluation Criteria: Increased revenue / user without degrade of user experience

5 Example: PUST when not right! 1 Enable police to file crimes in the field V1: user involvement, iterative prototyping, usability in focus V2 (Pust Siebel): based on standard solutions, cost saving in focus. -> Cancelled project. Cost, for v 1: approx 100 milj SEK for v 2: approx 200 milj SEK Feasible Scope for Development Prioritisation and Release Planning Feasible Scope, or Overscoped? for this project, next project, never? Scope Effects of overscoping Causes of overscoping - Changes to product scope and plans (DT = Development Team) - Wasted effort - Quality issues - Delays - Unmet customer expectations - Communication gaps, Reqts spec out-of-date - Overtime, demotivated engineers Time Cost Scoping & Release Planning Return-of-Investment (ROI) = value / cost Constraints: dependencies, resources Balancing conflicting stakeholders and risks Changing value over time Uncertain estimates Bjarnason, Elizabeth, Krzysztof Wnuk, and Björn Regnell. "Are you biting off more than you can chew? A case study on causes and effects of overscoping in large-scale software engineering." Information and Software Technology (2012):

6 Prioritization Techniques Grouping, Numerical assignment (grading) Ranking / sorting (ordinal scale) $100-test (ratio scale) Analytical Hierarchy Process (AHP) decision support combining multiple aspects Agile: backlog prio and planning poker Communicating Requirements Specification and Through Other Channels The Role of Requirements in Software Engineering sizeof(communication challenge) == exp(no of people involved) Flickr: carlcollins Participatory design etc. Flickr: nearsoft UX Testing User testing Acquire system/ product RE Software Engineering Flickr: m-i-k-e + portfolio and product size and complexity

7 Communication Gaps Effects - Unmet customer expectns - Quality issues - Wasted effort - Comm of incorrect reqts - Low motivation for RE - Low quality of reqts - Reqts volabilty - SE controls scope - Unclear reqts coverage - Test scope mismatch Requirements are documented in Requirements specifications Requirements databases Part of design specs Backlogs Story cards and acceptance criteria In task assignments s, Wiki pages As Test cases TCR Bjarnason, Wnuk, Regnell. "Requirements are slipping through the gaps A case study on causes & effects of communication gaps in large-scale software development." 19th IEEE International Requirements Engineering Conference (RE), Requirements are Formal Documented Expressed So we agree it should work like this.. Informal Undocumented Tacit Role of Requirements Validation Verification Testing Tracing to stakeholders, to development artefacts Managing requirements changes Legal contracts

8 Specification Techniques & Styles Context diagram Event & function list Feature requirement Screens & prototypes Task descriptions Tasks & Support Scenarios Good tasks High-level tasks Use cases Data model Data dictionary Data expression Virtual windows Tasks with data Dataflow diagrams Standards as requirements Development process reqts Complex & simple functions Decision tables Textual process descriptions State diagrams State-transition matrices Activity diagrams Class diagrams Collaboration diagrams Sequence diagrams, events and messages Quality grid Open metric and open target Planguage QUPER User stories Criteria for Good Requirements (ISO ) Correct Complete Unambiguous Consistent Ranked for importance and stability Modifiable Verifiable Traceable Test Cases as Requirements (TCR) Often used within agile Defacto or planned (Behaviour-Driven Dev) Reduced OH of separate spec Executable specification Communication + and Tools required When building: Ask Questions! Make sure you understand context Why is this required? How is it to be used? Who/what is the user? When, in which situations, will it be used? Make sure you get the full picture What quality aspects are required? Should this be configurable for products? Should other users/actors be able to access this data? Should this functionality interact with other functionality? Run in parallel?

9 Requirements WILL change Managing Changes Continuous RE irrespective of dev model Process needed for change management: decision forum Communicate to ALL affected roles: Direct and Indirect (Update spec!) Identify Needs & Expectations Eliciting Validating Set Feasible Scope Prioritise Communicate Your case study Requirements is a magic word avoid it! Need, expectations, goals Ask about who the users and stakeholders are Participatory design etc. How are there needs identified How is project / product scope decided Acquire system/ product RE UX Testing User testing How does developers and tester know what to build? What kind of reqts documentation is there? How are changes to project scope handled: decided and communicated? Software Engineering

10 Thank you!