Design Problem III Overview

1
Design Problem I-IIOverview

• INFO 425-426
• Glenn Booker

2
Course Overview

• INFO 425 and INFO 426 are the senior design
  project
• Your objective is to analyze, design, and
  implement a small information system
• You choose with whom to work (3-5 people per
  team), and what youll implement
• This lecture outlines the assignments

3
Text

• There is no textbook for this class
• Youre expected to make use of the texts from
  previous classes (most likely INFO 200, 355, 420,
  plus interface design 110/310), and research any
  other information you need

4
Development Approach

• All of the projects are designed to be created in
  three implementation cycles, roughly following
  the Rational Unified Process
• Therefore a key aspect of early planning is not
  only to identify the features for your product,
  but also to prioritize them into development
  cycles
• This class consists of one cycle of development
  and the start of cycle 2 INFO 426 finishes cycle
  2 and adds cycle 3

5
Development Approach

• Each cycle should produce a functional (working!)
  part of your system
• Cycle 1 has to establish the core or backbone of
  your system
• Cycles 2 and 3 add functionality onto the
  foundation of cycle 1
• The overall scope of your system can be larger
  than cycles 1-3

6
Document Templates

• Here are templates for all INFO 425 and INFO 426
  written documents
• Make sure to view the comments in each file,
  which provide detailed instructions
• And please delete the comments before submitting
  them!
• See also in that zipped file the Succeeding in
  ISYS 425 (sic) document by TJ Smith
• Its a review of specification and design
  concepts, in case you forgot ?

7
Written Deliverables

• Its expected that you will create several
  written documents to capture the analysis and
  design of your system
• Launch Report
• Software Requirements Specification (SRS)
• Test Specification
• Software Design Specification (SDS)
• Customer Documentation (used in INFO 426)
• Most of these documents will evolve over the
  life of your project

8
Presentation Deliverables

• You will give two oral presentations for each
  cycle
• The first three documents together (Launch
  Report, SRS Test Specification)
• A demonstration of your initial working system,
  and show key aspects of its design

9
Written Deliverables
10
Launch Report

• The Launch Report is a brief summary of the
  scope of your project
• Notice there are two templates for the Launch
  Report one just for Cycle 1, and one for all
  later cycles (Cycle ltngt)
• The Cycle ltngt version includes a post-mortem
  review of the previous cycle
• The schedule in the syllabus supercedes the one
  in the Launch Report

11
Launch Report

• Each cycle lasts about seven weeks, consisting
  of
• Launch (or after cycle 1, post-mortem of previous
  cycle and re-launch) 1½ weeks
• Requirements and Test Specification 2½ weeks
• Design and Prototyping 3 weeks
• Time periods are approximate dont wait for
  permission to start the next activity!

12
Launch Report

• This report
• Includes an overview of your system (Feature
  Highlights)
• Describes the source of key requirements and
  usability information (Sponsor or Proxy User)
• Identifies technical Issues which may affect
  development of your system
• And summarizes the logistics of your team (Team
  Members, Roles, Communication, Issues, etc.)

13
Launch Report

• After the first cycle, the launch report adds a
  post-mortem to analyze the previous cycle,
  identify and address any issues which emerged
  during that cycle
• The schedule might be amended, and the objectives
  for the new cycle are stated

14
Requirements - SRS

• The requirements specification (SRS) captures the
  evolution of requirements for your system
• The requirements expand on the Feature Highlights
  in the Launch Report, to guide the development of
  each part of the system
• The SRS template blends both traditional
  functional requirements with use case-based
  documentation

15
Requirements - SRS

• See the SRS examples on the course web site
• IEEE standard 830 and TJs summary provide more
  guidance on how to write a good SRS
• Functions are most often broken down by either
  the type of functionality, or the user who
  performs them
• Types of functionality could be, e.g. Sales,
  Distribution, Marketing, Reporting, etc.
• Users could be each type of role who uses the
  system clerks, managers, admin, etc.

16
Requirements - SRS

• Your team needs to decide if use cases will be
  used to capture functional requirements, or the
  IEEE 830 narrative-based structure
• So I should see a use case diagram, and detailed
  descriptions of key use cases, OR
• Functionality-based (ordering, accounting, human
  resources, etc.) description of requirements, OR
• User-based (end user, administrator, manager,
  clerk, etc.) description of requirements

See slide 41 for a reminder about use case
documentation
17
Requirements - SRS

• In addition to the functional requirements (in
  one of the three forms just mentioned), I should
  see a section for non-functional requirements
• Section 3.3 can be renamed Non-Functional
  Requirements, and include subsections for each
  variety thereof

18
Requirements - SRS

• Requirements are phrased in the form of simple
  sentences to express what capabilities are needed
  NOT how they will be implemented
• The system shall be able to open multiple
  documents simultaneously.
• The system shall ensure that the ten previous
  passwords are not allowed.
• The system shall operate in cold environments
  without degradation at temperatures down to -4F
  (-20C) in snow or sleet.

19
Requirements ? Design

• In the requirements, do NOT tell me
• What kind of computers or software will be used
  in your system
• What kind of architecture your system will use
• What programming language or development
  environment your team will use
• Those are all design and implementation issues,
  unless mandated by your customer
• Do tell me WHAT a user should be able to do with
  your system, and how WELL

20
Writing Good Requirements

• In writing requirements, watch out for and it
  often means that you have two distinct
  requirements in one sentence
• The system shall be able to print and save
  documents.really means
• The system shall be able to print documents.
  The system shall be able to save documents.
• Be sure requirements have an identifier, and are
  specific enough to be tested or demonstrated

21
Non-Functional Requirements

• In addition to detailed functional requirements
  (whether defined through traditional or use case
  means), non-functional requirements need to be
  addressed, where appropriate
• There are many kinds of non-functional
  requirements in general, they describe how well
  the functional requirements are performed

22
Non-Functional Requirements

• One way to categorize them is IBMs UPRIMDA
• Usability (HCI)
• Performance (speed, capacity)
• Reliability
• Installability
• Maintainability
• Documentation
• Availability

23
Non-Functional Requirements

• Could add, if applicable
• Upgradeability
• Internationalization
• Security
• Privacy
• Accommodation for disabilities
• In general, any characteristic ending in
  -ility is likely to be a kind of
  non-functional requirement
• Some arent critical for this project, but they
  are important to consider

24
SRS Template Notes

• In addition to the comments provided
• Section 1.3 please sort acronyms terms
  alphabetically!
• Section 1.4 use a recognized style for references
  (APA), and cite them in the rest of the document
  where used
• See the OWL at Purdue for examples
• Section 2.1 tells if this product is part of a
  larger system, or how it fits into the context
  of the organization that uses it
• If not relevant, just say its a standalone system

25
SRS Template Notes

• Section 2.2 outlines the functions of the system
  in more detail than section 1.2, but in less
  detail than section 3.2
• Good place for a use case diagram, if you have
  one
• Section 2.4 gives constraints on the development
  of the product given by the customer not
  artificial constraints you place on yourselves!

26
SRS Template Notes

• Section 2.5 can include assumptions about the
  knowledge and skill level of the system users
• Section 2.6 breaks down the functions from
  section 2.2 by the cycle in which theyll be
  implemented
• Section 3.1 describes the interfaces between the
  system and its users
• Can include typical graphic user interfaces (e.g.
  a web site), and interfaces to other external
  systems (info systems, web-based data sources,
  etc.)

27
SRS Template Notes

• Section 3.2 should give the detailed description
  of functional requirements for your system
• Should expand on section 2.2s outline
• Should identify and name each requirement
  uniquely
• The Action section should describe the logic used
  to perform the function, if any
• Priority should correspond to the cycle in which
  the function will be implemented (not all are
  High!)
• Every functional requirement should be testable
  or demonstrable

28
SRS Template Notes

• Section 3.3 can include all non-functional
  requirements
• Still need to define them so they can be tested!
• Easy to use and Reliable arent testable!
• Give each non-functional requirement an
  identifier and name
• Section 3.4 can describe the volume of data you
  expect to store, in business terms, e.g. 10,000
  users and 1 million transactions
• Section 3.6 consider interface design guidelines,
  such as the Windows Logo Program or Apple Human
  Interface Guidelines

29
Nested Requirements

• A common pattern for requirements that apply to
  multiple (human) languages, or interfaces (e.g.
  specific web browsers)
• A long list of interface-related requirements may
  need to be identified as a group
• Thats partly why we have requirement
  identifiers!
• Then for each language or browser, that whole
  list of requirements needs to be fulfilled (and
  tested!)
• Each specific language or browser is a
  requirement, which cites the list of other
  requirements

30
Requirements Review Report

• The Requirements Review Report is used to conduct
  a formal review of the SRS
• It should be completed after the SRS is first
  written, and each time the SRS is updated for
  each cycle
• The Requirements Review Report also provides a
  place to address controversial issues related to
  system requirements
• Similarly, the Schedule Update is used to
  identify a change in the projected schedule

31
Test Specification

• The test specification describes the testing
  approach for your system
• It is requirements-based, so make sure each
  requirement in the SRS has an identifier and
  brief name
• Most of the test spec should map to the SRS
  sections 3.2 and 3.3 your detailed
  requirements!
• The Actual Results section is blank when the
  specification is first written
• Its filled in after actual testing occurs

32
Test Specification

• In writing test cases, include both positive and
  negative test cases
• Positive cases test for correct functionality
• Can include tests for extreme values, unusual
  inputs, and typical boring inputs
• Negative cases test for handling errors
• Including missing required input fields, files or
  data sources not available, incorrect or
  impossible combinations of inputs, etc.

33
Test Specification Updates

• Naturally, the scope of the Test Specification
  will grow with each cycle as test scripts are
  added for new functionality
• Non-functional requirement testing should start
  with the first cycle (if feasible), and be
  repeated with each new cycle to show that system
  performance hasnt been degraded
• Similarly, regression testing should be done to
  prove earlier cycles functionality wasnt broken
  by new development

34
Design Specification (SDS)

• The Software Design Specification (SDS) is the
  most variable in content
• See IEEE 1016 for guidance
• Depending on your design approach, your design
  documentation might include
• Context diagram
• ERD and DFD (remember INFO 200?)
• Screen flow diagram
• Various UML diagrams (INFO 355)
• Class, sequence, package, etc. diagrams

35
Design Specification (SDS)

• Input and output prototypes arent needed in the
  SDS, since implementation will show the actual
  interface
• Note that there is a high level design section
  (architectural design) and detailed design
  section
• The former should show system-wide diagrams, and
  the latter specific diagrams for a given
  subsystem or use case

36
Design Specification (SDS)

• More specifically, the high level design might be
  shown with one or more of
• A context diagram
• A schematic of the systems architecture
• A conceptual class diagram (rarely used)
• A package or deployment diagram (from UML)
• The static structure of the system is typically
  shown using
• A detailed class diagram, and/or
• An entity-relationship diagram (ERD)

37
Design Specification (SDS)

• The key processes or functions of the system can
  be shown with
• A sequence or communication diagram (be sure to
  indicate which use case it pertains to!)
• Hence youll need a different sequence diagram
  for each significant process
• A data flow diagram (generally one diagram for
  the whole system, though more detailed diagrams
  can be done for each process)

38
Class Diagrams

• Class diagrams should show
• For each association a label (verb phrase),
  multiplicity, directionality (if not
  bidirectional)
• For each class the class name, attributes,
  methods (except the conceptual class diagram)
• Do not need to show data types for attributes
• All three types of classes should be shown for
  the detailed class diagram interface, control,
  and data classes
• Class and method names should be consistent
  between class diagram and sequence diagrams

39
Design Specification (SDS)

• Package and deployment diagrams should follow UML
  diagram conventions
• ERDs should show
• Entities should include entity name and fields
  (attributes)
• Do not need to show data types for fields
• Relationships should show verb phrases (in one
  direction is fine) and cardinality
• Scope of entities and classes should cover the
  systems functional requirements

40
Sequence Diagrams

• Sequence diagrams should show
• Object names, consistent with the class diagram
• Interface objects can be used to represent
  external systems or hardware devices
• Actors are optional but recommended
• If not used, messages should appear from a
  vertical line where the actor would appear
• Methods are implemented by the target object
• Hence methods cant point to a human actor
• Instead, point to the interface object currently
  visible

41
Sequence Diagrams

• See my summary of UML diagrams for other advice
  on generating sequence diagrams, and writing the
  use case descriptions (e.g. main success scenario
  and extensions) that inspire them

42
Design Specification (SDS) Updates

• As each cycle occurs, the design documentation
  should be updated to reflect additional entities,
  classes, screens, etc. that have been added to
  the system
• Or you could use color on the diagrams to
  indicate which portions have been implemented,
  and which are planned for future cycles

43
CONSISTENCY

• Key for excellent system documentation is
  consistency across the documents
• The schedule should be consistent with the sets
  of requirements to be implemented
• The design should address the requirements
• The design should be internally consistent e.g
  class names, use case names, etc.
• The code should match the design (e.g. class
  names and methods in design should match actual
  classes implemented)

44
Customer Documentation

• A template is provided for customer documentation
• It typically has Installation, Use, and
  Maintenance sections
• On larger projects these are often separate
  documents
• This isnt used until cycle 3, but you can
  consider how it will be used
• Outlining draft customer docs can help identify
  gaps in requirements

45
References

• Written reports should cite references to
  identify the sources of information
• Use a recognized format, such as APA
• In the body of your report, may use numbered
  brackets 3 to cite each reference, then give
  the full citation in a References section of the
  report
• 3 Shaller, G. B. (1993). The last panda.
  Chicago University of Chicago Press.

46
References

• A different acceptable approach is to give author
  and date in parentheses (Shaller, 1993) to cite
  each reference, then give the full citation later
• (Shaller, 1993) Shaller, G. B. (1993). The last
  panda. Chicago University of Chicago Press.
• Multiple references by one author in one year can
  add letters after the date (Shaller, 1993a),
  (Shaller, 1993b)
• Just use one approach 3 or the other (Shaller,
  1993) consistently!

47
References

• A great resource for formatting references is
  from Purdue
• http//owl.english.purdue.edu/owl/resource/560/01/
  
• Where possible, use peer-reviewed journals or
  books as sources
• Dont use Wikipedia, answers.com, etc.!
• Use a variety of sources, i.e. dont keep citing
  one source for everything
• Cite similar existing systems which inspired your
  design

48
WIT

• This is a Writing Intensive Course
• A WIT has been assigned, as described in the
  syllabus
• Both written assignments MUST BE REVIEWED BY A
  WIT before you can turn them in
• Hence you have to have a draft ready for WIT
  review well before the assignment deadline
• Turn in the WITs review sheet with the assignment

49
Oral Presentations
50
Oral Presentations

• There are two types of oral presentations
  expected
• Launch Report, SRS Test Specification
• Cycle Demonstration Design
• The syllabus has guidance on how the
  presentations are evaluated
• PRACTICE getting your voice loud, slow, and clear
  enough to be understood from far away
• Its okay to use crib notes, but dont sound
  like youre reading them for the first time

51
Oral Presentations

• The main challenge in preparing the oral
  presentations is to select the right information
  to present
• There isnt enough time (and it would be really
  boring) to cover everything in your written
  material, so you need to select the most relevant
  points
• Thats part of your challenge what is most
  important to convey to the audience?

52
Oral Presentations

• Make sure the slides visually reinforce the key
  points, in addition to what the speaker adds to
  them
• Think of the slides as an outline to remind the
  speakers what to discuss next
• Keep slides to about 6 bullet points or less, and
  never use font smaller than 20 points in the body
  (this is 28 pt Verdana, whereas this is 20 pt)
  (16 point is almost invisible)

53
Cycle Demonstrations

• The cycle demonstrations are the grade for your
  development work, so plan them carefully
• Teams typically give a PowerPoint overview of
  the system design and interface, then walk
  through typical activities using the real system
• Keep in mind that IST screen resolution is
  typically only 800x600 pixels, so dont hardwire
  screens to a larger resolution!

54
Mutual Evaluation

• With group projects comes the inevitable
  complaints about X didnt do their part
• To address that issue fairly, mutual evaluations
  will be filled out twice
• Evaluate everyone in your group, including
  yourself, and email the evaluation form to me
  (gbooker_at_drexel.edu)
• If you dont play nicely, your final grade may
  differ from the rest of your group!
• If youre wonderful, you may do better than your
  group

55
Senior Design Challenge

• Keep in mind that youre eligible for the next
  Senior Design Challenge do you want your
  project to be THAT good?
• See the examples on the walls of the second floor
  of Rush
• Can you do better?