1 cs 501 spring 2007 cs 501: software engineering lecture 10 requirements 4

32
1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 10 Requirements 4

Post on 21-Dec-2015

218 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 10 Requirements 4

1 CS 501 Spring 2007

CS 501: Software Engineering

Lecture 10

Requirements 4

Page 2: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 10 Requirements 4

2 CS 501 Spring 2007

Course Administration

Assignment 2, First Milestone, March 6-8

Read information on the Assignments Web page

Reserve time for your presentation. See the home page of the Web site.

i Client must be present

ii Not all team members must be present, but each team member must make a presentation at least once

during the semester

iii Try to find a time when the TA can be present

Page 3: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 10 Requirements 4

3 CS 501 Spring 2007

Planning for the Presentation

How will you use the time?

This is a presentation to the client, with the instructor as a secondary audience. Possible topics:

• Overview of project and progress against plan.

• Presentation of assumptions, decisions.

• Summary of requirements in moderate detail.

• What has been learned since feasibility study? Changes in plans.

Allow 15 minutes for questions. Expect interruptions.

"This is our understanding of your requirements."

Page 4: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 10 Requirements 4

4 CS 501 Spring 2007

Planning for the Presentation

Logistics

Have a rehearsal, check visual aids and demonstrations. Then change nothing.

Check out the equipment in the meeting room. What network will you use (if any). How will you connect a computer (if you do)? What about firewalls?

Will one person act as chair and call on other members of the team?

Not everybody is a great presenter, but everybody can be well-prepared.

Page 5: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 10 Requirements 4

5 CS 501 Spring 2007

During the Presentation

• The presenter should stand. Other people should sit.

• Appoint a team member to take notes.

• The first presenter should introduce everybody.

• When asked a question:

-> If the presenter knows the answer, answer it.-> Or the presenter may ask another team member to answer.-> Otherwise make a note and reply later.

• Never interrupt your colleagues. If you have information to add, raise you hand and the presenter can decide whether to call on you.

Page 6: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 10 Requirements 4

6 CS 501 Spring 2007

Formal Specification

Why?

• Precise standard to define and validate software.

Why not?

• May be time consuming

• Methods are not suitable for all applications

Page 7: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 10 Requirements 4

7 CS 501 Spring 2007

Remember

Formal specification does not prescribe the implementation

With formal specification it is possible, at least theoretically, to generate code automatically from the specification, but this may not be the most effective way:

• Writing the generator may be a very large programming task.

• The resulting code may perform badly.

Formal specification does not guarantee correctness

• If the specification is wrong, the system will be wrong.

Page 8: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 10 Requirements 4

8 CS 501 Spring 2007

Specification using Mathematical Notation

Mathematical requirements can be specified formally.

Example: requirements for a linear programming package:

• Maximize c' x, subject to Ax <= b, x >= 0

But this is not complete.

Page 9: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 10 Requirements 4

9 CS 501 Spring 2007

Specification using Mathematical Notation (continued)

Example: requirements for a linear programming package:

• Maximize c' x, subject to Ax <= b, x >= 0

• Use the Revised Simplex algorithm as defined in <reference>.

• The error in the results must not exceed <specify>.

• The package must be able to handle up to <specify> non-zero elements in A, b, and c, in the range of values <specify>.

• The package must provide the following interfaces for data input and results <specify>.

• The package must be numerically stable on computer systems with the following properties <specify>.

Page 10: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 10 Requirements 4

10 CS 501 Spring 2007

Formal Specification Using Diagrams

digitunsigned integer

digit. E

+

-

unsigned integerunsigned integer

unsigned number

Example: Pascal number syntax

Page 11: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 10 Requirements 4

11 CS 501 Spring 2007

Formal Specification of Programming Languages

<unsigned number> ::= <unsigned integer> | <unsigned real>

<unsigned integer> ::= <digit> {<digit>}

<unsigned real> ::= <unsigned integer> . <digit> {<digit>} | <unsigned integer> . <digit> {<digit>} E <scale factor> | <unsigned integer> E <scale factor>

<scale factor> ::= <unsigned integer> | <sign> <unsigned integer>

<sign> ::= + | -

Example: Pascal number syntax

Page 12: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 10 Requirements 4

12 CS 501 Spring 2007

Formal Specification using Z ("Zed")

Z is a specification language developed by the Programming Research Group at Oxford University around 1980. Z is used for describing and modeling computing systems. It is based on axiomatic set theory and first order predicate logic.

Ben Potter, Jane Sinclair, David Till,

An Introduction to Formal Specification and Z

(Prentice Hall) 1991

Jonathan Jacky

The Way of Z

(Cambridge University Press) 1997

Page 13: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 10 Requirements 4

13 CS 501 Spring 2007

Informal: The function intrt(a) returns the largest integer whose square is less than or equal to a.

Formal (Z):

intrt: N N

a : N •

intrt(a) * intrt(a) < a < (intrt(a) + 1) * (intrt(a) + 1)

Example: Specification using Z

Page 14: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 10 Requirements 4

14 CS 501 Spring 2007

Example: Implementation of intrt

1 + 3 + 5 + ... (2n - 1) = n2

Static specification does not describe the design of the system.

A possible algorithm uses the mathematical identity:

Page 15: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 10 Requirements 4

15 CS 501 Spring 2007

Example: Program for intrt

int intrt (int a)/* Calculate integer square root */{ int i, term, sum; term = 1; sum = 1; for (i = 0; sum <= a; i++) { term = term + 2; sum = sum + term; } return i;}

Page 16: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 10 Requirements 4

16 CS 501 Spring 2007

Formal Specification of Finite State Machine Using Z

In the previous lecture, we discussed finite state machines as a convenient tool for clarifying requirements in discussions with clients.

A finite state machine can also be used as a method of formal specification. It may be the input into automatic program generation.

Page 17: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 10 Requirements 4

17 CS 501 Spring 2007

State Transition Diagram

Patients Fields Setup ReadyBeam

on

Enter Enter Start

Stop

Select field

Select patient(lock on)

(lock off)

Page 18: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 10 Requirements 4

18 CS 501 Spring 2007

State Transition Table

SelectPatient

SelectField

Enter lock off Start Stop lock on

Patients

Fields

Setup

Ready

Beamon

Fields

Fields

Fields

Patients

Patients

Patients

Setup

Setup

Setup

Ready

Beamon

Ready

Page 19: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 10 Requirements 4

19 CS 501 Spring 2007

Z Specification

STATE ::= patients | fields | setup | ready | beam_on

EVENT ::= select_patient | select_field | enter | start | stop | lock_off | lock_on

FSM == (STATE X EVENT) STATE

no_change, transitions, control : FSM

Continued on next slide

Page 20: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 10 Requirements 4

20 CS 501 Spring 2007

Z Specification (continued)

control = no_change transitions

no_change = { s : STATE; e : EVENT • (s, e) s }

transitions = { (patients, enter) fields,

(fields, select_patient) patients, (fields, enter) setup,

(setup, select_patient) patients, (setup, select_field) fields, (setup, lock_off) ready,

(ready, select_patient) patients, (ready, select_field) fields, (ready, start) beam_on, (ready, lock_on) setup,

(beam_on, stop) ready, (beam_on, lock_on) setup }

Page 21: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 10 Requirements 4

21 CS 501 Spring 2007

Schemas in Z

Schema:

• The basic unit of formal specification.

• Enables complex system to be specified as subsystems

• Describes admissible states and operations of a system.

Page 22: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 10 Requirements 4

22 CS 501 Spring 2007

Z in Practice

In carefully monitored industrial use, Z has been shown to improve the timeliness and accuracy of software development, yet it is not widely used in practice.

Complexity of notation makes communication with client difficult.

Few software developers are comfortable with the underlying axiomatic approach.

Heavy notation is awkward to manipulate with conventional tools, such as word processors.

Page 23: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 10 Requirements 4

23 CS 501 Spring 2007

Requirements for user interfaces

It is very difficult to specify and comprehend an interactive interface in a textual documents

• Requirement documents benefit from sketches, comparison with existing systems, etc.

• Design documents should definitely include graphical elements and often benefit from a mock-up or other form of prototype.

• Implementation plans should include evaluation of user factors and time to make changes.

User interfaces must be tested with users, with a willingness to change the requirements as the result of testing.

Page 24: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 10 Requirements 4

24 CS 501 Spring 2007

The Requirements/Design/Evaluate Loop

Evaluate

?Design

Build

Requirements

Page 25: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 10 Requirements 4

25 CS 501 Spring 2007

Tools for developing usability requirements and evaluation of usability

Initial Mock-up Prototype Production

Client's opinions

Competitive analysis

Expert opinion

Focus groups

Observing users

Measurements

Page 26: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 10 Requirements 4

26 CS 501 Spring 2007

Tools for developing usability requirements: Mock-up

Page 27: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 10 Requirements 4

27 CS 501 Spring 2007

Tools for developing usability requirements: Focus group

A focus group is a group interview

• Interviewer

• Potential users

Typically 5 to 12

Similar characteristics (e.g., same viewpoint)

• Structured set of questions

May show mock-ups

Group discussions

• Repeated with contrasting user groups

Page 28: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 10 Requirements 4

28 CS 501 Spring 2007

Usability:Accessibility requirements

Requirements about accessibility (e.g., support for users with disabilities) are most likely to arise in the user interface.

You may have a legal requirement to support people with disabilities.

Example of requirements specification:

The system must comply with Section 508 of the US Rehabilitation Act. See http://www.section508.gov/

Page 29: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 10 Requirements 4

29 CS 501 Spring 2007

Usability: Design Tensions in Networked Systems

• Client computers and network connections vary greatly in capacity

• Client software may run on various operating systems. It may be current or an earlier version. What assumptions do you make about the user's computer and Web browser?

• System designers wish to control client software, e.g., Web browsers; users wish to configure their own environments. This can be a factor in accessibility, e.g., which part of the system determines the font size.

Page 30: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 10 Requirements 4

30 CS 501 Spring 2007

Usability: Device-aware user interfaces

• Examples of devices:

desk-top computer, fast network connectionlaptop computer, intermittent connectivityPalmPilot, synchronizationsmart telephonedigital camera, camcorder

• Device-aware user interfaces are aware of:

=> performance of device=> limited form factor (display, keyboard)=> connectivity

Page 31: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 10 Requirements 4

31 CS 501 Spring 2007

Special Considerations: Computer systems and networks

The performance, reliability and predictability of computer systems and networks is crucial to usability

• Response timeinstantaneous for mouse tracking and echo of key stroke5 seconds for simple transactions

• Example: Pipelined algorithm for the Mercury page turner

• Quality of Service for real time information

Page 32: 1 CS 501 Spring 2007 CS 501: Software Engineering Lecture 10 Requirements 4

32 CS 501 Spring 2007

Special Considerations: Usability and Cost

• Good usability may be expensive in hardware or special software development

• User interface development may be a major part of a software development project

Programming environments provide powerful user interface toolkits

• Costs are multiplied if a user interface has to be used on different computers or migrate to different versions of systems

Web browsers provide a general purpose user interface where

others maintain the user interface software