what is a requirement - PowerPoint PPT Presentation

About This Presentation
Title:

what is a requirement

Description:

remains impartial, with no preconceived ideas. isn't constrained by assumptions or tradition ... paradigm shifts and radical ideas. University of Toronto at ... – PowerPoint PPT presentation

Number of Views:90
Avg rating:3.0/5.0
Slides: 19
Provided by: kerstiwa
Category:

less

Transcript and Presenter's Notes

Title: what is a requirement


1
what is a requirement?
a property or behavior that must be exhibited
in order to solve some problem of the real
world

SWEBOK ch 2
  • requirements must be
  • clearly and formally stated
  • approved and prioritized
  • validated
  • subject to configuration management

2
examples of requirements
  • too vague . . .
  • backorders are permitted
  • the call centre must be more efficient
  • system must have a low probability of failure

why?
  • much better . . .
  • up to 5 backorders can be created from a single
    original order
  • the system must increase the call centres
    throughput by 20
  • probability of failure for any operation is less
    than 110-8

3
classification of requirements
functional emergent property general
requirement product high priority broad scope
(architectural) volatile
VS non-functional VS specific task VS
specific stakeholder need VS process VS
optional VS narrow scope (specific component) VS
stable
some requirements have emergent properties they
depend for their satisfaction on how well the
system components inter-operate
4
what do specifications tell you?
functional What does the system have to do? For
whom? What information is needed? By whom? When
are the functions and data needed? non-functional
What is the structure of the system? What
performance and capacity is needed? control How
does the system react to external events? How
does the system respond to unexpected events or
data? What is the event flow in the system?
The above are answered using text and diagrams.
5
the main challenge is complexity
Where does one system end and another start? If a
system is a view of reality, whos view do we
work with? What if the system is too large to be
understood by any one person? How do we handle
the continuous change in technology? How do we
handle requirements that change? How do we cope
with new development tools, techniques and
methodologies?
our main defense is abstraction and decomposition!
6
abstraction
  • is the main tool used in reasoning about software
    because ...
  • you can ignore inconvenient detail
  • abstraction simplifies the problem (but doesnt
    solve it)

how do you define an abstraction?
  • name and describe the functionality at several
    levels ...
  • by describing the desired outcome
  • by describing the pre-conditions and post
    conditions

source S. Easterbrook CSC444 2001
7
abstraction and decomposition
  • decompose the problem (requirement) so that
  • each subproblem is at (roughly) the same level
    of detail
  • each subproblem can be solved independently
  • the solutions to the subproblems can be combined
  • to solve the original problem
  • why?
  • different people can work on different
    subproblems
  • development and maintenance is easier
  • is decomposition always possible?
  • not for some complex, impossible or trivial
    problems

source S. Easterbrook CSC444 2001
8
decomposition and information hiding
  • 1. identify components
  • minimize dependencies between components,
    striving for . . .
  • low coupling (measure of inter-component
    connectivity)
  • high cohesion (measure of how well the contents
    of a
  • component go together)
  • hide information so that . . .
  • components keep their data private
  • components keep their methods (logic) private
  • 2. model the problem using formal diagrams that
    show . . .
  • flow of data and control between components
  • states of components
  • system architecture

source S. Easterbrook CSC444 2001
9
criteria for modularity
why modularity?
  • decomposability
  • composability
  • understandability
  • continuity
  • protection
  • information hiding
  • weak coupling
  • few interfaces
  • open-closed principle
  • compatible
  • reusable
  • extendible
  • reliable
  • correct
  • robust
  • efficient
  • inexpensive
  • portable
  • timely

10
how to elicit requirements?
analyst
  • the ideal investigator . . .
  • saves all the evidence
  • logs his research
  • can back up his claims with evidence
  • questions everything
  • remains impartial, with no preconceived ideas
  • isnt constrained by assumptions or tradition
  • pays attention to detail
  • is open to new methods and new interpretations

11
inspection and information gathering
  • organization charts
  • business mission and strategy statements
  • interview transcripts
  • observation notes
  • planning session results
  • documentation of old system
  • CASE repository documents
  • prototype models
  • meeting minutes
  • training manuals
  • policies and procedure manuals
  • sample reports, forms
  • consultants reports
  • questionnaire responses
  • etc.

12
what can we learn?
  • facts and figures
  • relevance of facts and figures
  • reasons for ways of doing things
  • ideas for the future
  • constraints
  • allocation of responsibilities
  • problems to avoid or solve
  • directions to take
  • opportunities
  • priorities
  • rules and laws
  • warning watch out for
  • the differences between
  • the formal and informal
  • the official and unofficial

13
methods of elicitation
  • reading, reading, reading
  • interviews
  • observation
  • questionnaires
  • group support systems
  • joint application design
  • prototyping
  • business process re-engineering
  • disruptive technologies / paradigm shift

14
Joint Application Design (JAD)
purpose to discuss and review system
requirements location off site attendees
leader/chairman, users, managers, sponsors,
systems analysts, scribe, advisors as
necessary tools used CASE and planning aids
outcomes designs, functional requirements,
operational plans, solutions to
problems agreement, documentation
15
group support systems (GSS)
Group members type suggestions,
questions everyone can read them and respond
prototyping
? iterative process to improve the systems
design ? provides hands on walkthroughs for
reality checking ? fast response to suggestions ?
ideal for decision support systems and new
business venture systems ? difficult to produce
useful documentation ? shared data and system
interfaces difficult to handle ? some systems
requirements get forgotten ? users want to use
the prototype
16
(No Transcript)
17
requirements validation and control
  • how do you know the requirements are correct?
  • formal documentation
  • prototypes
  • walkthroughs
  • formal approvals
  • prioritization
  • evaluation criteria
  • risk analyses
  • what do you do when requirements change?
  • set up a formal change request
  • estimate the impact on the benefits and the
    costs
  • get formal approval before accepting the change

18
the V model
system requirements
system integration
software requirements
acceptance test
preliminary design
software integration
analyze and design
test and integrate
detailed design
component test
level of abstraction
code and inspect
unit test
time
Write a Comment
User Comments (0)
About PowerShow.com