1 Lecture #8 Purpose of SSRD Describe Capability Requirements: system subject matter measured by concrete means Describe Project, Level of Service, and.

1Lecture #8

Purpose of SSRD• Describe Capability Requirements: system subject

matter measured by concrete means

• Describe Project, Level of Service, and Evolutionary (non-functional) Requirements: Behavioral properties of functions (performance, usability, etc.)

• Describe Global Constraints: constraints that apply to the entire system as a whole (including interface, environment and Data reqs)

• Mandates (“must”, “shall”, “will”): how the system must be implemented with respect to general tech.

Copyright 2000 by USC and the Center for Software Engineering, all rights reserved.

2Lecture #8

Requirements in General

• Describe a contract between the developers and the customer– customer: if the developers build these requirements, then I agree

that the system is built

– developer: if I build these requirements, then I have built a satisfactory system for the customer

• this is very misleading and full of strong assumptions!

• Important: all requirements must be implementable and testable

• Gotcha’s: – vague requirements

– volatile requirements

– “hidden” or implied requirements

3Lecture #8

SSRD Completion Criteria (LCO)

• Top-level capabilities, interfaces, quality attribute levels: Growth vectors (evolution reqs), Priorities

• Stakeholders’ Concurrence on Essentials

• Requirements Satisfiable by at least one system/software architecture

4Lecture #8

SSRD Completion Criteria (LCA)

• Elaboration of capabilities, interfaces, quality attributes by

iteration. Resolution of TBDs, Elaboration of evolution

reqs

• Stakeholders’ concurrence on priority concerns

(prioritization)

• Traces SSRD (and indirectly to FRD, LCP)

• Requirements satisfiable by the architecture in the SSAD

5Lecture #8

SSRD Audience and Participants

Audience• Domain Expert and Customer (decision makers)

• Implementers and Architects

Participants• Same stakeholders as WinWin negotiation

6Lecture #8

SSRD High-Level Dependencies (Page 1)

SSRD Depends on WinWin Taxonomy• Outline of SSRD evolves from taxonomy

• No one-size-fits-all taxonomy or requirements description

• Importance of adapting taxonomy to domain

SSRD Depends on OCD for:• Statement of Purpose

• Project Goals

• System Responsibilities• Evolution Requirements (Changes Considered but Not Included)

7Lecture #8

SSRD High-Level Dependencies (Page 2)

SSRD Depends on Prototype for:• User Interface Requirements

Additional documents depend on SSRD:• SSAD to obtain System and Project Requirements

• LCP to relate requirement priorities to system increments or to requirements to be dropped in a design-to-cost/schedule development plan

• FRD to check for satisfaction of: Capability, Interface, Quality, and Evolution Requirements

8Lecture #8

Purpose of SSAD

• Documents the Architectural Analysis and the System Design, “blueprint”

• Serves As A Bridge between Engineering (Inception and Elaboration) and Construction Phase

• The SSAD is refined during the Construction Phase into a Software Detailed Design Specification

• The SSAD should not repeat information from other documents: reference other information. Vital to project integration and cohesion. Conciseness is paramount

9Lecture #8

SSAD Completion Criteria (LCO)

• Top-level definition of at least one feasible architecture: Physical/Logical elements, choices of COTS and

reusable elements, detailed analysis

• Feasibility Criterion: a system built to the architecture would support the operational concept, satisfy the requirements, be faithful to the prototypes, and be buildable within the budgets and schedules in the Life Cycle Plan

• Identify infeasible architecture options

10Lecture #8

SSAD Completion Criteria (LCA)

• Choice of architecture and elaboration by iteration: physical/logical components, COTS, Architectural style, deployment considerations, critical algorithms, analysis issues resolved in design

• Architecture evolution parameters

• Complete design for each component of the system

• Tracing to and from OCD/SSRD

• Assurance of Satisfaction of Feasibility Criterion

11Lecture #8

SSAD Audience and Participants

Audience• Domain Expert for System Analysis

• Implementers for System Design

Participants• System Architect

• Domain Experts (to validate analysis models)

• Implementers (to validate design models)

• Project Managers (to test feasibility)

12Lecture #8

SSAD High-Level Dependencies

SSAD depends on OCD for:• Statement of Purpose

• Project Goals and Constraints

• System Responsibilities

SSAD depends on SSRD for:• System Definition and Requirements

• Level of Service Requirements

• Project Requirements

FRD depends on SSAD to ensure that:• Project, Capability, Interface, and Evolution Requirements are achievable

13Lecture #8

Starting Your Project• Meet with your team

– communication• basic approach• alternatives• fail-safe, “crunch” times, etc.

– designate basic responsibilities• “leads” not “do-all”• be flexible

– risks, constraints, problems– expectations for project

• stick with positive only

14Lecture #8

Starting Your Project• Meet with your TA

– communication• how your TA can help between

– your team and the customer

– your team and the class

– discuss class expectations and possible problems

• scheduling of reviews

• grading concerns

• resource issues

• project concerns

15Lecture #8

Starting Your Project• Meet with your customer

– communication• basic approach• alternatives• fail-safe, “crunch” times, etc.

– Domain interview (see recitation!)• CDL (OCD 4.)• Start building DD (OCD 2.)

– Scope project (simps/comps)• manage expectations

– discuss top risks and their severity

– Discuss next steps• WinWin negotiations

16Lecture #8

Purpose of LCP

• Basis for monitoring and controlling the project’s progress

• Basis for controlling the project's progress in achieving the software product objectives

• Helps make the best use of people and resources throughout the life cycle

• Provides evidence that the developers have thought through the major life cycle issues in advance

• Organized to answer the most common questions about a project or activity: why, what, when, who, where, how, how much, and whereas

• Maintaining the conceptual integrity between the tasks and the things they create/solve is a prime quality criterion.

17Lecture #8

LCP Completion Criteria (LCO)

• ID life-cycle stakeholders: users, customers, developers, maintainers, interfacers, general public, others

• Top-level stages, increments: Top-level WWWWWHH (Why, What, When, Who, Where, How, How Much) by stage

• Major risks Identified

• Achieve deliverables, budgets, and schedules: by at least one system/software architecture

18Lecture #8

LCP Completion Criteria (LCA)

• Elaboration of WWWWWHH for Initial Operational Capability (IOC). Partial elaboration, identification of key TBDs for later increments

• All major risks resolved or covered by risk management plan

• Achieve deliverables, budgets and schedules by the architecture in the SSAD

19Lecture #8

LCP Audience and Participants

Audience• Primarily for the performer teams in each stage

• Important for customers

• Useful for other stakeholders.

Participants• Project Manager: leads the baselining of the plan for that

stage.

• Plans for future stages: done by a designated team member during Engineering Stage.

• Stakeholders should participate: if affected by plan

20Lecture #8

LCP High-Level Dependencies

• Products specified by Requirements and Architecture must be buildable and supportable within the budgets and schedules in the Life Cycle Plan.

• Plans for transition and support must be consistent with the Operational Concept Description.

21Lecture #8

Purpose of FRD• Ensure feasibility and consistency of other package

components (OCD, SSRD, SSAD, LCP, Prototype)• Demonstrate viable business case for the system• Identify shortfalls in ensuring feasibility, consistency, and

business case as project risk items for LCP• Demonstrate that a system built using the specified architecture

(described in the SSAD) and life cycle process (described in the LCP) will fulfill prediction of other docs

• Rationalize life cycle decisions in a way the prime audience (the customer and users) and other stakeholders can understand

• Enable the customers to participate in the decision process

and to express their satisfaction with the product

22Lecture #8

FRD Completion Criteria (LCO)

LCO

• Assurance of consistency among elements above for at least one feasible architecture. Via analysis, measurement,

prototyping, simulation, etc.. • Business case analysis for reqs, feasible architectures

LCA• Assurance of consistency among elements above for the

architecture specified in the SSAD• All major risks resolved or covered by risk management

plan

23Lecture #8

FRD Audience

• The primary audiences are the LCO and LCA Architecture Review Board members– Key system stakeholders

– Experienced peers

– Technical Specialists in critical areas

• The parts dealing with client satisfaction must be understandable by the client representatives on the ARB.

• The technical parts must be sufficiently detailed and well organized to enable the peers and technical experts to efficiently assess the adequacy of the technical rationale.

• Valuable to developers and other stakeholders, provides a rationale for important decisions made by the project.

24Lecture #8

FRD Participants

• Project manager responsible for content

• OCD author should prepare business case

• All stakeholders responsible for consistency and feasibility via Win-Win negotiations

• Agreements can be contingent on demonstration of feasibility

25Lecture #8

FRD High-Level Dependencies

• The thoroughness of the Feasibility Rationale is dependent on the thoroughness of all the other LCO and LCA components.

• Issues incompletely covered in the Feasibility Rationale are sources of risk, whose management should be covered in the Life Cycle Plan’s (LCP) Risk Management and Monitoring Procedures section (LCP 4.1)

26Lecture #8

WinWin User Negotiations

• Teams work with representative users– Art, cinema, engineering, business, etc.– Begin with system responsibilities of top needs

• Use WinWin to balance user needs with customer and developer win conditions (WinWin to be introduced later)

27Lecture #8

Your project will succeed

if and only if

You make winners of all the critical stakeholders

• Usually: Users, customers, developers, maintainers

• Sometimes: Interfacers, testers, reusers, general public

The Fundamental Success Condition

28Lecture #8

Proposed Solution “Winner” Loser

Cheap, Sloppy Product (“Buyer knows best”)

Lots of bells and whistles(“Cost-plus”)

Driving too hard a bargain(“Best and Final offers”)

Developer & Customer

Developer & User

Customer & User

User

Customer

Developer

Win-Lose Evolves into Lose-Lose

29Lecture #8

WinWin Stakeholder Roles• Developer: The Architecture and Prototype team members will represent

developer concerns, such as use of familiar packages, stability of requirements, availability of support tools, and technically challenging approaches.

• Customers: The Rationale team member will represent customer concerns, such as the need to develop an IOC in one semester, limited budgets for support tools, and low-risk technical approaches.

• User: The Operational Concept and Requirements team members will work with their designated user-community representative to represent user concerns, such as particular multimedia access features, fast response time, friendly user interfaces, high reliability, and flexibility of requirements.

30Lecture #8

1. Identify success-critical stakeholders

2. Identify stakeholders’ win conditions

3. Identify win condition conflict issues

4. Negotiate top-level win-win agreements

– Invent options for mutual gain

– Explore option tradeoffs

– Manage expectations

5. Embody win-win agreements into specs and plans

6. Elaborate steps 1-5 until product is fully developed

– Confront, resolve new win-lose, lose-lose risk items

Theory W Management Steps

31Lecture #8

- Win-Win

Developer’sWin Space

- Win-Lose

User’sWin Space

- Win-Lose

- Lose-Lose

Win-Win, Win-Lose, and Lose-Lose Situations

32Lecture #8

Productdevelopercan build

in 12 months

Productuser wants

in 12 months

Getting to Win-Win: COCOMO F-16 Example

33Lecture #8

Productdevelopercan build

in 12 months

Productuser wants

in 12 months

Add Technology, Key People

PrioritizeDevelopmentIncrements

Getting to Win-Win: COCOMO F-16 Example

34Lecture #8

Win Condition

Rationale

Attachments

Agreement

Rationale

Attachments

Option

Rationale

Attachments

Issue

Rationale

Attachments

Involves

Addresses

Adopts

Covers

WinWin Negotiation ModelWinWin Negotiation Model

35Lecture #8

36Lecture #8

37Lecture #8

38Lecture #8