ANU COMP2110 Software Design lec 03: Requirements part 1 1/23 COMP2110/2510/6444 Software Design in 2006 module 1: 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. the course Assessment Scheme
26
Embed
COMP2110 Software Design in 2006courses.cecs.anu.edu.au › ... › lec03 › lec03-06.pdf · lec 03: Requirements part 1 7/23 Requirements – a short example part of the specifications
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
● 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 3/23
Implementation
Process vs Product in 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.
Product a SRS document describing information models
SoftwareRequirementsSpecification
Retirement
ANU COMP2110 Software Design
lec 03: Requirements part 1 4/23
The Process: Software Product Life Cycle
Software Product Life Cycle
RequirementsSpecification
Design
Implementation
Testing
Maintenancefrom Foxfig 1-3-2
Engineering Design
Product Design
Product Redesignand EngineeringRedesign
ANU COMP2110 Software Design
lec 03: Requirements part 1 5/23
Software Product Design
Software Product Design
Analyze ProductDesign Problem
Resolve ProductDesign Problem
RequirementsSpecification
Project MissionStatement
SoftwareRequirementsSpecificationfrom Fox
fig 4-0-1
an activityor process
a documentor product
Project MissionStatement
SoftwareRequirementsSpecification
ANU COMP2110 Software Design
lec 03: Requirements part 1 6/23
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 7/23
Requirements – a short examplepart of the specifications of An Assets Tracking System
Adding computers as tracked assets
1. The assets tracking system must allow staff to add computers to the tracking set.
1.1 when a computer is added to the tracking set, the system must require the staff member to provide type data for the added computer.
1.1.1 A computer’s type data must be text of length greater than 0 and less than 512 characters
1.2 When a computer is added to the tracking set, the system must require the staff member to provide description data for the added computer. ...
1.3 The tracking system must respond to added computer input with a unique serial number identifying the computer in the tracking system.
[adapted from Fox fig 5-2-2]
ANU COMP2110 Software Design
lec 03: Requirements part 1 8/23
Stating requirements – the desirable qualities
● the set of requirements is complete, unambiguous● statements are clearly stated in active voice
preferably using the words “must” or “shall”● consistent use of well-defined terms● grouped into meaningful sections● statements are numbered for tracing through the process● statements are “atomized” – short statements, each about
one small thing● requirements are verifiable – can be tested, or measured, or
objectively determined to be true or not, in the product
ANU COMP2110 Software Design
lec 03: Requirements part 1 9/23
Stating requirements – the desirable qualities(2)
● complete,unambiguous
● active voice● consistent,
defined terms● grouped in
sections● traceable● atomized
Adding computers as tracked assets
1. The assets tracking system must allow staff to add computers to the tracking set. ...
1.2 When a computer is added to the tracking set, the system must require the staff member to provide description data for the added computer.
1.2.1 A computer’s description data must be text of length greater than 0 and less than 512 characters
ANU COMP2110 Software Design
lec 03: Requirements part 1 10/23
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 it is, at first look– it depends on where the house and kennel are sited– it depends on owner’s use of or relationship with dog
Example: The kennel or dog house
ANU COMP2110 Software Design
lec 03: Requirements part 1 11/23
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
ANU COMP2110 Software Design
lec 03: Requirements part 1 12/23
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 – not grouped– can be managed easily without numbering, because
there are very few requirements listed
How can we gather the full set of requirements?
How can we improve these requirements specifications? (resolve and finalize)
We may return to the doghouse later.
ANU COMP2110 Software Design
lec 03: Requirements part 1 13/23
The Multiple Alarm Clock
A simplerapplication program example
(now run the demo, Chris)
ANU COMP2110 Software Design
lec 03: Requirements part 1 14/23
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 in may cases.
Option 2: elicit requirements from client
ANU COMP2110 Software Design
lec 03: Requirements part 1 15/23
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
ANU COMP2110 Software Design
lec 03: Requirements part 1 16/23
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.
ANU COMP2110 Software Design
lec 03: Requirements part 1 17/23
Alarm Clock requirements v0 - critique (2)
● uses imprecise vocabulary - no control of use of nouns, verbs– what choices of display? what is the “time”? “hog”?
– emulate which “simple alarm clock”? how exactly?
● it is incomplete
● there are no identifying labels –– statements will be hard to trace through the design
● 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?
ANU COMP2110 Software Design
lec 03: Requirements part 1 18/23
Specifying requirements: guide to a good SRS (0)
A good SRS is
1. unambiguous
2. complete
3. verifiable
4. consistent
5. modifiable
6. traceable
See:(1) textbook Fox chapter 5
(2) Comp2110 Guidelines for Software Requirements documentsin the website resources directory.Access schedule page, lecture 3.
ANU COMP2110 Software Design
lec 03: Requirements part 1 19/23
Specifying requirements: guide to a good SRS (1)
A good SRS is
1. unambiguoususes single unique term for each thing it describes
2. complete– includes all significant requirements,– all responses to all inputs in all situations,– full labelling and referencing of constituent figures,
tables, and diagrams
3. verifiable
4. consistent
5. modifiable
6. traceable
ANU COMP2110 Software Design
lec 03: Requirements part 1 20/23
Specifying requirements: guide to a good SRS (2)
A good SRS is1. unambiguous2. 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
ANU COMP2110 Software Design
lec 03: Requirements part 1 21/23
Specifying requirements: guide to a good SRS (3)A good SRS is: 1. unambiguous... 2. complete... 3. verifiable...
4. consistentNo subset of the individual requirements is in conflict.The requirements do not:– use different terms for the same real world thing – have any conflicting requirements of input or output
objects– have any logical or temporal conflict between
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, is named or numbered to allow tracing in any following documents (Design & Testing docs)
ANU COMP2110 Software Design
lec 03: Requirements part 1 23/23
Improved AClock SRS: 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 24/23
AClock version 1(b) Functional requirements
1 Functional requirements
1.0 The clock shall have a display.
1.1 The user shall be able to choose digital display or analogue display.
1.2 The user shall be able to choose whether 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
1.8 The default starting alarm setting is: no alarms set.
ANU COMP2110 Software Design
lec 03: Requirements part 1 25/23
AClock version 1(c) Interface & performance requirements
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