COMP2110 Software Design in 2003

Document Sample
COMP2110 Software Design in 2003 Powered By Docstoc
					         COMP2110 Software Design in 2004

                Requirements Specifications
                          lecture 3 - lecture 1 of 3

1. requirements // design // implementation
2. the hand-waving example of a dog house
3. the more realistic example of the Alarm Clock
4. course Assessment Scheme




ANU COMP2110 Software Design                 lec 03: Requirements part 1   1/16
recap What's in the course? comp2110 components
●   core content
     –   methods for designing software for a given purpose
     –   technical "design ideas" to use
          ●   at high level & at detailed level
     –   specifications of requirements for software
●   supporting concepts
     –   notational methods for describing software design
     –   notations for specification of requirements
     –   software lifecycle framework
     –   "quality" – what makes it a good design (or not)

ANU COMP2110 Software Design                      lec 03: Requirements part 1   2/16
                                   The Waterfall Software Process

                                              Processes
                                              -gathering requirements                                             Product
                                              -verifying requirements                                             a SRS document
        Requirements                                                                                              describing information
          Analysis                                                                                                models
                                                                                                                             Software
                                                                                                                             Requirements
                                                    Design
                                                                                                                             Specification
         Phases (activities)                                                Implementation
                                                                                                                    Testing
                                                                                                                                Maintenance
                                                                                                                                      Retirement

         ANU COMP2110 Software Design                                                                     lec 03: Requirements part 1   3/16   time
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
                       Requirements Analysis

 Requirements analysis: the process of
   understanding what is needed or wanted, and
   expressing the results in writing
 Challenges!
 ● express requirements in ordinary, clear English


 ● organise the requirements statements into logical

   groupings
 ● arrange for the management of the requirements


                               Adapted from Braude Software Design with permission


ANU COMP2110 Software Design                       lec 03: Requirements part 1   4/16
            Example: The kennel or dog house

 Inception: the starting idea
    the client wants a kennel
      – a dog house
 We want to provide a high quality doghouse-
    one that is fit for its purpose
 the “purpose” may not be quite what the client or
   the designer thinks at first look
       –   depends on where the house and kennel are
       –   depends on owner’s use of or relationship with dog



ANU COMP2110 Software Design            lec 03: Requirements part 1   5/16
           The dog house: what requirements?
 The kennel must
      –   keep the dog alive in freezing Canberra winter or
          dry and cool in Brisbane
      –   provide satisfactory (to owner) level of dog happiness
      –   anchor the dog to the home base -
          to provide security and visitor announcement services
      –   have good enough appearance to satisfy owner’s
          family, and increase or maintain house property value
      –   be easy for the owner to keep clean, remove fleas etc
      –   be “right size” for the number and size of dogs
      –   be maintainable: materials should need attention no
          more than once in 3 years in the intended location
ANU COMP2110 Software Design            lec 03: Requirements part 1   6/16
                      Dog house requirements


 These requirement statements are
      –   not expressed well: too broad and too vague to enable
          us to create a design
      –   not logically organised
      –   can be managed easily because there are very few
          requirements listed
 How can we gather the full set of requirements?



ANU COMP2110 Software Design           lec 03: Requirements part 1   7/16
                    The Multiple Alarm Clock


 A simpler
  application program
  example




       (now run the demo,
              Chris)

ANU COMP2110 Software Design        lec 03: Requirements part 1   8/16
          Gathering requirements: Alarm Clock
Option 1:
 Make me one just like that!
  The analyst must
  – discover all of the functions
  – reverse engineer the
    requirements from the
    functions of the thing

                                This is not easy to do.
                 ON             This is probably not what the client
                                actually wants.

       19 : 50 : 03        Option 2: elicit requirements from the client
 ANU COMP2110 Software Design                    lec 03: Requirements part 1   9/16
                     Alarm Clock Requirements                                                  ON
                             version 0
Title
  AClock Software Requirements Specifications, version 0                           19 : 50 : 03
Author                                              Date
  Chris Johnson, Dept of Computer Science, ANU        Thursday 24 July 2003

         Requirements
         •The alarm clock application emulates a simple alarm clock
         in an on-screen window.
         •The clock's timing is accurate,
         as far as a standalone computer's operating system allows.
         •The user has a choice of how the clock displays the time,
         and you can set more than one alarm.
         •It will not hog the CPU.

User characteristics
We don't really need to say this, but: the user is assumed to know how to use a computer.

  ANU COMP2110 Software Design                       lec 03: Requirements part 1       10/16
         Alarm Clock requirements v0 - critique
        •The alarm clock application emulates a simple alarm clock
        in an on-screen window.
        •The clock's timing is accurate,
        as far as a standalone computer's operating system allows.
        •The user has a choice of how the clock displays the time,
        and you can set more than one alarm.
        •It will not hog the CPU.
What’s good about this requirements specification?
   –   some of the requirements are made in separate statements
   –   the requirements state “what” the product must do in terms of
       an information model of the real world,
       not “how” a program might do it
This is one of the hardest things for programmers to learn
         when gathering and writing requirements.
  ANU COMP2110 Software Design                  lec 03: Requirements part 1   11/16
       Alarm Clock requirements v0 - critique (2)
             •The alarm clock application emulates a simple alarm clock
             in an on-screen window.
             •The clock's timing is accurate,         What’s wrong with this?
             as far as a standalone computer's operating system allows.
             •The user has a choice of how the clock displays the time,
             and you can set more than one alarm.
             •It will not hog the CPU.
●    imprecise vocabulary - no control of nouns, verbs
       –   what choices of display? what is the “time”? “hog”?
       –   emulate which “simple alarm clock”? how exactly?
●    there are no identifying labels –
       –   statements will be hard to trace
●    these are all imprecise statements - all hard to verify
       –   nothing stated here can be verified by a specific test of the software

    ANU COMP2110 Software Design                       lec 03: Requirements part 1   12/16
Specifying requirements: guide to a good SRS (1)
  A good SRS is
     1. unambiguous
     uses single unique term for each characteristic
     2. complete
      includes all significant requirements, responses to
     all inputs in all situations, full labelling and
     referencing of constituent figures, tables, diagrams
          3. verifiable
          4. consistent
          5. modifiable
                                See: Comp2110 Guidelines for
                                Software Requirements documents
          6. traceable

                                in the website resources directory
 ANU COMP2110 Software Design                lec 03: Requirements part 1   13/16
Specifying requirements: guide to a good SRS (2)
  A good SRS is
       1. unambiguous
       2. complete

  3. verifiable
    every requirement is capable of being
    verified in the product, by some cost-effective
    process of checking (testing etc)
     4. consistent
     5. modifiable
     6. traceable

 ANU COMP2110 Software Design   lec 03: Requirements part 1   14/16
Specifying requirements: guide to a good SRS (3)
  A good SRS is: 1. unambiguous... 2. complete... 3. verifiable...

    4. consistent
     No subset of the individual requirements is in
     conflict.
     They do not:
      – use different terms for the same real world object
      – have any conflicting requirements of input or output
        objects
      – have any logical or temporal conflict between
        actions
     5. modifiable
     6. traceable

 ANU COMP2110 Software Design          lec 03: Requirements part 1   15/16
Specifying requirements: guide to a good SRS (4)
  1. unambiguous... 2. complete... 3. verifiable... 4. consistent
  5. modifiable

     easy to read, careful structure and style, is coherent,
     organised, with no redundancy
     so newcomers understand it correctly, and changes do not
     need to be tracked to many places unnecessarily
     6. traceable

     the origin of each requirement is clear, can be traced
     to particular parts of any preceding document, are
     named or numbered to allow tracing in any following
     documents (Design & Testing docs)

 ANU COMP2110 Software Design           lec 03: Requirements part 1   16/16
Critically reading a requirements specification


 1. read the Encounter game specification –
    referenced from the course-plan
 http://cs.anu.edu.au/student/
    comp2110/course-plan.html
 1. share your opinions of good and bad points,
    suggest improvements, listen to other points of
    view
    in tutorials week 2
                Are you registered in Streams?

ANU COMP2110 Software Design       lec 03: Requirements part 1   17/16
               AClock version 1: (a) define terms
         Glossary: Definitions, acronyms and abbreviations

clock a device that has its own value of time in hours, minutes and
seconds, which it displays and which it maintains accurately relative to
when the time was last reset.
   In this document, a "conventional clock" means such a clockwork or
electric device in the real world;
"clock" means a computer operating system function that returns at
least an absolute or elapsed time as measured by the operating
system.
clock time the time relative to the last resetting of the clock.
analogue display
   a graphic that shows a traditional clock face, with short and long
(and thinner long) radial lines for hands positioned to show the hours
and minutes (and seconds).
   ANU COMP2110 Software Design            lec 03: Requirements part 1   18/16
      AClock version 1: (b) functional requirements
1 Functional requirements

1.1    The user shall be able to choose digital display or analogue display.
1.2 The user shall be able to choose to include seconds in the display, and to
choose between 12 or 24 hour display.
1.3    The user shall be able to set the time of the clock to any value.
1.4 The clock shall allow the user to set multiple alarms as one-off or repeating
every 24 hours.
1.5 The alarm shall sound for a period of 40 seconds when the alarm time is
reached, until the user cancels the alarm.
1.6    The user shall be able to inspect and modify the collection of alarm settings.
1.7 The default starting display mode shall be 12 hour digital with seconds, with no
alarms set.



      ANU COMP2110 Software Design                   lec 03: Requirements part 1   19/16
 AClock version 1: (c) interface and performance
2 External interface requirements
EI 2.1 The alarm clock shall use a single window for the display,
with a menu for commands which shall pop up a dialog box with buttons for
selecting modes.


3 Performance requirements
P 3.1 The alarm clock shall maintain its time accurate to within one second of
the operating system clock.
P 3.2 The alarm clock application shall consume less than 1% of the CPU on
any Linux system on a Pentium-family processor of better than 50MHz CPU.
P 3.3 The alarm clock application shall require less than 30MB of memory while
executing on a 32 bit Pentium-style processor under Linux.

                                 See: Alarm Clock SRS versions 0, 1, and 2
                                 in the website resources directory
  ANU COMP2110 Software Design                   lec 03: Requirements part 1   20/16
              Assessment scheme (summary) (1)
1. Assignment component: 2 assignments (total 50%)
2. Tutorial preparation and participation 5%
3. Final examination 45%
Assignments
    1. Minor assignment: written, 10% due 9 am Monday 9 August (before week 4)
       topic area: Requirements
     2. Major assignment: in 2 parts
       topic area: improved requirements and draft design of a given project

          1. (in small groups (3 people)) short presentation and written report 10%
   A joint report and the text of the presentation due 5pm Sunday 29 August (before week 7)
   Presentations will be made by the group in their registered lab class session of
   week 7 (week starting 30 August)

         2. (individual) written final design and critique 30%
           report due 6pm Friday 24 October (end of week 12)

   ANU COMP2110 Software Design                           lec 03: Requirements part 1   21/16
           Assessment scheme (summary) (2)
1. Assignment component: 2 assignments (total 50%)
       2. Tutorial preparation and participation 5%         3. Final examination 45%

Final course mark
will be the sum of the components, capped to be no more than 10 percentage points
    greater than the relative percentage scored in the smaller of the exam component or
    the assignments total.

Late penalties
Written assignment reports will be accepted up to 5 days (120 hours) after the due date -
   except the text of slides for the short presentation will not be accepted late without
   specific permission.
Each additional day past the due date will reduce the value of the mark awarded by a
   further 10 percent
   (10% reduction for 1 day late, 20% for 2 days etc.)

Extensions only for illness (medical certificate), personal or family emergencies, etc.




ANU COMP2110 Software Design                          lec 03: Requirements part 1   22/16

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:0
posted:4/11/2013
language:English
pages:22