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

Outline Organizing Requirements Vision Document Product Management Managing Scope

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

Product Families A series of products with closely related requirements A new way of viewing software products ◦ Investing in infrastructure to build product families Question 2 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?

Outline Organizing Requirements Vision Document Product Management Managing Scope

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?

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

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

Outline Organizing Requirements Vision Document Product Management Managing Scope

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

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”

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.

Maintaining the Product Road Map

For a laugh riot… Check out an old product / technology roadmap

Product Plan Product Services and support Commercial terms Positioning

Positioning Position Statement Branding Nice demo of the product For(target customer) WhoStatement of need The(product name)Is a (product category) ThatStatement of key benefit UnlikeRival product Our productA list of differences

Outline Organizing Requirements Vision Document Product Management Managing Scope

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

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

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!

Example Priorities #FeaturePriority 1External RDB supportCritical 4Portability to a new OSCritical 3Ability to clone new projectImportant 5New project wizardImportant 2Implementation of tool tipsUseful

Assessing Effort Developers should estimate effort ◦ Why?

Example Effort #FeaturePriorityEffort 1External RDB supportCriticalMedium 4Portability to a new OSCriticalHigh 3Ability to clone new projectImportantLow 5New project wizardImportantLow 2Implementation of tool tipsUsefulLow

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 

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

Example Baseline #FeaturePriorityEffort 1External RDB supportCriticalMedium 4Portability to a new OSCriticalHigh 3Ability to clone new projectImportantLow Baseline 5New project wizardImportantLow 2Implementation of tool tipsUsefulLow

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