CS351

© 2003 Ray S. Babcock

Requirements

What not How

“The Pizza Experiment”

1994, 350 companies, 8000 software projects.

31% were canceled before they were completedIn large companies, 9% were delivered on time

and cost what they were budgeted.In small companies, 16%

CS351

© 2003 Ray S. Babcock

Causes Of Failed Projects

1. Incomplete requirements (13.1%)2. lack of user involvement (12.4%)3. lack of resources (10.6%)4. unrealistic expectations (9.9%)5. lack of executive support (9.3%)6. changing requirements and

specifications (8.7%)7. lack of planning (8.1%)8. system no longer needed (7.5%)

CS351

© 2003 Ray S. Babcock

Notice

Some part of the requirements elicitation, definition, and management process is involved in almost all of these causes.

1. Requirements that absolutely must be met.

2. Requirements that are highly desirable but not necessary.

3. Requirements that are possible but could be eliminated.

CS351

© 2003 Ray S. Babcock

What Not How

Use CasesHow should the system respond to specific

users with a specific role.

User's manual.

Outputs, Inputs, Process

mock-ups

CS351

© 2003 Ray S. Babcock

Types Of Requirements

Physical EnvironmentInterfacesUsers and Human FactorsFunctionalityDocumentationDataResourcesSecurityQuality Assurance

CS351

© 2003 Ray S. Babcock

Sources For Requirements

Stakholder wants and needsDomain modelsCurrent situation modelReusable RequirementsSuggested Types of RequirementsExisting documentsCurrent organization and systems

CS351

© 2003 Ray S. Babcock

Requirement Steps

Review the current situation.Apprentice with the user to understand

context, problems, and relationships.Interview current and potential users.Make a video to show how the new system

might work.Dig through existing documents.Brainstorm with current and potential

users.Observe structures and patterns.

CS351

© 2003 Ray S. Babcock

Characteristics Of Requirements

CorrectConsistentCompleteRealisticNeededVerifiable (testable)Traceable

CS351

© 2003 Ray S. Babcock

Expressing Requirements

Static Descriptions

Indirect ReferenceRecurrence RelationsAxiomatic DefinitionExpressions as a Language(BNF)Data AbstractionAbstract Data Type (cs210 slides)

CS351

© 2003 Ray S. Babcock

cont.

Dynamic Descriptions

Decision TablesFunctional DescriptionsTransition DiagramsFinite State MachineEvent TablesPetri Nets

CS351

© 2003 Ray S. Babcock

Plain old English

I like just writing careful requirements in English.

Readable by both customers and developers.

Easily stored and edited.

CS351

© 2003 Ray S. Babcock

Object Oriented Specification

What data structures define an entity?

How does an entity's state evolve over time?

What aspects of entities and processes are persistent over time?

Object, method, operation, encapsulation, class hierarchies, multiple inheritance.

CS351

© 2003 Ray S. Babcock

Additional Requirements Notations

Hierarchical Techniques : Warnier diagram

Data Flow Diagrams

Software Requirements Engineering Methodology

Structured Analysis and Design Technique

Formal Languages (Z)

CS351

© 2003 Ray S. Babcock

Prototyping

Throw away prototype.

Evolutionary prototype.

Rapid prototyping.

CS351

© 2003 Ray S. Babcock

First Interface prototype

Enter year: ____________

Enter month: __________

Enter day: ____________

CS351

© 2003 Ray S. Babcock

Second Interface prototype

July 1998

1 2 3 4 5 6 7 8 9 10 11 ... (calendar page)

CS351

© 2003 Ray S. Babcock

Third Interface prototype

1998 ---------------|----------------------- 2025

1------------------------------|--------------31

Jan ------------|---------------------------Dec

[ Tues 16 October 2002]

CS351

© 2003 Ray S. Babcock

Level Of Specification

An Australian study reported the results of a survey or problems with requirements.

uneven level of specification

different writing stylesdifference in experience among analystsdifferent formats and writing stylesmixing requirements with partial solutionsoften over-specified (specific computers)

CS351

© 2003 Ray S. Babcock

cont.

under specified (especially when describing the operating environment, maintenance, simulation for training, administrative computing and fault tolerance.

Recommendations:1. Each clause should contain only one

requirement.2. Avoid having one requirement refer to

another requirement.3. collect like requirements together.

CS351

© 2003 Ray S. Babcock

Specifications Specification

IEEE

Michael will have these available soon.

CS351

© 2003 Ray S. Babcock

The Requirements Document

Many formats, but some common themes.

Each requirement numbered.

Figures numbered and labeled.

New sections start on a new page.

More later......

CS351

© 2003 Ray S. Babcock

How developers see usersUsers don't know what they want.Users can't articulate what they want.Users have too many needs that are politically

motivated.Users want everything right now.Users can't prioritize needs.Users refuse to take responsibility for the

system.Users are unable to provide a usable statement

of needsUsers are not comitted to system development

project. Users are unwilling to compromise.Users can't remain on schedule.

CS351

© 2003 Ray S. Babcock

How Users See Developers

Developers don't understand operational needs.Developers place too much emphasis on

technicalities.Developers try to tell us how to do our job.Developers can't translate clearly stated needs

into a successful system.Developers say no all the time.Developers are always over budget.Developers are always late.Developers ask users for time and effort, even to

the detriment of the user's important primary duties.

CS351

© 2003 Ray S. Babcock

cont.

Developers set unrealistic standards for requirements definition

Developers are unable to respond quickly to legitimately changing needs.

CS351

© 2003 Ray S. Babcock

Requirements Validation

The process of determining that the specification is consistent with the requirements definition; that is, validation makes sure that the requirements will meet the customer's needs.

Requirement Review

CS351

© 2003 Ray S. Babcock

Critera

ApplicabilityImplementabilityTestability/simulationCheckabilityMaintainabilityModularityLevel of Abstraction/expressibilitySoundnessVerifiabilityRun-Time safety

CS351

© 2003 Ray S. Babcock

cont.

Tools maturityLoosenessLearning CurveTechnique MaturityData ModelingDiscipline