software development phases, todayʼs problemlaser.cs.umass.edu/.../phasespart2rqmts-6.pdf ·...

CS 620 Spring 2011 Univ. of Massachusetts Copyright L. Osterweil, all rights reserved

Software Development Phases, their Artifacts, and Processes:

Part 2: The Requirements Phase"

Software Engineering"Computer Science 520/620"

Spring 2011"Prof. Leon Osterweil"


Todayʼs Problem"


Requirements Spec."

Test Plan"

Test Results must "match required behavior"

Design"

Characteristics of"System to be " built must"match required"characteristics"

Hi Level"

Low"level"

Code"

Code must"implement"design"

Hi level design must"show HOW requirements"can be met"

consistent"views"

Test plan"exercises"this code"

How to Build Something Like this"


Using some kind of approach like one of the following"


Process model"

•  Earliest design and test"Fix Code

System Testing

Integration Testing

Code & Unit Test

Detailed Design

Preliminary Design

Feasibility

Specification

Architecture

Requirements

 order -- "what shall we do next?”  transition criteria -- "how long shall we do it?"


1970ʼs"•  Recognition of feedback loops"

– Confined to successive stages"•  “Build it twice”"

– Early prototyping"

System Testing

Integration Testing

Code & Unit Test

Detailed Design

Preliminary Design

Feasibility

Specification

Architecture

Requirements


Reuse Based Development"

Repository

System Testing

Integration Testing

Code & Unit Test

Detailed Design

Preliminary Design

Feasibility

Specification

Architecture

Requirements

New Process

Requires data store semantics


"Throwaway" prototyping"

System Testing

Integration Testing

Code & Unit Test

Detailed Design

Preliminary Design

Feasibility

Specification

Architecture

Requirements

Prototypes

Prototypes

Prototypes

Prototypes

Prototypes

Prototypes

Prototypes

Prototypes

Prototypes


Evolutionary prototyping"

System Testing

Integration Testing

Code & Unit Test

Detailed Design

Preliminary Design

Feasibility

Specification

Architecture

Requirements

System Testing

Integration Testing

Code & Unit Test

Detailed Design

Preliminary Design

Specification

Architecture

System Testing

Integration Testing

Code & Unit Test

Detailed Design

Preliminary Design

Specification

Architecture


The Rational Unified Process"

Architect

Architectural Analysis

Architectural Design

Describe Concurrency

Describe Distribution

Review the Architecture

Database Design

Use-Case Analysis

Subsystem Design

Class Design

Use-Case Design

Review the Design

Designer

Database Designer

Design Reviewer

Architecture Reviewer

New semantics to show roles of agents


develop & verify

Boehm's Spiral Model"

objectives

cost (cumulative)

risk analysis determine, elaborate

plan next phase

proto I

Concepts of

operations LC plan

analysis

proto II

risk

models

design

design V&V

proto III

integration

test plan

risk analysis

models

plan

begin

risk analysis

CW

rqmnts

rqmnts

validation

risk analysis

proto IV

design

unit test

benchmarks

test

code

acceptance


Different Traversals of the Spiral Model to address different risks"

application rqmnts = low risk budget, schedule = high risk

stable appl. rqmts & budget errors = high risk

application rqmnts = high risk budget, schedule = low risk

SW

System Testing

Integration Testing

Code & Unit Test

Detailed Design

Preliminary Design

Feasibility

Requirements Specification

SW Requirements

validation

optimization

Concrete source code

tuning

formal repr.

formal spec

maintenance

req.anal.

Repository

rationale decisions,

SW

SW

SW


To the satisfaction of all of these?"

?

?

? ?

?

?

?

?!

?

?

?

?

?

?

?

?

?!

?!

?!?!?


Our Approach"•  What is the goal/role of each component type?"•  What is the nature of it?"

– Eg. what internal structure does it have?"•  What sorts of stakeholders are interested in it?"•  What sorts of questions do they generally have

about it?"•  What sorts of relations must it participate in?"

– Internal relations"– External relations"

•  What sorts of processes deal with it?"


Requirements Spec."

Test Plan"


Design"


Hi Level"

Low"level"

Code"



consistent"views"



Requirements Spec."

Test Plan"


Design"


Hi Level"

Low"level"

Code"



consistent"views"


This is the anchor"


Some Papers in Requirements Engineering"

•  D. Harel. Statecharts: A Visual Formalism for Complex Systems. Science of Computer Programming. 8 (1987)."

•  B. Nuseibeh and S. Easterbrook. Requirements Engineering: A Roadmap. Proceedings of 22nd International Conference on Software Engineering (ICSE 2000) June 2000. Limerick, Ireland. ACM Press"

•  B. Nuseibeh, J. Kramer, and A. Finkelstein. A Framework for Expressing the Relationships Between Multiple Views in Requirements Specification. IEEE Transactions on Software Engineering, 20 10 (1994). "

•  C. L. Heitmeyer. Software Cost Reduction. Encyclopedia of Software Engineering. J.J. Marciniak, editor. ISBN: 0-471-02895-9. January 2002."

•  A. van Lamsweerde. Requirements Engineering in the Year 00: A Research Perspective. Proceedings of 22nd International Conference on Software Engineering (ICSE 2000) June 2000. Limerick, Ireland. ACM Press"

•  A. van Lamsweerde. Goal-Oriented Requirements Engineering: A Guided Tour. 5th IEEE International Symposium on Requirements Engineering. Toronto, Canada, August 2001. "


Requirements: Goals and Purposes"

•  Clarify needs before plunging into design"– Customer “knows” what is wanted "– But usually doesn't know how to say it "– Weak sense of what can be achieved"

•  Clarify acceptance criteria"– How to know it really delivers what was wanted"

•  Serve as guide to developers, testers, customers, maintainers"– “Baselining” requirements"

Why “do requirements”?"


Requirements Spec."

Test Plan"


Design"



Requirements Spec." Design"

Functional" Safety"

Performance"Robustness"

Accuracy"

Modules"

Components"

Design Decisions"

Components"

Constraints"


Requirements Spec." Design"

Characteristics of system to be " built must"match required"characteristics"

Functional" Safety"

Performance"Robustness"

Accuracy"

Modules"

Components"

Design Decisions"

Components"

Constraints"


Requirements"

Functional" Safety"

Performance"

Robustness"

Accuracy"

Testplan"Inputs"

Outputs"Timing"

Setup"

Knockdown"


Requirements"

Functional" Safety"

Performance"

Robustness"

Accuracy"

Testplan"

Outputs"Timing"

Setup"

Knockdown"

Timing limit"must meet"performance"requirement"

Inputs"

Test input/output"behavior must"match functional"requirements"


Requirements Specification Driven By Stakeholders and their Questions"•  Customers"

– What must it do?"•  Developers (eg. designers)"

– What do I have to get it to do?"•  Testers"

– What is it supposed to be doing?"– How would I know it if I saw it?"

•  Users"– What is it supposed to do?"

•  Regulators"– Is enough being required?"

•  Others???"


Requirements Specification Parts"

•  Introduction/Background"•  Functional"•  Environmental"•  Performance"•  Accuracy"•  Robustness"•  Security"•  Safety"

Help stakeholders organize their thoughts about needs"by decomposing requirements specification into categories"needs and desires."

"Some examples: "


Background/Introduction"

Purpose: Give background/context out of which the "problem arises, and directions in which it is likely to go"

Should contain glossary, references"

Should give intuition about problem, domain, existing" solutions, components"

Probably best written mostly in natural language"

Example: UMass has 20,000 students, slow growth "" " "next few years"

Semester system" Existing system that works, but is not great" Define: FTE, fulltime load, etc."


Functional"Purpose: Indicate the functional transformations that" the system will have to compute"

Likely to be large and complex, therefore aids to easier"and clearer comprehension are needed (eg. hierarchy)"

Important to state WHAT the functions are and not HOW!they are to be computed"

Promising formalisms: dataflow diagrams, FSMʼs"

Usually the chief focus of a requirements specification," and of requirements formalisms--but non-functional " requirements are often at least as important"


Environmental"

Purpose: Indicate the environment in which the software" will have to operate"

• On which hardware and software will the software run?"• With which other applications will it have to interface?"• What will be the nature of the user community it will" have to support?"• With what other manual and automated systems will" it have to interface correctly? "

Example: System is to be interactive" Most users to be students" Must run using cellphones, PDAs" Must print reports on existing forms" Must interface successfully with existing" student and administrative databases"


Performance"Purpose: Specify how much computer and human" resource can be allocated to support the" execution of the software"

How much computer memory can the software use?"

How fast must response time be?" --average case" --worst case"

How long will users wait for batch runs to terminate?"

Example: 2 second response time" overnight printing of all reports" 1 Gbytes of memory available" 500 GBytes of disk available"


Accuracy"Purpose: Specify how much tolerance (if any)" is acceptable in the results"

Most important in numerical computations, but..."

Often where "optimality" is defined" eg: what is a "good" game of chess?"

Example: Reject scheduling constraints that cause" more than 10% of all student requests to" be denied "


Robustness"Purpose: Specify what sorts of abuse the software will" have to resist, and how it will respond"

What kinds of "illegal" inputs might be expected, and what" should be done about them?"

Must the system fail safe, fail soft? When?"

What abnormal environmental conditions might be " expected?"

Example: System must never corrupt any database" --even after a crash" System must deny illegal requests politely" System must not crash due to " --lack of storage" --user overload"


Security"Purpose: Specify which users can do which things, " and when"

Usually there are classes of users--what are they?"

How to distinguish among the users?"

Matrix (?) to specify what accesses and permissions ""different classes and users will have?"

Example: Students cannot:" --change course assignments" --cancel courses" --access data on others" Faculty cannot:" --cancel courses" --change course assignments" Faculty can: access any student data" Administrators can: .... do pretty much anything..."


Safety"

Purpose: Specify what hazards must be avoided"

Specify what the software must NEVER be allowed to do"

Has some elements of an inverse or negated set of" requirements"

Example: System must never corrupt student information" database, or faculty personnel database"


Not All Go Into All Requirements Specs."• Some of these may be omitted; some "

" " "emphasized/deemphasized"

• Other sorts of requirements may be added/substituted" eg: reliability, flexibility, portability....... "

• Requirements specification provides information needed" to satisfy needs of all stakeholders"

• Different stakeholder mixes determine choices of what goes" into the requirements spec."

" SOME EXAMPLES OF THESE UNDERLYING NEEDS:"

• Communication" • Testability" • Precision" • Clarity" • Completeness" • Changeability"


Requirement Specification Challenges"•  Is it Complete? (to the extent required)"

– Ultimately impossible to be sure about this"•  Is it Consistent? (no internal contradictions)"

– Many possible interpretations of this"•  Is it unambiguous ? (possible multiple interpretations)"•  Is it sufficently precise? "

– It is possible to be too precise too"•  Is it Feasible?"

– If it asks the impossible it would be good to know it "•  Is it Even? (consistent levels of detail)"•  Is it Understandable? (what does that mean?)"

– by all stakeholder groups!"•  Is there an implementation bias?"•  Is there a good basis for proceeding to design?"


A Requirement SpecificationIs Never Perfect in All (Any?) Aspects"

• Imperfections are often understandable, tolerable, ""unavoidable "

• Look at real underlying stakeholder needs for the ""requirements specification (communication, clarity, "precision, modifiability....??)"

• Plan requirements content, structure, relations to meet "these needs"

• Requirements specification medium is crucial in helping "assure needs are met"

• Select requirements specification medium to address ""needs"


Requirements Specification Formalisms and Processes"

•  Support addressing these challenges"•  Different formalisms emphasize facilities for

supporting the answering of different types of questions"

•  Different processes provide to different degrees of assurance and thoroughness"


Requirement Processes"•  Elicitation"

– How to ascertain requirements"– Interviewing, classifying, organizing"– Emphasis on perspectives/viewpoints"

•  Review"– How to determine consistency, completeness, etc."– Emphasis on analysis"– Need for semantic basis and inference reasoning"

•  Revision/improvement/enhancement"– How to add, delete, modify"– Rereview: how to determine consistency of

modified requirement specification"


Being Precise aboutRequirements Processes"

•  Helps developers understand"– Other stakeholders too"

•  Basis for automated support"•  Being precise about processes is closely tied to

being precise about artifacts"


Requirements

Develop Rqmt Element

Declare and Define Rqmt

Define Rqmt Element Declare Rqmt Element

Develop Rqmt Element

~ Rqmt OK

X

Inter-requirement Consistency Check

+

Rqmt OK

= ="Example RequirementSpecificationProcess"


Define Rqmt Element

=

Define Functional

Define Timing

Define Accuracy

Define Robustness

Define Input/Output

Definition of Define Rqmt Element"


Define Rqmt Element

=

Define Functional Define Input/Output

Better Definition of Define Rqmt Element"

……"

Fcn OK"

~Fcn OK"

~I/O OK"


Make Functional

X"

✓"

I/O OK"

Make Input/Output ✓"


Define Rqmt Element

=



……"

Fcn OK"

~Fcn OK"

~I/O OK"


Make Functional

X"

✓"

I/OOK"


How to do this???"


Define Rqmt Element

=



……"

Fcn OK"

~Fcn OK"

~I/O OK"


Make Functional

X"

✓"

I/OOK"


How to do this???"Helps if it is defined"as a DFG"


Many Details Left OutMany Other Alternatives"

•  When to check what"•  How to do the checks"•  How to respond"

– And when"•  Etc."•  Being more specific about process entails being

more specific about artifacts/products"

Focus on artifact specification approaches and issues"


Evaluation of Requirements Specification Media"

Representative Evaluation ""Criteria:"

• UNAMBIGUOUSNESS"

• CLARITY"

• COMPLETENESS"

• VERIFIABILITY"

• CONSISTENCY"

• MODIFIABILITY"

• LIFECYCLE UTILITY "



Example Specification Media:"

• NATURAL LANGUAGE"

• STRUCTURED NATURAL ""LANGUAGE"

• DIAGRAMS/CHARTS""DFDʼs, FSAʼs, Petri Nets"

• FORMAL APPROACHES"

• COMBINATIONS OF THE""ABOVE"



• CLARITY"

• COMPLETENESS"

• VERIFIABILITY"

• CONSISTENCY"

• MODIFIABILITY"

• LIFECYCLE UTILITY "CS 620 Spring 2011 Univ. of Massachusetts Copyright L. Osterweil, all rights reserved


Example Specification Media:"

• NATURAL LANGUAGE"

• STRUCTURED NATURAL ""LANGUAGE"

• DIAGRAMS/CHARTS""DFDʼs, FSAʼs, Petri Nets"

• FORMAL APPROACHES"

• COMBINATIONS OF THE""ABOVE"



• CLARITY"

• COMPLETENESS"

• VERIFIABILITY"

• CONSISTENCY"

• MODIFIABILITY"

• LIFECYCLE UTILITY "

How Do They Match Up with "

Each other?"


Natural Language Prose Requirements Specification"

• Write requirements in "plain English""• Build upon universal base of understanding of natural "

"language"• Possible to augment with defined terms"• Use of punctuation for clarification"• Text and word processing systems help automate/ "

"maintain/alter"Examples:"

All input data sets will be terminated with an end of file record" System will respond to service requests within 2 seconds" System will have a friendly user interface" System will never go into an infinite loop"

Problem: How to reason about a natural language reqts. spec?""How to determine: completeness, unambiguity, etc.?"


Disciplined Use of Natural Language"

• Natural response to problems of:" --imprecision" --ambiguity" --consistency (especially when due to size)"

• Familiar approaches:" --Restricted use of defined terms" --Introduction of structuring (paragraph numbering, "

"outline form, templates, etc.)"

• Other, earlier examples of disciplined use of natural ""language:"

--Legal documents" --Recipes"


Data Base Approaches"

•  Requirement items stored as database entries"•  Queries to retrieve information"•  Database tools to check for consistency"


PSL (Relational Database Organization)"DESCRIPTION: " this process performs those actions needed to interpret" time cards to produce a pay statement for each hourly employee.;"KEYWORDS: independent;"ATTRIBUTES ARE:" complexity-level high;"GENERATES: pay-statement, error-listing;"RECEIVES: time-card;"SUBPARTS ARE: hourly-paycheck-validation, hourly-emp-update," h-report-entry-generates, hourly-paycheck-production;"PART OF: payroll-processing;"DERIVES: pay-statement;"USING: time-card, hourly-employee-record;"DERIVES: hourly-employee-report;"USING: time-card, hourly-employee-record;"DERIVES: error-listing;"USING: time-card, hourly-employee-record;"PROCEDURE: <<not usually included in a requirements spec.>>"HAPPENS: number-of-payments TIMES-PER pay-period;"TRIGGERED BY: hourly-emp-processing-event;"TERMINATION-CAUSES: new-employee-processing-event;"SECURITY IS: company-only;"


Examples:"•  Use of structure and reserve words

User interaction functions;Timing: All functions must execute in < 2 seconds Subfunctions:

"Query"Browse "Enter

•  Disciplined use of naming

"….input_value: pay_rate

"pay_rate: input_to ….."


Hierarchical Decomposition Organization"• Requirements Specification as hypertext"

• Structure (DAG) of Requirements Elements" • Child element represents part-of relation"

• Requirement Element is a record"

• Requirement Element fields carry information as:"• Instances of preset types"• Instances related to others by relations" -- express consistency rules" -- define consistency determination" -- define inconsistency remediation"• Relations among" -- Requirement elements" -- Requirement elements and parts of other artifacts" (e.g., testplan elements, other rqts. representations)"


Functional Decomposition Rqts. DAG"name description

date functionality

author robustness

safety security

performance

name description

date functionality

author robustness

safety security

performance

name description

date functionality

author robustness

safety security

performance

name description

date functionality

author robustness

safety security

performance

name description

date functionality

author robustness

safety security

performance

name description

date functionality

author robustness

safety security

performance


Requirement Element:An Example Structure"

NAME"

DATE"

PARENTS"

CHILDREN"

ACCURACY"

TIMING"

FUNCTIONALITY"

ROBUSTNESS"

LOCAL"DATA"


Example: Using this to specify requirements for a Multifunction Watch"

•  Watch functions include"– Telling time"– Alarms"– Telephone directory"– Appointment book"– Memo pad"

•  With various additional constraints"– Speed"– Accuracy"– Robustness"– Etc."


Partial Formalization of FunctionalDecomposition Requirement

Specification "

A Requirements Specification, R, is a set ""R={r | r is a requirement element}"

r, a requirement element, is a tuple,""r = (children(r), parent(r), timing(r),"" "functionality(r), robustness(r),"" "inputs(r), outputs(r) )"

ETC.


Time and Alarm"Function" Datebook"

Functions"

Smart Watch"

Phone Directory"Functions"

Clock" Calendar"

Intermediate Function Decompositions"

Pictorially"


NAME"

DATE"

PARENTS"

CHILDREN"

ACCURACY"

TIMING"

FUNCTION DEFINITION"

ROBUSTNESS"

LOCAL"DATA"

INPUTS" OUTPUTS"

Physiology of a Requirement Element"


Using this for Hierarchy Specification"

children(r) = {s ε R | s is a subfunction of r}"

"Question: What do we mean by “subfunction”?"" "--Is included textually within"" "--Requires in order to execute properly"" " "(ie. is a module that is used)"" "-- ??

parent(r) = The s ε R such that r ε children(s)"

ancestors(r) = the transitive closure of r under the"" " "parent relation"" = r U parent(r) U parent(parent(r)) U …. "


Timing Requirement Specification"timing(r) is a Boolean function"

Intuition: To help clarify, define timing(r) to be""the function passr(testresult), which maps""the set of results of executing testcases for r""onto the Boolean values {True, False}"

"Thus, passr is a function that defines what""it means for a testresult to “pass” (ie. to""satisfy a timing constraint)"

Examples: timing(datebook) ≡""passdatebook(testresult)≡ testresult < 0.1 seconds""passdatebook(testresult)≡ testresult <"" " " "0.1 + size(datebook_cont)/1000"

Note obvious proximity to testing concerns " ""


Functionality Specification"functionality(r) ≡ n, a node in a graph, G"

Intuition: The functionality being specified here is""being specified with the help of a graph, whose""semantics provide rigor to the definition of the""function being required."

"The semantics of the graph will turn out to be""vitally important in supporting reasoning about""the requirements specification and its consistency""with design specifications."


Using a DFD"functionality(r) ≡ n, a node in the DFD, D = (N, E)"

Intuition: The functionality being specified here is""being specified with the help of a DFD."


func." 1"

func. 2" print"f.2.in" out 1"

input 2"

arg 1"

arg 2" f.3.in" func" 3" print"

alt."alt."out"

Input 1"

hierarchy"

functionality"


Input/Output Specification"inputs(r) = { i | i is an object needed for the execution"

" " "of the function denoted by n, the "" " "DFD node used to define the "" " "functionality of r }"

outputs(r) = { o | o is an object created by the execution"" " "of the function denoted by n, the"" " "DFD node used to define the"" " "functionality of r }"


func." 1"

func. 2" print"f.2.in" out 1"

input 2"

arg 1"

arg 2" f.3.in" func" 3" print"

alt."alt."out"

Input 1"

inputs inputs outputs outputs


An FSM can help too"

•  Use FSM to define how a (set of) function(s) must be related to others."

•  Create an “Accessed By” field?"•  Value is a pointer into FSM that describes the

workings of the system"


Each node (state) pointed to by the appropriate field in the appropriate

node of the requirements definition"

Time display mode

Datebook"mode"

Phone book"mode"

Alarm display"mode"

press button A

press button A

press button A

press button A


Children of these nodes point to these “substates”"

Time display mode

Datebook"mode"

Phone book"mode"

Alarm display"mode"

press button A

press button A

press button A

press button A

Time set mode

press button B

press button B

Datebook set mode

press button B press

button B

Datebook query mode

press button C

press button C

press button B

Phone book set mode

press button B

Phone book query mode

press button C

press button B

press button B

press button C

Alarm set mode

press button B

press button B


Multirepresentation Systems"•  Have seen that different representations are of different

uses"•  One diagram may be useful in different ways to

different stakeholders"•  But most stakeholders require a variety of diagrams"•  Several different diagrams can be expected to be

needed to satisfy the different stakeholders"•  Problems with different views/diagrams"

– Are they all representing the same software product?"

– How to assure that they are all consistent with each other?"

– If the product changes, then ALL views must change correspondingly"


STATEMATE supports Requirements Specification"

• Key feature is maintenance of consistency among views" --Done by projecting views of abstract model" --Change abstract model through changes to views"

• Use of Hierarchical Decomposition for understandability"

• Different diagrammatic views" --Statecharts (Enhanced FSMs)" --Enhanced Data Flow Diagrams"

• Statecharts, FSMs both support specification of different "requirements types simultaneously""--Functional""--Robustness""--Safety "


Statechart"

Initialize do: Initialize course object

do: Assign professor to course

Open

entry: Register a student

Closed do: Report course is full

Canceled do: Send cancellation notices

addStudent/ numStudents = 0

cancelCourse

RegistrationComplete do: Generate class roster

cancelCourse [ numStudents = 10 ]

cancelCourse

registration closed[ numStudents > = 3 ]

registration closed[ numStudents < 3 ]

Unassigned

addStudent


Statechart with Nested States"superstate

substate Initialize Register

Open entry: Register a student

Unassigned do: Assign professor to course

Open

Closed Canceled

RegistrationComplete do: Generate class roster

Add student / numStudents = 0

[ numStudents = 10 ]

cancelCourse

registration closed[ numStudents > = 3 ]

registration closed[ numStudents < 3 ]

addStudent

do: Report course is closed


Robustness Specification"

robustness(r) ≡ a first order logic implication""Ar => Br such that whenever an execution""of the functionality defined by r “satisfies” the""predicate Ar, then it necessarily also “satisfies” ""the predicate Br."

Example: "Ar: The clock stops ticking"" "Br: The datebook keeps working"


Security Specification"

•  Who is allowed to use this function?"•  Under what circumstances?"•  With what restrictions?"•  Etc."


NAME"

DATE"

PARENTS"

CHILDREN"

ACCURACY"

TIMING"

FUNCTION DEFINITION"

ROBUSTNESS"

Parents of Children" ="Children of Parents"

Speed of"Children" >"Speed of"Parents"

Functionality related to testcase" inputs/outputs"

Robustness Spec."Incorporated into"System Test Plan"

Some Possible Relations Involving Such Nodes

same function"as one in a DFD"

LOCAL"DATA"

Data object"also used in a"DFD"


Define Rqmt Element

=


This Diagram Suggested When to Check"

……"

Fcn OK"

~Fcn OK"

~I/O OK"


Make Functional

X"

✓"

I/O OK"



Examples of what to check and how"

Internal Consistency:"∀ r ε R, s ε children(r) ⇒ parent(s) = r"

∀ r ε R, ∀ testresult, passr(testresult) = True"" " ⇒ passs (testresult) = True"" " " ∀ s ε descendant(r)"

Interartifact Consistency:"

∀ r ε R, i ε inputs(r) ⇒ i is an input to the node"" " " "n in the DFD that defines the "" " " "functionality of r"


Examples of what to check and how"

Internal Consistency:"∀ r ε R, s ε children(r) ⇒ parent(s) = r"

∀ r ε R, ∀ testresult, passr(testresult) = True"" " ⇒ passs (testresult) = True"" " " ∀ s ε descendant(r)"

Interartifact Consistency:"

∀ r ε R, i ε inputs(r) ⇒ i is an input to the node"" " " "n in the DFD that defines the "" " " "functionality of r"

Examples of some checks performed after some steps" in some requirements processes"


Define Rqmt Element

=


Part of this feature of Process Definition"

……"

Fcn OK"

~Fcn OK"

~I/O OK"


Make Functional

X"

✓"

I/O OK"


How to do this"when using a"DFG to define"functional rqts."


Checking Timing Requirements Against Design (a look ahead)"

Showing consistency between a timing requirement, and"timing characteristics of a design specification:"

Suppose design is specified by a flowgraph; flowgraph is"defined by means of the Immfol relation. Use Immfol to"derive the Fol relation."

Suppose each flowgraph node is annotated with a timing"specification. Suppose requirements node is defined by "one or more flowgraph nodes."

Trace flowgraph paths to compute timing of function, and"compare to requirement node timing spec."


Checking Timing Requirements"

yes no

no

yes

yes

no

no yes

0.1"

5.1"0.6"

0.3"

0.8"

testresult<7.5"


Other Requirements Structures"•  Functional decomposition often works well as the

structure of a requirements specification"– Key feature: “all” requirements are clustered by

function"•  Other decompositions are sometimes better"•  Goal decomposition is increasingly interesting"•  vanLamsweerdeʼs KAOS system"

– Goals decomposed into subgoals"– Special attention to robustness with scoped

exception specification"– A. vanLamsweerde and E. Letier, “Handling

Obstacles in Goal-Oriented Requirements Engineering”, IEEE Trans. on Software Engineering v.26, #10 (2000)."


Security Decomposition"

•  Focus on who can do what"•  Hard to infer that from the functional decomposition"•  Makes most sense when security is the key focus of

the system"•  May make it harder to infer other things"

– Presumably they are less important"


(Recall) Typical Stakeholders and their Needs"

•  Customer: needs to"– communicate what the system must be like"– have a basis for determining if it works right"

•  Developer: needs to"– understand what the system must be like"– what the design must implement"

•  Tester: needs to "– know how to evaluate the final system"

•  User: needs to "– see that real underlying needs are going to be met"


Evaluate These RequirementSpecification Approach Against

Requirements Problems"

•  Incompleteness"•  Inconsistency"•  Ambiguity"•  Infeasibility"•  Unevenness"•  There are others…."


Requirements Incompleteness"•  EXAMPLES: Missing requirements, missing details"•  CAUSES"

– Customer may be unavailable, inaccessible, a group"– Customer asks for too little"

» doesn't understand computer's capabilities"» doesn't understand interfaces to larger system"

– Customer doesnʼt think of everything!» desired function not mentioned"» special case forgotten"

– The world changes, new things are required"•  REMEDIAL APPROACHES"

– Cross checking requirements with each other"– Facilitated by building in relations and redundancy"


Requirements Inconsistency"•  Many types of inconsistency: inconsistent wrt what?"

– Timing: function/subfunction mismatch"– Functionality: subfunctions donʼt “flow right”"– Robustness: no specification of error recovery"

•  CAUSES"– Customer may be a group that disagrees"– Different people may negotiate different parts"– Early identification of inconsistency can be a big

benefit"•  REMEDIAL APPROACHES"

– “Cross-checking” related requirements elementsʼ"» What to check against what? How? For what?"


Requirements Ambiguity"

•  More than one possible set of inferences"•  CAUSES"

– Customer may be a group where noone sees the whole picture--at least at first"

– Difficult to spot ambiguity in large, complex applications"– So many parts, related to each other in so many ways"

•  REMEDIAL APPROACHES"– Materialize the relations"– Use them to identify inconsistencies"

•  PROBLEM: How to control which inferences are possible,"and which are not allowable?"


•  CAUSES"–  Customer asks for too much!

» no conceivable algorithm"» unrealistic requests"

–  Still useful to know what ultimate desires are"»  Enables early expectation management"»  Suggests incremental development planning"

•  REMEDIAL APPROACHES"– This is a very hard problem"– Need to determine consistency of requirements

specification with designs and implementations"– Multiple notions of “consistency”"

Requirements Infeasibility"


Requirements Unevenness"

•  CAUSES"– Different sources of information"– Different people write different parts"– Different parts of specification are more

difficult than others"•  REMEDIAL APPROACHES"

– Relate details at different levels to other details at similar levels"

software development phases, todayʼs problemlaser.cs.umass.edu/.../phasespart2rqmts-6.pdf ·...

Documents