Organizing Requirements & Managing Scope (Chapters 15-19 of the requirements text )

1. Organizing Requirements & Managing Scope(Chapters 15-19 of the requirements text) Steve Chenoweth & Chandan Rupakheti RHIT Which brings up Question 1, tying that to requirements management…

2. Outline • Organizing Requirements • Vision Document • Product Management • Managing Scope

3. Organizing Requirements • Why should we organize requirements? • Requirements are rarely captured in a single document. Why? • Complex systems • Families of products • Marketing and business goals • Legal and other extraneous requirements

4. Product Families • A series of products with closely related requirements • A new way of viewing software products • Investing in infrastructure to build product families This is SEI’s view of product line development. Notice that there are two levels – and the Core Assets on the left need requirements, too – what’s common to the Products that can be done once, versus multiple times? Question 2

5. Outline • Organizing Requirements • Vision Document • Product Management • Managing Scope

6. Vision Document Purpose • Comprehensive description of the product • Designed for internal use, not for the customer • High level abstraction of the problem and the solution. • Provides “common goals and a common playbook.” • In the picture on Slide 4, of product line development, • This is what “Management” worries about • Like, if we do this project, will that lead to more projects like it in the future?

7. Vision Document Template • Introduction • User Description • Product Overview • Feature Attributes • Product Features • Use Cases • Supplementary Specifications • Documentation Requirements • Glossary A decent example of a vision document is “Vision Doc v3.0.doc”, under Resources on the course web site. Question 3

8. Changing Requirements • How do you handle changing requirements in a vision document? • Delta vision • Includes things that have changed and contextual information • Legacy Systems - There is a catch to doing legacy systems – • When you gather requirements, you don’t want to get a lot of really new ones. • These would require expensive changes to the old product. • So, you also are doing “sales” – trying to talk the new customer into liking your old system! Question 4

9. Outline • Organizing Requirements • Vision Document • Product Management • Managing Scope

10. Rationale • Every project needs an individual champion or a small champion team to advocate for the product. • The product manager drives the whole product solution: the application itself, support, user conveniences, documentation, and the relevant commercial factors. • From Avatar: Jake Sully’s list of qualities, also recommended for software product managers: • Brains • Guts • Charisma • Character

11. Tasks • The Product Manager does high-level tasks – • Listens to all the stakeholders • Negotiates amongst them • Manages and funds project people • Communicates features and releases to the outside world • Advocates the product to everyone • “Owns” the vision statement! “to help software teams build products that customers want to buy”

12. Driving the Product Vision Would actor W C Fields have been a good product manager? Here he is juggling 3 top hats. He supposedly held the record for juggling cigar boxes – 5.

13. Maintaining the Product Road Map

14. Customer drivers VISION Import. Compet. Position Core technology Area 1996 1997 1998 1999 2000 Ease of use Display C CF F 2 line, 12 character 4 line Graphical display - 1/4 VGA User interface Keypad Softkeys Voice recognition Keypad 10-key rubber Single piece None Software Talk time Power management Single chip processor Baseband processing Microcontroller 8523 8524 processor Mixed signal Memory devices Batteries Low cost Radio Antenna Power amp Housing Shielding PWB technology System design Standards Accessories Audio quality Voice recognition Voice coders L M H - 0 + C = Current, F = Future Technology Source: Research Lucent-ME Devel. Supplier For a laugh riot… Check out an old product / technology roadmap

15. Product Plan • Product • Services and support • Commercial terms • Positioning

16. Positioning • Position Statement • Branding • Nice demo of the product

17. Outline • Organizing Requirements • Vision Document • Product Management • Managing Scope

18. The Shape of Project Scope • Achievable scope • Brook’s Law • Adding labor to a late project makes it later • Why? • What happens when the scope is beyond available resources? Questions 4,5,6,7, 8

19. Requirements Baseline • Itemized list of features intended for a given release • Must be acceptable to customer • Must have reasonable probability of success

20. Setting Priorities • Customers should decide priorities. • Why? • If you are developing a new product for lots of customers, this is a little different… • The product manager has to forecast what they will want, and he/she takes more risk!

21. Example Priorities

22. Assessing Effort • Developers should estimate effort • Why?

23. Example Effort

24. Assessing Risk • Implementation of a feature will cause an adverse impact on the schedule and the budget Do on this week’s weekly assessment report 

25. Setting the Baseline • Include all "Critical" items • Add some "Important" items as budget allows • Can you deliver all “Critical” items on time?

26. Example Baseline

27. Suggestions for Dealing with the Client During Development • Communicate • Include customer in decisions about scope reduction • Negotiate changes to requirements • Give yourself some slack • Avoid "feature creep" Question 9