IST 412

1
IST 412

• Requirement Engineering

Chapter 7
2
Requirement Engineering

• What are requirements?
• Important the What? Not the how?
• Why are they important?
• When do you know when to stop with analysis and
  begin design?

3
Requirement Engineering

• Extracting what the customer wants
• Writing these requirements into a document that
  serves as a contract between customers and
  developers
• Requirements must be
• Clear
• Complete as if someone else is going to design
  the system
• Verifiable

4
Writing the Software Specification
Everyone knew exactly what had to be done until
someone wrote it down!
5
Requirements Engineering-I

• Inception determine
• Basics of the problem and scope
• who are the users
• communication and collaboration between the
  customer and the developer
• Elicitation
• Elaborationcreate a model that identifies data,
  function, nonfunctional, and behavioral
  requirements
• Negotiationagree on a deliverable system that is
  realistic for developers and customers

6
Requirements Engineering-II

• Specificationcan be any one (or more) of the
  following
• written english specification (what is the
  problem with that?)
• set of models (visual representations, e.g. UML)
• formal mathematical
• A collection of user scenarios (use-cases)
• A prototype (paper or code)
• Validationa review mechanism that looks for
• errors in content or interpretation
• areas where clarification may be required
• missing information
• inconsistencies (a major problem when large
  products or systems are engineered)
• conflicting or unrealistic (unachievable)
  requirements.
• Management, Tracking, and Re-planning

7
Inception

• Identify stakeholders
• who else do you think I should talk to?
• Recognize multiple points of view
• Work toward collaboration
• Questions to ask
• Who is behind the request for this work?
• Who will use the solution?
• What will be the economic benefit of a successful
  solution
• Is there another source for the solution that you
  need?

8
Eliciting Gathering Requirements

• What are the different methods for eliciting or
  gathering requirements?
• What methods are you using for your game and why?

9
Eliciting Req. through meeting

• meetings are conducted and attended by both
  software engineers and customers
• rules for preparation and participation are
  established
• an agenda is suggested
• a "facilitator" (can be a customer, a developer,
  or an outsider) controls the meeting
• a "definition mechanism" (can be work sheets,
  flip charts, or wall stickers or an electronic
  bulletin board, chat room or virtual forum) is
  used
• the goal is
• to identify the problem
• propose elements of the solution
• negotiate different approaches, and
• specify a preliminary set of solution
  requirements

10
Elicitation Work Products

• a statement of need and feasibility.
• a scope for the system or product.
• a list of users
• a description of the systems technical
  environment constraints
• a list of
• functional
• nonfunctional requirements
• (what are these?)
• a set of usage scenarios
• any prototypes developed to better define
  requirements.

11
Nonfunctional Requirements
12
Use-Cases

• user scenarios describing a usage thread
• Each scenario is described from the point-of-view
  of an actor what is an actor?
• Each scenario answers the following questions
• Who is the primary actor, the secondary actor
  (s)?
• What are the actors goals?
• What preconditions should exist before the story
  begins?
• What main tasks or functions are performed by the
  actor?
• What system information will the actor acquire,
  produce, or change?
• What feedback will the actor require?
• Does the actor wish to be informed about
  unexpected changes?
• What variations in the actors interaction are
  possible?

13
Use-Case Diagram
14
Building the Analysis Model

• Elements of the analysis model
• Data-based elements
• Scenario-based elements
• Class-based elements
• Behavioral elements
• State diagram
• Flow-oriented elements
• Data flow diagram
• These will form your specification document

15
Requirements Document

• Introduction (inception and elicitation)
• Problem definition
• Problem scope
• Software Environment and constraints
• Description of the users
• Nonfunctional Requirements (elicitation
  elaboration)
• Functional Requirements (specification)
• Data-based model
• Scenario-based model
• Class-based model
• Behavioral model
• Interface Specification (specification)
• UI
• API
• Key interface classes

16
IST 412

• Analysis Modeling

Chapter 8
17
A Bridge
18
Rules of Thumb

• High abstraction
• Delay consideration of infrastructure and detail
  description of the how until design.
• Keep the model as simple as it can be.

19
Data (Entity) Modeling

• examines data objects independently of processing
• focuses attention on the data domain
• creates a model at the customers level of
  abstraction
• indicates how data objects relate to one another

20
What is a Data Object (entity)?
Object
something that is described by a set
of attributes (data items) and that will be
manipulated within the software (system)
each
instance
of an object (e.g., a book)
can be identified uniquely (e.g., ISBN )

each plays a necessary role in the system
i.e., the system could not function without
access to instances of the object
each is described by attributes that are

themselves data items
21
Data Objects (entities)
A data object (entity) contains a set of
attributes that act as an aspect, quality,
characteristic, or descriptor of the object
object automobile attributes make model
body type price options code
22
Entity Relationship Notation
One common form
1
object
object
relationship
1
2
M
attribute
23
The ER Diagram An Example
request for service
Customer
places
1
M
1
standard task table
N
work order
generates
1
1
1
N
work tasks
selected from
consists of
N
N
materials
lists
24
Scenario-Based Modeling
Use-cases are simply an aid to defining what
exists outside the system (actors) and what
should be performed by the system (use-cases).
Ivar Jacobson
25
Use-Cases

• a scenario that describes a thread of usage for
  a system
• actors represent roles people or devices play as
  the system functions
• users can play a number of different roles for a
  given scenario

26
Use-Case Diagram
27
Activity Diagram
Supplements the use-case by providing a
diagrammatic representation of procedural flow
28
Flow-Oriented Modeling
Represents how data objects are transformed at
they move through the system A data flow diagram
(DFD) is the diagrammatic form that is
used Considered by many to be an old school
approach, flow-oriented modeling continues to
provide a view of the system that is uniqueit
should be used to supplement other analysis model
elements
29
The Flow Model
Every computer-based system is an information
transform ....
computer based system
input
output
30
Flow Modeling Notation
external entity
process
data flow
data store
31
Level 0 DFD Example
processing request
user
requested video signal
digital video processor
monitor
video source
NTSC video signal
32
The Data Flow Hierarchy
a
b
P
x
y
level 0
c
p2
a
f
p1
b
p4
d
5
g
p3
e
level 1
33
Flow Modeling Notes

• each bubble is refined until it does just one
  thing
• the expansion ratio decreases as the number of
  levels increase
• most systems require between 3 and 7 levels for
  an adequate flow model
• a single data flow item (arrow) may be expanded
  as levels increase (data dictionary provides
  information)

34
Class-Based Modeling

• Identify analysis classes by examining the
  problem statement use cases
• Use a grammatical parse to isolate potential
  classes
• Identify the attributes of each class
• Identify operations that manipulate the attributes

35
Class Diagram
Class name
attributes
operations
36
Class Diagram
37
CRC (class-Responsibility- Collaborator) Modeling

• Analysis classes have responsibilities
• Responsibilities are the attributes and
  operations encapsulated by the class
• Analysis classes collaborate with one another
• Collaborators are those classes that are
  required to provide a class with the information
  needed to complete a responsibility.
• In general, a collaboration implies either a
  request for information or a request for some
  action.

38
CRC Modeling
Why is this important from a design and coding
point of view?
39
Class Types

• Entity classes
• Boundary classes are used to create the interface
  (e.g., interactive screen or printed reports)
• Controller classes manage a unit of work
  UML03 from start to finish. That is, controller
  classes can be designed to manage
• the creation or update of entity objects
• the instantiation of boundary objects as they
  obtain information from entity objects
• complex communication between sets of objects
• validation of data communicated between objects
  or between the user and the application.

40
Collaborations

• three different generic relationships between
  classes WIR90
• the is-part-of relationship
• the has-knowledge-of relationship
• the depends-upon relationship

41
Associations and Dependencies

• Two analysis classes are often related to one
  another in some fashion
• Associations can be refined by indicating
  multiplicity (the term cardinality is used in
  data modeling
• In many instances, a client-server relationship
  dependency relationship

42
Behavioral Modeling

• The behavioral model indicates how software will
  respond to external events or stimuli. To create
  the model, the analyst must perform the following
  steps
• Evaluate all use-cases to fully understand the
  sequence of interaction within the system.
• Identify events that drive the interaction
  sequence and understand how these events relate
  to specific objects.
• Create a sequence for each use-case.
• Build a state diagram for the system.
• Review the behavioral model to verify accuracy
  and consistency.

43
The States of a System

• statea set of observable circum-stances that
  characterizes the behavior of a system at a given
  time
• state transitionthe movement from one state to
  another
• eventan occurrence that causes the system to
  exhibit some predictable form of behavior
• actionprocess that occurs as a consequence of
  making a transition

44
State Diagram Example
45
Sequence Diagram
46
Specification Guidelines
47
Specification Guidelines
48
Specification Guidelines
49
Requirements Document

• Introduction (inception and elicitation)
• Problem definition
• Problem scope
• Software Environment and constraints
• Description of the users
• Nonfunctional Requirements (elicitation
  elaboration)
• Functional Requirements (specification)
• Data-based model
• Scenario-based model
• Class-based model
• Behavioral model
• Interface Specification (specification)
• UI
• API
• Key interface classes