Applied Software Project Management

Applied Software Project Management
Requirements

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

Discussion Summary outline
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

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.

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.

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”

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).

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

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.

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.

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.

MS Technical Education How to write Effective Specs?
Writing Effective Specs

MS Technical Education
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. Notes This course illustrates spec'ing techniques that have proven successful at Microsoft. The functional spec is the "bible" by which products are built and managed. Although there is no one "Microsoft spec template" or even a single approach, accepted practices and shared conventions make specs around the company more similar than different. This course highlights some of these best practices, reviews basic concepts, and explores the bigger-picture reasons for the necessity for specs. As part of Writing Effective Specs, participants are provided with an understanding of the skills and techniques necessary 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 specifications with the right audience in mind. Troubleshoot unmanageable specs. Prepare for an effective spec review. Maintain a spec once the development team has started to code. Writing Effective Specs

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 Writing Effective Specs

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 Writing Effective Specs

What we cover What is an effective spec? Getting started Writing the spec Reviewing and maintaining the spec Writing Effective Specs

Lesson 1: What is an effective spec?
MS Technical Education 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 Writing Effective Specs

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, , or hallway conversation Notes No end in itself, the functional spec is the central element in the software development process until the product itself takes its place. Although the program manager (PM) typically is the formal creator and keeper of the spec, the entire team shares responsibility for its accuracy, thoroughness, and feasibility to create a strong spec as well as a strong product. A spec needs to remain current and serve all its audiences. The content of a detailed architecture spec will be vastly different from the functional spec...and you shouldn't clutter the spec with information that doesn't satisfy your particular purpose or audience. It helps for the team to identify a list of specs and determine what questions and for which audience each spec is designed. It even helps to have a checklist as you write the spec, to ensure that you're covering all aspects of the purpose and all audience needs. – More on this later. Dev owns implementation. PM owns user design. Test owns verification. Specs relate to other specs. Don't duplicate. Provide relationships among different docs. Writing Effective Specs

Benefits of writing specs
MS Technical Education 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 Notes A good spec anchors any feature. Spec bugs are radically less expensive than development bugs. (Doesn't mean they are easier to find). Writing Effective Specs

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." Notes A spec is about benefits to the user. How much do you document implementation? (The difference between a requirements spec, which is owned by PM and an implementation spec, which is owned by dev.) Writing Effective Specs

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? Writing Effective Specs

Lesson 2: Getting started
MS Technical Education 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 Writing Effective Specs

Talk to your customers Gather anything you can. Talk to the customers and all disciplines, including marketing. Listen to yourself also. Notes If project team members cannot immediately identify, in just a few sentences, the key goals and the key customers for the project, the project is in trouble….Without a vision for the project, the team will be unable to make difficult feature or bug tradeoffs, will be frustrated by communication problems in the team, and will inevitably make decisions that are misdirected because they have no foundation. This clear vision must be based on a solid understanding of your product's audience. If the customer is not readily identifiable and is not a key part of the goals and vision for the product, this is another major sign that the product is in trouble. When difficult decisions arise, make sure that a customer advocate is identified in the group, and that he is heard. Quick research checklist: Describe what you're doing "in 3 sentences" (meaning as succinctly as possible) What value the feature will provide to your customers Resources you'll have Technologies you'll invest in Strategic bets Include these sections in your spec right away: Value proposition for the feature. Might best be described in a separate overview document (includes discussion of users, market share, reference to business plan) that you can link to from your functional spec. Why would we invest in this particular user experience? Writing Effective Specs

Define the customer problem
MS Technical Education 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. Writing Effective Specs

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 Notes Research and understand all aspects of the problem. Talk to dev to test assumptions, think about a solution, talk to test to make sure the solution does not present a problem for testing, and do reviews to get everyone on the same page and agreeing with the solution. A PM should understand enough of the technical issues to be able to argue with dev and test. The PM should talk to the dev manager or the developer in charge of that area to resolve issues. If both cannot agree, the PM should reinforce her argument by doing some research to determine how others solved the same or a similar problem. Some PMs keep an "ideas and requirements" scratch document that they use while gathering information. Document your discussions and investigations. To minimize duplication, broadcast what you find. Key takeaways: Know your product Leverage and reuse Peers – Keep in mind we are not typical users. Microsoft also has natural checks and balances. Use each to its strength. Developers are tacticians, testers are doubters, PMs are dreamers. Talk to your leads. Writing Effective Specs

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. Writing Effective Specs

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? Notes It's not uncommon that you are not sure what the best solution is, or even if there is a viable solution. In these cases you prototype one or more possible solutions, learning as you go along; the "spec" tends instead to be documentation on the work you have done. The PM is the first person to develop a solution, and although the first solution is often wrong, it's a great way to start tackling the intricacies of the problem. Once a solution is proposed, people are more than willing to let you know what they think about it. You'll also need to prioritize the solutions according to what features your product must have, should have, and won't have in order to ship, and then continue evaluating them through the life of the project. Draw up a schedule for your spec. When do you need to start and finish? When are "add/cut" meetings? This is where the spec becomes part of the process. Writing Effective Specs

Develop solutions (cont.)
MS Technical Education 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 Writing Effective Specs

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? Writing Effective Specs

Lesson 3: Writing the spec
MS Technical Education 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 Writing Effective Specs

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 Writing Effective Specs

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 Notes Your group doesn't have one? Suggest possibilities. Writing Effective Specs

Develop scenarios Usage scenarios describe product requirements in task-oriented terms—from a user's point 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 Notes Every feature in your spec should be covered in the scenarios (explicit or implicit). If there is a resource constraint or feature creep, the cost of redefining priorities can be quantified as the elimination of a scenario. Writing Effective Specs

Organize your research
MS Technical Education 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 Notes Create an outline before you write lots of detail. Make it collaborative; go through the outline with dev, test, and marketing, and see if it will meet their needs. Your job as PM is to "shine a light into every corner". Exhaust all design possibilities. In the absence of any information, you need to come up with an answer. Writing Effective Specs

Pinpoint the needs of your audience
MS Technical Education Pinpoint the needs of your audience Design Development Executives and higher management Localization Marketing Operations Other PMs Testing UA/UE Usability Notes Development: Can I draft a development design spec from this? Reduce numbers of options Explain special cases Include desired delivery date Include increasing level of detail for successive development estimates Explain areas of consistency Validate that everything is standard, or at least do-able, for the operating system Take a position on open issues Explain which/how features work together Define hardware and software requirements State performance requirements on the minimum platform Identify any ways in which a feature emulates an existing one Consider word length and abbreviations, cultural differences, sorting differences, paper size, BiDi, DBCS Executives: What does this product do and why? What does each feature do and why? Explain rationale Provide scenarios Include visuals Use consistent terms Provide high-level overview of features Indicate feature priority Localization: Has the spec taken into account the key localization issues? Include a product glossary and describe term stability Define the hardware and software requirements Focus on error message clarity Provide implementation details for new features Marketing: Does the product deliver the benefits the user wants? Does the functional spec truly describe the product? Use an activity-based structure Operations: Have you thought through adequate reporting methodologies? Can you audit your data and conclusions? Fast and efficient Monitorable Reliable Stable Available Recoverable Scalable and tunable Accurate and auditable Secure Include sections for monitoring, reporting, uptime expectations Testing: Are all expected behaviors described? (Do I have something to test against?) Is the feature testable? Will it require special testing tools? Estimate the number of disks required State the performance requirements on the minimum platform Take a position on existing issues UA/UE: Can I draft a user ed design spec from this? Writing Effective Specs

Brainstorming Use brainstorming to tap your brain for a rush of ideas (Sounds cool, eh?) Notes To brainstorm: Write your purpose statement at the top of the page. Ask yourself: "What ideas do I need to give my reader in order to accomplish my purpose?" Make a list of those ideas, in whatever order they occur to you. Don't cross anything out. Tip This technique is appropriate for both individuals and teams. Writing Effective Specs

Clustering Clustering is an organizing technique that you can use with brainstorming Notes Clustering your brainstormed information 1. Read over your list, and do any additional brainstorming needed to make it complete. 2. Connect any related ideas with lines to create clusters of information. 3. Brainstorm these clusters as necessary to make them complete. 4. Place a star beside the main idea in each cluster. 5. Number the starred ideas in the order you want to present them. 6. Letter the information supporting each main idea in the order you want to present it. Clustering your mapped information 1. Read over your mapped material. Add any ideas that occur to you. 2. Look over the balloons connected directly to your purpose statement and ask yourself: "What information does my reader need first?" Place a "1" next to that main idea. 3. Look at any balloons connected to "1", and repeat the question. Place an "A" beside this balloon. (Note: you may not have balloons connected directly to balloon "1." If not, simply continue.) 4. Look again at balloon "1" and ask: "What information does my reader need to know next? Place a "B" beside that balloon. 5. Repeat step 4 until all balloons are lettered. 6. Look again at the balloons connecting directly to your purpose statement. Ask yourself: "What information does my reader need to know next?" 7. Repeat Steps 3 to 6 until you have numbered and lettered your whole map. Writing Effective Specs

Writing FOCUS ON AUDIENCE NEEDS  MAP/BRAINSTORM CLUSTER/ORGANIZE/OUTLINE DRAFT EDIT Notes Writing is a key part because the process of writing forces you to think through all of the issues. For UI-intensive features, prototyping forces you through a similar process. The best specs aren't written by locking yourself in your office. The best research is ongoing. Keep as many of the disciplines involved in this process and your progress. Don't "go dark" and pop up with the spec; keep visible progress to help gain buy-in in the end. Have you talked with the right people? Have you done your research? If you've done everything adequately, this "step" should be simple. Writing Effective Specs

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 Notes Your project may require one or more of the following sections: Summary Usually the first section in your spec, it answers the question: "What is this product/feature?" It provides readers with an immediate, solid understanding of the product/feature essentials. Justification Answers the questions: "Why develop this product/feature? And why this way?" It explains the business or technical reasons behind the product/feature. Goals Answers the question: "What are we trying to achieve with this product/feature?" It explains the product aims in terms of market position, strategic position, and/or technical performance. Requirements Answers the question: "What functionality must the product or feature have before it is released?" User scenarios Answers the question: "When would someone use this product/feature?" It may stand alone, be a part of the justification/rationale or part of summary/overview. Details Typically the longest spec section, it answers the question: "What exactly does this product or feature do?" It describes the operation of the product/feature from the user interaction view. Schedule Answers the question: "What are the major milestones and when must they be achieved?" It describes milestones, deliverables, owners, and dates. Dependencies Answers the question: "On what other products/features does this one depend?" It alerts readers about other projects, plans, and schedules that impact the goals and schedule of this one. Open issues Unresolved decisions about the product or feature. Other possible sections Third- party extensibility SDK Data dictionary Tips Make a separate docs to reference user scenarios. Don't invent user scenarios "out of the blue." Writing Effective Specs

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. Writing Effective Specs

Samples: Goals/Justifications
MS Technical Education Samples: Goals/Justifications Good: Needs Improvement There were a bunch of encoding issues that came up during the course of Office We’re fixing the ones that we think affect a substantial number of users. Writing Effective Specs

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 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. . Writing Effective Specs

Spec writing exercise Overview This exercise demonstrates the difficulty in writing a complete, accurate, and unambiguous spec. In this exercise two teams of two each compete, while the remainder of the class observes. Supplies Two place-settings: placemat, butter knife, main course knife, fork, soup spoon, dessert spoon, dinner plate, soup bowl, side plate, wine glass, and water glass. Exercise Team members sit back to back (so that they can’t look at each other), each with a place-setting in front of them. The first person (PM) arranges his place-setting any way he wants (5 minutes). The PM then describes this place-setting to the second person (developer), who tries to duplicate the place-setting as best as possible in 15 minutes. Rules The PM (first person) is not allowed to tell the developer (second person) how to build the place-setting, only what it looks like. (For example, the PM isn’t allowed to say, “Pick up the short knife and put it on top of the small plate.”) The PM can talk, but the developer can not talk. (Except to say ”ok” when finished with a move.) Rewards The team that duplicates the most accurate place-setting within the 15 minutes time limit wins. Follow-up discussion (15 – 20 minutes) Suggested topics: Common jargon used between the two members Assumptions made Complexity of design Complexity of team member’s interpretations Additional exercise (if time allows) This exercise demonstrates the problem of ambiguous “specifications.” Divide the class into 4 – 5 teams and give each team one of two signs (same sign for each team). Explain that the sign is displayed near an elevator. Sign #1 Dogs must be carried Sign #2 Shoes must be worn The teams must: Determine as many possible meanings for the sign as the team can think of. (Examples: Entry to the escalator is forbidden unless you are carrying a dog. All pairs of shoes in your possession must be worn to use the escalator. Entry to the escalator is forbidden if you are carrying new shoes. Old shoes are acceptable.) Agree on a “common sense” meaning for the sign, and construct wording that unambiguously conveys that meaning. Try to express the same meaning as a logical expression using mathematical symbols or terminology. Which description is more compact? Which description would be easier to validate? Time Each team has 20 minutes to complete the exercise. After 20 minutes, each team presents its answers to #2 and #3 above. The team with the most innovative meanings and constructs and most unambiguous common sense interpretations, as determined by the instructor,”wins.” Writing Effective Specs

Lesson 4: Reviewing and maintaining a spec
MS Technical Education 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 Writing Effective Specs

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 Notes Your product team members serve as primary reviewers: dev, test, UA, loc, and marketing; but other teams and executives are also likely to be interested and have valuable input. The only sure way to get review comments is to get reviewers into one room and walk through the spec with them. Some PMs always try to distribute specs and solicit feedback via , but the only way to be sure that people understand what you're trying to do is to walk through the spec, page by page. It can be tedious, but it has saved many, many misunderstandings and problems down the road. Offer food if you can (to encourage attendance) and make sure to deliver the spec at least a week before the meeting. Revise and review a lot. As you move through reviews, you can close parts of the spec to avoid reviewing sections you've already finalized. For additional resources on running an effective review, see: Spec reviews are PM driven. Spec inspections are test driven. Remember—no surprises. Everyone there should be bought into your proposals already. Learn to take criticism. Detailed spec reviews versus overview spec reviews: Different focus. Writing Effective Specs

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 and revision history FrontPage: Update the spec only when you need to communicate changes Word: Homegrown macros make updating easy Notes If your code is being shared cross-group, keep the spec up-to-date. Make sure that each section of your spec is as detailed as possible before coding begins. If there are open issues, make sure that they are clearly highlighted. Include a detailed table of revision history in your spec. Some teams also use revision marks (or strikethroughs) in the spec. Find out what has worked in the past for your team and follow that process. You can add functionality to your spec template that will track change dates and other information automatically. Don't devote your life to keeping your spec updated. It's only a tool to get the product shipped. Once the documentation is written, it often becomes a better representation of the feature functionality. When all the teams agree to it, you can stop updating the spec. Set up aliases for announcing spec changes. Late in the cycle, spec can include v2 vision. Think ahead to the next 3 releases. (Sets expectations, helps in reviews.) Adds and cuts section becomes more important. (Also important to delineate between "must have" and "nice to have.") Writing Effective Specs

When a spec is in trouble
MS Technical Education 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 Notes Recognize when a spec is in trouble, be "ok with that" and fix it. Not enough detail Too much detail Is the spec in numbered volumes? Is updating the spec someone's full-time job? Developers don't want to read through reams of text Solo effort Has the spec been read, really read, by anyone other than the author? Is the spec the review objective for the program manager, as opposed to a good feature in the product? Spending too much time getting it right too early in the process Prototype early and often. Usability test your assumptions By having an apparently bulletproof spec, a team can fail to prepare for the inevitable calamity or change in direction. Spending too much time updating The spec's purpose is to maintain a current, accurate (i.e., constantly changing) benchmark. If you don't keep it accurate, detailed, and dynamic, you won't empower dev and test. But too any updates can be randomizing. For organizational updates to specs (new document created to combine existing info, for instance) let dev/test know ahead of time. Not communicating changes Keep a change log in the spec, so a reader can see the date it was last updated. Using the wrong spec template General feature design issues Did you talk to the developer about this right from the start (maybe even before you wrote anything?) Is the feature really useful? Does the feature make sense in the big scheme of things? Are you reinventing the wheel: Are there similar (idea, actual design) elsewhere/in other products at MS? If it's hard to describe your feature, then rethink the design. New terminology: Means you probably didn't think it out that well. New mode to the product: Probably not well thought out - new modes add lots of complexity Should this new feature really be an extension of an old feature? Is the feature unified with existing features? Are there ways to get the same result already in the product? Can we eliminate the "old " way? Include how the feature would be used (the "vision") List related features you know about (if this changes, look at these other features...) Cross-reference to the activity area vision statement (if appropriate) Is there any usability testing planned? What are the likely candidates? Implications for the instrumented version? What parts are most important to hammer down up front? Anything in the product that contains text: Name of a feature (get marketing input) Menu command name Menu status bar text Text of all alerts Macro names Macro argument names and types Text in dialogs Any parts that "connect" the product with other products Features that could cause development a lot of new work (so schedule accuracy increases) "Management overview" of prioritized list of features: No use spending weeks spec'ing if the features aren't agreed to by everyone, and this section is how most people learn about them. Writing Effective Specs

Accommodating versions
MS Technical Education 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 Notes Reemphasize: PLAN AHEAD. Include next version plans. Explain why the original product or feature is still important, not just why modifications are necessary. Question the current applicability of everything you recycle from the prior product or feature. A goals statement that is three years old may be completely obsolete, given market and platform trends. Do not assume that every reader is familiar with the original product or feature. Explain any modifications of your version that are due to technology changes. Avoid acronyms or abbreviations that might confuse the reader between the original and the new version. Also, consider creating a list of ideas that come up for a future version. You can include requirements that didn't make it from the "might have" to the "must have" category this time around. Your list can go on the last page of your spec. You might call it something like "Beyond XP," or "What's Ahead for TabletPC?" Writing Effective Specs

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 Writing Effective Specs

Extra: Idea-mapping Use idea-mapping to generate ideas and identify their logical relationships Notes To idea-map: Write your purpose statement in a balloon in the center of the page. Ask yourself: "What information do I need to give my reader to accomplish my purpose?" Encapsulate the first idea in a balloon and draw a line from it to the purpose statement. Ask yourself, when the second idea comes: "Which idea does this relate to most directly? My purpose statement or the first idea?" Draw a line that connects this third idea to the one it most directly relates to, and encapsulate the third idea in a balloon. Continue the process until you have run out of ideas Tip Gather ideas from others. Use the interview question technique. Walk into a peer's office and ask a "how would you…" question. Writing Effective Specs

Let’s write some specs Assume yourself is a PM
The rough idea and problem In nowadays, many wife or girl friends read the SMS message on her BF or husband’s phone and then find the secrete behind her BF and husband. Can you design a software product to address the problem?

First step Assume you are a PM
Please write down an one-page long idea document

Applied Software Project Management

Similar presentations

Presentation on theme: "Applied Software Project Management"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Applied Software Project Management

Similar presentations

Presentation on theme: "Applied Software Project Management"— Presentation transcript:

Similar presentations

About project

Feedback