Administrivia

1
Administrivia

• AnkhSvn plugin for Visual Studio
• No discussion tomorrow
• See the FAQ for hw3 on how to go from windows to
  xbox and how to deploy to xbox
• Dont forget that you need an xbox live silver
  account and a creators club membership from
  msdnaa
• Any questions?

2
Concept Requirements

• Requirements are not easy to define in the
  context of software
• Certainly, formal definitions are often complex.
• In this case, we view requirements as the
  following
• Guidance on the purpose of software, from the
  viewpoint of users and other stakeholders
• Stakeholder Anyone with interest in the system
• Name some stakeholders
• When you talk requirements you must mention
  stakeholders or you arent talking about
  requirements ?

3
Requirements

• Some spilt requirements into two major types
• Functional
• Functionality for the user/stakeholder
• Non-functional
• High-level concerns that dont directly affect
  users
• For example, the use of a certain UI toolkit

4
Requirements

• A different, somewhat non-orthodox view on
  requirements
• Dont distinguish between functional and
  non-functional if possible
• Every requirement should be linked to a user or
  stakeholder (who wants this)
• That is, why specify a non-functional requirement
  if the stakeholder is not linked to it?
• Either the stakeholder doesnt care in which case
  it doesnt belong in the system
• Or the stakeholder does care and it is a
  functional requirement
• Requirements are typically a textual document
• Modeling of requirements provides a higher level
  view (abstract)
• Modeling of requirements allows more succinct
  expression of some concepts

5
Requirements and Use Cases

• We will get more and more into what a use case is
  a bit later, but for now, note that
• Use-cases are a way of representing requirements.
• A lot of the software world has embraced use
  cases as THE way to express requirements
• Some use a mix of ideas
• Formal specification to completely informal
  documents

6
Concept Architecture

• If requirements is hard to define, then
  architecture is just as hard (if not more so)
• Architecture provides a major view of the
  organization of software in terms of
• Architectural elements and their connections
• Grouping of these elements into components and
  interfaces
• Groups of components into subsystems, and
  subsystems into systems

7
Architecture Pitfalls

• Often, the hardest part of architecture is
• Choosing the proper set of architectural
  elements,
• Making new elements when needed
• Using those elements on a proper level of
  abstraction (not too high, not too low)
• Minimizing coupling, maximizing reuse potential
  in component, subsystems.
• Our goal
• Is to expose you to a couple of sample
  architectures (instead of you having to invent
  your own)
• See how to build solutions given a particular
  architecture

8
Requirements and Architecture

• Can have a great impact on the success or failure
  of a project
• Good requirements, architecture can make a
  project much more likely to succeed (but it still
  can fail)
• Bad requirements, architecture makes a project
  much less likely to succeed (but it still can
  succeed)
• Successful development requires focus, effort at
  every stage.

9
Where We are Headed

• As a system architect / team lead you would
• Be responsible for specifying the requirements
• Lead in architecture
• Lead or assist in design
• As a designer you would
• Consume requirements
• Assist in architecture
• Lead in design
• As a developer you would
• Consume requirements
• Consume architecture
• Assist in design
• So, our goal
• Expose you to writing requirements
• Focus on analysis and critique of requirements
  and architecture

10
Use Cases

• Originated with Ivar Jacobsen
• Object-Oriented Software Engineering 1992
• An important reference Writing Effective Use
  Cases by Alistair Cockburn
• Designed to capture the high-level requirements
  of a system
• Describes WHAT a system should do
• User focus
• Gives scope to the project
• Use cases are not functional decomposition
• That is, think about how you might build the
  system, decompose it, and describe each piece
• That is for design and implementation

11
Use Cases - 2

• You cant think like a programmer when writing
  them
• This makes it really hard for us programmer types
  to write use cases
• Use cases should not say HOW something is done
• There are other tools for HOW, that well see
  later
• Use cases are about stakeholder and their
  interaction
• You do not talk about what stakeholders do
  outside of the system unless it is relevant to
  the system
• Use cases are not strictly OO
• But they have been adopted fairly widely by the
  OO community

12
How To Write Use Cases

• Identify who will use the system
• These users are called actors
• Actors are not individuals, but they are roles
  of the users of the system
• Probably should have been called roles, because
  actor has too many connotations
• Pick one of the actors
• Figure out what the actor wants to do with the
  system
• Each thing that you figure out is a Use Case
• Naturally there may be many Use Cases for each
  actor

Excerpted from The Object Practioners Guides
by Edward Kenworthy http//www.zoo.co.uk/z00
01039/PracGuides/toc.htm
13
How To Write Use Cases - 2

• For each Use Case decide the most usual
  interaction course
• That is, what NORMALLY happens
• AKA Basic course
• AKA Basic flow
• AKA Main success scenario
• Describe the basic flow for the Use Case
• Actor does something
• System does something
• Actor does something
• System does something
• Keep it high level and dont mention GUI
• Describe only things for the system that the
  actor would be aware of
• Ditto for the reverse (actor does that the system
  would be aware of)
• Notice noun verb noun format above

14
How To Write Use Cases - 3

• Once you have the main success scenario, consider
  adding an exception to handle slightly different
  situations or errors
• AKA - alternate flow
• If the Use Case must be extended with additional,
  optional functionality create a separate use case
  and use extends dependency
• Examine the use cases and look for common flows,
  move them into a common use case (and use
  includes dependency)
• Repeat

15
Lets Work on an Example Use Case

• Online store Friendly Books and Things
• Instead of customer browsing and entering orders,
  FBaT has sales clerks that talk with the
  customers and do the ordering
• FBaT believes that they sell more because the
  clerks provide the personal touch and can talk
  the customers into buying other things
• Sales clerks talks with customers
• When a customer wants to buy some stuff, the
  sales clerk interacts with the computer to find
  the customers account, check their credit, and
  enter the order
• So, lets write a use case for the computer
  system to handle this task
• Go back and review the steps

16
Example Steps 1 to 5

• Use Case Enter a Sales Order
• Basic Steps
• The Sales Order Clerk enters the customers
  surname. The system displays all matching
  customers. The Sales Order Clerk selects one of
  those customers. The system displays that
  customers details.
• For each item that the customer wishes to order
  the Sales Order Clerk enters the line details.
• When all line items have been entered the system
  confirms the order.

• Use Case Credit Check a Customer
• The Sales Order Clerk enters the customers
  surname. The system displays all matching
  customers. The Sales Order Clerk selects one of
  those customers and the system displays that
  customers details.
• The system also displays the customers payment
  history for the last six months.

17
Example Step 6

• Use Case Enter a Sales Order
• The Sales Order Clerk enters the customers
  surname.
• Exceptions
• If the system cant locate the customers
  surname, then indicate an error and ask the Sales
  Order Clerk to enter a different surname.

• Use Case Credit Check a Customer
• The Sales Order Clerk enters the customers
  surname.
• Exceptions
• If the system cant locate the customers
  surname, then indicate an error and ask the Sales
  Order Clerk to enter a different surname.

18
Example Step 7

• Use Case Evaluate A Customers Credit
• This use case extends the Credit Check A
  Customer Use Case. The System evaluates the
  previous six months of payment data and provides
  the Sales Order Clerk with a credit worthiness
  evaluation of the Customer which the Clerk may
  use to request an up-front deposit on the order.

19
Example Step 8

• Use Case Credit Check a Customer
• Includes use case Display Customer Details to
  lookup and display a customers details.
• The system also displays the customers payment
  history for the last six months.

• Use Case Enter a Sales Order
• Includes use case Display Customer Details to
  lookup and display a customers details.
• For each item that the customer wishes to order,
  the Sales Order Clerk enters the line details.
  When all line items have been entered the system
  confirms the order.

Use Case Display Customer Details The Sales
Order Clerk enters the customers surname. The
system displays all matching customers. The
Sales Order Clerk selects one of those customers
and the system displays that customers
details. Exception If the system cant locate
the customers surname, then indicate an error
and ask the Sales Order Clerk to enter a
different surname.
20
Review of Our Use Cases

• Define
• Main success flow (basic steps)
• Exceptions (alternate flow) in a use case
• Includes another use case
• Extends another use case
• Display Customer Details (including exception)
• Enter Sales Order (which includes Display
  Customer Details)
• Credit Check a Customer (which also includes
  Display Customer Details)
• Evaluate a Customers Credit (this extends Credit
  Check a Customer)

21
UML

• UML is silent about Use Cases
• Use Cases are mostly about text documents
• However, you can draw a use case diagram to help
  you visualize the relationships
• A picture is worth a thousand words

22
Sales Order UML Diagram
23
Some Guidelines

• Simple, simple, simple, simple, simple, simple
• Adding too much is a very bad plan
• It is ok to attach other things to a requirements
  specification, but they dont belong IN with the
  Use Cases
• If you want to have a prototype GUI add a
  separate image
• Modeling some object relationships should be in a
  Class Diagram
• Model dynamic object relationships in a sequence
  diagram
• Use Cases need to be sized just right
• Try not to have tiny Use Cases (decomposing into
  too small of a piece usually means that you are
  falling into HOW)
• Try not to have giant Use Cases either
• Use extends and includes sparingly

24
Problems - 1

• What is wrong with this?

25
Problems - 2

• ?? Lets look at two Use Case descriptions to
  help us understand problem 2 in previous slide
• Use Case Enter A Sales Order
• The actor selects a customer from a list
  displayed by the system. Use Use Case "Lookup
  Customer". The system then displays the sales
  order screen and the actor enters the item code
  and quantity required for each item. The system
  displays a running total of the value of the
  order. Once the order is complete the actor
  confirms the order and the systems resets ready
  for the next order.
• Use Case Lookup Customer
• The actor selects a customer by entering their
  reference number. The system then displays the
  complete details of that customer, name, address
  etc along with a complete history of purchases
  they have made.
• That means that Enter A Sales Order is really
• Use Case Enter A Sales Order
• The actor selects a customer from a list
  displayed by the system. The actor selects a
  customer by entering their reference number. The
  system then displays the complete details of that
  customer, name, address etc along with a complete
  history of purchases they have made. The system
  then
• Also, do we really want to show the customers
  history?

26
Problems 3 Revised Model
27
Problems 4 Final Version

• Simplify all use cases apply to the user!!
• Even though we have lost information that
  information is most likely not relevant or over
  constraining the possible implementation

28
Another Problem

• What is wrong with this?

29
A Possible Solution
30
Last Problem - Choose

• Use Case Enter A Sales Order
• Display list of customers from central database.
• Actor chooses one of those customers.
• The system displays sales order form.
• While there are more items for this order
• actor enters item and quantity
• system updates running total
• End While
• Confirm the Order

• Use Case Enter A Sales Order
• The actor selects a customer from a list
  displayed by the system. The system then displays
  the sales order screen and the actor enters the
  item code and quantity required for each item.
  The system displays a running total of the value
  of the order. Once the order is complete the
  actor confirms the order and the systems resets
  ready for the next order.

B
?
A
?
C
Use Case Enter A Sales Order The sales person
selects a customer. The system prompts the
salesperson to enter the details of the order
(item code and quantity) and maintains a running
total of the value of the order. Once the
salesperson is happy with the order they confirm
it and the system records the confirmed order.
31
Next Time

• More on Requirements
• A good place for references on thinking about use
  cases is
• http//alistair.cockburn.us/crystal/articles/o/uca
  i/usecasealternateintro.html