applied software project management requirements 1

Applied Software Project Management


Requirements

http://www.stellman-greene.com 1


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• 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

1. Project backgrounda) Purpose of projectb) Scope of projectc) Other background information

2. Perspectivesa) Who will use the system?b) Who can provide input about the

system?3. Project Objectives

a) Known business rulesb) System information and/or diagramsc) Assumptions and dependenciesd) Design and implementation constraints

4. Risks5. Known future enhancements6. References7. 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.



How to write Effective Specs?


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.


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


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


What we cover

• What is an effective spec?• Getting started• Writing the spec• Reviewing and maintaining the spec


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


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


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


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


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?


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


Talk to your customers

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


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.


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


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.


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?


Develop solutions (cont.)

• BrainstormLook for various alternatives and call in folks from

various functional groups, as appropriate, to gather data

• Identify the viable alternative solutions1.Enumerate the pros and cons of each solution2.Pick a solution


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?


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


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


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


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


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


Pinpoint the needs of your audience

• Design• Development• Executives and higher management• Localization• Marketing• Operations• Other PMs• Testing• UA/UE• Usability


Brainstorming

Use brainstorming to tap your brain for a rush of ideas

(Sounds cool, eh?)


Clustering

Clustering is an organizing technique that you can use with brainstorming


WritingFOCUS ON AUDIENCE NEEDS

MAP/BRAINSTORM

CLUSTER/ORGANIZE/OUTLINE

DRAFTEDIT


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


Samples: Summaries

GoodThe 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 ImprovementWe 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.


Samples: Goals/JustificationsGood:http://office10/teams/UI/specs/core%20UI/auto%20under%20control%20frameset.htm

Needs ImprovementThere 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.


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 ImprovementAny time you have seen a file dialog in any custom applications. .


Spec writing exercise

Applied Software Project ManagementLesson 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


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


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


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


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


Course summaryWe 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


Extra: Idea-mapping

Use idea-mapping to generate ideas and identify their logical relationships


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
