Documente Academic
Documente Profesional
Documente Cultură
Slide 1
Objectives
Slide 2
Topics covered
Slide 3
Requirements engineering
Slide 4
What is a requirement?
Slide 5
If a comp any wishes to let a cont ract for a large software deve lopment project, it
must define its need s in a sufficien tly abstract way that a solution is not pre-defined.
The requirements must be written so that several contractors can b id for the con tract,
offering, perhaps, different ways of meeting the client organi sations need s. Once a
contract has been a warded, the contractor must write a system definition for the client
in more detail so that the client und erstands and can validate what the software will
do. Both of these docu ments may be called the requirements document for the
system.
Slide 6
Types of requirement
User requirements
System requirements
Slide 7
Slide 8
Requirements readers
Slide 9
Functional requirements
Non-functional requirements
Domain requirements
Slide 10
Functional requirements
Slide 11
Slide 12
Slide 13
Requirements imprecision
Slide 14
Slide 15
Non-functional requirements
Slide 16
Non-functional classifications
Product requirements
Organisational requirements
External requirements
Slide 17
Product
requir ements
Efficiency
requir ements
Relia bility
requir ements
Usa bility
requir ements
Performance
requir ements
Organisational
requir ements
Porta bility
requir ements
Deli very
requir ements
External
requir ements
Implementa tion
requir ements
Ethical
requir ements
Standar ds
requir ements
Space
requir ements
Pri vacy
requir ements
Leg islative
requir ements
Safety
requir ements
Slide 18
Product requirement
8.1 The user interface for LIBSYS shall be implemented as simple HTML
without frames or Java applets.
Organisational requirement
9.3.2 The system development process and deliverable documents shall
conform to the process and deliverables defined in XYZCo-SPSTAN-95.
External requirement
7.6.5 The system shall not disclose any personal information about
customers apart from their name and reference number to the
operators of the system.
Slide 19
Slide 20
Examples
A system goal
Slide 21
Requirements measures
Property
Measure
Speed
Processed transactions/second
User/Event response time
Screen refresh time
Size
M Bytes
Number of ROM chips
Ease of use
Training time
Number of help frames
Reliability
Robustness
Portability
Slide 22
Requirements interaction
Slide 23
Domain requirements
Slide 24
Slide 25
Slide 26
Understandability
Implicitness
Slide 27
User requirements
Slide 28
Lack of clarity
Requirements confusion
Requirements amalgamation
Slide 29
LIBSYS requirement
Slide 30
Slide 31
Requirement problems
Slide 32
Structured presentation
Slide 33
Slide 34
System requirements
Slide 35
Slide 36
Ambiguity
Over-flexibility
Lack of modularisation
Slide 37
Alternatives to NL specification
Notation
Description
Structured natural
language
This approach depends on defining standard forms or templates to exp ress the
requirements specification.
Design
description
language s
This approach uses a language like a programming langu age but with more ab stract
features to specify the requ irements by defining an op erational model of the system.
This approach is not now widely used although it can be useful for interface
specifications.
Graphical
notations
A graph ical languag e, supplemented by text anno tations is used to define the
functional requirements for the system. An early exa mple of such a graphical
language was SADT. Now, use-case descriptions and sequence d iagrams are
commonly used .
Mathematical
specifications
Slide 38
Slide 39
Form-based specifications
Slide 40
Action: CompDose is zero if the sugar level is stable or fa lling or if the level is increasing but the rate of
increase is decreasing. If the level is increasing and the rate of increase is increasing, then CompDose is
computed by dividing the diff erence between the current sugar level and the previous level by 4 and
rounding the result. If the result, is rounded to zero then CompDose is set to the minimum dose that can
be delivered.
Requires
Two previous readings so that the rate of change of sugar level can be computed.
Pre-condition
The insulin reservoir contains at least the maximum allowed single dose of insulin..
Post-condition
Side-effects
None
Slide 41
Tabular specification
Slide 42
Tabular specification
Condition
Action
CompDose = 0
CompDose = 0
CompDose = 0
Slide 43
Graphical models
Slide 44
Sequence diagrams
Validate card;
Handle request;
Complete transaction.
Slide 45
Database
Card number
Card OK
PIN
Validate card
Option menu
<<exception>>
invalid card
Withdraw request
Amount request
Balance request
Balance
Handle request
Amount
Debit (amount)
<<exception>>
insufficient cash
Debit response
Card
Card removed
Cash
Complete
transaction
Cash removed
Receipt
Slide 46
Interface specification
Procedural interfaces;
Data structures that are exchanged;
Data representations.
Slide 47
Slide 48
Slide 49
Slide 50
Introduction.
General description.
Specific requirements.
Appendices.
Index.
Slide 51
Preface
Introduction
Glossary
User requirements definition
System architecture
System requirements specification
System models
System evolution
Appendices
Index
Slide 52
Key points
Slide 53
Key points
Slide 54