1 CS 501 Spring 2006 CS 501: Software Engineering Lecture 10 Requirements 4
Dec 19, 2015
1 CS 501 Spring 2006
CS 501: Software Engineering
Lecture 10
Requirements 4
2 CS 501 Spring 2006
Course Administration
Presentations, March 7-9
Read the instructions on the Assignments Web page.
Reserve a time slot by sending email to [email protected]. Time slots are listed on the home page of the Web site. First-come-first-served.
Quiz 3
This quiz may be moved to March 16.
3 CS 501 Spring 2006
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."
4 CS 501 Spring 2006
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? Never interrupt your colleagues.
Not everybody is a great presenter, but everybody can be well-prepared.
5 CS 501 Spring 2006
Formal Specification
Why?
• Precise standard to define and validate software.
Why not?
• May be time consuming
• Methods are not suitable for all applications
6 CS 501 Spring 2006
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.
7 CS 501 Spring 2006
Formal Specification using Mathematical Notation
Mathematical requirements can be specified formally.
Example: requirements from a mathematical package:
B1, B2, ... Bk is a sequence of m x m matrices
1, 2, ... k is a sequence of m x m elementary matrices
B1-1 = 1
B2-1 = 21
Bk-1 = k ... 21
The numerical accuracy must be such that, for all k,
BkBk-1 - I <
8 CS 501 Spring 2006
Formal Specification Using Diagrams
digitunsigned integer
digit. E
+
-
unsigned integerunsigned integer
unsigned number
Example: Pascal number syntax
9 CS 501 Spring 2006
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
10 CS 501 Spring 2006
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
11 CS 501 Spring 2006
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
12 CS 501 Spring 2006
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:
13 CS 501 Spring 2006
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;}
14 CS 501 Spring 2006
Formal Specification of Finite State Machine Using Z
A finite state machine is a broadly used method of formal specification:
• Event driven systems (e.g., games)
• User interfaces
• Protocol specification
etc., etc., ...
15 CS 501 Spring 2006
State Transition Diagram
Patients Fields Setup ReadyBeam
on
Enter Enter Start
Stop
Select field
Select patient(lock on)
(lock off)
16 CS 501 Spring 2006
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
17 CS 501 Spring 2006
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
18 CS 501 Spring 2006
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 }
19 CS 501 Spring 2006
Schemas
Schema:
• The basic unit of formal specification.
• Enables complex system to be specified as subsystems
• Describes admissible states and operations of a system.
20 CS 501 Spring 2006
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.
21 CS 501 Spring 2006
User Interface Design: Requirements and Refinement
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
22 CS 501 Spring 2006
The Design/Evaluate Loop
Evaluate
?Design
Build
Analyze requirements
23 CS 501 Spring 2006
Requirements: Mock-up
24 CS 501 Spring 2006
Methods for Specifying Usability Requirements and Evaluation of Usability
Initial Mock-up Prototype Production
Client's opinions
Competitive analysis
Expert opinion
Focus groups
Observing users
Measurements
25 CS 501 Spring 2006
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
26 CS 501 Spring 2006
Special Considerations: Disabilities
• What if the user:
is visually impaired or color blind?does not speak English?is a poor typist?
• There is a tradition of blind programmers
• Navigation of web sites need not be only visual
You may have a legal requirement to support people with disabilities
27 CS 501 Spring 2006
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
28 CS 501 Spring 2006
Special Considerations: 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
• System designers wish to control clients; users wish to configure their own environments
29 CS 501 Spring 2006
Special Considerations: 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
30 CS 501 Spring 2006
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