Recall the waterfall modelRequirements / Design / Implementation / Testing / Maintenance

assuming anything about the customer. a.describing how to do it.b.

Requirements analysis refers to the art of precisely specifying what a project should do, without

Between developer and client about what the product should do.

a.

Between the requirements team and the design team, about the client's needs.

b.

Thus requirements analysis is mostly about effective communication:

Requirements analysisWednesday, September 16, 200910:35 AM

Requirements Page 1

Don't assume anything. a.When in doubt, ask. b.Avoid making design decisions before the design phase.

c.

Employ accepted elicitation methods.d.Seek consensus.e.

Some simple rules:

Some simple rulesWednesday, September 16, 200910:42 AM

Requirements Page 2

Don't assume anything because invalid assumptions lead to increased

development cost.

a.

When in doubt, ask, because cost of development is minimal when the actual

requirements are documented at the earliest possible time.

b.

Avoid making design decisions, because the design team needs freedom to

choose the best possible path.

c.

Employ accepted requirements elicitation methods, so that the design team will

not have to learn a new method for expressing requirements!

d.

Seek consensus because stakeholders will otherwise not use the product.

e.

Why?Wednesday, September 16, 200910:46 AM

Requirements Page 3

Requirements describe what to do. Design describes how to do it. Most common software engineering mistake: mix up design with requirements.

Why is this a bad thing?

Requirements versus design

Requirements versus designMonday, September 10, 20123:45 PM

Requirements Page 4

Dictionaries: listing all of the entities involved and their precise definitions.

○

Use cases: creating a "script" of one or more specific kinds of use.

○

Entity/relationship analysis: documents how entities interact.

○

State diagrams: document how entity states can change, and why.

○

Time/space diagrams: document how entities interact over time.

○

Control flow charts: describe the actions of a single entity.

○

Data flow charts: describe how data is exchanged between entities.

Several basic requirements analysis and elicitation techniques:

Requirements analysis basicsWednesday, September 16, 200910:51 AM

Requirements Page 5

What are the requirements for a task management system?

Inspiration: www.rememberthemilk.com

A simple example: task managementWednesday, September 16, 200912:25 PM

Requirements Page 6

A user browses to the website.Website says "login". User enters username and password. Website shows tasks to be done today. Buttons on website allow viewing of all tasks and entering new tasks.

User presses the button to see all tasks. User enters a new task. Task appears in list of all tasks, in alphabetical order.

User selects the category "Inbox".Website shows all tasks in that category. New task appears in the category "inbox".User clicks on the task. Task is checked in the list. User types "c".Task is marked as completed.

Use caseWednesday, September 16, 200912:17 PM

Requirements Page 7

Entities: nouns in the systemInteractions: verbsArrows: transitive verbs

Entity/relationship analysisWednesday, September 16, 200912:17 PM

Requirements Page 8

States of a task, with user input that causes each state change.

State diagramsWednesday, September 16, 200912:18 PM

Requirements Page 9

Time/space diagramsWednesday, September 16, 200912:18 PM

Requirements Page 10

Control flow charts:

Process

Sequence

Decision

Initiation/termination

Control flow chartsMonday, September 10, 20123:50 PM

Requirements Page 11

Flow chart exampleMonday, September 10, 20123:53 PM

Requirements Page 12

Data D flows from A to B

Data flow Monday, September 10, 20123:54 PM

Requirements Page 13

Data flow exampleMonday, September 10, 20123:56 PM

Requirements Page 14

Some problems don't have data flow. Some problems aren't easily expressible as state transitions.

Obviously, not all methods work on all problems

Suitability of depictionMonday, September 10, 20123:57 PM

Requirements Page 15

high level of abstraction○

in language understandable to the client○

but precise enough to empower design. ○

The requirements document is a bridge between the client and the designers.

Raising the level of abstractionWednesday, September 16, 200912:18 PM

Requirements Page 16

domain analysis: understanding similar problems

○

modeling: keeping requirements high-level and specific to the problem domain.

○

stepwise refinement: from general to specific

○

Some more general survival mechanisms:

Survival mechanismsWednesday, September 16, 200911:34 AM

Requirements Page 17

fancy name for figuring out what is known about your problem

what related applications are there? what do they do differently? why?

Domain analysis

Domain analysisWednesday, September 16, 200911:35 AM

Requirements Page 18

raises the level of abstraction○

generates more understandable depictions of state○

documents one aspect at a time○

Modeling

ModelingWednesday, September 16, 200911:35 AM

Requirements Page 19

Scenario-based models: describe a product's use in context.

○

Behavioral models: describe time-varying behavior. ○

Data models: describe input and output structure. ○

Class models: describe entities and interactions without considering time (document interface instead).

○

Flow models: describe movement ("flow") of data. ○

Kinds of models:

Kinds of modelsWednesday, September 16, 200911:29 AM

Requirements Page 20

easiest example: use casemore subtle example: user surveyBoth indirectly describe what a product should do

Scenerio-based models

Scenerio-based modelsWednesday, September 16, 200912:06 PM

Requirements Page 21

easiest example: state machines/flow chartsmore subtle example: protocol diagramRole: say what should happen.

Behavioral models

Behavioral modelsWednesday, September 16, 200912:07 PM

Requirements Page 22

easiest example: taxonomy of kinds of tasks in the task manager. more subtle example: object-oriented modeling.Watch out: object-oriented modeling (OOM) describes behavior, while object-oriented design

(OOD) describes structure. These are different!

Class models:

Class modelsWednesday, September 16, 200912:07 PM

Requirements Page 23

Object-oriented requirements modelingWednesday, September 16, 20091:33 PM

Requirements Page 24

Simply stated: start with the big picture, evolve details. ○

Largely a matter of "opening the box" when appropriate. ○

For every requirements analysis methodology, there is a different kind of refinement.

○

Most effective weapon in requirements analysis: stepwise refinement

RefinementWednesday, September 16, 200911:36 AM

Requirements Page 25

Simplest model of a task: two states

But active tasks can have several states too:

Example of refinementWednesday, September 16, 20091:41 PM

Requirements Page 26

"Software that processes data tends to follow the form of the data that is

processed."

The Jackson Duality principle:

Model the form of data and/or the software that processes it.

Jackson diagrams:

Advanced: the Jackson Duality principleMonday, September 10, 201210:51 AM

Requirements Page 27

A is comprised of B, plus perhaps more.

Sequence: A is comprised of B followed by C, plus perhaps more

Conditionals: A is comprised of 0 or 1 B's, plus perhaps more details other than B

Iteration: A is comprised of 0 or more repeats of B, plus perhaps more details.

Some other useful forms:

Iteration with lower bound: A is comprised of 1 or more repeats of B

Jackson diagram semanticsMonday, September 10, 201210:53 AM

Requirements Page 28

Simple example: flowchart and Jackson diagram. Monday, September 10, 20125:10 PM

Requirements Page 29

Ability to express choices without details. An easy metric for program complexity (McCabe's metric)

What jackson diagrams give us

Complexity = # if statements + 1 = total count of 0's and *'s + 1.

McCabe's metric:

If a piece of software exceeds a metric of 10, it cannot be tested by a human.

McCabe's claim:

What Jackson analysis gives usMonday, September 10, 20125:13 PM

Requirements Page 30

Can model data or actions. Duality principle: model for data is model for actions (in some sense).

No assumption that model is complete. Naturally indicates the complexity of the entity

(which determines cost of implementation)

The power of Jackson diagrams

The power of Jackson diagramsMonday, September 10, 201211:00 AM

Requirements Page 31

Jackson diagrams versus flow charts

Flow chart Jackson diagram

Expresses all activity

Expresses part of activity

Difficult to refine Easy to refine

Does not show hierarchical

structure

Shows hierachical structure in a natural

way

Jackson diagrams versus flow chartsMonday, September 10, 201210:58 AM

Requirements Page 32

An accounts payable client record includes the name and address of a person, and an

optional email address and phone number. It also indicates a payment amount and date to

pay. The accounts payable database is a set of these records.

Detailed exampleMonday, September 10, 201211:02 AM

Requirements Page 33