anu comp2110 software designlec 03: requirements part 1 1/16 comp2110 software design in 2004...

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

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


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)


Implementation

The Waterfall Software Process

time

RequirementsAnalysis

Design

Phases (activities)Testing

Maintenance

Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Processes-gathering requirements-verifying requirements

Product a SRS document describing information models

Software

Requirements

Specification

Retirement


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


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

Example: The kennel or dog house


The dog house: what requirements?The kennel must

– keep the dog alive in freezing Canberra winter ordry 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


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?


The Multiple Alarm Clock

A simplerapplication program example

(now run the demo, Chris)


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

ON

19 : 50 : 03

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

Option 2: elicit requirements from the client


Alarm Clock Requirementsversion 0

Requirements•The alarm clock application emulates a simple alarm clockin 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 characteristicsWe don't really need to say this, but: the user is assumed to know how to use a computer.

Title AClock Software Requirements Specifications, version 0Author Chris Johnson, Dept of Computer Science, ANU

Date Thursday 24 July 2003

ON

19 : 50 : 03


Alarm Clock requirements v0 - critique

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.

•The alarm clock application emulates a simple alarm clockin 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.


Alarm Clock requirements v0 - critique (2)

● 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

•The alarm clock application emulates a simple alarm clockin 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 wrong with this?


Specifying requirements: guide to a good SRS (1)

A good SRS is

1. unambiguoususes 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

6. traceable

See: Comp2110 Guidelines for Software Requirements documents

in the website resources directory



A good SRS is1. unambiguous

2. complete

3. verifiableevery requirement is capable of being verified in the product, by some cost-effective process of checking (testing etc)

4. consistent

5. modifiable

6. traceable



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



1. unambiguous... 2. complete... 3. verifiable... 4. consistent

5. modifiable

easy to read, careful structure and style, is coherent, organised, with no redundancyso 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)


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 viewin tutorials week 2

Are you registered in Streams?


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).


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.


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 2in the website resources directory


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 ofweek 7 (week starting 30 August)

2. (individual) written final design and critique 30%

report due 6pm Friday 24 October (end of week 12)


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 designlec 03: requirements part 1 1/16 comp2110 software design in 2004...

Documents