cs 564 – on requirements lecture 2. cs 564 requirements © 2004 prof. bernstein

CS 564 – On RequirementsLecture 2


QSE Lambda Protocol

• Prospectus

• Measurable Operational Value

• Prototyping or Modeling

• sQFD

• Schedule, Staffing, Quality Estimates

• ICED-T

• Trade-off Analysis


Real-time Requirements

• Computer uses only past and present data

• Data is sampled at a constant rate, the pulse repetition rate (prp) of the radar,

• The caclulations are completed in time to adjust the radar for the next sample

• The equations are stable


One Predictor Model

Predictor:

X#(n+1) = 2 X(n) - X(n-1)

X(n)

X(n-1)X#(n+1)

Where X(n) = X(nT) and T is the radar prp


Equation Analysis

• X#(n+1) = 2 X(n) - X(n-1)

this model does not account for traget dynamics

Error = X#(n+1) – X(n+1)

= 2 X(n) - X(n-1)- X(n+1)

For Error = 0, 2 X(n) - X(n-1)- X(n+1)= 0

solving X(n) = X(0) (1+ k) And if there is a measurement error at T=0 it will grow


Unstable Predictor

• Error evnetualy dominates the prediction

• For n<4 and the error is onoyu in the least dsignificant bit of the eqauiton this simple predictor can be used if the target does not move much between prp. This eliminates false tracks.


Stable Predictor

X# = 5/2 X(n) – 2X(n-1) -1/2 X(n-2),

With X# within preset measurement limits and fast prp compared to target movement

This is based on the simple differential equation

x(t) = x(0) + v t – ½ g t2


Prediction Equations

• Keep targets in track

• Easy to initialize

• Provide data to other functions

• Minimize processor time


Bed and Breakfast

Fakeville Georgia Bed and Breakfast Lodging Fakeville Inn GA.htm


Trustworthy Software is:

• Safe: Does no harm

• Reliable: No crash or hang.

• Secure: No Hacking Possible


QSE Lambda Protocol

• Prospectus

• Measurable Operational Value

• Prototyping or Modeling

• sQFD

• Schedule, Staffing, Quality Estimates

• ICED-T

• Trade-off Analysis


Universal Software Engineering Equation

Reliability (t) = ℮ -k t

when the error rate is constant and where k is a normalizing constant for a software shop and

= Complexity/ effectiveness x staffing


Conditions That Cause Unreliability

• Poor Algorithms• Missing Deadlines• Roundoff Error Build Up• Memory Leaks• Broken Pointers• Register Misuse


QSE Characteristics

• Solving the right problem the right way • Certified against requirements.• Certified against problem• Bounded execution domain


Case Study: SchedulerPro Prospectus

User friendly, efficient interface for students to create and modify class schedules.

Features:• Visual schedule creation and editing• Schedule suggestion• Schedule comparison view• Monitor closed-out sections


SchedulerPro Prototype Screen


SchedulerPro Notification Emails


Measurable Operational Value SchedulerPro MOV

Course scheduling and registration time reduced by an average of 20 minutes per student per semester.


SchedulerPro Functional Goals

Schedule Classes and Personal Time

Searching

Course Placement

Course Detail Viewing

Course Removal

Scheduling Personal Blocks

Notification (optional)

Course Suggestions (optional)


SchedulerPro Functional Requirements

• Search available classes by:Same professorSimilar timeSame or equivalent class but different sections

• Register and track registrations• Color classes and arbitrary time-blocks by

user choice


SchedulerPro Nonfunctional Requirements

• Integrate with “Web for Students’ and existing authentication systems and avoid incompatibilities

• Allow schedules to be saved/accessed from a server or local file

• Provide a scaled time-accurate visual representation of the schedule


More Non-functional requirements

• Make schedules available even if the application is down, provided an internet connection is available

• Perform some functions without a live connection to the ‘Web for Students’ registrar web site

• Make compatible with all popular browsers

• Display section states and print schedules without loss of detail


SchedulerPro sQFD

Features / Functions

Class FiltersAllocate non-

class timeLong term information

availabilityAuthenticate

Makes scheduling classes easier

8 3 6 2

19

Makes scheduling a semester easier

7 9 8 2

26

Find schedules in one place

1 1 5 7 14

Total 16 13 1911 59


SchedulerPro Product Reliability

• Two hours of unavailability allows for daily backups, service, and reboots of the system

• Connections to server are minimized, reducing overall activity on the server


Parnas reliability checklist

Failures in communication, secondary storage, memory, or any hardware that may interrupt a transaction:

• The SQL Server DBMS will not commit incomplete transactions. User will be notified of the error, and will have to redo the transaction.

Operator error:• Important operations are confirmed before they

are completed to avoid large accidental errors.


SchedulerPro Estimate of Reliability

R(t) = 1 - F(t) R(t) = 1 - F(t) F(t) = P(T ≤ t)F(t) = P(T ≤ t)

• During load testing, we discovered the test server can support 1500 user queries a minute.

• P(failures/query) = 55/1500 = 0.036P(failures/query) = 55/1500 = 0.036

• Thus, F(t) = 3.6%, which means the software is 96.4% reliable


SchedulerPro Reliability Estimate

1/ λ = MTTF = εE/kC k = scaling constant = 1

C is complexity = 2.78

E is the development effort = 36.4ε is the expansion factor = 1.5

λ = 0.05

t is the continuous execution time for the software

R(t) = 95.12%


Complexity Chart - Client

• Project Type: online transaction

• Problem Domain: 2

• Architecture Complexity: 3

• Logic Design – Data: 2

• Logic Design – Code: 3• Total Score: 10• Complexity = (10/18) * 5 = 2.78


Complexity Chart - Server

• Project Type: online transaction






Complexity Chart - Overall

• Project Type: client/server






Jan. Function Point Est.

Function Low (L) Average (A) High (H) Total

Outputs 1 3 0 19

Inquiries 8 4 1 49

Inputs 5 7 1 41

Internal Files 3 2 0 24

External Interfaces 2 1 0 10

Total UFP 143

Adjustment Factor 0.99

Total AFP 141


April Function Points Est.Function Low Average High Total

Outputs 1 0 1 9

Inquiries 3 0 0 9

Inputs 2 3 0 18

Internal Files 3 1 0 31

External Interfaces

1 1 0 12

Total UFP 79

AFP 82


History of Function Points

Date AFP Project Length*

Projected Finish*

January 27 141 19.7 staff months

August 2006

February 24 104 14.4 staff months

March 2006

April 17 82 8.5 staff months

May

2006

*Using COCOMO Model


Web Points

Function Total Web

Objects

Outputs 11

Inquiries 9

Inputs 18

Internal Files 31

External Interfaces 12

# Multimedia files 6

# Web building blocks 7

# Scripts 3

# Links 0

Total Web Objects 97

Effort = A * cdi (Size)P1

Because it is a small web project, assume:

A=2.1, B=2.0, P1=1.00, and P2=.5

Language Expansion Factor = 25

From this, we estimate 2.43 KLOC

Effort = A* KLOC = 2.1 * 2.43

= 5.103= 5.103 staff-months staff-months Duration =B * EffortP2 = 2.0 * 5.103.5

= 4.5184.518 calendar months calendar months


ICED-T

Scheduling by:Intuitive Consistent Efficient Durable Thoughtful

Paper 3 2 2 2 3

Excel 3 2 3 3 3

School Scheduler

3 4 4 3 4

SchedulerPro 4 4 5 4 5


ScheulerPro Creeping Features

Are the System Admins important stakeholders?

You bet…


SchedulerPro Installation Plan

Installation

1. Third Party Software Required

Scheduler Pro requires the following products to be already installed on the target machine. Please consult the documentation of each product for installation instructions specific to each.

- Windows 2000, XP, or 2003 Server- Microsoft IIS, version 5.0 or higher- Microsoft .NET, version 1.1- Microsoft SQL Server 2000- Message Queuing Service (Windows component)- ASP.NET State Service


2. Installing the Scheduler Pro applicationTo install Scheduler Pro, please follow these steps:

I. Setting up the web site1. Create a virtual directory for the site in IIS2. Copy the contents of the “site” folder to the directory on your hard drive

represented by the IIS virtual directoryII. Setting up the database

1. Using the SQL Server Enterprise Manager tool, attach the database located under the “sqldb” directory.2. Create a new user account for accessing this database, and give it read/write access for the database.

III. Installing the Suggest, Notified, and Data Loader Windows ServicesOpen the directory titled “services”. Run each of these files: - InstallSuggestService.exe - InstallNotifierService.exe - InstallDataLoaderService.exe

Each installer will properly install the service. The Data Loader installer willalso ask you for the location and name of the course data file it will load.




3. Configuring Your InstallationOpen the directory where you installed the site files (step 2A above). Open the file “web.config”, and find the properties labeled “DBLocation”, “DBUser”, “DBPassword”, and “SecretAuthenticateKey”. These are set to default values that you should modify. Make sure that the location, username, and password match those you set up in SQL Server in step 2B above. Set SecretAuthenticateKey to the random string you are using in your authentication web page.

Technical Information

Scheduler Pro uses HTTP and XMLTHTTP protocols:

- HTTP: As a typical client/server application, an HTTP request is sent to server. Server processes the request and returns HTTP response.- XMLHTTP: client opens XMLHTTP connection to the server. Server executes query on the database and returns needed data.

Refer to Development view and process view from the “4+1” architecture views for further technical details.


People

Software Trustworthiness depends on people:

I propose that customers insist that software products identify a Software Architect and Software Project Manager in their contracts


Software Architect:

• Affirms that the software product solves the customer’s problem

• Affirms that the software product is suitably reliable, easy-to-use, extendible, not harmful and robust. That it is trustworthy.

• Affirms that the requirements are valid.


Software Project Manager:

• Affirms that the software was successfully tested against the requirements.

• Affirms and identifies the good software engineering processes were used in the software development and integration.

• Affirms that the project is within budget, on-time and performs satisfactorily.


Requirements Engineering Process

Requirements ElicitationRequirements Elicitation

Requirements Analysis & Negotiation

Requirements Analysis & Negotiation

Agreed Requirements

Draft Requirements Document

Requirements Document & Validation Report

Informal Statement of Requirements

Decision Point: Accept Document or re-enter spiral

Requirements SpecificationRequirements Specification

Requirements ValidationRequirements Validation

• Process Models• Process Actors and

Stakeholders• Process Support

and Management• Process Quality and

Improvements• Relationship to the

Business Decision


Requirements Engineering Metrics

Requirements Document & Validation Report

Requirements ElicitationRequirements Elicitation

Requirements AnalysisRequirements Analysis

Agreed Requirements

Prospectus

Decision Point: Accept Document or re-enter spiral

Requirements SpecificationRequirements Specification

Requirements ValidationRequirements Validation

Prototype

Simple QFD

Baseline Document


Requirements Process - Context

• Varied Sources• Different Processes• Risk Factors

• Continuity• Strategic• Process & Project

• Varied “Consumers”• Development• Marketing• Training & Documentation• Information Base

RequirementsEngineering

Process

BusinessStrategy

BusinessStrategy

TechnologyStrategy

TechnologyStrategy

Project, Process & DocumentationStandards

Project, Process & DocumentationStandards

OpportunityAnalysis

MarketAnalysis

CustomerRequest

SoftwareDesign

SoftwareDevelopment

SoftwareTesting

Requirements Document

Requirements Document

Marketing,Etc.


Requirements Process

• Elicitation• Request Analysis

• Sourcing & Screening

• Definition• Purposeful• Understand value

• Analysis• Interrelationships• Prioritization• Risk & Cost Assessment

• Specification• Modeling

• Validation• Agreement

• Change Management

RequestAnalysis

RequirementsDefinition

RequirementsAnalysis

RequirementsElicitation

RequirementsSpecification

RequirementsValidation

Req

uirm

ents

Cha

nge

Man

agem

ent


Requirements Elicitation

Requirements Sources• Goals (Value)• Domain Knowledge• System

Stakeholders• Operational

Environment• Organizational

Environment

Elicitation Techniques• Interviews• Scenarios• Prototypes• Facilitated Meetings• Observation


Requirements Request Analysis

Formalizing the Request• Clearly stated• Categorized

• Discretionary/Non-discretionary

• Cost/Benefit

• Business Strategy Alignment, e.g.,• Migration to e-business• Corporate data access

• Technology Strategy Alignment, e.g.,• Commitment to middleware• Data base technology

RequirementsRequest

RequestScreening

BusinessStrategy

BusinessStrategy

TechnologyStrategy

TechnologyStrategy

Alignment Screening

Source: Andriole, Stephen J., Managing System Requirements, Methods,

Tools, and CasesMcGraw-Hill, 1996

Source: Andriole, Stephen J., Managing System Requirements, Methods,

Tools, and CasesMcGraw-Hill, 1996

ImperativeImperative PotentialValue

PotentialValue

DiscardDiscard


Prospectus & Elicitation

• What Information do we need?• Description of the Problem Domain• Scope of Solution• A list of project goals • Any constraints on the behavior or

structure of the solution-system


Interviews

Scenarios

Prototypes

Facilitated Meetings

Observation

Elicitation Techniques


Elicitation Challenges

• Experts don’t know what they know!• Much knowledge is tacit thru extensive use• Difficult to dig it out• Know-how expressed as solutions

• Analysts are domain novices• Tend to simplify • Often miss key functions


Requirements Definition

• Purposeful• Understand

• Users need and value• Problem domain• Business process

– Model– Cost– Benchmarks

• What’s the user payoff

• What is required to achieve the impact?

• Process changes• Automation• Improvement• Re-engineering

• Functional Requirements• From users or user surrogates

• Non-Functional Requirements• Linked to purpose and functional

requirements

UnderstandPurpose

ScreenedRequirements

Request

BuildDomain

Knowledge

BuildDomain

Knowledge

UnderstandProcess Impact

Understand User

Process

Understand User

Process

As isBusiness Process AutomationBusiness Process ImprovementBusiness Process Re-Engineering

ProcessStrategy

DefineFunctional

Requirements

Interviews and observations

Activity-based costingBenchmarking

DefineNon-FunctionalRequirements

Interviews and observationsTraced to Purpose & Functional Requirements

DefinedRequirements

DefinedRequirements


Requirements Analysis

• Requirements Classification• Product/Process• Priority/Risk• Scope/Allocation• Volatility/Stability

• Conceptual Modeling• Understanding &

Communication• Functional Architecture

• Requirements Negotiation• Trade Offs• Consensus with Stakeholder

RequirementsClassification

Constraints

Constraints

ProjectStrategy

ProjectStrategy

RisksRisks

Requirements Packages


RequirementsModeling

RequirementsNegotiation

DefinedRequirements

DefinedRequirements

DomainModels

DomainModels


Example

• Develop Use Cases• Focus on Goals• Identify Actors• Identify Main Tasks

• Use Case Concept• Complete, orthogonal,

externally visible functionality

• Initiated by an actor• Identifiable value to the

actor

OrderingSystem

Customer

<<actor>>AccountSystem

<<actor>>Inventory

Shipping Clerk

ViewStatus

Create & Submit Orders


Software Requirements Specification

• Concept of Operations• System Characteristics• User Operational Needs• Domain Perspective• Constraints• Trade-Off Analysis

• Software Requirements Specification• Basis for Agreement• Reduce Development• Provide Basis for Estimation• Baseline for Validation &

Verification• Basis for Enhancement

Concept of Operations



SoftwareRequirements Specification

Concept ofOperations

Concept ofOperations

DomainModels

DomainModels

SoftwareRequirementsSpecification



Requirements Specification Spec

1. Project Title, Revision Number and Author2. Scope and Purpose of the system3. Measurable Operational Value4. Description5. Feature List including ICED T and Simplified QFD

analysis6. Interfaces7. Constraints8. Change Log and Expected Changes9. Responses to the unexpected10. Measurements11. Glossary12. References


Requirements Validation

• Requirements Reviews• Formal• Customer Representative

• Prototyping• Model Validation

• Scenario Reviews with Customers

• Model Consistency

• Acceptance Tests• Verifiable Requirements

RequirementsReview

RequirementsReview

PrototypePrototype



DomainModels

DomainModels

ScenarioReview

ScenarioReview

SystemDesignSystemDesign

SystemTest

SystemTest

Customer Review

As of 9/9/04


Use Cases Drive Development

Use Cases

Test Case Design

Architecture and Design


Value of Use Cases

Customer Business Model

Operational Use Cases

E/R PairsPerformance

ModelingUI

PrototypeData

Modeling

External StimuliEvent FrequencyScenario FrequencyResource Budgets

API Specs E-R MatrixPhysical Config.OA&M Specs.

UI Specs DataArchitecture

BehaviorModelingArchitecture

DetailedFunctional

Specs


Use Case DocumentationFeature Use Case

The customer can order on the web. UC 1

The customer builds the order by selecting items from the on-line catalog and specifying a quantity.

UC 1

Only customers that have an account can create an order. UC 1

At any time during the process of creating an order, the customer can determine the current price of the order.

UC 1

The customer signifies that the order is complete by submitting the order. When an order is submitted, it is assigned an order number.

UC 1

Customers with the priority privilege may designate an order as priority. UC 1a

The customer can view the status of an order at any time by logging on to web site and requesting status on all open orders.

UC 2

Once an order is submitted, it is checked to see if it is pre-paid or whether the customer has an account in good standing. If these conditions are not met, the order is held until the conditions are met or the order is cancelled.

UC 1

…


Use Case DocumentationUse Case 1 Create Order & Submit

Brief Description A customer wishes to order. Provided that the customer has a non-delinquent account or has pre-paid, the product is removed from inventory and delivered to the customer.

Actors Customer, Inventory, Shipping Clerk, Account System

Trigger Customer visits web site & creates an order.

Preconditions Customer has established and account.

Customer email address is known.

Customers are pre-designated to enter priority orders.

Main flow Customer visits web site, signs on and is validated. Customer selects items from the online catalog and builds an order. Customer is appraised of current cost of order. Customer may denote that the order is a priority Customer submits order when done.

A customer order number is assigned and the customer’s credit and account status are checked. If credit is OK or the account shows pre-payment, then the order is sent to the inventory system. …..

Alternative flows Priority Order

Account is delinquent. Action taken ? Cancelled ?

Changes to or cancellation of the order?

Order cannot be fulfilled ?

Postconditions Order has been created and is either been cancelled or been fulfilled.


Package Diagram

• Groups related use cases

• Forms basis for a functional partitioning from the users point of view.

• Shorthand for tracking within the project

Order Entry

ViewStatus

Create & Submit Orders


Activity Chart

EnterOrder

CheckCredit

[submitted]

[aborted]

[denied]

AllocateInventory

[approved]

PrepareDelivery

ReceivePayment

Create Order& Submit

<<trace>>

Order Entry Finance FinanceShippingInventory

Management


Activity Diagram

OrderAssigned

Assign HeldOrders First

For each order item

Held Orders Done?

AllocateInventory

[not done]

<<trace>>

RequestOpen Items Inventory

Inventory Arrived

For each priority order

Items Available

Items Not Available

For each order item

HoldOrder

UpdateOrder Item

UpdateOrder Item

Post toDelivery

[done]

PriorityOrder?

[no]

New ItemsAssigned?

[no]

For all unfulfilled orders

For all fulfilled orders


Software Business Models

Mass MarketMass Market NicheNicheGeneral

Product CentricProduct Centric CustomCustomSoftware

In-HouseIn-House OutsourceDevelopment

OutsourceDevelopment

Requirements •Functional – Industry

•Configurable

•Functional – Company specific


Software vs. Hardware Income Statement

Hardware Software ConsultingProduct Centric Custom

($M) ($M) ($M)

Revenue $300 $300 $300Costs Cost of Sales $190 $20 $150 Amortization $0 $60 $0 Total Incurred Costs $190 $80 $150

Margin $110 $220 $150% Margin 37% 73% 50%

Expenses Development $10 $100 $50 Marketing/Sales $65 $65 $65 Distribution $10 $0 $0 G & A $5 $5 $5 Total Expenses $90 $170 $120

Other Income $0 $5 $0

Operating Income $20 $50 $30

OROS 7% 17% 10%


Capitalization/Amoritization Intervals

Research & Development Expense

Technical Feasibility

Product Realization Expense

General Availability

Capitalization

Marketing Expense

Amoritization

Asset Balance=0


Income Statement Elements

Line Item Hardware Software Consulting

Revenue Hardware Revenue and Maintenance

Licensing, services and maintenance

Services and Maintenance

Cost of Sales Manufactured and purchased componentsDedicated labor to assemble

Purchased componentsInstallation services

Labor related to deliverables

Amortization Writing off capitalized R&D

Margin Revenue minus Costs Revenue minus Costs Revenue minus Costs

Development Expenses

R&D to develop hardware R&D to develop software R&D to develop practices and non-billable hours

Marketing & Sales Sales and marketing program costs

Sales and marketing program costs

Sales and marketing program costs

Distribution Cost of distribution

G&A Overhead Overhead Overhead

Other Income Co-marketing income

Operating Income Revenue minus Costs minus Expenses

Revenue minus Costs minus Expenses

Revenue minus Costs minus Expenses


Mapping Requirements to a Framework

• ICED T• Intuition• Consistent• Efficient• Durable

• Thoughtful

• UML Framework• Use Cases• Structure • Business Rules

PMO Models

Requirements

ElicitationReports

Use Cases

Use Cases

Static Structure

Static Structure

Activity Model

Activity Model


ICED T Mappings

• Ratings• 1= ‘Worst I have ever seen’• 2 = ‘Worse than Average’• 3 = ‘Average, like most other systems’• 4 = ‘Better than Average’• 5 = ‘Best I have ever seen’


Simplified QFD (scale 0 to 10)

Goals/Features Track Delivery Trucks

.On-line Customer Inquiry

Credit Check

1. Easy to Order

0 9 3

2. 10% Less Inventory

0 0 0

3. 20% Profit Increase

3 9 9

4. Speed Product Introduction

0 9 0

Total 3 27 12


Systems Engineering

Systems Engineering

“An interdisciplinary approach and means to enable the realization of successful systems.”

– INCOSE (The International Council on Systems Engineering)

System:

“A group of interacting, interrelated, or interdependent elements that together form a complex whole.”

– NGE Project (Next Generation Education Project)


A Framework for Systems Analysis

FormulatingThe

Problem

Identifying,Designing,

AndScreening

TheAlternatives

BuildingAnd

Using ModelsFor

PredictingThe

Consequences

ComparingAnd

RankingAlternatives

Initiation

Boundaries & Constraints

Objectives

Values and Criteria

Alternatives

ForecastingFuture

Contexts

Consequences (Impacts)

Communicate Results

Formulation Research Evaluation and Presentation

Source: Miser, Hugh J., Quade Edward S., Handbook of Systems Analysis Overview of Uses, Procedures,

Applications, and PracticesNorth-Holland, 1985

Source: Miser, Hugh J., Quade Edward S., Handbook of Systems Analysis Overview of Uses, Procedures,

Applications, and PracticesNorth-Holland, 1985


Systems Engineer

CustomerNeeds

CustomerNeeds SolutionsSolutions

UnderstandDomain

Knowledge

UnderstandDomain

Knowledge

CommunicateDomain

Knowledge

CommunicateDomain

Knowledge

Customer Domain Development Domain


Some SE Foundation Concepts

• System Architecture Planning and Business Planning are not separate disciplines, but are a part of Systems Engineering

• Good Front End decisions of necessity are not serial, but a cascaded series of iterative decisions, at various levels, that optimize across:

• Customer Driven Requirements• Architecture requirements and needs (Function, Form, Economy and Time)• Business Strategies, sales needs and related considerations

• The difficulty in balancing these factors cannot be over-emphasized • There are many complex, inter-relating issues to solve• Zealots of various kinds can force particular views, losing balance

• In the final analysis, the above is an art, and any and all insights/data, etc. can help (even clairvoyance)


Work Areas for Systems EngineersPrimary work products:

• Gathering of customer needs and technology opportunities• Opportunity analysis, problem definition and objectives selection• Solution synthesis and analysis• System architecture and alternative selection including developing• business cases• Product specification including requirements generation • and documentation• Development planning to select implementation plan• Project feedback assessment and documentation

Interdisciplinary Skills:• People • Business• Financial• Technical

• • •


Concept of Systems Engineering Tiers

• Layers or Tiers• Many Applications

• Business

• Product Definition

• Interrelates the Artifacts

• Related to Craft Skill Model• Apprentice• Novice• Journeyman• Master

Tier 1Tier 1

Tier 2Tier 2

Tier 3Tier 3

Tier 4Tier 4

Context, Concepts, Framework, Architecture

Use Cases, Scenarios

Detailed Requirements

Business Cases, Customer Value Proposition

Skill Level

Master

Novice


Requirements Engineering Success

• Do the Right Thing• Evaluate Opportunities

• Customer Benefits• Business Case• Feasible Project

• Do It the Right Way• Valid Requirements

• Focused on Customer Value• Customer Agreement• Clearly communicated to Development, etc.


Requirements Specification Spec

1. Project Title, Revision Number and Author2. Scope and Purpose of the system3. Measurable Operational Value4. Description5. Feature List including ICED T and Simplified QFD

analysis6. Interfaces7. Constraints8. Change Log and Expected Changes 9. Responses to the unexpected10. Measurements11. Glossary12. References


Required Measurements

• Function Points

• Logical Consistency = %features with average QFD > 7

• Stability = feature changes/month

• ICED T Metrics


Key Question

• What’s the problem?


References

• CS 564 Notes by Rand Edwards• L. Bernstein and F.E. Slojkowski, “An

information system for the coordination of program design,” Proceedings of ACM National Meeting, ACM Publication P-66, 1966, Thompson Book Company, London

• K. Heninger, “Specifying Software Requirements for Complex Systems,” IEEE Transactions on Software Engineering 1980.

• American Cyanamid internal notes

cs 564 – on requirements lecture 2. cs 564 requirements © 2004 prof. bernstein

Documents