Software Requirements and Organizational Culture: 10 Lessons Learned

Transcription

1 Software Requirements and Organizational Culture: 10 Lessons Learned Sponsored by: Karl Wiegers Principal Consultant, Process Impact

2 Sponsor: IREB CPRE CERTIFIED PROFESSIONAL FOR REQUIREMENTS ENGINEERING Expert Level January 2018 Prerequisite: 3 Advanced Level certificates (2 certificates replaceable) Advanced Level available Modules: Requirements Elicitation and Consolidation Requirements Modeling Requirements Management RE@Agile Q Prerequisite: Foundation Level certificate Prerequisite: none Foundation Level Prerequisite: none RE@Agile Primer 2

3 Featured Speaker Karl Wiegers Principal Consultant, Process Impact Phone #: E mail: Blog: karl@processimpact.com Consulting Tips & Tricks Blog: Downloadable Process Goodies: Use discount code GOOD17 for $20 off on Process Impact Goodies Collection 3

4 Source Books Creating a Software Engineering Culture by Karl Wiegers (Dorset House Publishing, 1996) Software Requirements, 3rd Edition by Karl Wiegers and Joy Beatty (Microsoft Press, 2013) tinyurl.com/reqs3 4

5 Lesson One: Every software organization should determine its underlying cultural principles. Software Engineering Culture A set of beliefs, behaviors, and technical practices that define an environment in which all team members are committed to building quality software products through effective and appropriate software processes. Requires commitments: by each technical practitioner, to apply sound software engineering practices by managers at all levels, to provide a quality driven environment by everyone, to continuously improve the way they work 5

6 Some of My Old Group s Cultural Principles Never let your boss or your customer talk you into doing a bad job. Ongoing education is every team member s responsibility. A key to software quality is to iterate on all development steps except coding. Quality is the top priority; long term productivity is a natural benefit of high quality. People need to feel that the work they do is appreciated. If you measure what you do, you can learn to do it better. Strive to have a peer, rather than a customer, find a defect. Continual improvement of your software development process is both possible and essential. You can t change everything at once. 6

7 Lesson Two: Management at all levels plays a huge role in steering the culture for better or for worse. Actions matter, not words Culture Builders actions a manager takes to establish and reinforce a healthy culture Culture Killers actions a manager takes that undermine a healthy culture 7

8 Culture Builders and Culture Killers Some Culture Builders If no one is interested in serving as a product champion for a project, perhaps the project should be canceled. Make tracking charts of acceptance test results visible to the whole team to emphasize a shared focus on quality. Some Culture Killers We haven t got time to write requirements; just build me a system. Include every requirement anyone requests in the specification, regardless of usage frequency, cost, or feasibility. The customer is always right. Use the defect logs from peer reviews as input into individual performance appraisals. This shows you care about quality. 8

9 Lesson Three: A commitment to effective requirements engineering is a hallmark of a healthy software engineering culture. Some relevant cultural principles: Customer involvement is the most critical factor in software quality. Our greatest challenge is sharing the vision of the final product with the customer. 9

10 Management Commitment to Requirements 1. Asking that requirements for a project be documented in an appropriate form. 2. Working with the business analyst to provide business requirements. 3. Expecting requirements to be reviewed by appropriate stakeholders. 4. Asking stakeholders to agree on requirements before implementing each portion of the solution. 5. Ensuring that project plans include time and resources for requirements tasks. 6. Collaborating with other key stakeholders to gain their participation in requirements activities. 7. Establishing effective mechanisms and policies to handle changes. 8. Investing in training, tools, books, and other resources. 9. Funding and staffing activities to improve the organization s requirements processes. 10. Making the time available for team members to spend on requirements process improvement activities. 10

11 Lesson Four: Clearly defined business requirements are the foundation of a successful project. Business requirements include: business opportunity business objectives success metrics vision statement business risks, assumptions, dependencies scope of initial and subsequent releases limitations and exclusions stakeholder profiles 11

12 Three Levels of Software Requirements Business Requirements Business Rules Vision and Scope Document User Requirements Quality Attributes User Requirements Document System Requirements Functional Requirements External Interfaces Constraints Software Requirements Specification 12

13 Lesson Five: Taking a usage centric approach instead of a feature centric approach during elicitation better meets user needs. Traditional: Use Cases A description of a set of interaction sequences that a system performs to provide a result of observable or measurable value to one or more actors. Agile: User Stories A short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. 13

14 Create an Invoice Use Cases and User Stories Use Case Name conversations use case specification analysis functional requirements tests As a small business owner, I want to create an invoice so that I can bill a customer. User Story conversations refined user stories conversations acceptance tests 14

15 Benefits from the Usage Centric Approach User s terminology is applied Reveals functionality users need to get their work done Helps analysts understand application domain Avoids building unnecessary functionality Permits early drafting of acceptance tests Helps set priorities for functional requirements Permits tracing requirements back to voice of the customer 15

16 Lesson Six: Customer engagement is a vital contributor to building high quality software. Expectation Gap (Surprise!) Time 16

17 A Stakeholder Hierarchy Stakeholders Customers Other Stakeholders Direct and Indirect Users Other Customers Favored User Classes Disfavored User Classes Ignored User Classes Other User Classes 17

18 Key Aspects of Customer Involvement Identify stakeholders and their interests and priorities Identify distinct user classes Identify product champions to represent user classes Have a Customer s Requirements Bill of Rights and Bill of Responsibilities Select appropriate elicitation techniques Have customers define acceptance criteria Engage customers through prototypes, reviews, etc. 18

19 Reducing the Expectation Gap } Expectation Gap contact point contact point contact point Time 19

20 Lesson Seven: The business analyst plays a central role in understanding and communicating a project s requirements. Responsible for many tasks: Defining business requirements with project sponsor Identifying project stakeholders and user classes Eliciting requirements Analyzing requirements Specifying requirements in various ways Leading requirements validation Facilitating requirements prioritization Managing requirements 20

21 The Business Analyst: A Bridging Role sponsor business requirements size and complexity information project manager user functional and user reps requirements nonfunctional requirements development other stakeholders expectations and constraints functional and nonfunctional requirements testing 21

22 Lesson Eight: No single view of the requirements shows you everything you need to know. Naturallanguage requirements Prototypes and screen designs Data dictionary Visual analysis models Tables and structured lists Photographs, video clips, audio clips Acceptance tests Decision tables and decision trees Mathematical expressions 22

23 Lesson Nine: A guiding principle of requirements development is iterative refinement of detail. You can t get all the requirements the first time. You can t get the requirements right the first time. Requirements will change. An adaptive strategy: identify user requirements at a high level learn enough about them to do first cut prioritization allocate user requirements to releases or iterations elaborate requirements details prior to construction revise, refine, reprioritize, reallocate as change happens 23

24 Components of Requirements Engineering Requirements Engineering Requirements Development Requirements Management Elicitation Analysis Specification Validation clarify rewrite re-evaluate confirm and correct 24

25 Lesson Ten: Addressing nonfunctional requirements contributes significantly to user satisfaction. Nonfunctional Requirements Constraints External Interface Reqs Performance Quality Attributes design implementation user software hardware communication response time throughput latency degraded modes efficiency usability robustness installability security availability modifiability... 25

26 Software Quality Attributes Two views of product characteristics: External Quality (important to users) Internal Quality (important to developers and maintainers) Write them to be quantitative and verifiable Document these in the requirements specification Cannot be simultaneously optimized; there are tradeoffs 26

27 Bonus Lesson: Without high quality requirements, software is like a box of chocolates: you never know what you re going to get. 27

28 Sponsor: IREB The CPRE is worldwide acknowledged over 33,000 certified professionals in 70 countries Gain the relevant skills, improve your professional profile and you will gain a higher market value. CPRE RE@Agile addresses RE in an agile context Work more efficiently with stakeholders during elicitation. Learn the appropriate methods for successful negotiations. Be familiar with different techniques for modeling and documenting requirements. Be more effective at managing requirements during the entire lifecycle of a project or product. Know the terminology of RE Become part of an internationally recognized community. 28

29 Q & A Karl Wiegers thereconstructionbook.com 29