Applied Software Project Management

1. Applied Software Project Management Requirements http://www.stellman-greene.com

2. Software Requirements • Software requirements are documentation that completely describes the behavior that is required of the software-before the software is designed built and tested. • Requirements analysts (or business analysts) build software requirements specifications through requirements elicitation. • Interviews with the users, stakeholders and anyone else whose perspective needs to be taken into account during the design, development and testing of the software • Observation of the users at work • Distribution of discussion summaries to verify the data gathered in interviews http://www.stellman-greene.com

3. Discussion Summary • A requirements analyst can use a discussion summary to summarize information gathered during elicitation and validate it through a review. • Notes gathered during the elicitation should fit into the discussion summary template • The discussion summary outline can serve as a guide for a novice requirements analyst in leading interviews and meetings Discussion Summary outline • Project background • Purpose of project • Scope of project • Other background information • Perspectives • Who will use the system? • Who can provide input about the system? • Project Objectives • Known business rules • System information and/or diagrams • Assumptions and dependencies • Design and implementation constraints • Risks • Known future enhancements • References • Open, unresolved or TBD issues http://www.stellman-greene.com

4. Use Cases • A use case is a description of a specific interaction that a user may have with the system. • Use cases are deceptively simple tools for describing the functionality of the software. • Use cases do not describe any internal workings of the software, nor do they explain how that software will be implemented. • They simply show how the steps that the user follows to use the software to do his work. • All of the ways that the users interact with the software can be described in this manner. http://www.stellman-greene.com

5. Functional Requirements • Functional requirements define the outward behavior required of the software project. • The goal of the requirement is to communicate the needed behavior in as clear and unambiguous a manner as possible. • The behavior in the requirement can contain lists, bullets, equations, pictures, references to external documents, and any other material that will help the reader understand what needs to be implemented. http://www.stellman-greene.com

6. Nonfunctional Requirements • Nonfunctional requirements define characteristics of the software which do not change its behavior. • Users have implicit expectations about how well the software will work. • These characteristics include how easy the software is to use, how quickly it executes, how reliable it is, and how well it behaves when unexpected conditions arise. • The nonfunctional requirements define these aspects about the system. • The nonfunctional requirements are sometimes referred to as “non-behavioral requirements” or “software quality attributes” http://www.stellman-greene.com

7. Software Requirements Specification • The software requirements specification (SRS) represents a complete description of the behavior of the software to be developed. • The SRS includes: • A set of use cases that describe all of the interactions that the users will have with the software. • All of the functional requirements necessary to define the internal workings of the software: calculations, technical details, data manipulation and processing, and other specific functionality that shows how the use cases are to be satisfied • Nonfunctional requirements, which impose constraints on the design or implementation (such as performance requirements, quality standards or design constraints). http://www.stellman-greene.com

8. Requirements vs. Design • Many people have difficulty understanding the difference between scope, requirements and design. • Scope demonstrates the needs of the organization, and is documented in a vision and scope document • Requirements document the behavior of the software that will satisfy those needs • Design shows how those requirements will be implemented technically http://www.stellman-greene.com

9. Change Control • Change control is a method for implementing only those changes that are worth pursuing, and for preventing unnecessary or overly costly changes from derailing the project. • Change control is an agreement between the project team and the managers that are responsible for decision-making on the project to evaluate the impact of a change before implementing it. • Many changes that initially sound like good ideas will get thrown out once the true cost of the change is known. http://www.stellman-greene.com

10. Change Control • A change control board (CCB) is made up of the decision-makers, project manager, stakeholder or user representatives, and selected team members. • The CCB analyzes the impact of all requested changes to the software and has the authority to approve or deny any change requests once development is underway. • Before the project begins, the list of CCB members should be written down and agreed upon, and each CCB member should understand why the change control process is needed and what their role will be in it. http://www.stellman-greene.com

11. Change Control • Whenever a change is needed, the CCB follows the change control process to evaluate the change: • The potential benefit of the change is written down, and the project manager works with the team to estimate the potential impact that the change will have on the project. • If the benefit of the change is worth the cost, the project manager updates the plan to reflect the new estimates. Otherwise, the change is thrown out and the team continues with the original plan. • The CCB either accepts or rejects the change. http://www.stellman-greene.com

12. How to write Effective Specs?

13. Overview • Effective Specs is a refresher on the framework and fundamentals of spec'ing. Topics covered include the theory and motivation behind writing specs, the components that make up the spec, and the spec reviews that fine-tune the document.

14. Course goals Teach the skills and techniques that you will need to: • Collect relevant information about the context of a feature or set of features • Divide large features into manageable components • Develop user scenarios and prioritize components appropriately • Write specs with the right audience in mind • Troubleshoot unmanageable specs • Prepare for an effective spec review • Maintain a spec once development has started to code

15. Audience • This course is for: • PMs with one year or less of experience • Experienced PMs who want to refresh their spec writing and reviewing skills

16. What we cover • What is an effective spec? • Getting started • Writing the spec • Reviewing and maintaining the spec

17. Lesson 1: What is an effective spec? • After successfully completing this lesson, you will be able to: • Define the term "functional spec" • List the benefits and challenges of writing an effective spec

18. Definitions • A functional spec is : A product team's primary means of communicating the design and functionality requirements of each feature in a product • A functional spec is not : An architecture spec, vision document, one-page summary, e-mail, or hallway conversation

19. Benefits of writing specs • Documents the product design • Provides an overview for executives and other groups • Provides the details that the product team needs • Helps keep functional and external teams in sync during the development cycle

20. Challenges Many challenges faced by PMs in composing an effective spec can be viewed as a lack of: • Understanding of feature purpose • Ability to break down a feature into viable and manageable components • Defining valid user scenarios • Prioritizing functionality Instead of focusing on solving a technical problem, we get caught up in documenting a recipe for "code that must be written."

21. Review • Define the term functional spec. • What is the role of a spec in the development of a product? • What are some of the challenges that you face when trying to write a great spec?

22. Lesson 2: Getting started • After successfully completing this lesson, you will be able to: • Explain how to begin defining the customer problem • Describe how to conduct effective research • Explain the steps involved in coming to a viable solution

23. Talk to your customers Gather anything you can. Talk to the customers and all disciplines, including marketing. Listen to yourself also.

24. Define the customer problem • What are your customer's needs? • Why are you building a product or feature? • How did you determine your justification for building the product/feature? • What problems will you solve with the new feature or product? This needs to be done up front, not as the spec is evolving. If you need additional research or validation as you work through the document, that is OK. Save a place for it and design the research to get the answers that you need.

25. Research • Understand as many of the requirements and constraints as you can before you start; because you can't know them all, modify your spec as you learn new ones • Surf the Web… in a structured fashion • Do site visits… in a structured fashion • Know what research does and DOES NOT help you with

26. Research (cont.) • Ask your relatives (maybe) • Use product planning and usability • Check out competitors • Go to MS Library You need to know, at a feature level, what the industry is offering or wanting.

27. Develop solutions • Know your priorities • Break the problem down • What are the constraints? • What are the factors that need to be considered in the solution? • What goals need to be kept in mind to judge whether the proposed solution is successful?

28. Develop solutions (cont.) • Brainstorm Look for various alternatives and call in folks from various functional groups, as appropriate, to gather data • Identify the viable alternative solutions • Enumerate the pros and cons of each solution • Pick a solution

29. Review • What would you do to define the customer problem? • How would you conduct research to help define the problem and clarify a solution? • What are some of the specific steps involved in developing a solution?

30. Lesson 3: Writing the spec • After successfully completing this lesson, you will be able to: • Write an effective spec • Explain why templates are useful • Create scenarios • Describe techniques such as brainstorming and clustering • List different sections in a spec

31. Tools Decide what tools are most appropriate for the type of message you want to communicate: • Word • FrontPage • Sharepoint • Excel • Project • Visio (flow charts) • Rational • Visual Basic (prototypes) • Paint

32. Spec templates • Include a table of contents • Provide explanatory placeholder text in each section that describes what information you should include • Leverage existing templates • Always start with a template, not an old spec

33. Develop scenarios • Usage scenarios describe product requirements in task-orientedterms—from a user'spoint of view • The purpose of scenarios is three-fold: • Ensure that the new system will meet the user's needs and accomplish all steps necessary to meet the product's purpose • Determine if all the exceptions are properly handled • Help prioritize features

34. Organize your research • Develop summaries and categorize • An outline is one tool that gives you a framework to work with; you will likely alter it as you proceed • It can be as simple as a few headings or be the result of idea-mapping or brainstorming

35. Pinpoint the needs of your audience • Design • Development • Executives and higher management • Localization • Marketing • Operations • Other PMs • Testing • UA/UE • Usability

36. Brainstorming Use brainstorming to tap your brain for a rush of ideas (Sounds cool, eh?)

37. Clustering Clustering is an organizing technique that you can use with brainstorming

38. Writing FOCUS ON AUDIENCE NEEDS  MAP/BRAINSTORM  CLUSTER/ORGANIZE/OUTLINE  DRAFT  EDIT

39. Sections of a spec • Summary: Management • Justification: Management • Goals: Management • Design • Requirements: UA, PM, test • User Scenarios: PM, test • Programmability • Operations/Deployment: PM, test • Schedule: Dev, mrkting, PM, test • Dependencies: PM, dev, test • Open issues • History • Cuts • International • Security

40. Samples: Summaries Good The Office Web Server supports DAV as a native protocol on non-Platinum server platforms.[1] DAV clients implicitly get access to the rich document management services that Office Web Server provides, such as link fixup. DAV clients can also participate in the Office Web Server world by gaining access to the Office Web Server metadata store. Office Web Server benefits because DAV is embraced and extended, and ISPs/Server Admins aren’t faced with a choice about open protocol with less functionality vs. closed protocol with rich fully integrated with office functionality. OWS gets the open standards checkbox. Implementing a DAV stack also begins the process of figuring out how to extend DAV to encompass the richness of the Office Web Server functionality. Needs Improvement We add support for surrogate pairs and the BOM in UTF-8, and for improving load performance on common code pages. We’re also working with IE to have better support for half-width kana in the “Japanese (JIS)” encoding if the user has IE 6 MLANG installed.

41. Samples: Goals/Justifications Good: http://office10/teams/UI/specs/core%20UI/auto%20under%20control%20frameset.htm Needs Improvement There were a bunch of encoding issues that came up during the course of Office 2000. We’re fixing the ones that we think affect a substantial number of users.

42. Samples: Scenarios Good: [Easier and faster faxing] When Cheryl signed up for Office.NET, she noticed that there is a Fax service provided by Office. In the past, each time she needed to send a fax, she printed out her file, brought it to her company fax machine, and stood by the machine to monitor it as it sends her fax. Now with Office.NET, she can do all this from her computer. While logged onto Office.NET, she selects the documents she wants to fax and faxes it with just a few clicks of her mouse. She gets a confirmation in her email inbox a few minutes later, notifying her that the documents were successfully faxed. Needs Improvement Any time you have seen a file dialog in any custom applications. .

43. Spec writing exercise

44. Lesson 4: Reviewing and maintaining a spec • After successfully completing this lesson, you will be able to: • Effectively review a spec • Describe best practices for maintaining a spec • List positive things to do when a spec is in trouble

45. Reviewing a spec • Why get your spec reviewed? • You want the issues worked out to avoid substantial rework and delays later • When do you get your spec reviewed? • How do you get people to review it? • Host a meeting

46. Maintaining a spec • Find out the update policy for your group; if there doesn't appear to be one, find out from your manager what kind of updates are expected from you • Different styles for different teams: • HomeAdvisor: Fewer spec changes for an online product • Encarta: Communicate changes through e-mail and revision history • FrontPage: Update the spec only when you need to communicate changes • Word: Homegrown macros make updating easy

47. When a spec is in trouble • Not enough detail   • Too much detail   • Solo effort • Spending too much time getting it right too early in the process   • Spending too much time updating   • Not communicating changes   • Using the wrong spec template • Dev/Test estimates are wrong

48. Accommodating versions • Articulate exactly what will, and what will not, change in the new version • Provide postmortem information about the previous version in the Justification section of the spec

49. Course summary We covered and practiced spec'ing techniques that have proven successful at Microsoft and we learned that: • The functional spec is the "bible" by which products are built and managed • Using templates and best practice techniques can help you write more effective specs • Understanding the customer problem, and researching and providing viable solutions are essential for producing effective specs • Reviewing and maintaining specs is critical

50. Extra: Idea-mapping Use idea-mapping to generate ideas and identify their logical relationships