Introductory Software Engineering CSE100

1
Introductory Software EngineeringCSE100
2
Recap

• Last time we looked some more at requirements
  analysis and definition
• We talked about the method used with information
  systems the use of Data Flow Diagrams etc.
• Here, the nature of the data dictates how the
  software is built analysis of the data is a
  prime step leading to the design of the database
  for the application
• This is not solely, nor in fact typically, what
  SE needs to be concerned with

3
The SRS (Software Requirements Specification)

• Need to consider
• Level of detail?
• What system does not how it does it
• The users view
• Who is it for?
• So, how technical should the language be?
• What notation to use?
• Informal (natural language)
• Formal (mathematical/technical language)
• Semi-formal (natural language plus diagrams,
  pseudo-code etc)

4
Key Characteristics of the SRS

• Must be
• Implementation free
• (Its about what not how)
• Complete
• Consistent
• Unambiguous
• Concise
• Minimal
• Understandable
• Achievable
• Testable

5
Must contain

• Functional Requirements (what the system must
  do)
• Non-functional Requirements (environmental
  factors, usability, how)
• Data requirements
• Performance requirements
• Constraints
• Implementation Guidelines

6
Methods/notations used in SRSs

• Nowadays, most SRSs are written in natural
  language plus Use Case Diagrams
• So, well look at
• Use Cases
• UML Use Case Diagrams

7
Use Cases

• Scenarios describing how the system will be used
• They comprise
• Textual description of a complete users task
• Can be enhanced by UML Use Case Diagrams
• Capture users functional requirements (one by
  one)
• Can be used to help create test cases, predict
  cost, derive the structure of the software, and
  help write the user manual.

8
Use Cases

• Describe the users point of view
• Users performing roles are called Actors.
• Actors are external entities people or other
  systems interacting with the system.
• Actors perform Tasks
• The use case is this task (at an overarching
  level) e.g.

• ?
• Input card
• Enter pin, etc..
• are sub tasks
• are not distinct use cases

• ?
• Withdraw cash (from ATM/cashpoint system)
• is a use case

9
Use Cases

• 1. A use case tells a story of someone using the
  system to accomplish some goal. That means it has
  more than one step
• 2. A use case describes the black box behaviour
  of the system. That is, it says what other
  systems the system under design talks to.
• 3. A use case usually describes more than one
  scenario it almost certainly has two exits, one
  where the users goal is accomplished and another
  where the users goal is not accomplished.
• E.g. in the Withdraw cash scenario the user
  either withdraws cash or doesnt (if they have no
  money left in the bank)
• Definitions from http//alistair.cockburn.us

10
Student Activity

• Write a Use Case for Withdraw Cash from the
  Cashpoint system
• Hint step by step, describe what the user does
  (i.e. the person trying to withdraw cash)
• Assume they are already standing at the cashpoint
  with their card in their hand.

11
Outcomes of Activity

• Answer could be
• The user inputs their card.
• The system asks for the PIN.
• The user enters the PIN.
• The system checks the PIN.
• If the card and PIN are valid, the system asks
  the user for their choice of function.
• The user selects cash withdrawal.
• The system asks the amount.
• The user enters the amount.
• The system ejects the card.
• When the user has withdrawn the card, the system
  dispenses the cash.

12
Other Use Cases in cashpoint system

• As well as withdraw cash what else could be a
  use case?
• Check balance
• Top up mobile phone
• Etc
• What would the Use Case for Check Balance be?

13
Possible answer for Check Balance

• The user inputs their card.
• The system asks for the PIN.
• The user enters the PIN.
• The system checks the PIN.
• If the card and PIN are valid, the system asks
  the user for their choice of function.
• The user selects check balance.
• The system asks the user their choice of output
  (screen or printout).
• The user selects the method of output.
• The system outputs the balance, and asks for
  continue or return card.
• The user selects return card.
• The system ejects the card.

14
Potential confusion with use cases

• Confusion 1
• You will have seen that there is overlap in the
  several different use cases (e.g. insert card,
  input pin). Overlap is fine.
• Confusion 2
• Determining distinct use cases
• E.g. enter validate pin isnt distinct use case
• Why? Because its not a useful function from the
  users point of view
• The key is to identify a users end goal

15
Complexity

• In large systems therell be many Use Cases
• To stop it getting too complex we use Use Case
  Packages
• Group related things together
• E.g. web browser functions grouped by menus of
  activity File, Edit, View, Tools, Favourites,
  Help

16
UML Use Case Diagram
Use Case function
Actor role
17
Student Activity

• Write a Use Case for the following specification
  (Taken from Bell, 2005)
• Spec
• A window displays a defender and an alien. The
  alien moves sideways. When it hits a wall it
  reverses its direction. The alien randomly
  launches a bomb that moves vertically downwards.
  If it hits the defended the user loses, game
  over. The defender moves left or right according
  to the mouse. When the mouse is clicked, the
  defender launches a laser that moves upwards. If
  a laser hits the alien, the user wins, game over.
  A button is provided to start a new game.
• Hint remember you are writing from the users
  (defenders) perspective!
• User Interface screenshot on next slide

18
Cyberspace Invaders Interface Screenshot
19
Outcomes of Activity
20
Student Activity

• See Case Study handout.
• Read through 1, 2 and 3.
• In small groups write a case study for 4)basic
  Social Networking Site
• Feedback to class and agree on a single
  class-wide description of case study 4)

21
Activity (page 2 of 4)

• For each one, identify any problems with the
  specs such as
• Ambiguity
• Inconsistency
• Vagueness or Incompleteness
• Identify who would be the stakeholders i.e. to
  whom would you need to speak to gather/clarify
  the requirements

22
Activity (page 3 of 4)

• For each case study identify
• The functional requirements and
• The non-functional requirements
• For each case study
• identify and write the use cases
• Who/what are the actors in each one?
• draw a use case diagram.

23
Activity (page 4 of 4)

• Tomorrow well be looking at User Interface
  Design
• If time permits today, consider for case studies
  1, 3 and 4 what the interface should look like
• State why you have made these design choices
• Draw your ideas for the interfaces
• Bring any initial drawings or descriptions to
  tomorrows session

24
Outcomes of Activity