Applied Software Project Management 5n3y2q

)))))j)

11))

1))

J))

1111)))))]

11

j)

11

J

J

111111))

Applied Software Project Management

Applied Software Project Management Requirements

http://www.stellman-greene.com

0 REILLY®

o REILLY®

Applied Software Project Management

Software Requirements II 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 s, stakeholders and anyone else whose perspective needs to be taken into during the design, development and testing of the software • Observation of the s at work • Distribution of discussion summaries to the data gathered in interviews

http://www.stellman-greene.com I) J J J J J j J) J J J J

2 J

J

J)

II1I

Andrew Stellman & Jennifer Greene I

II

I

I

1

I

I

I

11

I

I

I

I

I

I

I

I

I

I

I

III

J II

I)

I I 11

I I J

J))

I

1

I

J

J

1)

1 1 J.l

J I I J 1]

J

J

I))

0 REILLY®

Applied Software Project Management

Discussion Summary A requirements analyst can use a discussion summary to summarize information gathered during elicitation an~ validate it through a review. (II Notes gathered during the elicitation should fit into the discussion summary template III The discussion summary outline can serve as a guide for a novice requirements analyst in leading interviews and meetings

Discussion Summary outline

•

http://www.stellman-greene.com

J)]

1.

Project background a) b) c)

2.

Perspectives a) b)

3.

Who will use the system? Who can provide input about the system?

Project Objectives a) b) c) d)

4. 5. 6. 7.

Purpose of project Scope of project Other background information

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

o REILLY®

Applied Software Project Management

Use Cases 11 A use case is a description of a specific interaction that a may have with the system. IJ 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 follows to use the software to do his work. [> All of the ways that the,s interact with the software can be described in this manner.

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

I )

J

J

J

J

I

J

J

j

4 J

J

J

II

I

I

I

I

I

I

I

I

I

I

I

Andrew Stellman & Jennifer Greene I

I

I

I

I

I

I

I

I

I

I

I

I

J ) J J J

j

) ')

J )

j

I ') 1 J J ) J J J J

J I J J J J J ) 1 1 1 J J 1 ') j J J ) J J

Applied Software Project Management

0 REILLY®

Functional Requirements lIJ Functional requirements define the outward behavior required of the software project.

t> The

goal of the requirement is to communicate the needed behavior in as clear and unambiguous a manner as possible.

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

o REILLY®

Applied Software Project Management

Nonfunctional Requirements IJ Nonfunctional requirements define characteristics of the software which do not change its behavior.

r> s 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.

r>

• The nonfunctional requirements are sometimes referred to as "non-behavioral requirements" or "software quality attributes"

http://www.stellman-greene.com

JJJJ

J

J

J

J

J

J

J

J

6 J

J

J

IIIIIII

I

I

III

I

I

Andrew Stellman & Jennifer Greene I

I

I

I

I

I

I

I

I

I

I

I

I

I

1

1JIJ

lJ1llJ1Jl111

)lJJ11JJ1JJIJJJJJJJ

Applied Software Project Management

lJJJ

0 REILLY®

Software Requirements Specification [!J The software requirements specification (SRS) represents a complete description of the behavior of the software to be developed. II The SRS includes: [> A set of use cases that describe all of the interactions that

the s 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

)

·0 REILLY®

Applied Software Project Management

Requirements vs. Design *\1

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 [> Requirement~ 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 J

J)

JJJ

J

J

I

J

I

J

J

8 I)

J

j

j

1III1III1

Andrew Stellman & Jennifer Greene I

I

\

I

)

I

\

I

I

I

I

I

I

I

I

J)

I

j

II)

J J 1 j J J I i j

J

J

J i)

1 iJ)

I

J)))

)

J J J

Applied Software Project Management

I

1 J

0 REILLY®

Change Control III 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

J)

o REILLY®

Applied Software Project Management

Change Control II A change control board (CCB) is made up of the decision-makers, project manager, stakeholder or representatives, and selected team . l> 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. l> Before the project begins, the list of CCB 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.com10 JJJJ

JJJ

J

1

J

J

J

J

J

Andrew Stellman & Jennifer Greene III1

\

11111

ii'

I1I1

I

I

I

I

I

I

I

I

I

I

'"

Applied Software Project Management

o REILLY®

Change Control [II Whenever a change is needed, the CCB

follows the change control process to evaluate the change: l> 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. l> 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. l> The CCB either accepts or rejects the change.

http://www.stellman-greene.com