COMP2110 Software Design in 2004 lecture 4 Requirements...

ANU comp2110/250/6444 Software Design lecture 4 1

COMP2110/2510/6444 Software Design 2006 lecture 4 Requirements Specifications lecture 2 of 3Aim: Describe the Activity of Creating Software Requirements• introduction to example problems–

(1) the AquaLush System, (2) the Encounter game• the product/document: examples from the specification

document (SRS) – in lecture 3• the process/activity: first steps towards the process of

1. discovering requirements2. organising and improving requirements

This lecture is an introduction.More examples will follow in the next lecture and in problem

class, tutorial classes, and assignments.

recap 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


The Software Requirements activitythe scheme for this lecture

• recap and expand the process• process steps

• description and discussion• examples


The Process: Generic Software Product Design

Analyze Product Design Problem

from Foxfig 4-1-1

Project MissionStatement

Elicit/Analyze Detailed Needs

Evaluate Candidate Reqs.

Engineering Design

Finalize Requirements

Select Requirements

Generate/Improve candidate reqs.

[complete]

[else][adequate]

[else]

SRS

reworkdefectsfound by inspection- not shownin Fox


The Software Requirements Specification SRS

The product of the Analysis and Requirements process is a well-defined information model:• a set of labelled, organised requirements statements:

• functional requirements for consumer and developer• system requirements• performance requirements (& other non-functional

requirements)• a set of use cases or scenarios

that capture and express the relationships between the model and the real world of the problem

• other explanatory models:• user interfaces, states, decision, etc as needed


A Case Study of AquaLush: Overview (1)AquaLush is the large case study example in Fox.

The AquaLush software system controls water valves in a home garden irrigation system. It has inputs from a clock, user control interface, and soil sensors.

Background: The AquaLush company wishes to produce a computer-based controller for home irrigation systems, to control the small sprinkler, drip and spray units that water the gardens around the house. The system is designed to work with a timer and with soil moisture sensors to make most effective use of the limited quantity of water available.

The system allows the user to restrict water flows to keep within the legal restrictions (times and days).For example: under stage 3 restrictions in Canberra, odd-numbered houses can water gardens only on odd-numbered dates.

AquaLush also allows the user to specify a maximum moisture level target using sensors buried in the soil.

The user needs the system to operate correctly, because applying large quantities of water (overwatering) may kill garden plants and cost money for penalty water use charges. Applying too little water (underwatering) will kill plants. – so AquaLush company has financial risks as well.

See Appendix B in Fox for another more detailed overview, and a mission statement, user-level requirements, software requirements, conceptual model, software architecure – and detailed design.

www.gardenirrigation.gr/main_uk.htm

http://www.gardenirrigation.gr/main_uk.htm


A Case Study of the Encounter game

The Encounter game [Braude] is• a computer based role playing game which simulates all

or part of the lifetime of the player’s character• includes characters not under player’s

control, called foreign characters• all characters have a number of qualities:

strength, speed, patience etc.• each quality has a numeric value• the game is played over a map of

areas (rooms)• characters engage each other when they

are in the same area• the result of an engagement depends on the area and the

values of the qualities of the two characters• success is measured by the player’s character living as

long as possible, with accumulated points.


Preliminaries: the problem statement

• operational concept – mission statement• vision, scope, target market• identify stakeholders• assumptions and constraints• business requirements => IT Governance


Analyze the problem => problem statement

• write a project mission statement including product vision and scope, stakeholders, markets, assumptions, business requirements see Fox p. 99

Pr od uc t v is ion s t a t em ent : Th e Aqu a Lu s h Ir r iga t ion Sys tem will u s e s oil m ois tu re s en s ors to con trol ir r iga t ion , th u s s a vin g m on ey for cu s tom ers a n d m a k in g b et ter u s e of wa ter res ou rces .

Ma jor fea t ur es : Aqu a Lu s h will•m on itor wa ter u s a ge a n d lim it u s a ge to a m ou n ts s et b y u s ers•a llow u s ers to s p ecify t im es wh en ir r iga t ion occu rs•b e op era ted from a s im p le cen tra l con trol p a n el•h a ve a Web -b a s ed s im u la tor

Pr ojec t s cop e : th e p roject will cr ea te th e m in im a l h a rd wa re a n d s oftwa re n eces s a ry to field a via b le p rod u ct , a lon g with a Web -b a s ed s im u la tor for m a rk etin g th e p rod u ct . Fo x Appe ndix B.2 s e c t io n 2 , p.6 1 0


Elicit Detailed needs

• not part of this course

• get details... from the stakeholders• who are they?

• There are many techniques to get information system user-level requirements from non-computing people• Business Analysts do this• taught in INFS courses, by School of

Acounting and Business Information Systems, ANU CoBE


Generate and improve candidaterequirements

• creativity!and management, quality control

• many methods exist to generate• use cases – see next few pages• competing or alternative or similar products• brainstorming and refinement• props and metaphors• modelling – see COMP3110

• danger: it is easy to miss somerequirements


Use cases (1)

What?• A use case is a description of one type of complete

interaction between a product and its environment.• described by

• use case diagrams• use case detailed descriptions

Why?• use cases capture knowledge about situations• generalisations of scenarios• focus the minds of designers and clients on intended

usage and interactions with externals

• only a brief introduction in this course - see Fox Chapter 6 for more description


Use cases (2)

• A use case is concerned with one coherent interaction, e.g.• getting an account balance from an ATM• setting a new start time for irrigation• encountering (engaging) another game character

• The product’s environment is mainly seen as consisting of actors.

• An actor is a type of external agent that interacts with the product: e.g. people, other computer systems• for AquaLush: the actors include

valve, sensor, operator, maintainer, simulation user


Use cases (3)

• one use case is a sequence of actions, each by one actor or the software product, with few conditions.

• use cases are not pseudocode


Use cases (4) - AquaLush use cases

1. Toggle irrigation

2. Set irrigation parameters

3. Manually control irrigation4. Make repairs

5. Report failure

6. Start up

7. Irrigate

8. Simulate AquaLush


Use cases (5) - AquaLush use case example

1. Set irrigation parametersTrigger: Operator sets automatic irrigation parameters.Basic Flow

1. operator sets the irrigation time, water allocation, or critical moisture levels

2. AquaLush validates the new settings3. AquaLush records and confirms the new settings

Fox has a longer description: stakeholders, pre- and post-conditions, and extensions of the description (3 times as big as the basic flow)


2. Player requests a window for setting his character’s qualities.

(improved cwj)


Encounter: Engage Foreign Character Use Case

Encounter

player

1. System displays the foreign character in the same area as the player’s character.2. System exchanges data between characters to determine result of the engagement.3. System displays the results of the engagement in a message window. 4. Player dismisses window.

Initialize

. . . .

Engageforeign

character

Name of use case

Details of use case

Actor (agency external to the application)

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.


Evaluate and select requirements

• use the quality criteria:• complete, unambiguous• active voice• consistent, all terms defined• grouped in sections• traceable• atomized

• also look for feasibility,simplicity, power, common sense,stakeholder interests

• go round again! improve, evaluate, improve...


Finalize requirements

• collect and organize• logical groupings – not always obvious or easy

• validate: no testing is possible on requirements: need human checks and reviews• do desk checks, formal reviews• inspection – see description in Fox p.136

• create rough low fidelity prototypesbeware of the clients!

• revise (rework) to remove any defects that are found


The Process: Generic Software Product Design

Analyze Product Design Problem

from Foxfig 4-1-1

Project MissionStatement

Elicit/Analyze Detailed Needs

Evaluate Candidate Reqs.

Engineering Design

Finalize Requirements

Select Requirements

Generate/Improve candidate reqs.

[complete]

[else][adequate]

[else]

SRS

reworkdefectsfound by inspection- not shownin Fox

internalreviewsand revision


Sources (1) Case Study of specification & design for the AquaLush controller

Christopher Fox, Introduction to Software Engineering Design, Addison Wesley 2007 (the textbook)Appendix B


Sources (2) Case Study of specification & design for the Encounter game

The Specification of the Encounter video game is described in Braude, Software Design.The specification document is available online.It comes in 2 parts: http://cs.anu.edu.au/student/comp2110/resources/ Encounter-SRS/EncounterSRS-1.htmland ...

EncounterSRS-2.html

COMP2110 Software Design in 2004 lecture 4 Requirements...

Documents

Transcript of COMP2110 Software Design in 2004 lecture 4 Requirements...