Requirements Specifications 2/3 -...

Requirements Specifications 2/3

Comp2110Software DesignComp2510Software Design for Software Engineers30 July 2008

Srinivas Chemboli

Department of Computer Science

ANU College of Engineering and Computer Science

The Australian National University

[email protected]

In This Session...

Describe the activity of creating Software Requirements Introduction to example problems

• The AquaLush system• The Encounter game

The product / document : examples from the specification document (SRS)

The process / activity : first steps towards the process of• Discovering requirements• Organizing and improving requirements

© Chris Johnson 2007

The Process: Software Product Life Cycle

Software Product Life Cycle

RequirementsSpecification

Design

Implementation

Testing

Maintenance

Engineering Design

Product Design

Product Redesignand EngineeringRedesign

from Foxfig 1-3-2

© Chris Johnson 2007 © Chris Johnson 2007

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




from Foxfig 4-1-1




Engineering Design


Select Requirements


[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 labeled, organized 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: OverviewAquaLush 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

Product vision statement: The AquaLush Irrigation System will use soil moisture sensors to control irrigation, thus saving money for customers and making better use of water resources.

Major features: AquaLush will•monitor water usage and limit usage to amounts set by users•allow users to specify times when irrigation occurs•be operated from a simple central control panel•have a Web-based simulator

Project scope: the project will create the minimal hardware and software necessary to field a viable product, along with a Web-based simulator for marketing the product. Fox Appendix B.2 section 2, p.610


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 [c.f. COMP8100], taught in

courses in 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• modeling – 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 generalizations 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 irrigation

4. Make repairs

5. Report failure

6. Start up

7. Irrigate

8. Simulate AquaLush


Use cases (4) - AquaLush use cases

1. Toggle irrigation

2. Set irrigation parameters3. Manually control irrigation

4. Make repairs

5. Report failure

6. Start up

7. Irrigate

8. Simulate AquaLush


Use cases (5) - AquaLush use case example

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


Initialize Use Case for Encounter


(improved cwj)

Encounter: Engage Foreign Character Use Case

© Srinivas Chemboli 2008

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




from Foxfig 4-1-1




Engineering Design


Select Requirements


[complete]

[else][adequate]

[else]

SRS




from Foxfig 4-1-1




Engineering Design


Select Requirements


[complete]

[else][adequate]

[else]

SRS



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

and ...http://cs.anu.edu.au/student/comp2110/resources/Encounter-

SRS/EncounterSRS-2.html


Summary

Creating Software Requirements Introduction to example problems

• The AquaLush system• The Encounter game

The product / document : examples from the specification document (SRS)

The process / activity : first steps towards the process of• Discovering requirements• Organizing and improving requirements



Next... In

Software Design 2110/2510

Specifying Requirements 3/3Information Models

Requirements Specifications 2/3 -...

Documents

Transcript of Requirements Specifications 2/3 -...