Requirements analysis Wednesday, September 16, 2009 10:35 AM

Recall the waterfall model Requirements / Design / Implementation / Testing / Maintenance Requirements analysis refers to the art of precisely specifying what a project should do, without a. assuming anything about the customer. b. describing how to do it. Thus requirements analysis is mostly about effective communication: a. Between developer and client about what the product should do. b. Between the requirements team and the design team, about the client's needs.

Requirements Page 1

Some simple rules Wednesday, September 16, 2009 10:42 AM

Some simple rules: a. Don't assume anything. b. When in doubt, ask. c. Avoid making design decisions before the design phase. d. Employ accepted elicitation methods. e. Seek consensus.

Requirements Page 2

Why? Wednesday, September 16, 2009 10:46 AM

a. Don't assume anything because invalid assumptions lead to increased development cost. b. When in doubt, ask, because cost of development is minimal when the actual requirements are documented at the earliest possible time. c. Avoid making design decisions, because the design team needs freedom to choose the best possible path. d. Employ accepted requirements elicitation methods, so that the design team will not have to learn a new method for expressing requirements! e. Seek consensus because stakeholders will otherwise not use the product.

Requirements Page 3

Requirements versus design Monday, September 10, 2012 3:45 PM

Requirements versus design 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 Page 4

Requirements analysis basics Wednesday, September 16, 2009 10:51 AM

Several basic requirements analysis and elicitation techniques: ○ 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.

Requirements Page 5

A simple example: task management Wednesday, September 16, 2009 12:25 PM

What are the requirements for a task management system? Inspiration: www.rememberthemilk.com

Requirements Page 6

Use case Wednesday, September 16, 2009 12:17 PM

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.

Requirements Page 7

Entity/relationship analysis Wednesday, September 16, 2009 12:17 PM

Entities: nouns in the system Interactions: verbs Arrows: transitive verbs

Requirements Page 8

State diagrams Wednesday, September 16, 2009 12:18 PM

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

Requirements Page 9

Time/space diagrams Wednesday, September 16, 2009 12:18 PM

Requirements Page 10

Control flow charts Monday, September 10, 2012 3:50 PM

Control flow charts:

Process

Sequence

Decision

Initiation/termination

Requirements Page 11

Flow chart example Monday, September 10, 2012 3:53 PM

Requirements Page 12

Data flow Monday, September 10, 2012 3:54 PM

Data D flows from A to B

Requirements Page 13

Data flow example Monday, September 10, 2012 3:56 PM

Requirements Page 14

Suitability of depiction Monday, September 10, 2012 3:57 PM

Obviously, not all methods work on all problems Some problems don't have data flow. Some problems aren't easily expressible as state transitions.

Requirements Page 15

Raising the level of abstraction Wednesday, September 16, 2009 12:18 PM

The requirements document is a bridge between the client and the designers. ○ high level of abstraction ○ in language understandable to the client ○ but precise enough to empower design.

Requirements Page 16

Survival mechanisms Wednesday, September 16, 2009 11:34 AM

Some more general survival mechanisms: ○ domain analysis: understanding similar problems ○ modeling: keeping requirements highlevel and specific to the problem domain. ○ stepwise refinement: from general to specific

Requirements Page 17

Domain analysis Wednesday, September 16, 2009 11:35 AM

Domain analysis fancy name for figuring out what is known about your problem what related applications are there? what do they do differently? why?

Requirements Page 18

Modeling Wednesday, September 16, 2009 11:35 AM

Modeling ○ raises the level of abstraction ○ generates more understandable depictions of state ○ documents one aspect at a time

Requirements Page 19

Kinds of models Wednesday, September 16, 2009 11:29 AM

Kinds of models: ○ 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.

Requirements Page 20

Scenerio-based models Wednesday, September 16, 2009 12:06 PM

Scenerio-based models easiest example: use case more subtle example: user survey Both indirectly describe what a product should do

Requirements Page 21

Behavioral models Wednesday, September 16, 2009 12:07 PM

Behavioral models easiest example: state machines/flow charts more subtle example: protocol diagram Role: say what should happen.

Requirements Page 22

Class models Wednesday, September 16, 2009 12:07 PM

Class models: 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!

Requirements Page 23

Object-oriented requirements modeling Wednesday, September 16, 2009 1:33 PM

Requirements Page 24

Refinement Wednesday, September 16, 2009 11:36 AM

Most effective weapon in requirements analysis: stepwise refinement ○ 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.

Requirements Page 25

Example of refinement Wednesday, September 16, 2009 1:41 PM

Simplest model of a task: two states

But active tasks can have several states too:

Requirements Page 26

Advanced: the Jackson Duality principle Monday, September 10, 2012 10:51 AM

The Jackson Duality principle: "Software that processes data tends to follow the form of the data that is processed." Jackson diagrams: Model the form of data and/or the software that processes it.

Requirements Page 27

Jackson diagram semantics Monday, September 10, 2012 10:53 AM

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

Requirements Page 28

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

Requirements Page 29

What Jackson analysis gives us Monday, September 10, 2012 5:13 PM

What jackson diagrams give us Ability to express choices without details. An easy metric for program complexity (McCabe's metric) McCabe's metric: Complexity = # if statements + 1 = total count of 0's and *'s + 1. McCabe's claim: If a piece of software exceeds a metric of 10, it cannot be tested by a human.

Requirements Page 30

The power of Jackson diagrams Monday, September 10, 2012 11:00 AM

The power of Jackson diagrams 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)

Requirements Page 31

Jackson diagrams versus flow charts Monday, September 10, 2012 10:58 AM

Jackson diagrams versus flow charts Flow chart Expresses all activity Difficult to refine Does not show hierarchical structure

Jackson diagram Expresses part of activity Easy to refine Shows hierachical structure in a natural way

Requirements Page 32

Detailed example Monday, September 10, 2012 11:02 AM

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.

Requirements Page 33