Requirements

1
Requirements Use Cases
2
Requirements

• capabilities and conditions to which the system
  must conform
• managing requirements
• changing requirements
• find, communicate, and document what is
  required

3
Evolutionary Waterfall

• dont need to say it again

4
Finding Requirements

• workshops
• focus groups
• iteration demos
• any elicitation of requirements

5
Types Categories

• functional, usability, reliability, performance,
  supportability
• plus
• implementation, interface, operations, packaging,
  legal
• functional and non-functional
• aka quality attributes or quality requirements

6
UP Artifacts for Requirements

• Use Case Model
• Supplementary Specification
• Glossary
• Vision
• Business Rules
• information abstractions

7
Examples

• some examples
• p. 61
• p. 493
• p. 101

8
Use Cases

• text stories to discover and record requirements
• used to influence the project

9
Example

• p. 62 p. 63

10
Actors

• something with behavior
• participates in the system functionality

11
Scenarios

• specific sequence of actions and interactions
  between actors
• use case instance

12
Use Cases

• collection of related success and failure
  scenarios
• used for input of key requirements
• show requirements in context

13
Use Case Model

• model of the system functionality and
  requirements with a collection of use cases
• may include use case diagrams

14
Functional Requirements

• what the system will do
• behavior of the system

15
3 Kinds of Actors

• primary
• supporting
• offstage

16
Use Case Formats

• brief
• casual
• full dressed

17
Fully Dressed Example

• starting on p. 67

18
Use Case Sections

• scope
• level
• primary actor
• stakeholders interests list
• preconditions postconditions
• main success scenario
• extensions
• other use cases
• special requirements
• technology data variations list

19
Other Formats

• 2 column
• conversational
• best?

20
Guidelines to Writing

• essential UI free style
• terse use cases
• black box
• actor actor goal perspective

21
Guidelines to Finding

• choose system boundary
• identify primary actors
• identify primary actors goals
• define use cases to satisfy those goals

22
Testing Use Case Findings

• Boss, EBP, Size
• May need to write sub-function level use cases

23
Use Case Diagram

• notation to illustrate use cases and actors
• shows use case in its context
• short and simple

24
Activity Diagram

• workflows and business processes
• may be necessary if you have many parties and
  concurrent actions

25
Use Cases with Iterative

• UP emphasizes use case driven design
• functional requirements
• iterations defined by choosing use case scenarios
• use case realizations drive the design
• may influence use manuals
• functional system testing

26
Evolving Use Cases

• start with 10
• production quality development starts immediately
• more use cases are detailed
• requirements workshop

27
Artifacts

• Use Case Model started in inception
• see table on p. 97

28
During each phase

• inception
• elaboration
• construction

29
Other Requirements

• part of UP
• should be done only if needed

30
Supplementary Specification

• captures other requirements, information and
  constraints

31
Vision

• may include high level system feature lists
• should be short and sweet summary of the Use Case
  Model and Supplemental Specification

32
Glossary

• important terms and their definitions

33
Domain Rules

• how a domain or business may operate

34
Evolutionary Requirements

• must evolve through the entire project
• allowing feedback to refine specifications

35
Iteration Requirements Emphasis

• dont implement all requirements at once
• incremental development across iterations

36
Inception activities

• short requirements workshop
• most actors, goals, and use cases named
• brief format for most, fully dressed 10
• risky and influential requirements identified
• Vision and Supplemental Specification
• risk list
• proof of concepts prototypes
• UI prototypes
• build/buy recommendations
• high level candidate architecture components
• plan for 1st iteration
• candidate tools list

37
Elaboration

• initial series of iterations
• core risky software architecture is addressed
• majority of requirements are discovered and
  stabilized
• major risks are mitigated or retired

38
Elaboration 2

• short timeboxed risk driven iterations
• start programming early
• adaptively design, implement test core and
  risky parts
• test early and often
• adapt based on feedback
• write most of the use cases and other
  requirements in detail

39
Artifacts to start

• Domain Model
• Design Model
• Software Architecture Document
• Data Model
• Use Case Storyboards
• UI Prototypes

40
Didnt do elaboration right when

• it takes more than a few months
• it only has one iteration
• more requirement defined before elaboration
• risky elements and architecture are not being
  tackled
• does not result in executable architecture
• it is a design phase
• full design before programming
• minimal feedback and adaptation
• no early and realistic testing
• architecture finalized before programming
• part of the proof of concept phase

41
Planning next iteration

• organize by risk, coverage, and criticality

42
Relating Use Cases

• when one use case uses another one
• OO
• reuse

43
includes

• some behavior that is common and re-used
  throughout the system
• use when repeating in two or more separate use
  cases
• p. 499

44
concrete, abstract, base, addition

• concrete instantiated by an actor
• abstract never instantiated
• base -
• addition -

45
extends

• an extending or addition use case
• p. 30.2

46
Use Case Diagrams

• the illustration
• p. 499